[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16179854#comment-16179854
 ] 

Ioannis Sermetziadis commented on HTTPCLIENT-293:
-------------------------------------------------

I see how RFC 7578 (in section 2 and 4.2) handles the non-ASCII character usage 
in the multipart part's content-disposition header. 

Both RFC 7578 and RFC 2231 seem to provide a solution to the problem but I do 
not know which approach is the currently dominant. Based on the big difference 
in their release date, I would assume that RFC 2231 was in wide use before RFC 
7578 was released, so providing support for that would be a benefit. 
Additionally, supporting RFC 7578 would be valuable, as it seems simple and 
efficient.

Sure, I would be interested to work on both or one of the options. Not sure, 
however, how the implementation might conflict with the existing 
HttpMultipartModes. For example, it is not clear to me which specifications the 
browser_compatible mode follows. Also, should the HttpClient be backwards 
compatible with the currently defined modes? 

> Provide support for non-ASCII charsets in the multipart disposition-content 
> header
> ----------------------------------------------------------------------------------
>
>                 Key: HTTPCLIENT-293
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-293
>             Project: HttpComponents HttpClient
>          Issue Type: Improvement
>          Components: HttpClient (classic)
>    Affects Versions: 1.0 Alpha
>         Environment: Operating System: All
> Platform: All
>            Reporter: Eric Dofonsou
>            Priority: Minor
>             Fix For: 4.0 Beta 2
>
>
> Because of the the following line in getAsciiBytes 
>  data.getBytes("US-ASCII");
> The returned string is modified if has Latin Characters.
> Ex : Document non-controlé -> Document non-control?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to