Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Date: Mon, 17 Jun 2013 12:39:20 +0000 (UTC)
From: "Karl Wright (JIRA)" <jira@apache.org>
To: dev@hc.apache.org
Message-ID: <JIRA.12652840.1371201345504.125129.1371472760380@arcas>
In-Reply-To: <JIRA.12652840.1371201345504@arcas>
References: <JIRA.12652840.1371201345504@arcas>
Subject: [jira] [Commented] (HTTPCLIENT-1372) Content-Disposition header in
 form data does not adhere to RFC6266
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Karl Wright commented on HTTPCLIENT-1372:
-----------------------------------------

Hi Oleg,

I'm not arguing for removal of the BROWSER_COMPATIBLE mode, provided you are convinced this is the way browsers actually behave.  It's hard to believe that it actually works, though, because the encoding of fields other than the one with the filename is left as mime default (ISO-8859-1) with no way to change it.  I can believe that browsers might omit the Content-Type field unless the encoding differed from ISO-8859-1, but I find it hard to believe they'd *always* omit it.

I'm in no position to do extensive testing with multiple browsers, as you know.  And it is probably more productive to create a multipart mode corresponding to RFC6532 than to mess with the BROWSER_COMPATIBLE mode that is in place - unless we can show that the BROWSER_COMPATIBLE mode is not really browser compatible after all.  Which is why I raise the issue.


> Content-Disposition header in form data does not adhere to RFC6266
> ------------------------------------------------------------------
>
>                 Key: HTTPCLIENT-1372
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1372
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpMime
>    Affects Versions: 4.2.5
>            Reporter: Karl Wright
>             Fix For: 4.3 Beta3
>
>
> The Content-disposition header, as it appears for an item of form data, does not allow for UTF-8 encoding as specified in RFC6266, as described here:
> http://tools.ietf.org/html/rfc6266
> This is causing ManifoldCF severe problems working in Japan with Solr, since Solr content extraction relies on accurate filenames in order to determine the likely document encoding.
> A fix for the 4.2.x branch will be needed, I am afraid.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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