- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 20 Oct 2006 21:44:38 +0200
- To: "Roy T. Fielding" <fielding@gbiv.com>
- CC: Henrik Nordstrom <henrik@henriknordstrom.net>, Jamie Lokier <jamie@shareable.org>, HTTP Working Group <ietf-http-wg@w3.org>
Roy T. Fielding schrieb:
>> But if we say (as you suggested):
>>
>> "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 the set of selecting request-headers present in the
>> new request match the corresponding set of stored request-headers in
>> the original request."
>>
>> In this case, the cache would have an entry where the set of stored
>> request headers is "Accept-Language", which isn't present in the new
>> request. Thus, the cache would be allowed to use the cached entry,
>> right (because the set of selecting response headers *present* in the
>> request is empty).
>
> Oh, that is not how I was interpreting "present" (the set is present, not
> the set of present header fields). It is actually unambiguous, but only if
> you parse the sentence carefully. Delete "present" if you like.
>
> The empty set {} != {"Accept-Language: de"}, and therefore the cached
> response will not be used.
Ah! Aha.
I think getting rid of "present" makes things clearer. How about the
"corresponding" then? What does it refer to?
It seems to me that the spec really needs to spell out more explicitly
what headers are being compared, what it means for a header not to be
present, and how the comparison function for each header works.
Best regards, Julian
Received on Friday, 20 October 2006 19:44:47 UTC