This was fixed some time ago by Helmut Tschemernjak email@hidden.
Here is his message:
I enhanced JavaWebObjects to support uploads larger then 2GB via the
existing upload form data streaming API. At present we don't use Wonder
which means the changes apply to WO 5.4.3 deploying it standalone by
including three updated classes in your app. We will investigate into
Wonder but this is on a second page.
Here is the description of the changes:
Changed calling WONoCopyPushbackInputStream to use long length based
on the x-content-length instead of the aRequest._contentLengthHeader()
Added public long contentLengthRemainingLong() to return the size as long.
Added public long _estimatedContentLengthLong(() to return the size as long.
Changed totalRemaining, delimiterLength, chaff from int to long
WONoCopyPushbackInputStream
===========================
WONoCopyPushbackInputStream constructor uses now long size
Changed readMax, originalReadMax from int to long
Changed several size calculations from int to long
As WONoCopyPushbackInputStream is only used by WOMultipartIterator and
WOHttpIO of the JavaWebObjects package others will not be affected.
As many apps and classes use the content-length header to define the
I decided to add a new header called x-content-length containing the
content-length value, then I limit the content-length for compatibility
Integer.MAX_VALUE which avoids changes in many WO classes (NSRange,
This way everybody adding 2GB request support in their apps should just call
request.headerForKey("x-content-length") to receive the 64 bit length.
For everybody else it should stay compatible.
Fixed code to compile again and reorder code to match the original
Main header tuning changes are in: public InputStream _readHeaders()
Changed several parseInt to parseLong.
Changed several contentLengthInt to contentLengthLong
Changed use of ContentLengthKey in several instances to XContentLengthKey
If you are interested to receive the three 5.4.3 patches/files please
Hy,
WO parses the ContentLength header as an Integer and 2.1 GB is MaxInt.
Everything larger results in an ParsingException. So this size is a hard limit for an upload, even when its an wis-action (wo-streaming-action).
Best regards,
Wolfy
I’m having issues with an application in which i use a modified version of ERDragAndDropUpload and I can’t upload files larger than 2.1 GB. I’ve searched in the mailing list but I only got a few references about
this problem about 6 years ago… What’s the current situation?
The log line i get is <com.webobjects.appserver._private.WOHttpIO> Unable to parse content-length header: '2635300961’.
Is there a quick fix or should I investigate alternatives to WO for this specific scenario?
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription:
email@hidden