Bill Barker wrote:
"Bill Stoddard" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
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 www.apache.org 80
then type in:
POST /foo/bar HTTP/1.0
<enter>
<enter>
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.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
