tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Stoddard <>
Subject Re: TCK Issue with Tomcat 5.5.12
Date Thu, 22 Dec 2005 22:21:31 GMT
Bill Barker wrote:
> "Bill Stoddard" <> wrote in message 
>>Remy Maucherat wrote:
>>>Bill Stoddard wrote:
>>>>Nope, that's incorrect.
>>>> From RFC2616, the official HTTP standard definition:
>>>>   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.
>>>>A bodyless POST request w/o a TE or CL header field is permitted by 
>>>>RFC2616. Of course, if the POST really does have a body, then bad things 
>>>>are guaranteed to happen.
>>>It's a HTTP/1.0 request. Is that still true ?
>>Yes, HTTP/1.1 servers can handle HTTP/1.0 requests.  Here's an experiment 
>>to try.
>>telnet 80
>>then type in:
>>POST /foo/bar HTTP/1.0
>>watch what happens. Apache httpd handles the request properly.
> Tomcat handles it much the same way for for a 404 ;-).

Got me, bad example ;-)

> However, I'm guessing that Httpd sets up an EOS-only bucket-brigade 

Yep, your right. HTTP input filter sets EOS on the input stream if a CL or TE header is not
received. The 
input filter does not consider the HTTP method (POST, GET, et. al). Consumers of the input
stream will know 
they are done when they read the EOS bucket off the stream.

> Given that the request is malformed under RFC1945, so Tomcat probably should 
> do the same thing (which is basically what Remy's patch does).

Humm... this is straight from from RFC1945:

Status of This Memo

    This memo provides information for the Internet community.  This memo
    does not specify an Internet standard of any kind.  Distribution of
    this memo is unlimited.

IESG Note:

    The IESG has concerns about this protocol, and expects this document
    to be replaced relatively soon by a standards track document.


so I am not sure of the utility in quoting RFC1945. I suspect (but don't know for sure) the
'standards track 
document' being referenced turned out to be RFC2069 followed by RFC2616.

I am not convinced the request is malformed by any recognized standard, but we can disagree
on this point so 
long as we all agree:
1. Tomat is an HTTP/1.1 compliant server
2. An HTTP/1.1 compliant server should be able to accept POST w/o a body
3. It is acceptable for an HTTP client to tell an HTTP/1.1 compliant server that it has no
body by omitting 
the TE and CL header fields (regardless of HTTP method type).

Assuming the request really is malformed, the dictum "Be permissive in what you accept, strict
in what you 
send" would suggest we not pedantically fail this particular request as malformed simply because
it sent 
"HTTP/1.0" in it's version field.


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

View raw message