Re: Last-Modified in chunked footer
Scott Lawrence (lawrence@agranat.com)
Mon, 08 Sep 1997 15:44:45 -0400
>>>>> "KH" == Koen Holtman <koen@win.tue.nl> writes:
KH> Did we already discuss the problem of a proxy which gets a chunked 1.1
KH> response and forwards it unchunked to a 1.0 recipient? It seems to me
KH> that, if we don't define something different explicitely, this proxy
KH> would be obliged to move all chunked footer-headers to the 1.0 message
KH> header before forewarding the response as a 1.0 response. This
KH> obligation would be a pain because it requires buffering of the whole
KH> response.
The only header fields legal in the trailer now are Content-MD5 and
Authentication-Info, neither of which are likely to be meaningfull
to an HTTP/1.0 browser.
Technically the Authentication-Info field is part of RFC2069 which
could be supported by a 1.0 browser, but the only reason for putting
Authentication-Info in the trailer is to support the digest
attribute. As far as we have been able to determine there are no
deployed browsers that support that attribute (if I am mistaken I'd
_love_ to hear about it), so the point is moot.
This thread began with the question of whether or not Last-Modified
and Vary should be allowed in the trailer to allow for accurate
values in the server side include case. The Last-Modified field is
usefull to a 1.0 browser, but if the proxy were to just drop it the
result would be at most one more request for that from the browser,
which the proxy could satisfy from the cache with the correct
Last-Modified header field.
I see no particular reason to forbid those two headers, but as I've
said before I think that at this late date the browser people should
get the last word on it.
--
Scott Lawrence EmWeb Embedded Server <lawrence@agranat.com>
Agranat Systems, Inc. Engineering http://www.agranat.com/