|
Created an attachment (id=17350)
Simple workaround for FileUpload 1.0 Added a simple workaround for FileUpload 1.0. Created an attachment (id=17351)
Simple workaround for FileUpload 1.1 Added a simple workaround for FileUpload 1.0. Handling of unknown length requests as demonstrated in the patch works but does
not apply maxSize, as request size is -1. For maxSize to be applied, request size needs to be computed on the fly, and maxSize check should be checked during parsing too. This can necessitate further handling of FileItem created to the point where maxSize is attained. I currently cannot dedicate time to this point, but I may need to resolve this
Here's a more enhanced version of the patch, which allows the absence of a content-length, but keeps the check on-the-fly.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Closed
Minor
[fileupload] Allow parsing requests of unknown length
but it isn't required (Section 5.2 of RFC1867). I'm attempting to zip and send a
collection of files on the fly and I'm running into "Stream ended unexpectedly"
exception. I am dealing with large files and of course I can't predetermine the
length of the resulting zip file.