W3C home > Mailing lists > Public > ietf-http-ext@w3.org > April to June 1998

Re: "end-to-end" headers in HTTP/1.1 [was Re: Mandatory]

From: Henrik Frystyk Nielsen <frystyk@w3.org>
Date: Sat, 11 Apr 1998 09:42:56 +0900
Message-Id: <>
To: Jeffrey Mogul <mogul@pa.dec.com>, hardie@nic.nasa.gov
Cc: ietf-http-ext@w3.org
At 13:34 04/09/98 MDT, Jeffrey Mogul wrote:
>In context, it should be clear that an "end-to-end" header is one
>that MUST be delivered to the server that is the target of
>a request (unless the request isn't forwarded to that server at all).

I am not sure whether you mean this only goes for end-to-end header fields
in requests or also for header-fields in responses.

In any case, we can't say that - it simply doesn't work with existing HTTP
applications as well as what we write elsewhere in the HTTP/1.1 specification.

1) A proxy can change the encoding as well as transform the contents in
several other ways. These characteristics are all described using
end-to-end header fields inserted, changed, or deleted by the proxy. Note
that his may happen on a PUT as well as on a GET - it goes both ways. The
no-transform cache control directive which can be used to avoid this is
both a request and a response directive (there is a problem with the
warning header that I have described in a separate mail).

2) Applications like a PICS (or some other content filtering mechanism)
enabled proxy can filter contents on behalf of the people it serves.
Typical examples of this is schools using proxies for accessing the Web.
The proxy looks for PICS headers and filters the content according to a set
of rules agreed upon by the school authority.

3) An annonymizing proxy that takes out user agent generated header fields
and inserts its own instead is also a commonly used application.

Ted is right, btw. that caching is different - it was a bad example I used
in my previous mail, sorry!

The above examples are all cases of "smart" proxies performing an operation
on behalf on somebody else, either because it has an out-of-band agreement
or because it is explicitly allowed to do this within HTTP. The operation
can involve one or more header fields but does not have to included the
whole message.

Looking at deployed applications and how people are using HTTP, we can't
change the policy now and not allow this behavior - it has been there all
along. The current wording in the Mandatory draft reflects this use of the
term end-to-end.

I fail to see why you want to impose this restriction (in HTTP as well as
in Mandatory)? I very much agree with Paul that this form for flexibility
is crucial to HTTP.

>You cannot separate an end-to-end header from the request of the
>request (or response).

The only thing that it truly end-to-end in the sense that it must be
performed by the origin server is generating the initial response to a
request. This response may then under certain circumstances be cached and
reused but the first must come from the origin server.

And even then, this is only true for responses with status codes which are
not explicitly defined otherwise. This is for example the case with 504
(Gateway Timeout).

Henrik Frystyk Nielsen,
World Wide Web Consortium
Received on Saturday, 11 April 1998 04:42:36 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 1 July 2021 15:49:08 UTC