You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Amichai Rothman (JIRA)" <ji...@apache.org> on 2006/05/19 01:47:06 UTC

[jira] Updated: (FILEUPLOAD-108) FileUploadBase.parseHeaders() has logic and performance flaws related to max header size.

     [ http://issues.apache.org/jira/browse/FILEUPLOAD-108?page=all ]

Amichai Rothman updated FILEUPLOAD-108:
---------------------------------------

    Attachment: commons-fileupload-1.1-bug-108.patch

An implementation of the suggested fix.

> FileUploadBase.parseHeaders() has logic and performance flaws related to max header size.
> -----------------------------------------------------------------------------------------
>
>          Key: FILEUPLOAD-108
>          URL: http://issues.apache.org/jira/browse/FILEUPLOAD-108
>      Project: Commons FileUpload
>         Type: Improvement

>     Versions: 1.1 Final
>     Reporter: Amichai Rothman
>     Priority: Minor
>  Attachments: commons-fileupload-1.1-bug-108.patch
>
> FileUploadBase.parseHeaders() has logic and performance flaws:
> MultipartStream.readHeaders() already limits the total header size, so FileUploadBase.parseHeaders() doesn't have to limit each header as well (it can cause problems, and gains nothing).
> Furthermore, the current implementation would cause an ArrayOutOfBoundsException if a longer header would in fact be present, which is undocumented and would cause trouble in calling app.
> Finally, the local buffer which is the cause of this limit is not needed - copying into it just takes up more memory and cpu.
> A simple solution is using  substrings rather than a buffer - substrings point into the same char buffer as the original (immutable) string, so no additional memory is used, no char copying is necessary, the undocumented exception will not occur, and the artificial max header size is no longer needed, so FileUpload can be more robust and flexible.

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


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org