Re: Definition of "variant" and "requested variant", was: New "200 OK" status codes, PATCH & PROPFIND

Roy T. Fielding wrote:
>>>> 1) for PROPFIND and friends, not only request header fields and 
>>>> method names, but also the request *body* select the variant -- I 
>>>> don't have a problem with that, but it should be spelled out.
>>> I have lots of problems with that, though I don't think it impacts
>>> the definition of variant. What does PROPFIND specify in the body?
>>
>> For instance, the body specifies what properties to return. Thus, as 
>> far as I can tell, it needs to be taken into account in this 
>> definition, otherwise it won't help.
> 
> Generally speaking, a subset of properties should have the same etag
> as the whole set of properties.  I was wondering if the body also
> did resource selections, like depth=infinity.

...I don't think this is the case. It would be true if the only 
properties would be "dead" properties, but there are also live 
properties, and furthermore things a more complicated with REPORT and 
SEARCH.

For instance, I would expect that the following properties are handled 
completely separately, thus will have differently behaving etags:

- DAV:get* (such as DAV:getcontenlength), which will be tied to the 
requested variant upon GET,

- DAV:activelocks (depending on the locking subsystem), and

- DAV:displayname (stored somewhere else).

(I picked simple ones that are indeed implemented in Apache/httpd).

*PROPFIND* doesn't do resource selection depending on the body, but 
other methods such as REPORT and SEARCH do.

>>>> 2) a bigger problem IMHO is that allowing this additional level of 
>>>> indirection creates different classes of entity tags. Example: 
>>>> Entity tags returned in GET/HEAD/PUT/POST/DELETE can only be used 
>>>> for GET/HEAD/PUT/POST/DELETE. Similarly, for PROPFIND/PROPPATCH. I'm 
>>>> a bit concerned about that.
>>> It is already true in practice -- people just aren't aware of it, or
>>> are inserting fake etags just to comply with nonsense.  From my
>>> perspective, PROPFIND/PROPPATCH are incredibly bad protocols within
>>> a protocol (essentially, search and replace tunneled through other
>>> resource interfaces).  I don't need HTTP to make sense of them any
>>> more than I need it to make sense of POST requests.
>>
>> The whole point of my proposal is to build a bridge to "proper" 
>> resources, that can be retrieved using GET, and manipulated using 
>> PUT/PATCH.
> 
> Right, but you are also trying to make the HTTP model make sense
> for a method that intentionally violates the HTTP model.  It is
> easier just to say that PROP* is a search method that is separate from
> the HTTP model.

Whether it's intentional or not I'll not comment on (how would I know?). 
As far as I can tell from what's stated, PROPFIND does not violate that 
model, though.

> ...

Best regards, Julian

Received on Saturday, 18 August 2007 18:28:37 UTC