Getting back to last week's discussion ...

>>You've got a problem here.  The definition of Vary is such that the
>>server is required to send all header field-names that might impact
>>the request content on any *future* request, not the current response.
>>Thus, with your example, the only compliant response would be
>>
>>     HTTP/1.1 200 OK
>>     Vary: *
>
>I don't think I agree. It is true that it should be for all future requests
>but these are future requests (within its freshness time) issued to the
>caching proxy which caches this particular response and not the origin
>server which I think is different. Section 14.43 says that
>
>"When the cache receives a subsequent request whose Request-URI specifies
>one or more cache entries including a Vary header, the cache MUST NOT use
>such a cache entry to construct a response to the new request unless all of
>the headers named in the cached Vary header are present in the new request,
>and all of the stored selecting request-headers from the previous request
>match the corresponding headers in the new request."
>
>...
>
>and later in the same section that "A cache MAY assume that the same
>selection will be made for future requests with the same values for the
>listed field names, for the duration of time in which the response is fresh."
>
>The difference is that for the cached entity, the vary header is true,
>whereas it may not be true for all time for the resource on the origin
>server. This does not break anything in the cache and it is still
>guaranteed to operate semantically correct.

Hmmm, your argument makes sense, but section 12.1 says

   HTTP/1.1 origin servers MUST include an appropriate Vary header field
   (section 14.43) in any cachable response based on server-driven
   negotiation. The Vary header field describes the dimensions over
   which the response might vary (i.e. the dimensions over which the
   origin server picks its "best guess" response from multiple
   representations).

and 13.6 says

   A server MUST use the Vary header field (section 14.43) to inform a
   cache of what header field dimensions are used to select among
   multiple representations of a cachable response. A cache may use the
   selected representation (the entity included with that particular
   response) for replying to subsequent requests on that resource only
   when the subsequent requests have the same or equivalent values for
   all header fields specified in the Vary response-header. Requests
   with a different value for one or more of those header fields would
   be forwarded toward the origin server.

and 14.43 says

   Field-names listed in Vary headers are those of request-headers. The Vary
   field value indicates either that the given set of header fields
   encompass the dimensions over which the representation might vary, or
   that the dimensions of variance are unspecified ("*") and thus may
   vary over any aspect of future requests.

>The origin server can only use the vary header to describe what has been
>part of its selection when issuing the response. If this is not true then
>only a vary header with a value "*" can be used as nothing else can be
>guaranteed.

I think that what we'll need to do then is to rewrite the rest of the
Vary definition (and probably move it into one place instead of three)
so that there isn't a contradiction. 

>...
>What is bad about the example that I gave was that if every instance
>defines its own private map originator ID, the you will get a very big vary
>header. This is of course not a good solution. Instead, the server should
>define (which should maybe be a part of PSP itself) a special map
>originator ID header which would then only have a single entry in the vary
>header.

I'm not sure if that would help, since the Vary has to be on something in
the client's request.  That would also be equivalent to a required cookie,
which would suck.

>>Why not just do what I suggested earlier and simply define
>>
>>   all new header fields that start with "{" shall obey the
>>   PEP self-descriptive grammar, which would include the URI
>>   for semantics, strength, scope, and parameters.
>>
>>Alternatively, define it as all field-names that start with "PEP-",
>>and reserve "PEP-method" as containing a URL that defines the meaning
>>of the request method.
>
>Hmmm, how would any of these representations solve the caching problem above?

They would use multiple standard names instead of creating a dynamic
name or putting everything under a single name.  Basically, it would ditch
the notion of name collisions being a problem (they haven't been in practice).

>>The final alternative is to just drop PEP for HTTP/1.x and instead
>>code it directly into the binary encoding of header fields for HTTP/2.x.
>
>With the time it took to develop HTTP/1.1 I would be very frustrated about
>not having anything that is workable now instead of 2 years from now. I
>don't think that it is necessary even though you are right that it would
>make certain things easier. The RTSP folks are in fact considering to
>enable support from day one in their new protocol. This avoids the method
>name game and make the integration much easier.

I still don't understand why it will take so long to deploy a binary
encoded HTTP.  OTOH, I don't understand why it hasn't happened already.
I guess we can talk about it next week.

....Roy