TRACE: HTTP/1.1 open issue

To avoid his getting lost, I wanted to put the following item out as, I
believe, an open issue for HTTP/1.1.

I like the idea of the TRACE method.  However, I would like some discussion
about its intended use, which affects how it should be specified.

Here's my concern:  can TRACE take an Entity in the request?  If not, I see
no implementation problems, but TRACE is less useful.  (It would be nice to
replace any method, including POST and PUT, with TRACE and see what the
server thought it got.)  If so, either there must be a content-length, or
there must be chunks or MIME multipart to delimit it.  If either of the
last two, my question is:  what is the valid form for reflecting that
entity to the sender?  That is, must the server send the entity back to the
client exactly as it saw it?  Or can the server consume the entity and
regurgitate it in its favorite form?

Consider this request:

TRACE * HTTP/1.1
Transfer-encoding: chunked

1
a
1
b
1
c
1
d
1
e
0

Is this a (one of many, given that chunking can be done many ways) valid
response?  (Boy, is this hard to do, and I probably got it wrong!)

HTTP/1.1 200 OK
Transfer-encoding: chunked

18                                      ; count for response line
TRACE * HTTP/1.1
28                                      ; count for line
Transfer-encoding: chunked
2                                       ; count for blank (CRLF) line

3                                       ; count for count of regurgitated chunk
5
7                                       ; count for regurgitated chunk + CRLF
abcde
3                                       ; count for end-of-chunks 0 + CRLF
0
0                                       ; end of response chunking

The alternative (in case you're wondering) is that the server must reflect
back *exactly* what it got, including the exact incoming chunking or MIME
multipart separators.  I believe this alternative is unacceptably difficult
for the server:  for chunking, for example, the server cannot just read
everything "to the end", because it doesn't know where the end is unless it
interprets the chunks.  That means it would have to remember the chunk
sizes and reproduce them exactly, which, in turn, probably means two
separate routines to handle chunked input.

Dave Kristol

Received on Monday, 4 March 1996 22:13:38 UTC