- From: Yaron Goland <yarong@microsoft.com>
- Date: Sun, 14 Sep 1997 23:56:22 -0700
- To: 'Larry Masinter' <masinter@parc.xerox.com>, Jeffrey Mogul <mogul@pa.dec.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
If we are going to adopt the broader interpretation I would suggest language along the lines of: "A header included in the message-header of a message is overridden by headers of the same name included in a chunked transfer footer. Implementers need to be aware that RFC 2068 compliant servers and clients will ignore all headers but content-MD5 in a chunked transfer footer. Thus, for example, if a Vary header is dynamically generated, it would be reasonable to place a "Vary: *" in the message-header and then the proper Vary value in the footer. That way RFC 2068 clients and servers will not cache the document improperly thinking there was no Vary header at all." I realize it would be preferable to put in language where the same header in both message-header and in the footer were combined according to normal HTTP rules but that would break RFC 2068 compliant clients and servers. We can hopefully resolve this discrepancy in HTTP/1.2. Yaron > -----Original Message----- > From: Larry Masinter [SMTP:masinter@parc.xerox.com] > Sent: Saturday, September 13, 1997 8:21 AM > To: Jeffrey Mogul > Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com > Subject: Re: Last-Modified in chunked footer > > I like Jeff's proposal, even though it's a significant broadening > of the requirements for HTTP/1.1 recipients (both clients & servers) > to deal with header-fields in a chunked trailer, since I think > it goes a long way toward making HTTP more useful with dynamically > generated content. > > > In some cases, however (such as an indefinitely long server push), > > it is actually impossible to buffer the entire response at any > > point. In such cases, one clearly needs to put the headers > > before the content! This would seem to preclude the use of > > Content-MD5 (and some forms of Digest Authentication?) in these > > cases. > > I think that "indefinitely long server push" should be explicitly > disallowed. What's a robot to do, for example? I suppose this > is a different topic. > > Larry > > -- > http://www.parc.xerox.com/masinter >
Received on Monday, 15 September 1997 01:56:37 UTC