Bug 38030

Summary: HTTP 1.0 POST Request without a message body improperly receives a 403
Product: Tomcat 5 Reporter: kevan <kevan.miller>
Component: Connector:HTTPAssignee: Tomcat Developers Mailing List <dev>
Severity: major    
Priority: P2    
Version: 5.5.12   
Target Milestone: ---   
Hardware: Macintosh   
OS: Mac OS X 10.4   

Description kevan 2005-12-23 20:29:25 UTC
An HTTP 1.0 POST request with no message body and no content-length attribute
will receive a 403 "The request body was too large to be cached during the 
authentication process" Response.

Although the validity of the POST request can be called into question, the
Tomcat response is clearly counter to RFC 2616 Section 4.3 ( The presence of a
message-body in a request is signaled by the inclusion of a Content-Length or
Transfer-Encoding header field in the request's message-headers).

I've tested an HTTP 1.1 POST without a message body and no content-length
attribute. Although Tomcat handles it properly, Tomcat seems to block in a read
attempting to read a message body (I see an 8 second delay between POST Request
and the Response). Although that behavior is "correct", I think it could be
accurately described as "undesirable".

Thanks to Bill Barker, Remy Maucherat, and Bill Stoddard for their help on
dev@tomcat.apache.org. On dev, Remy proposed removing the "if (keepAlive)" from
the following fragment (I presume it applies to both Http11Processor.java and
Http11AprProcessor.java). I have not tested this fix...

         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;
Comment 1 william.barker 2005-12-29 09:00:09 UTC
This is now fixed in the SVN trunk, and will appear in 5.5.15.
Comment 2 william.barker 2005-12-29 09:40:29 UTC
(In reply to comment #1)
> This is now fixed in the SVN trunk, and will appear in 5.5.15.

Urm, this in no way means that I don't agree with Remy that the TCK test is 
completely invalid.  It really s*cks when Tomcat has to program around bugs in 
Sun's test, for no other reason than that the test author is completely brain-