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

Re: Last-Modified in chunked footer

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Wed, 03 Sep 97 11:09:15 MDT
Message-Id: <9709031809.AA15072@acetes.pa.dec.com>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Larry Masinter:
    I think there are a lot of 'headers' that might want to appear in
    the 'trailer' from the point of view of the sender, but of course,
    a recipient cache want to use some of the header information to
    decide where to cache the incoming data.
    
It's not clear whether deciding "where" to cache the incoming data
is the biggest problem that a cache faces, or whether the response
headers have much to do with this.  (As far as I know, most caches
use some function of the URL, and some might not even store the
incoming data on disk until after forwarding it; you don't want to
add latency to the forwarding path, normally.)

A bigger issue might be deciding *whether* to cache the incoming data,
since if the answer is "no", then a proxy wouldn't have to allocate
space for the entire object before forwarding it.

But my guess (after having looked at only a few cache implementations)
is that there is no strong reason to prohibit servers from putting
headers in the trailer for either of these reasons.

Larry also says:

    I don't think we can continue to evalute these one-by-one, though.
    Is there some general principle to apply?
    
I'll note that in other contexts, you (Larry) have argued against
excessive use of MUST and SHOULD; I think this is the best principle
to apply here.  I've never really understood why the specification of
what can go into trailers has been so restrictive.  Once you allow
the possibility that a recipient has to parse at least some headers
in the trailer, this weakens (but doesn't eliminate) the argument that
allowing other headers here would increase implementation complexity.

Scott Lawrence writes:

    If the value of the header field may be dependant on the content,
    then it might be desirable to send that field in the trailer.

True, but it's not just the content per se; it's the process by
which the content is generated.

John Franks writes:

    A general principle which might make sense is that if the
    alternative to the header in the trailer is not sending the header
    at all, then we should allow it.  After all, the proxy can ignore
    it and be no worse off.  Vary does not quite fit in this situation,
    but I think a good case can be made for it.

How about turning that around?  I.e., instead of prohibiting what
is not explicitly allowed, as we do today, we should allow what
is not explicitly prohibited.  So, I would say "if putting the
header in the trailer makes it too late to be useful, then we should
prohibit that."

Putting "Vary" in the trailer does make it harder to construct
the cache-store key (since the Vary header says what request
headers participate in the key).  But this doesn't make a
trailer-ized Vary useless; it just increases the implementation
complexity a little.  (The simplest implementation, of course,
is "if you have just cached something and then discover that
a Vary in the trailer means that your cache key is wrong, then
immediately delete it from the cache."  This is "correct" with respect
to the spec for Vary, although it's not a good use of the cache!
But there are other implementation techniques that would work
better.)

On the other hand, one probably can't put "Cache-control" into
the trailer (not in general, anyway), because some of the directives
(e.g., "no-transform") affect what a non-caching proxy might do while
forwarding a response, before it sees the trailer.  And I believe
that most (all?) of the hop-by-hop headers could also affect the
forwarding behavior of a non-caching proxy.

Summary: ban hop-by-hop headers and Cache-control (and perhaps
a few others, if I've missed them).  Allow all others in responses.

In a request (e.g., PUT or POST), the situation is different, because
almost any of the request headers might be "selecting" without the user
agent realizing it.  I'm not quite sure what to say about this.

    However, the spec might say the server SHOULD put headers at the
    beginning rather than in a trailer if this is possible.

This seems too strong.  I would suggest a note of the form

	Note: the transmission of headers in the trailer of a
	message might reduce the effectiveness of proxy caches,
	and it is recommended that servers not do so except when
	it significantly simplifies their implementation or
	significantly increases their own performance.

-Jeff
Received on Wednesday, 3 September 1997 11:14:28 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:00 EDT