Rules for combining headers in a caching proxy...

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.

Note that this actually gives the origin server nearly as much control
over the response seen by the client as the "toss-it-all" rule; if the
origin server ships the same set of headers with the 304 response as
it did for the prior 200, the older headers *will* be completely
overridden.  The one thing that the origin server cannot do with the
revised rule is to cause the cache to *delete* a header from the cached
set.

If the intention of 13.4.3 really *is* to just toss it all, this
behavior should probably be limited to HTTP/1.1 origin servers (and
they should certainly be required to send the same set of headers with
the 304 as they would for a 200 --- i.e., to treat a conditional get
with the condition satisified exactly as if it had been a HEAD request).
  
My fairly quick read of the document thus far has left me with a few
more minor quibbles.  The definition of "variant" in section 1.3 is a
bit confusing --- the current text is:

  Each representation of that resource that corresponds to a different
  sequence of entities that could be returned for a requested resource
  is termed a variant.

This had me scratching my head for a bit (starting with "which
resource?") ---  perhaps something like:

  If multiple representations could be returned for a single requested
  resource, each such representation is termed a variant of that resource.

is simpler.  (Then again, perhaps it seems simpler to me because that's
the one which I wrote).

Section 8.1.3 specifies that a proxy server MUST NOT establish a persistent
connection with an HTTP/1.0 client.  This presumably applies even if the
HTTP/1.0 client sent an explicit "Connection: Keep-Alive".  I'm not
sure of the rationale for this rule (I am aware of the problems with
HTTP/1.0 proxies forwarding "Connection: keep-alive" headers, but the
proxy in this case is 1.1); a few sentences describing it would be
helpful.

On a lighter note, section 13.1.2 specifies that warnings may be
provided in Basque.  We have a Basque graduate student here who would
be pleased to provide Basque translations of any sample English
warning text, should they be desired for examples.

Finally, regardless of the quibbles above, this document is an
enormous improvement over draft-03.  I'd like to congratulate the
editorial group, and wish them a speedy convalescence and recovery.

rst

Received on Wednesday, 29 May 1996 18:09:09 UTC