Re: [Fwd: I-D ACTION:draft-dusseault-http-patch-09.txt]

Grr... Yaron, I'm sure you're a good person and all but your mail
clients inability to wrap lines of text sucks. ;-)

In any case.. some comments below (with the quotes from you manually
wrapped ;-) ..)

Yaron Goland wrote:
> As part of the Web3S effort I need to define the equivalent of "Prefer: content-returned" and 209.
> 
> My current intention is to introduce a dedicated HTTP request header called "Web3SGetResponse" 
> whose semantics are the same as content-returned. The reason why I have chosen not to use Prefer 
> is that I am uncomfortable with placing all "safe to ignore" headers in HTTP into a single Prefer 
> header. In other words I can't figure out what kind of 'safe to ignore' header wouldn't end up in 
> Prefer and putting everything into Prefer just doesn't seem right.

The semantics of Prefer are clear... it's where the client can tell the
server what behaviors it would like the server to implement without
placing any requirements on the server.  While it certainly could be
overloaded to do lots of other things, doing so would definitely be a
mistake.  That possibility, however, does not lessen the value of the
Prefer header.

> 
> I choose the name "Web3SGetResponse" to indicate that I'm not trying to solve the general problem,
> I'm just solving a specific problem in the context of Web3S. If a more generic solution is agreed upon 
> I would be happy to use it. But my vote in that case would be not to use the Prefer header but to 
> introduce a dedicated "please give me a 209" header.

I'm all for solving specific problems with targeted solutions.  However,
this one in particular seems to be generic and broadly applicable enough
that a general solution is well waranted.

> 
> 209, on the other hand, makes sense to me. My litmus test for HTTP response codes is 
> "Can a client, without domain specific knowledge, do something useful with the code?" If the 
> answer is 'no' then re-use an existing code like 200 or 400. If 'yes' then adding a new code 
> makes sense. In this case 209 seems to meet the bar so I am just using it and referencing>
> draft-dusseault-http-patch-09 in my spec.
>

Good to hear.

> In reading sections 3 and 4 it would seem to a naïve reader (e.g. me) that 
> Prefer: content-returned and 209 could be used with any method. But I could only 
> figure out how to make it make sense for PUT/POST/PATCH. So in my own spec, at least
> for Web3S resources, I have restricted Web3SGetResponse and 209 to only be used on 
> PUT/POST/PATCH (although we still use the name UPDATE, but that's a whole other discussion).

That's perfectly fine.  Not all status codes make sense for all methods
in every case, that's true for all of the codes defined in RFC2616 and
its true for 209.

> 
> In my current spec I threw in some language that basically says that a 209 response 
> might include content that goes beyond the changes in the associated method. E.g. in 
> theory the following is legal according to my spec:
> Time 0 - Issue PUT with Web3SGetResponse
> Time 1 - PUT succeeds
> Time 2 - Another method that changes the resource's state is successfully executed
> Time 3 - The 209 response body to the PUT received at Time 0 is created and returned
> It isn't clear to me if this behavior is legal according to the PATCH spec.

assuming that 0, 1 and 3 all fall within the scope of a single HTTP
request-response then yes, this should likely be the expected behavior.
 I wouldn't go so far as to say that it MUST work this way, however.

> 
> Also I put in some text that said that 209s can, in theory, be returned 
> even if a client hasn't specified Web3SGetResponse but it isn't encouraged. 
> I wasn't sure if this is legal according to the PATCH spec.

Yes, this would be fine.

- James

Received on Thursday, 30 August 2007 04:08:30 UTC