Re: Comments on section 9.8, TRACE

> From: Louis Discepola <disc7701@sparky.cs.nyu.edu>
> The protocol states that "a TRACE request MUST NOT include 
> an entity".  For someone writing a server program, this 
> requirement implies that the server program must check that 
> this condition is upheld.  But after reading a line of data 
> from a client, there is no way for the server program to 
> distinguish whether it received the first line of an entity 
> body or the fist line of a badly formatted request line.  It 
> cannot therefore reply with an accurate response code.  I 
> suggest that the HTTP/1.1 specification clearly force the client 
> side to enforce this requirement.

It can distinguish this with a CRLF pair.  Because a TRACE request 
cannot contain an entity as per the specification, then anything after 
the CRLF pair (not including additional CRLFs) would have to be 
considered the beginning of a new request.  However, another 
question to ask would be how a server should handle a TRACE 
request when a Content-Length header, for example, is included.  
Should the server simply read in the entity in any event even though 
it's forbidden by the spec (I'd think so, in keeping with being 
lenient), and then just not return it with the response?  Or should 
the server respond with the entire trace?  Or should the trace, in 
this case, be answered with a 400 status code?

> From: Catalin Floristean <floriste@slinky.cs.nyu.edu>
> Also, it would help if it were stated clearly that the 
> request headers apply to the trace response (e.g. a TRACE 
> request with a "TE: chunked" will have it response's 
> message body -- the trace -- chunked) and that a "*" URI is 
> allowed here (although this could be implied from other 
> sections).

I think we all missed the point of TE.  "TE: chunked" is never 
required since chunked encoding is *always* acceptable, correct, 
working group?

Adam



mailto:adam@cyber-guru.com

Received on Wednesday, 27 May 1998 14:24:34 UTC