tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <devli...@hanik.com>
Subject Re: svn commit: r582291 - /tomcat/tc6.0.x/trunk/STATUS
Date Fri, 05 Oct 2007 18:28:49 GMT
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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message