Re: Meaning of Vary header applied to non-existent headers

Alex Rousskov wrote:
> As you know, RFC 2616 defines Vary matching based on the existence of
> a LWS/merge transformation. Such transformation cannot add new or
> remove existing headers. Thus, IMO, a present header can never match
> an absent header. An absent header matches an absent header.

I agree totally with you, Alex.

> I would add Vary header unconditionally. Whether you want to disable
> caching depending on request properties is a question that goes beyond
> protocol semantics. The right thing to do would depend on the
> trade-off between more hits and fewer incorrect objects delivered.

Sure, forget about my caching preferences.  I wanted to know if it was
technically ok to add the Vary header unconditionally - and more
importantly, if that would work according to everyone else's reading
of the standard.

> Note that a valid Accept-Language cannot be empty. It is not clear,
> however, how an invalid header is supposed to be treated by the
> matching algorithm in the RFC.

Ok, but that's a different question from the one I'm interested in.

I would like to see the language of the standard clarified to cover
the case of absent headers mentioned in Vary, so that there is no
confusion.  The two paragraphs I cited seem contradictory, given a
strict reading of the language.

To cut to the precise language which is ambiguous:

   *all of the selecting request-headers present in the new request
   match the corresponding stored request-headers in the original
   request.*

In my understanding of English, if the marked text begin with "each"
instead of "all", it's unambiguous but means the wrong thing.  (It
means to try each selecting request-header in the new request, and one
at a time match it against the corresponding stored request-header).

"All" in that position can mean _either_ the same as "each", or that
all the new request-headers are taken as a set and matched against all
the stored request-headers as a set, in one single match operation.  It
depends how you parse the quantifier.

Matching as a set is wanted, and the next paragraph confirms that
interpretation, although it wasn't until you drew my attention to it
that it made sense to me that way.

Better language may be:

   When the cache receives a subsequent request whose Request-URI
   specifies one or more cache entries including a Vary header field,
   the cache MUST NOT use such a cache entry to construct a response to
-  the new request unless all of the selecting request-headers present
-  in the new request match the corresponding stored request-headers in
+  the new request unless the set of selecting request-headers present
+  in the new request matches the set of selecting request-headers stored in
   the original request.

   The selecting request-headers from two requests are defined to match
   if and only if the selecting request-headers in the first request can
   be transformed to the selecting request-headers in the second request
   by adding or removing linear white space (LWS) at places where this
   is allowed by the corresponding BNF, and/or combining multiple
   message-header fields with the same field name following the rules
   about message headers in section 4.2.

+  Headers may be named in the Vary field value which do not exist in
+  one or both requests.  Headers which are named in the Vary field
+  value and do not exist in one request are matched if and only if
+  the corresponding headers do not exist in the other request.

That last paragraph is a logical consequence of the preceding two
paragraphs, if you read them the right way.  However, I have read the
standard many times and implemented a HTTP/1.1 server, and not
understood that logical consequence until now.  So the extra
clarifying paragraph is suggested.

Thanks,
-- Jamie

Received on Monday, 23 February 2004 18:55:37 UTC