Re: Comments on section 9.8, TRACE

Arthur P. Goldberg wrote:
> 
> Two of my students offer the following comments on 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.

1) The presence of an entity is signaled by the presence of an entity
header, such as Content-Length or Content-Type.  Without some indication
that there's an entity there, the server must assume there is none.

2) I don't necessarily agree with the assertion that the "server program
must check".  The statement that "a TRACE request MUST NOT include an
entity" is more a requirement on the client.  It equally well means that
if a client does send an entity, then there's no guarantee about how the
server might/must respond.

In particular, consider three scenarios:
a) If the server is written with the assumption that there's never an
entity, then, on a persistent connection, it would assume that the next
line that follows the end of the previous request would be a new request
line, not part of an entity.
b) OTOH, for that same example, if there happen to be entity headers in
the TRACE request (but there's no entity) and the server is written to
read an entity, even though one is not defined by the specification,
then the second request would be interpreted as an entity, not as a
request.
c) The server in the second example could instead return a 400 Bad
Request because there's an entity implied by the headers, but TRACE does
not permit one.

The specification is quite imprecise about what to do in many error
cases.  It is mostly concerned with what's supposed to happen if you do
things the right way.

3) The specification can't *force* the client (or server) to do
anything.  The "MUST NOT" you cite is about as good as you can do.  How
can you make the client "enforce this requirement"?  Either it does the
right thing or it doesn't.

> 
> From: Catalin Floristean <floriste@slinky.cs.nyu.edu>
> The specification states that if the request is "successful"
> it should return a 200 message containing the whole
> original request as message-body but does not define
> what successful means.  Understandably, it should be checked
> for correct syntax and semantics, but how far should the
> semantic check go?  Specifically, in the case where the
> Request-URI is the URL of a resource and not "*", should
> the origin server also make sure that the resource exists
> and is readable?  Since the intention is just to provide a
> loop-back trace method (otherwise a HEAD request would do),
> probably a syntax check and a basic semantic check (the
> protocol version, presence of the Host header containing
> the correct host/port in case of HTTP/1.1) should suffice
> and this fact should be clearly stated.

1) I think the wording "If successful, the response..." is poor
English.  (It isn't the response that's successful!)  Perhaps it should
say "If the request is valid, the response...."  What constitutes a
valid request is sprinkled through the specification.

2) I think the student is trying to read too much into the
specification.  The description of the response says only that the
request message should be returned as an entity.  It says nothing about
checking the Request-URI or the resource so-identified  The topic of
what to do when something is unstated often comes up in discussions here
(and I often raise them :-).  If the specification doesn't say to do
something anywhere, then don't do it.  In this case, a server might or
might not check the syntax of the Request-URI, but it need not check the
resource so-identified.

> 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've been here before.  "TE: chunked" doesn't say the server
*must* chunk the response.  It says the client would accept "chunked". 
But for an HTTP/1.1 request, that fact is implied and, therefore, the
header is redundant.

Dave Kristol

Received on Wednesday, 27 May 1998 08:17:50 UTC