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

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
`unknown'.

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

       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.
+
+

Koen.

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