RE: Last-Modified in chunked footer

"Vary:CRLF" *is* a syntatically correct header.
We ignore "Referer:CRLF" from Lynx and "Authorization:CRLF" from MSIE
all the time...

** Reply to note from Yaron Goland <yarong@microsoft.com> Mon, 15 Sep 1997 12:16:18 -0700
>   
> 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/
>   
> 
 

Richard L. Gray
chocolate - the One True food group

Received on Tuesday, 16 September 1997 10:01:07 UTC