RE: Last-Modified in chunked footer

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.

		Yaron

> -----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