W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1997

RE: Last-Modified in chunked footer

From: Yaron Goland <yarong@microsoft.com>
Date: Mon, 15 Sep 1997 12:16:18 -0700
Message-Id: <11352BDEEB92CF119F3F00805F14F48503A157E2@RED-44-MSG.dns.microsoft.com>
To: 'Scott Lawrence' <lawrence@agranat.com>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4417
Depending upon clients handling syntactically illegal headers in order
to implement a new mechanism is a guaranteed recipe for the disaster. 

For case evidence, look at what happened with cookies. 

As such I believe that any ruling which requires us to violate the
syntax given in RFC 2068 is a non-starter. I think we need to take our
lead from the 302/307 issue where a solution was produced which solved
the problem without punishing RFC 2068 implementers.


> -----Original Message-----
> From:	Scott Lawrence [SMTP:lawrence@agranat.com]
> Sent:	Monday, September 15, 1997 9:28 AM
> To:	http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> Subject:	Re: Last-Modified in chunked footer
> >>>>> "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/
Received on Monday, 15 September 1997 12:46:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:16:28 UTC