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

(VARY) Removal of `Vary: {unknown}'

From: Koen Holtman <koen@win.tue.nl>
Date: Tue, 9 Apr 1996 23:29:58 +0200 (MET DST)
Message-Id: <199604092129.XAA06592@wsooti04.win.tue.nl>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Cc: Koen Holtman <koen@win.tue.nl>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/207

I have received several comments to my proposed text for the Vary
header indicating that people don't like my current proposed `other'
and `unknown' parameters, because HTTP/1.1 caches have to treat them
both in the same way.

Larry Masinter suggested that I remove `unknown' and keep the
semantically equivalent `other'.  This sounds like a good idea to me.

Some background: I included `unknown' because there was an `unknown'
parameter in the Vary header text by David Robinson.  I cannot rule
out that there is a good reason, unknown to me, to have `unknown'.  On
the other hand, David Robinson may have just included `unknown' as a
rhetorical device to ease defining the required behavior when
encountering unknown extension-parameters.

If you want to keep `unknown', now is the time to speak up.  

I'll be working on the assumption that nobody wants to keep `unknown',
until I get mail from someone who does want to keep it.  The next
version of the Vary header text I post will therefore probably remove

For reference, here is the text I have currently on `other' and

       Vary                 = "Vary" ":" 1#selection-parameter

       selection-parameter  = field-name
                            | "{" "accept-headers" "}"
                            | "{" "other" "}"
                            | "{" "unknown" "}"
                            | "{" extension-parameter "}"

       extension-parameter  = token


+  The inclusion of the "{other}" parameter in a Vary field signals
   that parameters other than the contents of request headers, for
   example the network address of the sending party, play a role in
   the selection of the response.

+     Note: This specification allows the origin server to express
+     that other parameters were used, but does not allow the origin
+     server to specify the exact nature of these parameters.  This
+     is left to future extensions.

+  The "{unknown}" parameter signals that the origin server is not
   willing or able to specify the selection parameters used.  If an
   extension-parameter unknown to the cache is present in a Vary
+  header, the cache must treat it as the "{unknown}" parameter.

+     Note: HTTP/1.1 caches have to treat the "{other}" and
+     "{unknown}" parameters in the same way.  For example, presence
+     of the response header
+       Vary: accept-language, {other}
+     requires the same caching behavior as does the presence of 
+       Vary:  {unknown}
+     Use of the "{unknown}" parameter is discouraged.  Header fields
+     which use "{other}" are more readable for humans, and better
+     support the use of heuristics to improve caching performance.

Received on Tuesday, 9 April 1996 14:39:16 UTC

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