[jira] Resolved: (STR-1528) [upload] FileUpload always assumes transfer encoding to be BINARY and does not properly handle 'Content-Transfer-Encoding' header

["Don Brown (JIRA)" <ji...@apache.org>]

     [ http://issues.apache.org/struts/browse/STR-1528?page=all ]
     
Don Brown resolved STR-1528:
----------------------------

    Resolution: Not A Problem
     Assign To:     (was: Jakarta Commons Developers Mailing List)

All the file upload code is now in the Jakarta Commons Fileupload project.  Please raise this issue there if it is still a problem.

> [upload] FileUpload always assumes transfer encoding to be BINARY and does not properly handle 'Content-Transfer-Encoding' header
> ---------------------------------------------------------------------------------------------------------------------------------
>
>          Key: STR-1528
>          URL: http://issues.apache.org/struts/browse/STR-1528
>      Project: Struts Action 1
>         Type: Improvement

>   Components: Core
>     Versions: 1.1 Final
>  Environment: Operating System: Linux
> Platform: All
>     Reporter: Oleg Kalnichevski
>     Priority: Minor

>
> 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 -----

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira