Hi, Dan, thanks for your informative response.
|File Upload was badly broken with mod_jk/ajp13 in both 3.2 and 3.x
|-- some basic bugs have been fixed in both of those repositories,
|but have not yet been released. Just so you know.
I am working with source from jakarta-tomcat cvs head, but so far
I have only been working with mod_jk/ajp12 .. I had discounted ajp13
because of its 'experimental' tag, but I'll turn my focus there.
|Where in RFC 1867 (which I just spent a while looking through)
|does it discuss the issues you mention (early response by the
|servlet + consumption of the body)?
At the end of 1867 s 5.2, it specifies that the 'web server' has
the perogative to reject large uploads. My opinion is that a servlet
should have the same perogative. However, in ajp12, servlet responses
are checked only after the entire request body (file upload) has been
written to the server. I think this architecture is the 'basic bug'
to which you refer. A failure case (again ajp12) would be:
mod_jk/ajp12 servlet
------------ -------
sends headers reads headers, decided rq is too big
sends 8k body chunk
sends 8k body chunk do some work
sends 8k body chunk .. send blocks
because tcp buffer is filled. sends friendly html response
closes socket
send unblocks with ESHUTDOWN,
return 500
Worse, mod_jk/ajp12 does not consume the remaining bits after the
socket shutdown above. Apache considers that the incoming bits are
a persistent connection and begins parsing a new request from the
uploaded file bits mid-stream.
So I had tweaked ajp12 to use select and to pay attention to servlet
responses, but it appears that is the basic architecture of ajp13,
so I'll take a look at it and see if it succeeds in this case.
Many thanks again,
Keith W.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
