Re: Fixed the WO 5.4.3 2GB file/form upload limitations
Re: Fixed the WO 5.4.3 2GB file/form upload limitations
- Subject: Re: Fixed the WO 5.4.3 2GB file/form upload limitations
- From: Helmut Tschemernjak <email@hidden>
- Date: Sun, 29 Jul 2012 22:17:06 +0200
- Organization: HELIOS Software GmbH
Hi Jesse,
I believe my original posting explained what was done. I wrote some
years ago a little java based web server (experimental only) and I have
some knowledge about networking IO and protocols. After learning at
WOWODC that we need to fix/enhance WebObjects on our own, I spend some
time doing it. For me, JavaWebObjects (without EOF/Wonder) works pretty
good, only the 2GB upload limit was restricting our solution.
We will investigate into Wonder, I believe Wonder uses a different
"Adaptor" which means changes will only partially match Wonder.
Thanks for the motivation.
Helmut
On 29.07.12 18:49, Jesse Tayler wrote:
Nice work!
I was not aware anyone was working on this.
Can you explain a little about what you found, did and so forth just so we're aware of what went down?
thanks, and thanks!
jess
On Jul 29, 2012, at 7:04 AM, Helmut Tschemernjak <email@hidden> wrote:
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
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden