I am a newbie to jmeter, i just started recording the scripts, when i try to record it through proxy server which is available in jmeter, I would see a message on the view of site saying -
java.net.URISyntaxException: Illegal character in query at index 121: https://xxx.xxx.com/xyz/RELEASE99/" at java.net.URI$Parser.fail(Unknown Source) at java.net.URI$Parser.checkChars(Unknown Source) at java.net.URI$Parser.parseHierarchical(Unknown Source) at java.net.URI$Parser.parse(Unknown Source) at java.net.URI.(Unknown Source) at java.net.URL.toURI(Unknown Source) at org.apache.jmeter.protocol.http.sampler.HTTPHC4Imp l.sample(HTTPHC4Impl.java:234) at org.apache.jmeter.protocol.http.sampler.HTTPSample rProxy.sample(HTTPSamplerProxy.java:62) at org.apache.jmeter.protocol.http.sampler.HTTPSample rBase.sample(HTTPSamplerBase.java:1088) at org.apache.jmeter.protocol.http.proxy.Proxy.run(Proxy.java:211)
It would be thankful if some one could help me out with a possible solutions on it.
Thanks, Revanth
It looks like that you have a non-ASCII character at position 121. Could you please check the following:
Search for something like jmeter.JMeter: file.encoding= in jmeter.log file. It usually lives under /bin folder of your JMeter installation. It should be "UTF-8". If it's not the case - relaunch JMeter with -Dfile.encoding=UTF-8 option as
jmeter.bat -Dfile.encoding=UTF-8
Check your HTTP Request Defaults config element. If it's not there - add it and set Content encoding stanza to be "UTF-8" (without quotes)
Check problematic HTTP request "Send Parameters with the request" section. If you're passing parameters directly in URL it's better to transfer them to "Send Parameters With the Request". If there is any non-ASCII stuff make sure that the relevant "Encode?" box is checked.
It seems there is something wrong in your URL? I assume you made the xxx.xxx? As the mentioned index (121) suggests a much longer URL string.
You might start with a 'trusted' URL, like a search engine, so you can check that your jmeter proxy works ok, to be sure.
There were multiple checkpoints which i have actually run through, prime of them were
1. Choosing the right HTTP protocol from HTTP(S) script recorder
2. as #dmitri and #ray said, both the options were true
3. In addition to above scenarios, i have got a valid signed certificate for the test environment i was trying to and was able to proceed further
Related
My results tree shows a separate status for a URL connection I have absolutely no idea where it might come from:
The first result with the -0 at the end is that of the request I send willingly. The other connection with the -1 comes out of the void.
In the response body I can see that JMeter fails while trying to resolve the DNS name:
java.net.UnknownHostException: aida.xyz.removed
at java.base/java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
at java.base/java.net.InetAddress$PlatformNameService.lookupAllHostAddr(Unknown Source)
This is my definition of the HTTP Request:
As you can see this goes to a totally different host and protocol (http instead of https).
I checked the defined csv, it does not contain the hostname "aid". Same goes for the JMX file and any environment variables set.
I am using Apache JMeter 5.0
After I read Ubiks answer I checked if there are any redirects in the first request. There are no redirects but in the content there are several script and img resources.
It looks like JMeter parses the first request for resources it has to download. But I didn't enable this setting / don't even know where to activate this.
I guess it’s either a redirect issued from response to the first request or because JMeter tries to download embedded resources.
Check the response of first request.
If the reason is that JMeter downloads (probably missing) resources, make sure you disable Retrieve All Embedded Resources in the Advanced tab.
The error you're getting indicates the problem with the system under test, JMeter cannot resolve an embedded resource - image, script, style, font, iframe, whatever.
You need to raise an issue as not available content is not good i.e. for SEO purposes, moreover it might be essential for your application functionality of LAF
If this is a known issue which is in process of fixing (or considered as won't fix) you can turn JMeter's check for embedded resources presence by adding the next line to user.properties file:
httpsampler.ignore_failed_embedded_resources=true
JMeter restart will be required to pick the property up.
More information:
JMeter Properties Reference
Configuring JMeter
Apache JMeter Properties Customization Guide
I have attached the screenshots of Http Request and CSV Data config. Please check and let me know where i am making mistake
I got the below response when i run this script
java.net.URISyntaxException: Illegal character in fragment at index 89: http://letsbac.colanonline.net/#/login?inputUsername=msinghzx4&inputPassword=A12345b&Sign In=submit
at java.net.URI$Parser.fail(Unknown Source)
at java.net.URI$Parser.checkChars(Unknown Source)
at java.net.URI$Parser.parse(Unknown Source)
at java.net.URI.<init>(Unknown Source)
at java.net.URL.toURI(Unknown Source)
at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:399)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1189)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1178)
at org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:490)
at org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:416)
at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:250)
at java.lang.Thread.run(Unknown Source)
You need to tick Encode box where Sign In parameter is or change your Sign In to Sign%20In as special character in URLs need to be Encoded
I doubt that you use correct method, my expectation is that you should use POST in Method dropdown
The easiest way to build a proper request is recording it using HTTP(S) Test Script Recorder as your test plan doesn't look very realistic to me as my expectation is that the real user would rather open login page first and then perform the login. i.e. at least 2 requests while you have only 1
According to JMeter Best Practices you should always be using the latest version of JMeter so consider upgrading to JMeter 5.0 on next available opportunity
I requested a web page using Jmeter with "Retrieve all embedded resources" enabled. When I ran the scenario, some URLs' of pictures did not open with the error "Bad Request". When I compared the working URL and URL that Jmeter checks, I realized that / is missing on the URL that Jmeter checks.
Screenshot
Screenshot2
What should I do to fix this?
It looks like a bug in JMeter.
You should submit a bug following this doc:
http://jmeter.apache.org/issues.html
Ensure you attach:
- the HTML page content that contains the links
- The jmeter.log
- A sample test plan
I tried the same with the version 2.13. No problem, which means that version 3.3 is buggy in terms of this issue.
I'm trying to record my interactions with a SAAS website using JMeter 2.12. I get the following error trace as soon as I try to login:
java.util.zip.ZipException: Not in GZIP format
at java.util.zip.GZIPInputStream.readHeader(Unknown Source)
at java.util.zip.GZIPInputStream.(Unknown Source)
at java.util.zip.GZIPInputStream.(Unknown Source)
at org.apache.http.client.entity.GzipDecompressingEntity.decorate(GzipDecompressingEntity.java:56)
at org.apache.http.client.entity.DecompressingEntity.getDecompressingStream(DecompressingEntity.java:68)
at org.apache.http.client.entity.DecompressingEntity.getContent(DecompressingEntity.java:82)
at org.apache.http.client.entity.GzipDecompressingEntity.getContent(GzipDecompressingEntity.java:41)
at org.apache.http.conn.BasicManagedEntity.getContent(BasicManagedEntity.java:89)
at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:348)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1141)
at org.apache.jmeter.protocol.http.proxy.Proxy.run(Proxy.java:236)
Blockquote
I searched for the solution and found one in BugZilla: Bug 51918 where it says to turn off the concurrent download. I tried that by unchecking the "Retrieve All Embedded Resources" option in the 'HTTP Requests Defaults'- but still getting the error and cannot proceed.
Can anyone please help? Thanks a lot!
--Ishti
Ok, I think I got an answer. Thanks to Bhargav in his post where he basically told to change the 'HTTP sampler settings' (in the HTTP test script recorder) to 'Java'. I tried that and it's not giving me the error anymore. I can proceed. Thanks!
I got into this problem in JMETER this week. The solution that worked for me in current version is.
In the header manager add:
Accept-Encoding: gzip;q=0,deflate,sdch
The server will send you a response that JMETER can handle.
I got this error on a Web application (Genexus WebApp) when it sent me an HTTP 403 error code with invalid encoding.
So to troubleshoot the problem I use two approaches:
First, turn on the log level to DEBUG, and enable the Log Viewer:
With this we can see the current payload in the Viewer:
Another alternative is to set the accept-encoding to identity, to receive the payload uncompressed.
So after that, I figured out the problem was my request (invalid params)
I attempted to record a file upload in JMeter, using port 8888, but the file failed to upload when using JMeter as the proxy ( Recording Controller and HTTP(S) Test Script Recorder ). I also tried to run this from within JMeter by choosing "Start" and viewing what I had just recorded in the View Results Tree listener. When I ran it this way, I received a 500 error for the file upload line in the View Results Tree listener.
So, I ran Charles network proxy while doing the file upload to see if the same thing happened. It did not. I was able to successfully upload the file going through the Charles network proxy on the same port 8888.
Furthermore, I took out all proxies and did the file upload successfully.
Only when I use JMeter as the proxy do I have a problem uploading the file.
In JMeter, after first running it with no changes, I then tried to change many settings like Implementation, Content Encoding, Browser-campatible headers, Retrieve All Embedded Resources, and many others to see if this would help, but it did not.
So, my gut tells me that there is a setting that is set incorrectly.
I found this post that talks about changing to use "Java" in the HTTP Request Defaults. ( Unable to upload image/file when using Jmeter HTTP Proxy server ) This did not help me though when I tried that.
I found this post also which mentions some other types of things ( Unable to record an upload file scenario in JMeter though it is possible by manual effort with specific browser settings ) . I did check the headers against Charles and they look the same.
Any ideas?
============= Edit below is adding the test plan screen shot===============
During recording you need to put the file you want to upload in jmeter/bin folder.
This is due to some limitations of browsers which do not transmit the full path.
So, apparently, I had to remove the parameters from the "Path" line and move them to the "Send Parameters With the Request:" for the line that I had the 500 error on ( the highlighted line in the screen shot I had attached above ).
In summary, here is what happened. When I recorded the file upload with JMeter using the Recording Controller and HTTP(S) Test Script Recorder, JMeter had put all of the parameters in the "Path" field for me on many of the lines that JMeter had recorded for me. I did not even think twice about what JMeter had done automatically for me. So, after I removed all text except "/" in the "Path" field and added each parameter one at a time under "Send Parameters With the request", I received a "200" status code on the line that had given me the problem. I also went into all other lines and made these same changes for the parameters. I still am not sure if the file upload is actually working, but I don't care about that right now since I did get a "200" on the line that was giving me a problem. That is enough progress to keep me moving ahead... :-).