RE: Last-Modified in chunked footer

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 15:50:38 UTC