DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=30420>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=30420 [PATCH]character encoding handling is invalid at multipart ------- Additional Comments From [EMAIL PROTECTED] 2004-08-02 09:45 ------- oops, you're right. RFC 1867 is referenced in the JavaDocs for MultipartPostMethod and it says (in section 7): Field names originally in non-ASCII character sets may be encoded using the method outlined in RFC 1522. RFC1522 is available at http://www.faqs.org/rfcs/rfc1522.html and is also MIME encoding (it's part two of the document that RFC 2047 is part three of). One of the options is provides is: 4.1. The "B" encoding The "B" encoding is identical to the "BASE64" encoding defined by RFC 1521. We already have BASE64 encoding available to us. The other option seems to be quoted-printable. I'd need to read the spec in more detail to be sure about how it all works but it looks like the header values could be pre-encoded according to RFC 1522 and then passed into HttpClient as I mentioned earlier. It should wind up looking something like: =?US-ASCII?Q?Keith_Moore?= Which is the same format used in email headers. In fact, our own JavaDocs quote the standard: Field names originally in non-ASCII character sets may be encoded using the method outlined in RFC 1522. We probably should look at implementing support for this at some point then. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
