W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2008

RE: i69: Clarify "Requested Variant" [was: New "200 OK" status codes, PATCH & PROPFIND]

From: Brian Smith <brian@briansmith.org>
Date: Thu, 14 Feb 2008 11:33:36 -0800
To: "'HTTP Working Group'" <ietf-http-wg@w3.org>
Message-ID: <006201c86f40$7eeab440$6501a8c0@T60>

Mark Nottingham wrote:
> PROPOSAL: Remove 'requested variant' from terminology and 
> define 'selected representation' as (roughly): "The 
> representation that would be returned by the server if the 
> request method were GET, taking into consideration selecting 
> headers, as specified by the Vary header's payload."


> PROPOSAL:
> A 201 response MAY contain an ETag response header field indicating  
> the current value of the newly created resource's selected  
> representation ETag (i.e., the ETag that would be returned if 
> the same selecting headers had been sent in a GET request to it).

> > 10.2.5 (204 No Content):
> >> The server has fulfilled the request but does not need to 
> >> return an entity-body, and might want to return updated 
> >> metainformation. The response MAY include new or updated
> >> metainformation in the form of entity-headers, which if
> >> present SHOULD be associated with the requested variant.
> >
> > This makes internal sense; see comments about adjusting the  
> > definition above.
> 
> PROPOSAL: s/requested variant/selected representation/

There are many servers deployed that do not implement this. In
particular, there are servers that will return an ETag for an
uncompressed variant of the newly-created resource in a "201 Created",
ignoring the Accept-Encoding header of the POST that created the
resource. But, if the same Accept-Encoding header is used in a GET to
the selected representation, a different ETag (the one for the
compressed variant) would have been returned. And, similar problems
arise with entity headers (in particular, Content-MD5, Content-Length).
Such servers are currently conforming with RFC 2616 but would become
nonconforming if the proposed changes were made.

The Vary header cannot be used here because the server might not have
varied its response to the POST/PUT/DELETE, but it may vary its response
to a GET on the newly created resource. Also, as was mentioned by other
people, the response often depends on the request body, but there is no
way to indicate that except with "Vary: *", which is useless for what is
intended here.

> > 14.14 (Content-Location)
> >> The Content-Location entity-header field MAY be used to 
> >> supply the resource location for the entity enclosed in the
> >> message when that entity is accessible from a location separate
> >> from the requested resource's URI. A server SHOULD provide
> >> a Content-Location for the variant corresponding to the
> >> response entity; especially in the case where a resource has
> >> multiple entities associated with it, and those entities
> >> actually have separate locations by which they might  
> >> be individually accessed, the server SHOULD provide a Content- 
> >> Location for the particular variant which is returned.

> PROPOSAL: s/for the variant//; s/the particular variant/the 
> particular representation/

I suggest keeping the first sentence, and dropping everything after.
Elsewhere in the specification, include the advice that resources with
multiple representations should make each representation available at a
distinct URI.

> > 14.25 (If-Modified-Since)
> >> The If-Modified-Since request-header field is used with a 
> >> method to make it conditional: if the requested variant has
> >> not been modified since the time specified in this field, an
> >> entity will not be returned from the server [...]

> > 14.28 (If-Unmodified-Since)
> >> If the requested variant has been modified since the specified  
> >> time, the server MUST NOT perform the requested operation, 
> >> and MUST return a 412 (Precondition Failed).

> > Interestingly, Last-Modified validation is defined in terms of  
> > 'requested variant', whereas ETag validation (If-Match, If-None- 
> > Match) seem to go out of their way to say that *any* entity that  
> > meets the conditional can be returned, and never mind the 
> > selecting headers. I'd be interested in hearing if any
> > implementations actually do that, and unless some are found,
> > I'd suggest we need to tighten up how ETag validation is defined..

This implies that A PUT/POST/DELETE with an If-Modified-Since or
If-Unmodified-Since applies to a specific representation. But, there is
no way to select a specific representation for any method whose response
entity isn't a representation of the resource. I suggest "if the
requested variant" should be replaced by "if any representation". This
also makes it consistent with If-Match and If-None-Match.

- Brian
Received on Thursday, 14 February 2008 19:33:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:37 GMT