- From: Scott Lawrence <lawrence@agranat.com>
- Date: Mon, 08 Sep 1997 15:44:45 -0400
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>>>>> "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/
Received on Monday, 8 September 1997 12:49:36 UTC