W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

Re: Rules for combining headers in a caching proxy...

From: Balint Nagy Endre <bne@carenet.hu>
Date: Thu, 30 May 1996 05:20:47 +0200 (MET DST)
To: "Robert S. Thau" <rst@ai.mit.edu>
Cc: http WG <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
Message-Id: <1267.bne@bne.ind.eunet.hu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/594
Robert S. Tau:
> Section 13.4.3 of draft 04-alpha-1 specifies a rule for how a cache
> should construct the headers of the response it sends its client when
> it has both a 304 Not Modified response from the origin server, and a
> confirmed-fresh entity body in the cache.  The guts of the rule are:
>   ... It uses the end-to-end headers from the incoming response,
>   not from the cache entry ...
>   ... the complete set of end-to-end headers received in the
>   incoming response overrides all end-to-end headers stored with
>   the cache entry.
> This rule *seems* to say that the cache should toss whatever headers
> it has cached, and replace that set in toto with whatever came in with
> the 304 (though I'm not quite sure this was actually the intention).
> In any case, the section on the 304 response itself (10.3.5) says that
> the origin server SHOULD only include headers which might be relevant
> to cache management; this seems to exclude headers like Content-type:
> which the ultimate client will probably require in order to deal
> properly with whatever entity it finally gets.
> FWIW, many existing HTTP/1.0 servers, including at least Apache and
> the Netscape-Communications/1.1 server I just probed at www.netscape.com,
> return very few headers with a 304 --- Content-type, for instance,
> being commonly omitted.  An HTTP/1.1 cache which sent only those
> headers received (perhaps as little as Server: and Date:) along with
> its cached entity-body probably would not be doing its clients a
> favor.
> If the intention of the text in 13.4.3 is that the response headers
> from the 304 should override any cached headers of the same type
> (e.g., the Content-Language supplied with the 304, *if received*,
> should override any previously cached Content-Language header or
> headers), it might be better to say something like the following
> (though it is admittedly wordier):
>   When a cache makes a validating request to a server, and the server
>   provides a 304 (Not Modified) response, the cache must construct a
>   response to send to the requesting client.  The cache uses the
>   entity-body stored in the cache entry as the entity-body of the
>   outgoing response.  The entity-headers are formed as follows:
>   If an end-to-end header was received with the 304 response, the
>   cache MUST discard any existing cached header or headers of the same
>   name, and replace them with the newly received headers.  The cache
>   retains all end-to-end headers which it has already cached, and which
>   were not replaced by newer headers received with the 304 response.
>   This new set of headers is then returned to the cache's client as
>   the entity-headers of the outgoing response.  The cache may add
>   Warning headers (see section 14.45) to this set.
This is in sync with my understanding of the caching discussions,
and the only way to live with 1.0 servers.
I see no good reasons to handle 1.1 servers differently.

Andrew. (Endre Balint Nagy) <bne@bne.ind.eunet.hu>
Received on Wednesday, 29 May 1996 20:26:49 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:17 UTC