[
https://issues.apache.org/jira/browse/FILEUPLOAD-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553191
]
Clint Popetz commented on FILEUPLOAD-135:
-----------------------------------------
I'd like to note that this is actually browser independent and not just an
issue with short files...when data is coming via AJP (coyote / mod_jk) in
tomcat, it comes in chunks, and if a chunk falls on a boundary, it triggers
this bug (which it does for my web site a _lot_ and I've been chasing it for
weeks) because the first read will just return what's left in that chunk (not
enough for a boundary) and the second read would return the rest of the
boundary.
> InputStream created with Streaming API returns EOF on first read() for short
> files uploaded from FireFox over HTTPS
> -------------------------------------------------------------------------------------------------------------------
>
> Key: FILEUPLOAD-135
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-135
> Project: Commons FileUpload
> Issue Type: Bug
> Affects Versions: 1.2, 1.2.1
> Environment: Windows XP
> Browser: Firefox 1.5.0.11
> Protocol: HTTPS
> Reporter: Alexander Sova
> Assignee: Jochen Wiedmann
> Fix For: 1.2.1
>
> Attachments: commons-fileupload-1.1-bug-short-file-eof.patch,
> commons-fileupload-1.2-bug-short-file-eof.patch, FILEUPLOAD135.patch
>
>
> This problem happens only with files shorer then boundary string generated by
> browser and only with Firefox using HTTPS protocol.
> For some reason in this particular environment inputStream.read() in
> MultipartStream.ItemInputStream.makeAvailable() reads not whole HTTP response
> body, but only file content before boundary string.
> I've created a patch fixing this issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
