[
https://issues.apache.org/jira/browse/FILEUPLOAD-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12483294
]
Michael Macaluso commented on FILEUPLOAD-130:
---------------------------------------------
It was labeled a blocker because we are trying to adopt commons-fileupload but
we need those hidden headers. Semantics though, so make the type
what you wish.
I am checking out the files now. However one problem on the build. When
checking-out the trunk release and building with ant, I am getting an error
downloading the commons-io-1.4-SNAPSHOT.jar from
http://repo1.maven.org/maven/commons-io/jars/commons-io-1.4-SNAPSHOT.jar. This
download is available from http://people.apache.org/repo/m1-snapshot-repository
which I notice is referenced in the build.properties. However, the build.xml
file references the hard-coded URL above. Is this correct?
> Add ability to get any header from the FileItem and FileItemStream interfaces
> -----------------------------------------------------------------------------
>
> Key: FILEUPLOAD-130
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-130
> Project: Commons FileUpload
> Issue Type: Improvement
> Affects Versions: 1.2
> Reporter: Michael Macaluso
> Priority: Minor
>
> The FileItem and FileItemStream interfaces should have a way to return back
> any header that was encountered during the header parsing for an "Item".
> Currently, from the FileItemStatus you can only get information from the 2
> pre-defined headers "Content-Type" and "Content-Disposition" (Sort-of because
> the header can not be accessed raw). Other than the interface changes
> (including the change to pass them along in the FileItemFactory interface),
> it appears that all changes can be made within the FileUploadBase.java file.
> FileUploadBase.java:859 (as of 1.2) has the headers, but the call to create
> the FileItemStreamImpl on lines 877 and 887 do not include the headers map.
> Further, the parseRequest method uses the FileItemStream interface to build
> the FileItem, so you should always have the headers in question.
> The reason for this request is that we have an application that is sending
> per-part headers (not precluded by the specs as far as we know of) to provide
> more information than name and content-type and using the FileUpload project
> means that we can no longer find out those header values.
> [Also, not completely sure, but I believe FileUploadBase.createItem(Map,
> boolean) on line 480 is not referenced anymore in this project.]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
