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

Don't the default HTTP header semantics already provide the same behavior as Prefer (e.g. pass end-to-end and ignore if not understood)? If so then doesn't Prefer essentially create a new HTTP header system within HTTP? If so wouldn't it be easier to just get rid of the Prefer header and instead use new HTTP headers for values like Content-Returned?

In my original mail I was suggesting the following additional changes to the spec:
1. Put in a note clarifying that 209 is currently only defined for PUT/POST/PATCH.
2. Put in a note clarifying that it is legal (read: possible) to have a situation where after the method (E.g. PUT/POST/PATCH) is executed and before the GET response is generated additional changes might happen.

        Thanks,

                Yaron

> -----Original Message-----
> From: James M Snell [mailto:jasnell@gmail.com]
> Sent: Wednesday, August 29, 2007 9:08 PM
> To: Yaron Goland
> Cc: HTTP Working Group
> Subject: 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 Wednesday, 5 September 2007 21:01:38 UTC