RE: Last-Modified in chunked footer

Of course, some applications, which already implemented RFC2068, will
ignore most headers in the footer. So if last-modified or vary appear in
the footer then the message will be treated as if those headers were not
present.

Can we please try to not punish early implementers. I think our deal
with 307 was a really good example of how to fix broken things without
punishing those who choose to implement issued RFCs.

		Yaron

> -----Original Message-----
> From:	koen@win.tue.nl [SMTP:koen@win.tue.nl]
> Sent:	Monday, September 08, 1997 12:24 PM
> To:	lawrence@agranat.com
> Cc:	http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> Subject:	Re: Last-Modified in chunked footer
> 
> Scott Lawrence:
> >
> >  In principle, I would have supported the less restrictive rule that
> >  any header field can be sent in the trailer unless it is
> >  specifically required to be in the header, but I think it is very
> >  late in the game to be changing the rules on the client developers
> >  now.
> 
> I agree.  I propose that we put a list of `headers which may be in the
> footer' in the 1.1 spec.  We can further add a note to future protocol
> authors, telling them that whenever they define a header which is
> allowed in the footer of a HTTP/1.1 message, they should explicitely
> say so, because the HTTP/1.1 default is to disallow a header to be in
> the footer.
> 
> Did we already discuss the problem of a proxy which gets a chunked 1.1
> response and forwards it unchunked to a 1.0 recipient?  It seems to me
> that, if we don't define something different explicitely, this proxy
> would be obliged to move all chunked footer-headers to the 1.0 message
> header before forewarding the response as a 1.0 response.  This
> obligation would be a pain because it requires buffering of the whole
> response.  So we should either allow a proxy to drop the
> footer-headers when converting to 1.0, or there should at least be
> some
> advance notification that these headers will be present, so that
> buffering can be avoided most of the time.  The first alternative
> seems best to me.
> 
> >Scott Lawrence           EmWeb Embedded Server
> <lawrence@agranat.com>
> >Agranat Systems, Inc.        Engineering
> http://www.agranat.com/
> 
> Koen.