Re: some small comments on 04

[Thomas Broyer <t.broyer@xxxxxxxxxxx>]

Joe Gregorio wrote:

> On 6/14/05, Thomas Broyer <t.broyer@xxxxxxxxxxx> wrote: 
>  
>
> > So what about:
> >
> >    * if the server sends an ETag in response to a GET on a Member URI,
> >      the client SHOULD send an If-Match header in a PUT request to the
> >      same Member URI.
> >    
>
> Unless the client wants to intentionally overwrite the resource, in which
> case they can send an If-Match: "*".
>
> The wording in Section 13.3.4 makes this a MUST on the client
> side for GETs. I believe that making the If-Match: on PUT a MUST 
> for clients would increase interop. The server didn't send that ETag 
> just for the fun of it.
>  
OK for me.

> > If the server sent an ETag in response to a GET
> >      and doesn't receive an If-Match in a PUT, it MAY respond with a
> >      4xx status code
> >    
>
> That also seems reasonable. Again, the server sent that ETag for 
> a reason.
>
>  
>
> > [[need to resolve which 4xx code?]]. [[add wording
> >      on preconditions and 412 status code as in the W3C Note]]
> >    * if the server does not send an ETag in response to a GET on a
> >      Member URI, it might however use another mechanism to detect
> >      conflicts and concurrent versioning and MAY send a "409 Conflict"
> >      status code in response to a PUT on the same Member URI. The body
> >      of such a response SHOULD contain the representation of the
> >      Resource that would be returned in response to a GET. [[is this
> >      doable? or must a server send ETag to enable "versioning conflict
> >      checks"?]]
> >    
>
> I would like to have the wording of the spec *enable* using ETags to detect
> lost updates, without requiring it, and without ruling out other forms of 
> protection.
+1

> For example,  http://www.w3.org/1999/04/Editing/ covers only 
> detecting lost updates. It does not cover how to do Reserved
> Checkouts, which for some people might be a preferred mechanism.
>
> I believe the above additions to the APP would do just that, enable 
> ETag dection of lost updates, but not require it and not rule out other
> protection mechanisms.
>  
I think however that speaking about the 409-Conflict status code 
wouldn't be harmful: it's a guidance for other protection mechanisms. If 
an implementation uses some kind of "reserved checkout", it seems to me 
that it should send such a status code to indicate that the resource has 
been "locked" by someone else (this is still a conflict, isn't it?).

What about:
[
if the server does not send an ETag in response to a GET on a Member 
URI, it might however use another mechanism to detect conflicts and 
concurrent versioning and MAY send a "409 Conflict" status code in 
response to a PUT on the same Member URI. The body of such a response, 
if it's Content Type matches the one of the Resource, SHOULD contain the 
representation of the Resource that would be returned in response to a GET.
]
(not really well-phrased but...)

--
Thomas Broyer