You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Alf Hogemark (Bug 42098):
Currently, the HTTP Samplers always url encode the parameter values using the
UTF-8 encoding when a HTTP GET request is made. This is according to the HTTP
specification.
But most, if not all browsers, do not follow the specification when urlencoding
for HTTP GET request. Most browsers use the encoding of the page where the form
was present, or uses the value of the "accept-charset" attribute for the <form>
html tag.
Since the HTTP Request GUI currently has a field "Content encoding", which is
used in HTTP POST request to encode the URL for HTTP Post according to the
specified encoding, I would like to suggest the same functionality for HTTP GET.
This means that if the user has filled in a value in "Content encoding", and is
doing a HTTP GET, then the specified encoding will be used to encode the
parameter values, if encoding checkbox is on. Only the parameter value will be
encoded with this encoding, the parameter name will always be encoded using UTF-8.
If the user has not specified a value for "Content encoding", then "UTF-8" will
be used, which is like it is today.
I think this patch makes it possible to let Jmeter behave more like other browsers.
OS: All
The text was updated successfully, but these errors were encountered:
Alf Hogemark (migrated from Bugzilla):
The suggested patch lets the HTTPSamplerBase construct the query string by
encoding parameter values according to the specified encoding.
This also means that the PostWriter can use this
getQueryString(contentEncoding) method, instead of having it's own version of
the method.
I have also added unit tests to TestHTTPSamplersAgainstHttpMirrorServer. If you
only apply the unit test, then the test from line 353 will fail.
I.e. where the values are set like this :
titleValue = "mytitle\uc385";
descriptionValue = "mydescription\uc385";
Because these values look different when url encoded in utf-8 and iso-8859-1.
This patch will also make it easier to add functionality to the HTTP Proxy
server.
Created attachment patch_for_42098.patch: Suggested patch for encoding HTTP GET urls
Alf Hogemark (Bug 42098):
Currently, the HTTP Samplers always url encode the parameter values using the
UTF-8 encoding when a HTTP GET request is made. This is according to the HTTP
specification.
But most, if not all browsers, do not follow the specification when urlencoding
for HTTP GET request. Most browsers use the encoding of the page where the form
was present, or uses the value of the "accept-charset" attribute for the <form>
html tag.
Since the HTTP Request GUI currently has a field "Content encoding", which is
used in HTTP POST request to encode the URL for HTTP Post according to the
specified encoding, I would like to suggest the same functionality for HTTP GET.
This means that if the user has filled in a value in "Content encoding", and is
doing a HTTP GET, then the specified encoding will be used to encode the
parameter values, if encoding checkbox is on. Only the parameter value will be
encoded with this encoding, the parameter name will always be encoded using UTF-8.
If the user has not specified a value for "Content encoding", then "UTF-8" will
be used, which is like it is today.
I think this patch makes it possible to let Jmeter behave more like other browsers.
OS: All
The text was updated successfully, but these errors were encountered: