W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 1997

RE: Last-Modified in chunked footer

From: Yaron Goland <yarong@microsoft.com>
Date: Mon, 8 Sep 1997 12:36:09 -0700
Message-Id: <11352BDEEB92CF119F3F00805F14F48503A15768@RED-44-MSG.dns.microsoft.com>
To: "'koen@win.tue.nl'" <koen@win.tue.nl>, lawrence@agranat.com
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4367
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

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.


> -----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.
Received on Monday, 8 September 1997 12:39:12 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:03 UTC