Rainer Jung wrote:
Remy Maucherat wrote:
Rainer Jung wrote:
So my question is: is there a reliable way to detect, if it would be
safer to just drop a flush request?
I think flush should still send a flush packet. One scenario would be
(in the servlet): write 10 bytes and flush (in this case, the
response has not been committed yet). The server should write the
response header, then make sure the 10 bytes are sent because it has
to send them right away. AFAIK, the front end server will not do that
without the explicit flush.
If it's 10 body bytes (thinking about http), then in principle OK, but
see below.
What if the flush comes before the body and the headers are not yet
setup for the future body? Then we send out kind of default headers
not fitting to the response generated afterwards. Of course the flush
command coming from the webapp is the root of the evil, but in that
case, doing the flush would not be necessary and harmful.
as you mention, the webapp calls flush, the servlet container must
submit headers, buffering and not sending headers, even though the
client wants to submit 10 bytes, would be erronous, and not sending any
headers, but just the body, is protocol violation :)
I looked around in the existing code and found some strange things:
a) the patch we are talking about is for JK and we do something
similar for http already. This might be a plus point for the patch.
b) the jk code path looks like the sending of the headers resets the
output buffer, so uncommitted response bytes will be lost
(JkInputStream.appendHead() first does a outputMsg.reset())
c) For http I've got the impression, that
Http11Processor.prepareResponse() triggers direct writes via
InternalOutputBuffer (sendStatus(), write() and sendHeaders()). This
looks like uncommitted body parts will get out before the headers.
d) in the http case all relevant implementations of doWrite seem to
implicitely commit the response, if it is not already committed (e.g.
in InternalOutputBuffer). In InternalOutputBuffer, a flush() also
implies a commit. Assuming that I'm looking at the right classes, this
might fix c), but would also let a) for http (i.e. the commit before
flush) be unnecessary.
e) In the JK case, doWrite() does an implicit commit in
JkInputStream but not in RequestHandler. flush does not do an implicit
commit in ChannelSocket. Again assuming the classes are correct, the
JK case indeed needs additional commits to get the headers back early
enough, but those will destroy the uncommitted content when sending
out the headers.
not too familiar with this code either, but a flush, should always do an
implicit commit, as soon as the headers have gone out the response
is(should be) committed.
Filip
As you all know, the class structure is not easy and I might be wrong.
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
