DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20815>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20815 FileUpload always assumes transfer encoding to be always BINARY and does not properly handle 'Content-Transfer-Encoding' header Summary: FileUpload always assumes transfer encoding to be always BINARY and does not properly handle 'Content-Transfer- Encoding' header Product: Commons Version: 1.0 Beta 2 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: File Upload AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Each individual part in the 'multipart/form-data' encoded requests may have its own content transfer encoding definition. Sadly enough, it is quite customary to assume that such encoding would always be BINARY. For instance, all the commonly used browsers do make such an assumption and do not even bother to include 'Content-Transfer-Encoding' header when sending 'multipart/form-data' encoded requests. However, at least in my opinion, such assumption is too liberal and is in violation of the RFC 1867. I believe that at the very least FileUpload component should expose 'Content-Transfer-Encoding' through FileItem's interface. It should also, at the very least, throw an exception when an attempt is made to convert non-BINARY encoded content to a String using DefaultFileItem#getString or DefaultFileItem#getString(String). Ideally, FileUpload component should implement other common transfer encodings such as "quoted-printable" and "base64" -- RFC1867: Quote ------------ 7. Registration of multipart/form-data The media-type multipart/form-data follows the rules of all multipart MIME data streams as outlined in RFC 1521 -- RFC1867: End of quote ----- For more details refer to http://www.ietf.org/rfc/rfc1867.txt -- RFC1521: Quote ------------ 5. The Content-Transfer-Encoding Header Field Many Content-Types which could usefully be transported via email are represented, in their "natural" format, as 8-bit character or binary data. Such data cannot be transmitted over some transport protocols. ... It is necessary, therefore, to define a standard mechanism for re- encoding such data into a 7-bit short-line format. This document specifies that such encodings will be indicated by a new "Content- Transfer-Encoding" header field. The Content-Transfer-Encoding field is used to indicate the type of transformation that has been used in order to represent the body in an acceptable manner for transport. ... The Content-Transfer-Encoding field is designed to specify an invertible mapping between the "native" representation of a type of data and a representation that can be readily exchanged using 7 bit mail transport protocols, such as those defined by RFC 821 (SMTP). This field has not been defined by any previous standard. The field's value is a single token specifying the type of encoding, as enumerated below. Formally: encoding := "Content-Transfer-Encoding" ":" mechanism mechanism := "7bit" ; case-insensitive / "quoted-printable" / "base64" / "8bit" / "binary" / x-token -- RFC1521: End of quote ----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
