Re: UrlEncodedFormEntity and parameter value encoding

[Oleg Kalnichevski]

On Sat, 2016-09-24 at 10:50 +0200, Philippe Mouawad wrote:
> Hi Oleg,
> If you look at :
> https://bz.apache.org/bugzilla/show_bug.cgi?id=60120
> You can see that this encoding can break some applications.
> 
> If I read https://en.wikipedia.org/wiki/Percent-encoding#The_
> application.2Fx-www-form-urlencoded_type
> 
> 
> Which references https://tools.ietf.org/html/rfc1630
> I understand @ is safe.
> 

Maybe, but Oracle seems to disagree.

System.out.println(URLEncoder.encode("@", "US-ASCII"));

> %40

Oleg 



-
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org

Re: UrlEncodedFormEntity and parameter value encoding

[Philippe Mouawad]

Hi Oleg,
If you look at :
https://bz.apache.org/bugzilla/show_bug.cgi?id=60120
You can see that this encoding can break some applications.

If I read https://en.wikipedia.org/wiki/Percent-encoding#The_
application.2Fx-www-form-urlencoded_type


Which references https://tools.ietf.org/html/rfc1630
I understand @ is safe.

Regards



On Sun, Sep 18, 2016 at 5:04 PM, Oleg Kalnichevski  wrote:

> On Sun, 2016-09-18 at 16:27 +0200, Philippe Mouawad wrote:
> > On Sunday, September 18, 2016, Oleg Kalnichevski 
> wrote:
> >
> > > On Sun, 2016-09-18 at 16:12 +0200, Philippe Mouawad wrote:
> > > > So is it a bug ? or a regular behaviour ?
> > > >
> > >
> > > We back to where we started. Why do you think it should not be encoded?
> >
> > it does not seem to be when using browser.
> > It should if it's in url but I am not sure it is reserved when located in
> > form parameter.
> > I don't fully understand the rfc documentation.
> >
>
> I can be easily wrong here but I am not aware of any RFC that defines
> composition of application/x-www-form-urlencoded content.
>
> As far as I know HttpClient presently emulates the behavior of
> java.net.URLEncoder. It also seems safer to me to rather encode too much
> and to encode too little.
>
> Oleg
>
> > Regards
> >
> > >
> > > Oleg
> > >
> > > > thanks
> > > >
> > > > On Sunday, September 18, 2016, Oleg Kalnichevski  > > > wrote:
> > > >
> > > > > On Sun, 2016-09-18 at 15:11 +0200, Philippe Mouawad wrote:
> > > > > > Hi Oleg,
> > > > > > Thanks for rapid answer.
> > > > > > Correct me if I am wrong but:
> > > > > > - URLENCODER is built from an or on UNRESERVED (which contains
> '_',
> > > '-',
> > > > > > '.', '*' and a-z, A-Z, 0-9.
> > > > > >
> > > > > > URLENCODER is passed as safechars in
> > > > > > private static String urlEncode(
> > > > > > final String content,
> > > > > > final Charset charset,
> > > > > > final BitSet safechars,
> > > > > > final boolean blankAsPlus)
> > > > > >
> > > > > >
> > > > > > @ is not part of the chars, so you end up in this part of
> algorithms
> > > > > right
> > > > > > ?:
> > > > > > } else {
> > > > > > buf.append("%");
> > > > > > final char hex1 =
> > > > > > Character.toUpperCase(Character.forDigit((b >> 4) & 0xF,
> RADIX));
> > > > > > final char hex2 =
> > > > > > Character.toUpperCase(Character.forDigit(b & 0xF, RADIX));
> > > > > > buf.append(hex1);
> > > > > > buf.append(hex2);
> > > > > > }
> > > > > >
> > > > > > And thus it gets URL encoded no ?
> > > > > >
> > > > >
> > > > > Yes, I was mistaken. Sorry about that.
> > > > >
> > > > > Oleg
> > > > >
> > > > >
> > > > >
> > > > > 
> -
> > > > > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> > > 
> > > > > 
> > > > > For additional commands, e-mail: httpclient-users-help@hc.
> apache.org
> > > 
> > > > > 
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> > > 
> > > For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> > > 
> > >
> > >
> >
>
>
>
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
>
>


-- 
Cordialement.
Philippe Mouawad.

Re: UrlEncodedFormEntity and parameter value encoding

[Oleg Kalnichevski]

On Sun, 2016-09-18 at 16:27 +0200, Philippe Mouawad wrote:
> On Sunday, September 18, 2016, Oleg Kalnichevski  wrote:
> 
> > On Sun, 2016-09-18 at 16:12 +0200, Philippe Mouawad wrote:
> > > So is it a bug ? or a regular behaviour ?
> > >
> >
> > We back to where we started. Why do you think it should not be encoded?
> 
> it does not seem to be when using browser.
> It should if it's in url but I am not sure it is reserved when located in
> form parameter.
> I don't fully understand the rfc documentation.
> 

I can be easily wrong here but I am not aware of any RFC that defines
composition of application/x-www-form-urlencoded content. 

As far as I know HttpClient presently emulates the behavior of
java.net.URLEncoder. It also seems safer to me to rather encode too much
and to encode too little.

Oleg  

> Regards
> 
> >
> > Oleg
> >
> > > thanks
> > >
> > > On Sunday, September 18, 2016, Oleg Kalnichevski  > > wrote:
> > >
> > > > On Sun, 2016-09-18 at 15:11 +0200, Philippe Mouawad wrote:
> > > > > Hi Oleg,
> > > > > Thanks for rapid answer.
> > > > > Correct me if I am wrong but:
> > > > > - URLENCODER is built from an or on UNRESERVED (which contains '_',
> > '-',
> > > > > '.', '*' and a-z, A-Z, 0-9.
> > > > >
> > > > > URLENCODER is passed as safechars in
> > > > > private static String urlEncode(
> > > > > final String content,
> > > > > final Charset charset,
> > > > > final BitSet safechars,
> > > > > final boolean blankAsPlus)
> > > > >
> > > > >
> > > > > @ is not part of the chars, so you end up in this part of algorithms
> > > > right
> > > > > ?:
> > > > > } else {
> > > > > buf.append("%");
> > > > > final char hex1 =
> > > > > Character.toUpperCase(Character.forDigit((b >> 4) & 0xF, RADIX));
> > > > > final char hex2 =
> > > > > Character.toUpperCase(Character.forDigit(b & 0xF, RADIX));
> > > > > buf.append(hex1);
> > > > > buf.append(hex2);
> > > > > }
> > > > >
> > > > > And thus it gets URL encoded no ?
> > > > >
> > > >
> > > > Yes, I was mistaken. Sorry about that.
> > > >
> > > > Oleg
> > > >
> > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> > 
> > > > 
> > > > For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> > 
> > > > 
> > > >
> > > >
> > >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> > 
> > For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> > 
> >
> >
> 



-
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org

Re: UrlEncodedFormEntity and parameter value encoding

[ecki]

Hello,

While I think it does not hurt to encode it, if you look at the context (form 
represrntation) you only need to escape characters which hinder thenparsing of 
forms. And @ is not a problem for that

Gruss
Bernd
-- 
http://bernd.eckenfels.net
>From Win 10 Mobile

Von: Oleg Kalnichevski

Re: UrlEncodedFormEntity and parameter value encoding

[Philippe Mouawad]

On Sunday, September 18, 2016, Oleg Kalnichevski  wrote:

> On Sun, 2016-09-18 at 16:12 +0200, Philippe Mouawad wrote:
> > So is it a bug ? or a regular behaviour ?
> >
>
> We back to where we started. Why do you think it should not be encoded?

it does not seem to be when using browser.
It should if it's in url but I am not sure it is reserved when located in
form parameter.
I don't fully understand the rfc documentation.

Regards

>
> Oleg
>
> > thanks
> >
> > On Sunday, September 18, 2016, Oleg Kalnichevski  > wrote:
> >
> > > On Sun, 2016-09-18 at 15:11 +0200, Philippe Mouawad wrote:
> > > > Hi Oleg,
> > > > Thanks for rapid answer.
> > > > Correct me if I am wrong but:
> > > > - URLENCODER is built from an or on UNRESERVED (which contains '_',
> '-',
> > > > '.', '*' and a-z, A-Z, 0-9.
> > > >
> > > > URLENCODER is passed as safechars in
> > > > private static String urlEncode(
> > > > final String content,
> > > > final Charset charset,
> > > > final BitSet safechars,
> > > > final boolean blankAsPlus)
> > > >
> > > >
> > > > @ is not part of the chars, so you end up in this part of algorithms
> > > right
> > > > ?:
> > > > } else {
> > > > buf.append("%");
> > > > final char hex1 =
> > > > Character.toUpperCase(Character.forDigit((b >> 4) & 0xF, RADIX));
> > > > final char hex2 =
> > > > Character.toUpperCase(Character.forDigit(b & 0xF, RADIX));
> > > > buf.append(hex1);
> > > > buf.append(hex2);
> > > > }
> > > >
> > > > And thus it gets URL encoded no ?
> > > >
> > >
> > > Yes, I was mistaken. Sorry about that.
> > >
> > > Oleg
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> 
> > > 
> > > For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> 
> > > 
> > >
> > >
> >
>
>
>
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> 
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> 
>
>

-- 
Cordialement.
Philippe Mouawad.

Re: UrlEncodedFormEntity and parameter value encoding

[Oleg Kalnichevski]

On Sun, 2016-09-18 at 16:12 +0200, Philippe Mouawad wrote:
> So is it a bug ? or a regular behaviour ?
> 

We back to where we started. Why do you think it should not be encoded?

Oleg

> thanks
> 
> On Sunday, September 18, 2016, Oleg Kalnichevski  wrote:
> 
> > On Sun, 2016-09-18 at 15:11 +0200, Philippe Mouawad wrote:
> > > Hi Oleg,
> > > Thanks for rapid answer.
> > > Correct me if I am wrong but:
> > > - URLENCODER is built from an or on UNRESERVED (which contains '_', '-',
> > > '.', '*' and a-z, A-Z, 0-9.
> > >
> > > URLENCODER is passed as safechars in
> > > private static String urlEncode(
> > > final String content,
> > > final Charset charset,
> > > final BitSet safechars,
> > > final boolean blankAsPlus)
> > >
> > >
> > > @ is not part of the chars, so you end up in this part of algorithms
> > right
> > > ?:
> > > } else {
> > > buf.append("%");
> > > final char hex1 =
> > > Character.toUpperCase(Character.forDigit((b >> 4) & 0xF, RADIX));
> > > final char hex2 =
> > > Character.toUpperCase(Character.forDigit(b & 0xF, RADIX));
> > > buf.append(hex1);
> > > buf.append(hex2);
> > > }
> > >
> > > And thus it gets URL encoded no ?
> > >
> >
> > Yes, I was mistaken. Sorry about that.
> >
> > Oleg
> >
> >
> >
> > -
> > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> > 
> > For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> > 
> >
> >
> 



-
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org

Re: UrlEncodedFormEntity and parameter value encoding

[Philippe Mouawad]

So is it a bug ? or a regular behaviour ?

thanks

On Sunday, September 18, 2016, Oleg Kalnichevski  wrote:

> On Sun, 2016-09-18 at 15:11 +0200, Philippe Mouawad wrote:
> > Hi Oleg,
> > Thanks for rapid answer.
> > Correct me if I am wrong but:
> > - URLENCODER is built from an or on UNRESERVED (which contains '_', '-',
> > '.', '*' and a-z, A-Z, 0-9.
> >
> > URLENCODER is passed as safechars in
> > private static String urlEncode(
> > final String content,
> > final Charset charset,
> > final BitSet safechars,
> > final boolean blankAsPlus)
> >
> >
> > @ is not part of the chars, so you end up in this part of algorithms
> right
> > ?:
> > } else {
> > buf.append("%");
> > final char hex1 =
> > Character.toUpperCase(Character.forDigit((b >> 4) & 0xF, RADIX));
> > final char hex2 =
> > Character.toUpperCase(Character.forDigit(b & 0xF, RADIX));
> > buf.append(hex1);
> > buf.append(hex2);
> > }
> >
> > And thus it gets URL encoded no ?
> >
>
> Yes, I was mistaken. Sorry about that.
>
> Oleg
>
>
>
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> 
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> 
>
>

-- 
Cordialement.
Philippe Mouawad.

Re: UrlEncodedFormEntity and parameter value encoding

[Oleg Kalnichevski]

On Sun, 2016-09-18 at 15:11 +0200, Philippe Mouawad wrote:
> Hi Oleg,
> Thanks for rapid answer.
> Correct me if I am wrong but:
> - URLENCODER is built from an or on UNRESERVED (which contains '_', '-',
> '.', '*' and a-z, A-Z, 0-9.
> 
> URLENCODER is passed as safechars in
> private static String urlEncode(
> final String content,
> final Charset charset,
> final BitSet safechars,
> final boolean blankAsPlus)
> 
> 
> @ is not part of the chars, so you end up in this part of algorithms right
> ?:
> } else {
> buf.append("%");
> final char hex1 =
> Character.toUpperCase(Character.forDigit((b >> 4) & 0xF, RADIX));
> final char hex2 =
> Character.toUpperCase(Character.forDigit(b & 0xF, RADIX));
> buf.append(hex1);
> buf.append(hex2);
> }
> 
> And thus it gets URL encoded no ?
> 

Yes, I was mistaken. Sorry about that.

Oleg



-
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org

Re: UrlEncodedFormEntity and parameter value encoding

[Philippe Mouawad]

Hi Oleg,
Thanks for rapid answer.
Correct me if I am wrong but:
- URLENCODER is built from an or on UNRESERVED (which contains '_', '-',
'.', '*' and a-z, A-Z, 0-9.

URLENCODER is passed as safechars in
private static String urlEncode(
final String content,
final Charset charset,
final BitSet safechars,
final boolean blankAsPlus)


@ is not part of the chars, so you end up in this part of algorithms right
?:
} else {
buf.append("%");
final char hex1 =
Character.toUpperCase(Character.forDigit((b >> 4) & 0xF, RADIX));
final char hex2 =
Character.toUpperCase(Character.forDigit(b & 0xF, RADIX));
buf.append(hex1);
buf.append(hex2);
}

And thus it gets URL encoded no ?

Thanks

On Sun, Sep 18, 2016 at 2:37 PM, Oleg Kalnichevski  wrote:

> On Sun, 2016-09-18 at 14:08 +0200, Philippe Mouawad wrote:
> > On Sunday, September 18, 2016, Oleg Kalnichevski 
> wrote:
> >
> > > On Sat, 2016-09-17 at 15:55 +0200, Philippe Mouawad wrote:
> > > > Hello,
> > > > We have a bug report at JMeter :
> > > > https://bz.apache.org/bugzilla/show_bug.cgi?id=60120
> > > >
> > > > Where  a user post a form with a parameter having this value
> > > > 'IqGo6EM1JEVZ+MSRJqUSo@qhjVMSFBTs'
> > > >
> > > > It appears that the '@' character is encoded.
> > > >
> > > > The form is submitted using application/x-www-form-urlencoded
> > > >
> > > > As per rfc:
> > > > > then reserved characters are escaped as described in [RFC1738]
> > > > , section
> > > 2.2:
> > > >
> > > >
> > > > > The characters ";"  "/", "?", ":", "@", "=" and "&" are the
> characters
> > > > which may be reserved for special meaning within a scheme. No other
> > > > characters may be reserved within a scheme.
> > > >
> > > > So @ is reserved and as such HttpClient encodes it.
> > > >
> > > > But it is not clear for me if @ is reserved when place in URI or also
> > > > reserved when being part of a form parameter value.
> > > >
> > > > In JMeter code, we use UrlEncodedFormEntity and I check that when
> > > parameter
> > > > is passed , its value has still @ unencoded.
> > > >
> > >
> > > Why do you think it should be encoded?
> >
> >
> > I don't think it should but it is by HtTpClient class.
> > Maybe my last sentence was confusing, I recap, debugging the call, I see
> @
> > passed unencoded to httpclient method which encodes it.
> >
> >
>
> But it should not
>
> https://github.com/apache/httpclient/blob/4.5.x/
> httpclient/src/main/java/org/apache/http/client/utils/
> URLEncodedUtils.java#L654
>
> @ is not in the set of characters that need encoding
>
> https://github.com/apache/httpclient/blob/4.5.x/
> httpclient/src/main/java/org/apache/http/client/utils/
> URLEncodedUtils.java#L454https://github.com/apache/httpclient/blob/4.5.x/
> httpclient/src/main/java/org/apache/http/client/utils/
> URLEncodedUtils.java#L457
>
> Oleg
>
>
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
>
>


-- 
Cordialement.
Philippe Mouawad.

Re: UrlEncodedFormEntity and parameter value encoding

[Oleg Kalnichevski]

On Sun, 2016-09-18 at 14:08 +0200, Philippe Mouawad wrote:
> On Sunday, September 18, 2016, Oleg Kalnichevski  wrote:
> 
> > On Sat, 2016-09-17 at 15:55 +0200, Philippe Mouawad wrote:
> > > Hello,
> > > We have a bug report at JMeter :
> > > https://bz.apache.org/bugzilla/show_bug.cgi?id=60120
> > >
> > > Where  a user post a form with a parameter having this value
> > > 'IqGo6EM1JEVZ+MSRJqUSo@qhjVMSFBTs'
> > >
> > > It appears that the '@' character is encoded.
> > >
> > > The form is submitted using application/x-www-form-urlencoded
> > >
> > > As per rfc:
> > > > then reserved characters are escaped as described in [RFC1738]
> > > , section
> > 2.2:
> > >
> > >
> > > > The characters ";"  "/", "?", ":", "@", "=" and "&" are the characters
> > > which may be reserved for special meaning within a scheme. No other
> > > characters may be reserved within a scheme.
> > >
> > > So @ is reserved and as such HttpClient encodes it.
> > >
> > > But it is not clear for me if @ is reserved when place in URI or also
> > > reserved when being part of a form parameter value.
> > >
> > > In JMeter code, we use UrlEncodedFormEntity and I check that when
> > parameter
> > > is passed , its value has still @ unencoded.
> > >
> >
> > Why do you think it should be encoded?
> 
> 
> I don't think it should but it is by HtTpClient class.
> Maybe my last sentence was confusing, I recap, debugging the call, I see @
> passed unencoded to httpclient method which encodes it.
> 
> 

But it should not

https://github.com/apache/httpclient/blob/4.5.x/httpclient/src/main/java/org/apache/http/client/utils/URLEncodedUtils.java#L654

@ is not in the set of characters that need encoding

https://github.com/apache/httpclient/blob/4.5.x/httpclient/src/main/java/org/apache/http/client/utils/URLEncodedUtils.java#L454https://github.com/apache/httpclient/blob/4.5.x/httpclient/src/main/java/org/apache/http/client/utils/URLEncodedUtils.java#L457

Oleg


-
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org

Re: UrlEncodedFormEntity and parameter value encoding

[Philippe Mouawad]

On Sunday, September 18, 2016, Oleg Kalnichevski  wrote:

> On Sat, 2016-09-17 at 15:55 +0200, Philippe Mouawad wrote:
> > Hello,
> > We have a bug report at JMeter :
> > https://bz.apache.org/bugzilla/show_bug.cgi?id=60120
> >
> > Where  a user post a form with a parameter having this value
> > 'IqGo6EM1JEVZ+MSRJqUSo@qhjVMSFBTs'
> >
> > It appears that the '@' character is encoded.
> >
> > The form is submitted using application/x-www-form-urlencoded
> >
> > As per rfc:
> > > then reserved characters are escaped as described in [RFC1738]
> > , section
> 2.2:
> >
> >
> > > The characters ";"  "/", "?", ":", "@", "=" and "&" are the characters
> > which may be reserved for special meaning within a scheme. No other
> > characters may be reserved within a scheme.
> >
> > So @ is reserved and as such HttpClient encodes it.
> >
> > But it is not clear for me if @ is reserved when place in URI or also
> > reserved when being part of a form parameter value.
> >
> > In JMeter code, we use UrlEncodedFormEntity and I check that when
> parameter
> > is passed , its value has still @ unencoded.
> >
>
> Why do you think it should be encoded?


I don't think it should but it is by HtTpClient class.
Maybe my last sentence was confusing, I recap, debugging the call, I see @
passed unencoded to httpclient method which encodes it.


>
> Oleg
>
> > Thanks for clarification.
> > Regards
> > Philippe M.
>
>
>
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> 
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> 
>
>

-- 
Cordialement.
Philippe Mouawad.

Re: UrlEncodedFormEntity and parameter value encoding

[Oleg Kalnichevski]

On Sat, 2016-09-17 at 15:55 +0200, Philippe Mouawad wrote:
> Hello,
> We have a bug report at JMeter :
> https://bz.apache.org/bugzilla/show_bug.cgi?id=60120
> 
> Where  a user post a form with a parameter having this value
> 'IqGo6EM1JEVZ+MSRJqUSo@qhjVMSFBTs'
> 
> It appears that the '@' character is encoded.
> 
> The form is submitted using application/x-www-form-urlencoded
> 
> As per rfc:
> > then reserved characters are escaped as described in [RFC1738]
> , section 2.2:
> 
> 
> > The characters ";"  "/", "?", ":", "@", "=" and "&" are the characters
> which may be reserved for special meaning within a scheme. No other
> characters may be reserved within a scheme.
> 
> So @ is reserved and as such HttpClient encodes it.
> 
> But it is not clear for me if @ is reserved when place in URI or also
> reserved when being part of a form parameter value.
> 
> In JMeter code, we use UrlEncodedFormEntity and I check that when parameter
> is passed , its value has still @ unencoded.
> 

Why do you think it should be encoded?

Oleg

> Thanks for clarification.
> Regards
> Philippe M.



-
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org

UrlEncodedFormEntity and parameter value encoding

[Philippe Mouawad]

Hello,
We have a bug report at JMeter :
https://bz.apache.org/bugzilla/show_bug.cgi?id=60120

Where  a user post a form with a parameter having this value
'IqGo6EM1JEVZ+MSRJqUSo@qhjVMSFBTs'

It appears that the '@' character is encoded.

The form is submitted using application/x-www-form-urlencoded

As per rfc:
> then reserved characters are escaped as described in [RFC1738]
, section 2.2:


> The characters ";"  "/", "?", ":", "@", "=" and "&" are the characters
which may be reserved for special meaning within a scheme. No other
characters may be reserved within a scheme.

So @ is reserved and as such HttpClient encodes it.

But it is not clear for me if @ is reserved when place in URI or also
reserved when being part of a form parameter value.

In JMeter code, we use UrlEncodedFormEntity and I check that when parameter
is passed , its value has still @ unencoded.

Thanks for clarification.
Regards
Philippe M.