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 protected]> 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 protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/jtayler%40oeinc.com
This email sent to [email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
