tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: TCK Issue with Tomcat 5.5.12
Date Thu, 22 Dec 2005 09:52:33 GMT
Bill Barker wrote:
>>AFAICT, this code is assuming that there will always be a message  body in 
>>the POST Request. However, this is not necessarily the case  (and is 
>>certainly not true for the problem at hand). Eventually, 
>> is called from within 
>>o.a.coyote.http11.InternalReadBuffer.fill(). This call will throw a 
> Then the test is broken.  It should either have a 'Content-Length: 0' header 
> or a 'Transfer-Encoding: chunked' header with a '0' content delimater.  I 
> don't do NDAs, so I don't know which it is.  If Sun can't follow the RFC, I 
> really don't care.

Or it could close the input of the socket (note: nobody should be crazy 
enough to use this method, though, as I suppose it won't work in many 
cases). One of the three methods is required, otherwise the request is 
invalid. Of course, we could decide that Tomcat should instead consider 
these sort of requests (no content-length + no chunking) to have no body 
(in the HTTP processor) to get more robust handling, since the client 
obviously doesn't know what it's doing at this point. To summarize, this 
could break "legitimate" HTTP/1.0 POSTs

In prepareRequest, this block could be modified and the if (keepAlive) 
         if (!contentDelimitation) {
             // If there's no content length and we're using keep-alive
             // (HTTP/1.0 with keep-alive or HTTP/1.1), assume
             // the client is not broken and didn't send a body
             if (keepAlive) {
                 contentDelimitation = true;

Kevan, please provide a dump of the request causing the problem.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message