Currently, the HTTP Proxy does not take the encoding for the request it parses into consideration. It just does a "postData = line.toString()", which uses the default JRE encoding. I suggest that the HTTP Proxy should keep track of the encoding of the pages and forms that it sees, and then use that encoding when decoding request to pages or forms, and set the content encoding on the sampler it creates. When the HTTP Proxy knows about the encoding, it can also decode parameter values which has been URL encoded by the browser, for example in HTTP GET and in HTTP Post application/x-www-form-urlencoded requests.
Created attachment 20003 [details] Suggested patch This suggested patch adds two maps to the proxy Deamon class, so that the proxy server can keep the page and form encodings it finds in a request, so it can be used in requests the proxy will see in the future. The access to these two maps are synchronized, since the deamon kicks off a Proxy on a separate thread for each incoming request. The patch makes the HttpRequestHdr uses the encoding for the request / page / form, and then decodes the request body using that encoding, and then adds parameters undecoded where appriopriate to the sampler.
Tried applying the patch, and it causes serveral NPEs and some other test failures...
(In reply to comment #2) > Tried applying the patch, and it causes serveral NPEs and some other test > failures... Thanks for the comments. I will look into improving this patch. And I will try to convince myself that this patch is really needed, I am currently a bit skeptical if the functionality we gain is worth the extra complexity of the code.
Created attachment 20160 [details] Updated suggested patch Patch is now updated, fixed a couple of bugs, which caused unit tests to fail. The patch is needed to support posting of forms with encoding UTF-8, when entering UTF-8 characters. Without this patch, you see only garbage in the test plan, and the data recieved from browser is then sent garbled from proxy to web server. The patch is nice to have, in that you get the values unencoded into the test plan, so it is easier to read for the test plan user.
Thanks - added to SVN in r552959/r552960
This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/1915