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.
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.
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]
