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: Jesse Tayler <email@hidden>
- Date: Sun, 29 Jul 2012 12:49:59 -0400
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