Re: Last-Modified in chunked footer

Scott Lawrence (lawrence@agranat.com)
Mon, 15 Sep 1997 12:27:32 -0400 

>>>>> "YG" == Yaron Goland <yarong@microsoft.com> writes:

YG> "A header included in the message-header of a message is overridden by
YG> headers of the same name included in a chunked transfer footer.
YG> Implementers need to be aware that RFC 2068 compliant servers and
YG> clients will ignore all headers but content-MD5 in a chunked transfer
YG> footer. Thus, for example, if a Vary header is dynamically generated, it
YG> would be reasonable to place a "Vary: *" in the message-header and then
YG> the proper Vary value in the footer. That way RFC 2068 clients and
YG> servers will not cache the document improperly thinking there was no
YG> Vary header at all."

  I'm not comfortable with the idea of overriding a value in the
  header; this is (as Yaron pointed out) in conflict with the normal
  rules for combining multiple instances of a header field.  However,
  this is not such a problem if the header field in the message header
  has _no_ value.  To use Yarons example, if a Vary header is to be
  dynamically generated, the server would place 'Vary:CRLF' in the
  message header and a normal Vary header in the trailer.

  This would produce some change to the existing parsing rules, but
  might provide a usefull hint for many cases.

  I almost suggested this back when I had misinterpretted the wording
  of 2068 to mean that Content-MD5 was specifically forbidden in the
  trailer.  I had assumed that implementors did not want to perform
  the MD5 calculation just in case the digest apeared in the trailer
  (reasonable), and thought that we could signal that the value would
  be in the trailer by sending an empty Content-MD5 in the header.

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