Re: mid-course errors

>>>>> "HS: == Henry Sanders writes:

HS> Around the time of the LA IETF there was some desire to remove
HS> footers entirely from chunked T-E. Phill Hallam objected strongly
HS> to this, and a compromise was reached where Content-MD5 was allowed
HS> in the footer for 1.1 and future versions of HTTP might allow other
HS> headers. The issue was considered closed for draft 04 in
HS> http://www.ics.uci.edu/pub/ietf/http/hypermail/1996q2/0058.html .
HS> The wording has changed a bit since then (I vaguely remember that
HS> happening as an editorial change) , but I believe the intent is
HS> still the same, which is that only Content-MD5 is valid in an HTTP
HS> 1.1 chunked  footer.

>>>>> "JM" == Jeffrey Mogul <mogul@pa.dec.com>:

JM> Thanks for digging this up (although the message you cite doesn't
JM> specifically address this issue).  I probably ignored most of that
JM> discussion when it took place.

HS> I agree that the text could use some clarification. I think the
HS> simplest change consistent with my understanding of the intent
HS> would be to add a sentence to 14.16 saying "This header is allowed
HS> in the chunked Transfer-Encoding footer".

  As I recall, there was a consensus in Memphis that the
  Authentication-Info header should be allowed in the footer, and I've
  proposed wording both to clarify the paragraph that started this
  discussion and to add explicit statements allowing both
  Authentication-Info and Content-MD5 in the footer.  See:

    http://www.ics.uci.edu/pub/ietf/http/hypermail/1997q2/0063.html

HS> I seem to recall discussions about Content-Length as a chunked
HS> footer, and I seem to recall it was considered a bad idea.

  We did agree that Content-Length could be added by a Proxy, for what
  that is worth; it doesn't seem so different.

JM> But if the consensus is that Content-Length doesn't belong in the footer,
JM> then perhaps we need to define a new "footer-eligible" header that
JM> serves purpose that we are looking for: "Stop this response, I didn't
JM> mean it when I said '200' back in the header".  E.g., a new header
JM> called "Failed:" which can convey an updated status code and message.

  Our present implementation just closes the connection without
  sending the terminating (zero-length) chunk.  Browsers all seem to
  display some sort of error when you cut off a response in the middle
  if you've passed Content-Length in the header; we assume that they
  would do the same for this case.

--
Scott Lawrence           EmWeb Embedded Server       <lawrence@agranat.com>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/

Received on Wednesday, 16 April 1997 06:45:17 UTC