Re: i107

On mån, 2008-07-28 at 16:56 +0100, Mark Nottingham wrote:

> a) Allow a cache to return a response which doesn't match selecting  
> headers. For example, if a cached response has:
> 
> Vary: Accept-Encoding ; request had 'gzip'
> ETag: "123"
> 
> and a request comes in with
> 
> Accept-Encoding: deflate
> If-None-Match: "123"
> 
> the cache would be allowed to return it (doesn't make much sense), or

No it can't, unless the server says it's ok.

> b) define the set of representations that conditional requests apply  
> to on a per-method basis.

Some methods apply to the URI, some to the requested variant. Nothing
strange with that. Conditions always apply on the requested variant.

Remember that HTTP is defined in such way that each resource variant
SHOULD (but not MUST) have an unique URL of it's own, as indicated by
Content-Location. If you want to DELETE just a specific language then
this is the URL you use in DELETE. 

For PUT it's less obvious, as how a PUT updates the server state is
implementation defined. But my reading is that for PUT to
content-negotiation enabled request-URI then the content headers
(Content-*) possibly define the resource variant to be stored and
negotiated headers (i.e. Accept-* as indicated by Vary) the variant to
match in conditionals used in the PUT request.

PUT /resource HTTP/1.0
If-Match: "a"
Accept-Language: en
Content-Language: sv

MAY stores the Swedish variant of the resource IF

* the english variant exists and has etag "a"
* content-negotiation is enabled on the resource

The response to the PUT request then carries a ETag for the created
variant, and unique Content-Location, and Vary indicating the axis of
variance on the resource.

If content negotiation is not enabled for the request-URI then the PUT
simply replaces any existing resource (and all variants) at the request
URI. Many servers may well have this as the only implementation
requiring PUT on specific variant unique URLs to create or update
negotiated resources, and the structure of those is implementation
dependent and not specified in HTTP/1.1. 

Servers MAY also use 307 to the to be created variants unique URL if
seeing a PUT to a negotiated URL. But it's then not possible to build
conditions across variants as above. For many implementations this is
perhaps the cleaner approach.

Regards
Henrik

Received on Thursday, 31 July 2008 02:06:17 UTC