RE: Last-Modified in chunked footer

Am I missing something key here ... I interepreted Vary:CRLF as shorthand
meaning that the Vary: field was empty ... I didn't interpret CRLF as
a value but rather the normal header 'line' delimiters. 

Any other interpretation would clearly break HTTP as a empty line 
indicating end of headers would appear in the wrong place.

Dave Morris

On Tue, 16 Sep 1997, Yaron Goland wrote:

> Vary  = "Vary" ":" ( "*" | 1#field-name )
> field-name     = token
> token          = 1*<any CHAR except CTLs or tspecials>
> tspecials      = "(" | ")" | "<" | ">" | "@"
>                          | "," | ";" | ":" | "\" | <">
>                          | "/" | "[" | "]" | "?" | "="
>                          | "{" | "}" | SP | HT
> CTL            = <any US-ASCII control character
>                            (octets 0 - 31) and DEL (127)>
> CR             = <US-ASCII CR, carriage return (13)>
> LF             = <US-ASCII LF, linefeed (10)>
> 
> So CR is a 13 and LF is a 10, which makes them CTL, which are forbidden
> in tokens, which can not be used in a field-name, which thus can not be
> used in Vary. So it is syntactically incorrect.
> 
> As for Authorization, you have already been contacted by a Microsoft
> developer who will track down the problem and fix it.
> 
> 		Yaron
> 
> > -----Original Message-----
> > From:	rlgray@raleigh.ibm.com [SMTP:rlgray@raleigh.ibm.com]
> > Sent:	Tuesday, September 16, 1997 10:58 AM
> > To:	HTTP Working Group
> > Subject:	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 16:35:17 UTC