RE: Last-Modified in chunked footer

If it were legal to have an empty Vary header the definition would be, I
would assume #field-name. However 1#field-name is used. Which indicates
that this header must have a value.

All this having been said I must admit that I wouldn't be surprised to
find out that buried somewhere in that 162 page spec is a line which
says "All headers can be empty".

			Yaron

> -----Original Message-----
> From:	David W. Morris [SMTP:dwm@xpasc.com]
> Sent:	Tuesday, September 16, 1997 4:31 PM
> To:	Yaron Goland
> Cc:	'rlgray@raleigh.ibm.com'; HTTP Working Group;
> http-wg@cuckoo.hpl.hp.com
> Subject:	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 20:34:39 UTC