Re: PATCH draft

Lisa Dusseault wrote:
>> Section 2., paragraph 4:
>> OLD:
>>
>>   If the request passes through a cache and the Request-URI identifies
>>   one or more currently cached entities, those entries SHOULD be
>>   treated as stale.  Responses to this method are not cacheable, unless
>>   the response includes appropriate Cache-Control or Expires header
>>   fields or the response uses the 209 Content Returned status code as
>>   defined in Section 4.  The 303 (See Other) response can be used to
>>   direct the user agent to retrieve a cacheable resource.
>>
>> NEW:
>>
>>   If the request passes through a cache and the Request-URI identifies
>>   one or more currently cached entities, those entries SHOULD be
>>   treated as stale.  Responses to this method are not cacheable, unless
>>   the response includes appropriate Cache-Control or Expires header
>>   fields or the response uses the 209 Content Returned status code as
>>   defined in Section 4.  The 303 (See Other) response can be used to
>>   direct the user agent to retrieve a cacheable resource. [[anchor1:
>>   ???]]
>>
>> I'm not totally sure why we'd want 303 here. What's wrong with 200; 
>> it's not like the 303 ever would include a different URI in the 
>> Location header, right?
> 
> Right, but the 303 would direct the client to do a GET request to 
> presumably the same resource, which would then trigger caches to update 
> their copies -- even if the cache were oblivious to the meaning of PATCH.
> 
> I have no objection too keeping in 303 or taking it out, but I want to 
> make sure we remember why it was added before we flip-flop again.  
> Julian, let me know.

This seems to target the same use case as 209 and Content-Location (as 
proposed by Roy).

We really should converge on a single solution, so if we can make 
Content-Location work (potentially with an example in the PATCH spec amd 
an improvement in HTTPbis), that would be best.

> ...
>> Why exactly do we require a strong etag here in general?
> 
> This spec text doesn't require strong ETags to be used by the server.  
> It sidesteps the issue that we have no clue what a weak ETag would mean 
> and how a client could reasonably use it -- it just says what the client 
> can do if it gets a strong one.  Your proposed text could lead clients 
> very astray if a weak ETag was used as defined in RFC2616, and a PATCH 
> was applied to a document that has slight changes from what the client 
> thought it would be.

But it's the server that mints the etags (decided on strong vs weak), 
and also which implements a specific PATCH format. Thus, it seems, it's 
best to let the server decide whether it can execute a given conditional 
request.

 >...
>> I think in all these cases 422 is not the right choice, because the 
>> problem is not with the request, but the state of the resource.  Thus 
>> it seems 409 Conflict would be better.
> 
> What's wrong with 422?  It doesn't say that there's a problem with the 
> request necessarily, in fact the description says "this error condition 
> may occur if an XML request body contains ... semantically erroneous XML 
> instructions".

Yes, that is the request, isn't it? :-)

> It's unclear from the part of the text you quoted, do you think all of 
> the cases in the document are bad for 422 or just the 3 points you quoted?

Sorry, that was a result of rfcdiff being confused, and myself 
selectively pasting stuff into the mail.

Let's see:

>     * The client attempted to apply a patch document to an empty or non-existent resource, but the patch document chosen cannot be applied to an empty or non-existent resource.

I'd say that's 409 or 404.

>     * The client attempted to apply a structural modification and the structures assumed to exist did not exist (e.g. a patch which specifies changing element 'foo' to element 'bar' but element 'foo' doesn't exist).

My choice would be 409 (Conflict -- the current state of the resource 
doesn't allow the request to succeed)

>     * The client attempted to modify a resource in a way that would cause the resource to become invalid. For instance, a modification to a well-formed XML document that would cause it to no longer be well-formed.

No proposal for this one; a 422 might be ok here if the request will 
always fail, no matter what state the resource is in.

>     * The client attempted to modify a resource that has multiple representations but the server was unable to choose which representation to modify.

This would be content negotiation for write operations. This doesn't 
seem to work for PUT in the real world, so I wouldn't even mention it 
for PATCH (that is, always apply PATCH to a more specific URI, as 
returned in GET/HEAD's Content-Location).

> Do you think the 422 response is useful for anything in PATCH?

Maybe one of these cases (see above).

BR, Julian

Received on Monday, 2 February 2009 20:51:56 UTC