tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <kevan.mil...@gmail.com>
Subject Re: TCK Issue with Tomcat 5.5.12
Date Fri, 23 Dec 2005 19:37:09 GMT
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 <bill@wstoddard.com> wrote:
>
> Bill Barker wrote:
> > "Bill Stoddard" <bill@wstoddard.com> wrote in message
> > news:43AB0E1A.9070700@wstoddard.com...
> >
> >>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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message