This was fixed some time ago by Helmut Tschemernjak
email@hidden. Here is his message:
From:
<webobjects-dev-bounces+chill=email@hidden> on behalf of Helmut Tschemernjak <email@hidden>
Organization: HELIOS Software GmbH
Date: Sunday, July 29, 2012 at 4:04 AM
To: "email@hidden" <email@hidden>
Subject: Fixed the WO 5.4.3 2GB file/form upload limitations
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:
WOMultipartIterator
===================
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.
WOHttpIO
========
As many apps and classes use the content-length header to define the
request size
I decided to add a new header called x-content-length containing the
original
content-length value, then I limit the content-length for compatibility
reasons to
Integer.MAX_VALUE which avoids changes in many WO classes (NSRange,
NSData, etc.)
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
intention.
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
contact me.
Regards
Helmut
From:
<webobjects-dev-bounces+chill=email@hidden> on behalf of Wolfgang Hartmann <email@hidden>
Date: Friday, August 26, 2016 at 10:41 AM
To: "email@hidden" <email@hidden>, "email@hidden" <email@hidden>
Subject: RE: Large file uploads
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
From: email@hidden
Subject: Large file uploads
Date: Fri, 26 Aug 2016 19:33:30 +0200
To: email@hidden
Hi list,
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?
This email sent to email@hidden