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

From: "Mark Baker" <[email-masked]>
Date: Wed, 1 Aug 2007 00:26:19 -0400

On 7/31/07, Lisa Dusseault <[email-masked]> wrote:
>
> On Jul 31, 2007, at 9:59 AM, Mark Baker wrote:
>
> > Hi Lisa,
> >
> > On 7/31/07, Lisa Dusseault <[email-masked]> wrote:
> >> If we allow the server to return arbitrary bodies in a 200 response
> >> to a PATCH, we'll have to be very clear on how clients should handle
> >> the returned information.  A caching or synching client might use the
> >> body as the new representation of the resource regardless of what
> >> headers appeared in the 200 response.
> >
> > That would be a broken client, AFAICT.
>
> Interesting!  What's your basis for believing that?

Just from the meaning of PATCH.  It's purpose is just to affect a
state change on the server, and isn't requesting that anything
specific be returned in the response, just like PUT and POST.
Therefore there's no reason to limit the meaning of what might be
returned.

>    Would a client
> that cached the body of a 200 OK response in response to a GET behave
> correctly if it cached the body regardless of whether there was a
> Content-Location header?  According to my reading of 2616, the
> Content-Location header might or might not be there if the response
> contains a representation of the resource.

GET's different because it is requesting that the response body
include a representation of the resource identified by the
Request-URI.  The meaning of the response body is predetermined.

>
>
> > Are you aware of any software
> > which behaves this way?
>
> No, because we don't have PATCH clients implemented yet.

How about for PUT and POST?

> > The normal meaning from 2616 seems to be "the request was successful,
> > here's some data".  I don't see any reason to be more specific than
> > that.
>
> The 200 OK response for GET is certainly more specific than that --
> the data has a specific context, address and cache behavior
> intended.  That's what I'm driving at for PATCH.

GET is certainly different.  Indeed, GET responses are not
self-descriptive precisely because the response body has a fixed
meaning, but that fact isn't indicated in the message.  I think PUT
and POST make more appropriate role models for PATCH though.  Heck,
PATCH is just an optimized PUT.

Mark.
-- 
Mark Baker.  Ottawa, Ontario, CANADA.         http://www.markbaker.ca
Coactus; Web-inspired integration strategies  http://www.coactus.com

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 1 Aug 2007 11:36:35 -0700

> Therefore there's no reason to limit the meaning of what might be

That's backwards.  If we had the choice of doing so at the time, PUT
would have been defined such that 200 responses would be the same as
if the method had been GET (i.e., return the resulting representation
after the PUT was applied) and 204 would be success without a body.
The only reason we did not define it that way is because some of the
existing, deployed implementations were inconsistent (because they
were deployed before 204 was available).

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.

....Roy

---

From: "Mark Baker" <[email-masked]>
Date: Wed, 1 Aug 2007 15:02:26 -0400

Hi Roy,

> forcing the server to return 200 -- the server can choose which

Sure, but if the server wants to signal a successful PATCH, then it's
stuck with 2xx.

What if, for example, a server wanted to respond to a successful PATCH
attempt with a document which revealed (via hyperlinks) a new part of
the application?  I've done this with both PUT and POST (mostly POST)
in several applications I've developed, so can attest to its utility.

What am I missing?  What's the value in restricting the information
that a response message can communicate?  What's wrong with just
treating a response which communicates the state of the resource
post-invocation, as a special case?

Mark.

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 1 Aug 2007 12:23:32 -0700

> post-invocation, as a special case?

It's a different model, that's all.  I see PATCH as something that  
automated clients can use to control the state of server resources in  
a reasonably predictable manner, and signaled this by talking about  
caching and synching clients.  Your model, if I may characterize it,  
is closer to having the server in control than the client.

But you already have POST for server-controlled interactions leading  
the client to a new part of the application.  There's nothing  
restricting a javascript/forms application, AJAX or otherwise, from  
using POST to send a delta -- you don't need a standards committee  
for that!

Lisa

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 1 Aug 2007 12:52:03 -0700

> post-invocation, as a special case?

Do you mean indicated by 200 and (Content-Location == Request-URI)?
Or a new 2xx status code that specifically says the enclosed response
entity is as if it were a response to GET on the new state?  I would
prefer a new response code at this point, since experience has shown
that content-location is difficult to reconstruct in the presence of
intermediaries.

....Roy

---

From: "Mark Baker" <[email-masked]>
Date: Wed, 1 Aug 2007 16:45:47 -0400

> Do you mean indicated by 200 and (Content-Location == Request-URI)?

As a means to indicate the special case, yes, that's what I was
thinking and mentioned to James.  I wasn't aware of the problem you
pointed out below though ...

> entity is as if it were a response to GET on the new state?

That would be fine with me.  But earlier you said;

"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"

So to be clear, are you now suggesting that a 200 PATCH response would
*not* have this specific meaning, and that only this new response code
would indicate that it did have it?  If so, great, we're in sync.

>  I would

Interesting, I wasn't aware of that.

Mark.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 1 Aug 2007 15:26:33 -0700

> would indicate that it did have it?  If so, great, we're in sync.

Yes.

> Interesting, I wasn't aware of that.

It is a common problem with HTTP gateways (a.k.a., reverse proxies)
that divert requests at a firewall.  (Actually, the real problem is
with people confusing location with configuration, but that's a long
story).  Authoring servers tend to suffer more from gateway-style
"protection" than normal HTTP servers.  If everyone implemented
HTTP as specified, there would be no problem.

....Roy

---

From: "Mark Baker" <[email-masked]>
Date: Wed, 1 Aug 2007 20:29:32 -0400

> > would indicate that it did have it?  If so, great, we're in sync.

Great.

So I'm going to propose that we add this response code to the PATCH
draft.  What does everyone think?

Mark.

---

From: James M Snell <[email-masked]>
Date: Wed, 01 Aug 2007 19:29:55 -0700

Just so I'm clear on this: the new response code would be used to
indicate that the response entity is equivalent to what would be
returned on a subsequent GET. If so, I'm perfectly fine with that and
have no problem adding it to the spec.

- James

---

From: James M Snell <[email-masked]>
Date: Wed, 01 Aug 2007 19:35:18 -0700

One additional point I thought of just as this was being sent... even
with the new status code, we will likely still need to say something
about 2xx responses that contain Content-Location

- James

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 2 Aug 2007 10:03:35 +0200

> forcing the server to return 200 -- the server can choose which

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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 02 Aug 2007 12:32:15 +0200

Stefan Eissing wrote:
> 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.

Right. Not good.

It seems to me that this tries to optimize the uncommon case. What's the 
problem with refetching the content in a second request if you really 
need it?

Yes.

> It sounds like a nice job for a new "Expect" request header. Let's say 
> we call this "patched-content":
> 

This has as deployment problem: "Expect" is hop-by-hop, so it won't work 
with intermediates that do not now about it.

Best regards, Julian

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 2 Aug 2007 13:40:30 +0200

Am 02.08.2007 um 12:32 schrieb Julian Reschke:

> This has as deployment problem: "Expect" is hop-by-hop, so it won't  
> work with intermediates that do not now about it.

Objection, your honor! 2616, section 14.20:

"The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST  
return a 417 (Expectation Failed) status if it receives a request  
with an expectation that it cannot meet. However, the Expect request- 
header itself is end-to-end; it MUST be forwarded if the request is  
forwarded."

So, it MUST reach the origin server, since proxies are unlikely to  
answer a PATCH from cache.

//Stefan

--
Stefan Eissing

<green/>bytes GmbH
Hafenweg 16
D-48155 Münster
Germany

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 2 Aug 2007 13:45:10 +0200

Uhm, since we have proxy expert here on the list:

Will a proxy answer an unknown "Expect" header with 417? The spec  
seems to ask for that, if we assume an unknown expectation means  
"cannot meet".

//Stefan

Am 02.08.2007 um 13:40 schrieb Stefan Eissing:

>> This has as deployment problem: "Expect" is hop-by-hop, so it  
>> won't work with intermediates that do not now about it.
>
> "The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy  
> MUST return a 417 (Expectation Failed) status if it receives a  
> request with an expectation that it cannot meet. However, the  
> Expect request-header itself is end-to-end; it MUST be forwarded if  
> the request is forwarded."
>

--
Stefan Eissing

<green/>bytes GmbH
Hafenweg 16
D-48155 Münster
Germany

---

From: Julian Reschke <[email-masked]>
Date: Thu, 02 Aug 2007 14:07:37 +0200

Stefan Eissing wrote:
> return a 417 (Expectation Failed) status if it receives a request with 
> an expectation that it cannot meet. However, the Expect request-header 
> itself is end-to-end; it MUST be forwarded if the request is forwarded."
> 

No, a proxy will have to 417 it if it doesn't know about it.

I guess if this wouldn't be the case, "Expect" would indeed be used in 
practice (in addition to 100-continue which HTTP/1.1 components MUST 
understand).

Best regards, Julian

---

From: Yaron Goland <[email-masked]>
Date: Thu, 2 Aug 2007 13:17:46 -0700

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: [email-masked] [mailto:[email-masked]]
> On Behalf Of Stefan Eissing
> Sent: Thursday, August 02, 2007 1:04 AM
> To: Roy T.Fielding
> Cc: Mark Baker; Lisa Dusseault; [email-masked]
> Subject: Re: [Fwd: I-D ACTION:draft-dusseault-http-patch-08.txt]
>
>
>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 02 Aug 2007 22:51:26 +0200

> 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…

+1.

Either do not do it at all (and let clients do the additional GET), or 
make it "opt in".

Best regards, Julian