W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 1996

TRACE: HTTP/1.1 open issue

From: Dave Kristol <dmk@allegra.att.com>
Date: Mon, 4 Mar 1996 22:14:14 -0800
Message-Id: <v01530502ad61870285c2@[]>
To: masinter@parc.xerox.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
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:

Transfer-encoding: chunked


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
28                                      ; count for line
Transfer-encoding: chunked
2                                       ; count for blank (CRLF) line

3                                       ; count for count of regurgitated chunk
7                                       ; count for regurgitated chunk + CRLF
3                                       ; count for end-of-chunks 0 + CRLF
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

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:42:57 UTC