Re: Last-Modified in chunked footer

This discussion so far has concentrated on caches and dynamic services.
But take the user agent into account, and it looks totally different.

Johm Franks already mentioned why user agents will want to have the
content-type before the body.  That same reason applies at least to
content-encoding, content-language, content-base and content-location.
(For caching-related headers, considerations similar to those for proxies

On Wed, 3 Sep 1997, Jeffrey Mogul wrote:
> 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.

Eliminating that "MUST NOT" for servers means, whether this is made
explicit or not, that a new "MUST" is introduced for user agents:
they must be able to deal with the message body before receiving the
headers they may have to (or wish to) examine.  They must also be able
to function without knowing how complete the set of headers is, since
there is no way to say in the header before the body "wait for these
header fields to appear in footer".  I think these are unreasonable new

Consider also what happens when transmission of a response is interrupted,
either because of network failure or because of "pressing the STOP
button".  Als some resources are designed so that this is the only way to
end transmission, and a user agent doesn't always know when it is dealing
with such a resource.  In such cases the client will never know whether it
has received all the meta data.

> 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."
> Summary: ban hop-by-hop headers and Cache-control (and perhaps
> a few others, if I've missed them).  Allow all others in responses.

Note that such a change would apply by default to all new headers not
defined within the HTTP spec.  New headers like window-target or
content-disposition which get introduced outside of a wg standard process
would be legal in footers.  No doubt for some dynamic services it will be
more convenient to put them in the footer than at the beginning, so
they'll do that.  Some user agents would probably support a specific
header when it is received after the body, while others would not.  
Such icompatibilities can be avoided from the start, by continuing to
allow only explicitly approved header fields in the footer.

>     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 believe the MUST should stay as it is, for the benefit of clients, 
except for specific headers as it is now.  I am not arguing against
adding any specific headers (like the ones proposed) to the list of 
those allowed in footers, just against changing the default rule.


Received on Wednesday, 3 September 1997 14:11:39 UTC