Bill, Bill, and Remy -- thanks for your help. I've raised bug 38030 -- http://issues.apache.org/bugzilla/show_bug.cgi?id=38030
FYI, I tested TC behavior with an HTTP 1.1 POST without a message body and no content-length. It worked, properly. However, I noticed an 8 second delay between request and response. I assume TC was blocking in a socket read until it timed out... That doesn't seem very desirable... Possible to target the fix for 5.5.14? --kevan On 12/22/05, Bill Stoddard <[EMAIL PROTECTED]> wrote: > > 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] > >
