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

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

From: Yaron Goland <yarong@microsoft.com>
Date: Thu, 2 Aug 2007 13:17:46 -0700
To: Stefan Eissing <stefan.eissing@greenbytes.de>, Roy T.Fielding <fielding@gbiv.com>
CC: Mark Baker <distobj@acm.org>, Lisa Dusseault <lisa@osafoundation.org>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <AE9A8CBCE1A9744D975A9FBBF822DD784FC1DACFF8@NA-EXMSG-C102.redmond.corp.microsoft.com>

I just lived through the issue of returning 'GET Equivalent' content on a method response in Web3S. In the originally released Web3S spec we stated that PUT/POST/UPDATE had to return what this list is discussing as the GET Equivalent content body on the response. But once the OPS folks got a look at that and explained what the bandwidth bills would look like if we did that things got flipped around. Now, by default, we will return 204s on successful responses and define a new header that clients can submit saying "BTW, I'd really like the GET equivalent response."

> -----Original Message-----
> From: ietf-http-wg-request@w3.org [mailto:ietf-http-wg-request@w3.org]
> On Behalf Of Stefan Eissing
> Sent: Thursday, August 02, 2007 1:04 AM
> To: Roy T.Fielding
> Cc: Mark Baker; Lisa Dusseault; ietf-http-wg@w3.org
> Subject: Re: [Fwd: I-D ACTION:draft-dusseault-http-patch-08.txt]
> Am 01.08.2007 um 20:36 schrieb Roy T. Fielding:
> > We don't have that problem today with PATCH, AFAIK.  There is no
> > reason not to define a 200 response to PATCH as being the same as
> > the representation that would have been received in a GET response
> > after the patch has been successfully applied.  Remember, we aren't
> > forcing the server to return 200 -- the server can choose which
> > status is returned.
> Since we are defining anyway, I am wondering how this works with
> clients that are not interested in such a response body. The only way
> they could avoid retrieving the body is to close connection.
> I imagine as use case clients that edit/add ID tags on a web resource
> and perform a binary patch. Most certainly that will be protected by
> ETags and the client will not be interested in retrieving the quite
> large representation again.
> Is it worth considering a way for him to say so, or is closing the
> connection the appropriate behaviour? Imagine someone like flickr...
> It sounds like a nice job for a new "Expect" request header. Let's
> say we call this "patched-content":
> PATCH /resource/x HTTP/1.1
> Host: www.example.com
> Expect: patched-content
> Content-Type: ...
> HTTP/1.1 417 Expectation failed
> ...
> <html><body>Sorry, we do not server content on a patch.</body></html>
> --
> Stefan Eissing
> <green/>bytes GmbH
> Hafenweg 16
> D-48155 Münster
> Germany
> Amtsgericht Münster: HRB5782
Received on Thursday, 2 August 2007 20:18:07 UTC

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