RE: Last-Modified in chunked footer

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.


> -----Original Message-----
> From:	Larry Masinter []
> Sent:	Saturday, September 13, 1997 8:21 AM
> To:	Jeffrey Mogul
> Cc:
> 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
> -- 

Received on Monday, 15 September 1997 01:56:37 UTC