Re: PATCH draft

I'm applying most of these fixes, but have some questions.

On Jan 30, 2009, at 5:17 AM, Julian Reschke 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.

If we keep it, I suggest we expand the sentence: "The 303 (See Other)  
response can be used to direct the user agent to retrieve a cacheable  
resource with a new GET request, which will have the side effect of  
updating caches along the path."

>
> Section 2., paragraph 5:
> OLD:
>
>   Collisions from multiple requests are more dangerous than PUT
>   collisions, because a patch document that is not operating from a
>   known base point may corrupt the resource.  Clients wishing to apply
>   a patch document to a known entity can first acquire the strong ETag
>   of the resource to be modified, and use that Etag in the If-Match
>   header on the PATCH request to verify that the resource is still
>   unchanged.  If a strong ETag is not available for a given resource,
>   the client can use If-Unmodified-Since as a less-reliable safeguard.
>
> NEW:
>
>   Collisions from multiple requests are more dangerous than PUT
>   collisions, because a patch document that is not operating from a
>   known base point may corrupt the resource.  Clients wishing to apply
>   a patch document to a known entity can first acquire the ETag of the
>   resource to be modified, and use that Etag in the If-Match header on
>   the PATCH request to verify that the resource is still unchanged.   
> If
>   an ETag is not available for a given resource, the client can use  
> If-
>   Unmodified-Since as a less-reliable safeguard.
>
> 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.

>
>
> Section 2.2., paragraph 3:
> OLD:
>
>      *  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).
>      *  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.
>      *  The client attempted to modify a resource that has multiple
>         representations but the server was unable to choose which
>         representation to modify.
>   Conflicting modification:  Specified with a 412 (Precondition  
> Failed)
>      when a client uses either the If-Match or If-Unmodified-Since
>      request headers and attempts to apply a patch document to a
>      resource whose state has changed since the patch was created.  If
>      the server detects a possible conflicting modification and  
> neither
>      the If-Match or If-Unmodified-Since request headers are used, the
>      server can return a 409 (Conflict) response.
>   Concurrent modification:  When a server receives multiple concurrent
>      requests to modify a resource, those requests SHOULD be queued  
> and
>      processed in the order in which they are received.  If a server  
> is
>      incapable of queuing concurrent requests, all subsequent requests
>      SHOULD be rejected with a 409 (Conflict) until the first
>      modification request is complete.
>
> 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".

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?

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

Thanks,
Lisa

--- Scanned by M+ Guardian Messaging Firewall ---
Messaging Architects sponsors The Spamhaus Project.

Received on Monday, 2 February 2009 22:28:33 UTC