[
https://issues.apache.org/jira/browse/HTTPCLIENT-1708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Idan Sheinberg updated HTTPCLIENT-1708:
---------------------------------------
Description:
Hey Guys
Trying to send an httpclient HttpHead request for the following url -
'http://some.domain.com/amnetcanadaplatform/HomeDépot_Électros_WEB22s_video.mp4'
I Notice it gets escaped as
'http://some.domain.com/amnetcanadaplatform/HomeD%C3%A9pot_%C3%89lectros_WEB22s_video.mp4'
While other programs/utilities/frameworks expect it to be
'http://some.domain.com/amnetcanadaplatform/HomeDe%CC%81pot_E%CC%81lectros_WEB22s_video.mp4'
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 RESPONSIBILITY
)object being called in order to retrieve the request line
Class : org.apache.http.client.methods.HttpRequestWrapper
Method : getRequestLine()
Line : 113
Internally the line 'String ns = Normalizer.normalize(s, Normalizer.Form.NFC);'
manipulates the chars so their unicode value changes , which causes the
'inappropriate' values to be displayed for the escaped URI
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 specific why
you used the "toASCIIString()" method instead of the plain "toString()" method
Do you think there's a chance this issue can be resolved on your end ?
was:
Hey Guys
Trying to send an httpclient HttpHead request for the following url -
'http://cdn.adap.tv/amnetcanadaplatform/HomeDépot_Électros_WEB22s_FR_COMPRESSED-12142015112448-280.mp4'
I Notice it gets escaped as
'http://cdn.adap.tv/amnetcanadaplatform/HomeD%C3%A9pot_%C3%89lectros_WEB22s_FR_COMPRESSED-12142015112448-280.mp4'
While other programs/utilities/frameworks expect it to be
'http://cdn.adap.tv/amnetcanadaplatform/HomeDe%CC%81pot_E%CC%81lectros_WEB22s_FR_COMPRESSED-12142015112448-280.mp4'
I've done some digging up the source code and tracked the issue down to
"toASCIIString()" of the Java URI object being called in order to retrieve the
request line
> Issues With Extended ASCII ( Latin Chars ) Escaping with HttpClient 4.5.1
> -------------------------------------------------------------------------
>
> Key: HTTPCLIENT-1708
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1708
> 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 -
> 'http://some.domain.com/amnetcanadaplatform/HomeDépot_Électros_WEB22s_video.mp4'
> I Notice it gets escaped as
> 'http://some.domain.com/amnetcanadaplatform/HomeD%C3%A9pot_%C3%89lectros_WEB22s_video.mp4'
> While other programs/utilities/frameworks expect it to be
> 'http://some.domain.com/amnetcanadaplatform/HomeDe%CC%81pot_E%CC%81lectros_WEB22s_video.mp4'
> 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
> RESPONSIBILITY )object being called in order to retrieve the request line
> Class : org.apache.http.client.methods.HttpRequestWrapper
> Method : getRequestLine()
> Line : 113
> Internally the line 'String ns = Normalizer.normalize(s,
> Normalizer.Form.NFC);' manipulates the chars so their unicode value changes ,
> which causes the 'inappropriate' values to be displayed for the escaped URI
> 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 specific
> why you used the "toASCIIString()" method instead of the plain "toString()"
> 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: [email protected]
For additional commands, e-mail: [email protected]
