W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2007

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

From: Yaron Goland <yarong@microsoft.com>
Date: Wed, 29 Aug 2007 17:34:26 -0700
To: James M Snell <jasnell@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <AE9A8CBCE1A9744D975A9FBBF822DD785FC3D06D22@NA-EXMSG-C102.redmond.corp.microsoft.com>
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.

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.

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.

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).

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.

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.

Just my two cents, your mileage may vary,



> -----Original Message-----
> From: ietf-http-wg-request@w3.org [mailto:ietf-http-wg-request@w3.org]
> On Behalf Of James M Snell
> Sent: Wednesday, August 22, 2007 4:59 PM
> To: HTTP Working Group
> Subject: [Fwd: I-D ACTION:draft-dusseault-http-patch-09.txt]
> FYI... Updated based on recent discussions.
> - James
> -------- Original Message --------
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>         Title           : PATCH Method for HTTP
>         Author(s)       : J. Snell, L. Dusseault
>         Filename        : draft-dusseault-http-patch-09.txt
>         Pages           : 15
>         Date            : 2007-8-22
> Several applications extending HTTP require a feature to do partial
>    resource modification.  Existing HTTP functionality only allows a
>    complete replacement of a document.  This proposal adds a new HTTP
>    method, PATCH, to modify an existing HTTP resource.
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-dusseault-http-patch-09.txt

> [snip]
Received on Thursday, 30 August 2007 00:34:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:43 UTC