commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Deven Phillips (JIRA)" <j...@apache.org>
Subject [jira] Commented: (FILEUPLOAD-131) MultipartStream always assumes transfer encoding to be BINARY
Date Fri, 18 Mar 2011 21:24:29 GMT

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

Deven Phillips commented on FILEUPLOAD-131:
-------------------------------------------

I was just running into this problem myself today. I checked out the SVN HEAD and see that
the header object is now being returned properly, but here's an idea:

When the code retrieves the InputStream for the FileItem, have it return an appropriate InputStream
which is based on the content-transport-encoding. For example, if the encoding is Base64,
return a Base64InputStream. That way, the implementing developer can be completely ignorant
of the underlying encoding and still get valid data. We could also provide a path to access
a raw InputStream for "Power Users".

> MultipartStream always assumes transfer encoding to be BINARY
> -------------------------------------------------------------
>
>                 Key: FILEUPLOAD-131
>                 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-131
>             Project: Commons FileUpload
>          Issue Type: Bug
>         Environment: N/A
>            Reporter: Walco van Loon
>
> MultipartStream always assumes transfer encoding to be BINARY and does not handle 'Content-Transfer-Encoding'
header at all.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message