DO NOT REPLY [Bug 20815] New: - FileUpload always assumes transfer encoding to be always BINARY and does not properly handle 'Content-Transfer-Encoding' header

[bu...@apache.org]

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: commons-dev@jakarta.apache.org
        ReportedBy: olegk@apache.org


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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org