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: <jg@w3.org>
Date: Fri, 31 May 96 20:03:46 -0400
Message-Id: <9606010003.AA05893@zorch.w3.org>
To: Koen Holtman <koen@win.tue.nl>
Cc: Balint Nagy Endre <bne@carenet.hu>, rst@ai.mit.edu, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Here's a set of edits from Jeff I've applied we hope will close this out.
			- Jim

To: jg@w3.org
Cc: mogul@pa.dec.com
Cc: koen@win.tue.nl, fielding@avron.ics.uci.edu
Subject: EDITS to 13.4.3 (Combining Headers)
Date: Thu, 30 May 96 16:31:11 MDT
From: Jeffrey Mogul <mogul@pa.dec.com>
Content-Length: 2977

This is pretty much a complete rewrite, after the first few
sentences.

*** rev81.txt	Thu May 30 11:59:22 1996
--- rev81.txt.revised	Thu May 30 16:16:26 1996
***************
*** 4388,4416 ****
  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 this outgoing
! response. It uses the end-to-end headers from the incoming response, not
- from the cache entry.  Unless it decides to remove the cache entry, it
- must also replace the end-to-end headers stored with the cache entry
- with those received in the incoming response.
- 
- In other words, the complete set of end-to-end headers received in the
- incoming response overrides all end-to-end headers stored with the cache
- entry. The cache may add Warning headers (see section 14.45) to this
- set.
- 
- These rule allows an origin server to completely control the response
- seen by the client of a cache when the cache revalidates an entry, and
- may be necessary for preserving semantic transparency or for certain
- kinds of security mechanisms or future extensions.
- 
- 
  13.4.4 Combining Byte Ranges
  A response may transfer only a subrange of the bytes of an entity,
  either because the request included one or more Range specifications, or
--- 4388,4415 ----
  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 this outgoing
! response.  The end-to-end headers stored in the cache entry are used
! for the constructed response, except that any end-to-end headers
! provided in the 304 response MUST replace the corresponding headers
! from the cache entry.  Unless the cache decides to remove the cache
! entry, it MUST also replace the end-to-end headers stored with the
! cache entry with corresponding headers received in the incoming response.
  
! In other words, the set of end-to-end headers received in the incoming
! response overrides all corresponding end-to-end headers stored with the
! cache entry. The cache may add Warning headers (see section 14.45) to
! this set.
  
+ If a header field-name in the incoming response matches more than one
+ header in the cache entry, all such old headers are replaced.
  
!     Note: this rule allows an origin server to use a 304 (Not Modified)
!     response to update any header associated with a previous response
!     for the same entity, although it might not always be meaningful or
!     correct to do so.  This rule does not allow an origin server to use
!     a 304 (not Modified) response to entirely delete a header that it
!     had provided with a previous response.
  
  13.4.4 Combining Byte Ranges
  A response may transfer only a subrange of the bytes of an entity,
  either because the request included one or more Range specifications, or

-Jeff
Received on Friday, 31 May 1996 17:20:15 EDT

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