[
https://issues.apache.org/jira/browse/FILEUPLOAD-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi updated FILEUPLOAD-116:
--------------------------------------
Fix Version/s: 1.2.1
> max headers size is checked but improperly handled
> --------------------------------------------------
>
> Key: FILEUPLOAD-116
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-116
> Project: Commons FileUpload
> Issue Type: Bug
> Affects Versions: 1.2
> Reporter: Amichai Rothman
> Priority: Minor
> Fix For: 1.2.1
>
> Attachments:
> ASF.LICENSE.NOT.GRANTED--commons-fileupload-1.2-bug-max-header-size.patch
>
>
> MultipartStream enforces a maximum headers section size limit to prevent
> abuse. However, when the limit is reached, it silently discards the rest of
> the headers block, and returns an invalid partial headers string back to
> FileUploadBase. There it may, depending on the data and location of the
> cutoff, either return partial headers, return among them an invalid header,
> or throw an undocumented IllegalStateException.
> Instead, it should inform the caller that the headers are not properly
> processed - whether or not the oversized headers are due to a malformed
> stream or not, after cutting them off they certainly become malformed.
> The attached patch fixes this by having MultipartStream throw a
> MalformedStreamException when the limit is reached, as it does if other
> errors occur. This both leaves existing error handling (whomever catches such
> an exception) unchanged, and seems right since an extremely oversized header
> block is likely due to a malformed stream. This change further guarantees
> that if the exception is not thrown, the returned headers string must be
> valid, which simplifies processing in FileUploadBase (also included in the
> patch).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
