Bug 60120 - JMeter 3.0 HTTP Request POST parameters are silently encoded
Summary: JMeter 3.0 HTTP Request POST parameters are silently encoded
Status: REOPENED
Alias: None
Product: JMeter
Classification: Unclassified
Component: HTTP (show other bugs)
Version: 3.0
Hardware: PC All
: P2 normal (vote)
Target Milestone: ---
Assignee: JMeter issues mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-09-12 14:46 UTC by Stuart Barlow
Modified: 2018-06-25 10:34 UTC (History)
1 user (show)



Attachments
Simple test plan with HTTP POST Request (5.65 KB, application/xml)
2016-09-12 14:46 UTC, Stuart Barlow
Details
Test Plan with POST (8.67 KB, application/xml)
2016-09-17 13:18 UTC, Stuart Barlow
Details
Workaround (127.50 KB, image/png)
2016-09-17 13:50 UTC, Philippe Mouawad
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stuart Barlow 2016-09-12 14:46:26 UTC
Created attachment 34238 [details]
Simple test plan with HTTP POST Request

A HTTP Request configured to POST a parameter containing the @ symbol sees that parameter silently encoded. The @ symbol is incorrectly encoded as %40. This occurs whether I tick the 'Encode?' check box or not. 

To demonstrate the issue I have attached a simple .jmx that should be executed against the following HTML. 

<html><body>
<img alt="Captcha" class="captcha-image" width="100" height="50"
             src="/IqGo6EM1JEVZ+MSRJqUSo@qhjVMSFBTs/37/0/1">
</img>
<input type="hidden" name="captchaCapiId" value="IqGo6EM1JEVZ+MSRJqUSo@qhjVMSFBTs">
</body></html>
Comment 1 Philippe Mouawad 2016-09-17 13:03:09 UTC
Hi Stuart,
The attached test plan does not have a POST method.
Can you provide the correct one ?
Thank you
Comment 2 Stuart Barlow 2016-09-17 13:18:52 UTC
Created attachment 34259 [details]
Test Plan with POST
Comment 3 Stuart Barlow 2016-09-17 13:20:44 UTC
Sorry. I attached the wrong .jmx
The correct one has been attached now.
Comment 4 Philippe Mouawad 2016-09-17 13:50:35 UTC
Created attachment 34260 [details]
Workaround

Hello,
Your issue is due to the fact that we use UrlEncodedFormEntity class from HTTPClient when posting a form.

I'll investigate if it's a bug or not.
Meanwhile attached a way to workaround your problem.
Regards
Comment 5 Stuart Barlow 2016-09-20 10:43:52 UTC
The workaround worked. Thanks.

Personally I think it is a bug. I'd expect the Encode? checkbox to alter the paramter. At the moment it appears from a user perspective to have no affect.
Comment 6 Philippe Mouawad 2016-09-24 08:53:09 UTC
(In reply to Stuart Barlow from comment #5)
> The workaround worked. Thanks.
> 
> Personally I think it is a bug. I'd expect the Encode? checkbox to alter the
> paramter. At the moment it appears from a user perspective to have no affect.

Hi Stuart,
If you feel it's a bug, then can you joint httpclient-users@hc.apache.org and participate to discussion "UrlEncodedFormEntity and parameter value encoding"

Thank you
Regards
Comment 7 Philippe Mouawad 2016-09-27 09:01:39 UTC
(In reply to Stuart Barlow from comment #5)
> The workaround worked. Thanks.
> 
> Personally I think it is a bug. I'd expect the Encode? checkbox to alter the
> paramter. At the moment it appears from a user perspective to have no affect.

Hi Stuart,
In fact maybe you should check that the bug is not in your server stack.
Encoding of @ should not break your code.
Frankly the RFC is not very clear on that side so it's hard to tell if encoding should be done or not.
Anyway JAva encodes it so I think it's not a bug.

I am closing issue as WORKSFORME. Feel free to reopen if you find a reference telling it should not be.
And I am of course interested if it ends up to be a bug in your server stack.
Regards
Comment 8 Stuart Barlow 2016-09-27 10:34:48 UTC
Hi Philippe

I'm not sure a Wikipedia page can be used definitively but I found this
https://en.wikipedia.org/wiki/Percent-encoding#Percent-encoding_reserved_characters

"When a character from the reserved set (a "reserved character") has special meaning (a "reserved purpose") in a certain context, and a URI scheme says that it is necessary to use that character for some other purpose, then the character must be percent-encoded."

I think the RFCs leave it open and optional. It depends on the context. Likewise it should probably be optional for JMeter users too. 

Thanks for looking into it and I see you've put effort in but I would still disagree. I feel JMeter is defective. From the users' perspective, whether they click the 'encode?' checkbox or not should influence whether that parameter is percent-encoded or not. At the moment @ is encoded whether the check box is clicked or not. The user isn't aware or concerned what underlying API is used. Just because Java does it, doesn't mean it is right :)

Regards
Comment 9 Stuart Barlow 2018-06-25 10:34:27 UTC
Hi Philippe,

Just revisiting this ticket after a lengthy pause. 

In the example I provided, the POST parameter value contains jumble of letters, digits and special characters. I'm not sure it is up to the application to decode. If this value was for example, a password and just happened to contain the sequence of characters %40 (or any other sequence that looks like an encoded character), if the application were to decode the value, the original value would be lost. The passwords would not match.

We can agree that the specs are not clear, at least I haven't found a clear definition, but at the same time from the end-user's perspective, when using JMeter, if they see a check box that gives them the option to encode a parameter or not, they would expect toggling that check box to affect the behaviour. They would still expect JMeter to encode or not to encode. 

What do you think?