Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Date: Mon, 28 Dec 2015 17:44:49 +0000 (UTC)
From: "Idan Sheinberg (JIRA)" <jira@apache.org>
To: dev@hc.apache.org
Message-ID: <JIRA.12924525.1451318761000.16633.1451324689764@Atlassian.JIRA>
In-Reply-To: <JIRA.12924525.1451318761000@Atlassian.JIRA>
References: <JIRA.12924525.1451318761000@Atlassian.JIRA>
 <JIRA.12924525.1451318761528@arcas>
Subject: [jira] [Comment Edited] (HTTPCLIENT-1708) Issues With Extended
 ASCII ( Latin Chars ) Escaping with HttpClient 4.5.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/HTTPCLIENT-1708?page=3Dcom.atla=
ssian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=
=3D15072946#comment-15072946 ]=20

Idan Sheinberg edited comment on HTTPCLIENT-1708 at 12/28/15 5:44 PM:
----------------------------------------------------------------------

Hi=20

Before closing this as not a problem , can you please hear me out a bit mor=
e ??

I understand there's no particular charset encoding but that's not the issu=
e here.
Using the toASCIIString() method causes character value manipulation - that=
's the issue :

%CC%81  ( which the browser , URLEncode , curl and other tools generate  ) =
stands for UTF hex code cc 81 , Unicode U+0301 :
first row in the table here  - http://www.utf8-chartable.de/unicode-utf8-ta=
ble.pl?start=3D769

While %C3%A9 encoding ( which the toASCIIString() method generates ) stands=
 for UTF hex code c3 a9 , Unicode U+00E9 :
first row in the table here  - http://www.utf8-chartable.de/unicode-utf8-ta=
ble.pl?start=3D233

These are different chars, different symbols/values with different meanings=
 !

Don't you think it's a problem that line of code you library is using can t=
rigger character manipulation in certain cases such as this ( where U+301 b=
ecomes U+00E9 , due to the Normalizer usage ?)=20


was (Author: idans):
Hi=20

Before closing this as not a problem , can you please hear me out a bit mor=
e ??

I understand there's no particular charset encoding but that's not the issu=
e here.
Using the toASCIIString() method causes character value manipulation - that=
 the issue :

%CC%81  ( which the browser , URLEncode , curl and other tools generate  ) =
stands for UTF hex code cc 81 , Unicode U+0301 :
first row in the table here  - http://www.utf8-chartable.de/unicode-utf8-ta=
ble.pl?start=3D769

While %C3%A9 encoding ( which the toASCIIString() method generates ) stands=
 for UTF hex code c3 a9 , Unicode U+00E9 :
first row in the table here  - http://www.utf8-chartable.de/unicode-utf8-ta=
ble.pl?start=3D233

These are different chars, different symbols/values with different meanings=
 !

Don't you think it's a problem that line of code you library is using can t=
rigger character manipulation in certain cases such as this ( where U+301 b=
ecomes U+00E9 , due to the Normalizer usage ?)=20

> Issues With Extended ASCII ( Latin Chars ) Escaping with HttpClient 4.5.1
> -------------------------------------------------------------------------
>
>                 Key: HTTPCLIENT-1708
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-170=
8
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpClient
>    Affects Versions: 4.5.1
>         Environment: Ubuntu Variant 15.04
> Netbeans 8.1 IDE
> Java 8 ( Oracle JDK 1.8.6x)
>            Reporter: Idan Sheinberg
>
> Hey Guys
> Trying to send an httpclient HttpHead request for the following url  - 'h=
ttp://some.domain.com/amnetcanadaplatform/HomeDe=CC=81pot_E=CC=81lectros_WE=
B22s_video.mp4'
> I Notice it gets escaped as 'http://some.domain.com/amnetcanadaplatform/H=
omeD%C3%A9pot_%C3%89lectros_WEB22s_video.mp4'
> While other programs/utilities/frameworks expect it to be 'http://some.do=
main.com/amnetcanadaplatform/HomeDe%CC%81pot_E%CC%81lectros_WEB22s_video.mp=
4'
> I've done some digging up the source code and tracked the issue down  to =
 "toASCIIString()" of the Java URI ( WHICH OF COURSE IS NOT YOUR RESPONSIBI=
LITY )object being called in order to retrieve the request line
> Class : org.apache.http.client.methods.HttpRequestWrapper
> Method : getRequestLine()=20
> Line : 113
> Internally the line 'String ns =3D Normalizer.normalize(s, Normalizer.For=
m.NFC);' manipulates the chars so their unicode value changes , which cause=
s the 'inappropriate' values to be displayed for the escaped URI=20
> Class : java.net.URI
> Method : encode(String s)
> Line : 2723
> Now I know this would extra hard to even get to a point where I find out =
if this is a java language issue , but I don't believe unicode manipulation=
  of bytes is a desired behavior  for url encoding. Is there any known spec=
ific why you used the "toASCIIString()" method instead of the plain "toStri=
ng()" method
> Do you think there's a chance this issue can be resolved on your end ?


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org