Re: 12, 14.43: resource arguments and conneg

koen@win.tue.nl (Koen Holtman) writes:
> Give me one month, and I can write a nice 10-page section,
> which people might might understand, that exactly
> defines how `understood variation' works.

Yikes...then how can you be so confident that this will be  
interoperably implemented?  In any case, since the current text is  
wrong, how about if I take one more crack at a conceptually simple  
description?

------------------------------

1.3. Terminology

required-variation header
	A request header is a required-variation header if this
	specification provides any circumstances under which the
	server MUST vary its response as a function of that header's
	value.  More specific notions of required-variation header
	can also be defined, by considering only those transactions
	which have some specified property (such as a given method).

argument-entity
	If a method allows an entity body in the request, the
	argument-entity of that method is the entity defined by the
	entity-body together with all entity-headers of the request.

method-call on a resource
	A network data object or service that can be identified by
	the combination of a URL (section 3.2), a method on the
	resource corresponding to that URL (section 9), and an
	optional argument-entity for the method (when applicable).

14.43. Vary

The Vary response-header field is used by a server to signal that  
the response entity was selected from the available representations  
of the response using server-driven negotiation (section 15).  The  
selected representation is always assumed to vary as a function of:
  * the method-call on the resource defined by the request;
  * all required-variation headers for that method-call.

The Vary field value indicates either that the given set of header  
fields (together with the assumed variations listed above)  
encompasses 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.  [...]

A Vary field value consisting of a list of field-names signals that  
the representation selected for the response is based on a  
selection algorithm which (aside from the assumed variations listed  
above) considers ONLY the listed request-header field values in  
selecting the most appropriate representation.  This selection  
algorithm MAY be assumed to remain unchanged (and thus apply to  
future requests) for the duration of time in which the response is  
fresh.

------------------------------


P.S.  I don't understand how it can make sense to let the Vary  
value depend on the (non-5xx) response code.  The cache is  
responsible for matching cached responses with suitable _requests_,  
whereas the response code is part of what the cache must calculate  
from the request, with the help of Vary headers.  (If I'm missing  
something, just stick the response code into the list of assumed  
variations.)

--------------------------------------------------------------------
Paul Burchard	<burchard@cs.princeton.edu>
``I'm still learning how to count backwards from infinity...''
--------------------------------------------------------------------

Received on Sunday, 2 June 1996 13:31:27 UTC