Subject: PATCH Draft

From: James M Snell <[email-masked]>
Date: Mon, 25 Jun 2007 13:10:04 -0700

Hello,

Recent revived interest in the ability to apply partial modifications to
Web resources led me to contact Lisa Dusseault regarding the status of
her expired PATCH draft [1].  After speaking with her a bit about it,
and considering the needs of things like the Atom Publishing Protocol
and other REST-based protocols, I have (at Lisa's invitation) prepared
an updated draft that builds on her original ideas and seeks to address
many of the concerns that had been raised.  The updated draft posted today:

  http://www.ietf.org/internet-drafts/draft-dusseault-http-patch-07.txt

The short story is this: to apply a partial modification of a Web
resource, use the PATCH method with a payload that describes the changes
to be made:

  PATCH /some/web/resource HTTP/1.1
  Content-Type: application/diff+xml

  [some-diff-format]

The server responds with...

  HTTP/1.1 204 OK
  ...

This draft evolves Lisa's original by dropping reliance on the
mechanisms defined by RFC3229 in favor of using Content-Type.  The draft
does not define any minimum-to-implement delta encodings and leaves it
completely open as to what kinds of formats can be considered "delta
encodings".

There are some issues that definitely need to be worked out.

  * Should there be a single minimum recommended diff format
    for binary/character based resources.  I know that this has
    been controversial in the past and I personally don't have
    an opinion on it.  I know that Lisa would prefer for there
    to be at least one minimum recommendation

  * Should it be possible to create new resources with PATCH

  * Should it be required to use If-Match and If-Unmodified-Since
    on PATCH.

I'm sure there are other issues :-)

Comments? Concerns?

- James

[1] http://www.ietf.org/internet-drafts/draft-dusseault-http-patch-06.txt

---

From: Stefan Eissing <[email-masked]>
Date: Mon, 25 Jun 2007 22:27:58 +0200

Ah, I was waiting for this and had something prepared. Many thanks  
for James for reviving the draft!

>     to be at least one minimum recommendation

Personally, I think this is not helpful. PATCH cannot require servers  
to support such a format. For every format it is trivial to think of  
an application where it does not make sense.

>   * Should it be possible to create new resources with PATCH

Non-issue in my mind: up to the application. See above.

>   * Should it be required to use If-Match and If-Unmodified-Since

Definitely not. Let's say subversion wants to use PATCH, using the  
good old diff format on text files. It is definitely counter- 
productive to require it to fail on changed ETags when it clearly  
does not want to.

On the other hand, one can think of applications using PATCH to save  
bandwidth. Using some simple binary patch format. Such applications  
will make heavy use of If-Match headers and rightly so.

> I'm sure there are other issues :-)

Comments and personal opinions about patch-07:

based on: http://www.greenbytes.de/tech/webdav/draft-dusseault-http- 
patch-07.html

2.1 PATCH Method

replace "delta encoding" by something not using "encoding". "patch  
document type" maybe...

Strike: "and MUST include sufficient information to allow the server  
to recreate the changes necessary to convert the original version of  
the resource into the desired version."
Reason: obvious

Replace: "The server MUST NOT create a new resource with the contents  
of the request body, although it MAY (depending on the delta  
encoding) apply the request body to an empty resource."
By: "If the server accepts PATCH on a non-existing resource is up to  
the server implementation."
Reason: there may be applications where it makes sense, others might   
strictly forbid it.

Replace: "origin server" by "server"

Replace whole paragraph: "Collisions from ...."
By:
"PATCH documents should carry enough context information that allow  
the server to correctly apply the change or fail the PATCH. While  
applications may differ in their requirments here, the general idea  
is that PATCH documents can be applied to a start document in any  
order and either produce a failure or the very same end document.

Changes that require strict ordering SHOULD be secured by using ETags  
and If-Match headers."

Drop: "Servers should provide strong ETags..."

Idea: "maybe replace the hyptothetical example by a diff/patch text one?

2.2 PATCH Response

Idea: Only describe difference of PATCH responses to PUT responses
Idea: should "Accept-Patch" header also appear in responses to PATCH?

2.3 Advertising Support

Idea: clarify what advertising "Accept-PATCH" headers in GET  
responses mean?

"If Accept-PATCH appears on a response to a GET request, the client  
can expect the server to support PATCH with the listed document types  
on this particular resource."

3. Delta Encodings

Rename to: "PATCH Document Types"

Strike: everything about character encoding of PATCH documents
Strike: "Structure-based delta...."

Not Found:

- Some words about safety, idempotent aspect of PATCH?

Cheers,

Stefan
--
Stefan Eissing

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

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 26 Jun 2007 00:26:27 +0200

> an application where it does not make sense.

Sure, but for interoperability it helps a lot if there is at least one
text and one binary format that most clients can expect to be supported
on most servers, therefore one or two recommendations on formats to use
helps a lot.

This do not mean that every server MUST support those formats, or that
there SHOULD NOT be any other formats supported. Only that there is an
established recommendation on what formats to use unless there is strong
reasons not to, in order to make interoperability reasonable.

> Non-issue in my mind: up to the application. See above.

I disagree. Part of this should be in the protocol. Most importanly if
it should be possible for the client to ask the server that a new
resource should be created based on another "template" resource and a
delta.

> productive to require it to fail on changed ETags when it clearly  

I'd say it should be a SHOULD requirement unless the delta format in
question has it's own conflict resolution.

> will make heavy use of If-Match headers and rightly so.

Needs to be clearly mentioned, or I'm afraid there will be lots of
implementations which overlooks this.

> Reason: there may be applications where it makes sense, others might   

Why? There is already the PUT method for creating entities. Unless we
talk about creating a resource from a template + delta ofcourse..

> Idea: Only describe difference of PATCH responses to PUT responses

Perhaps.

> Idea: should "Accept-Patch" header also appear in responses to PATCH?

Yes, I'd say so. The modified resource do not need to support further
PATCH modifications, depending on the application.

Regards
Henrik

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 26 Jun 2007 00:35:59 +0200

2.1  PATCH Method

the part talking about caching..

Why isn't the response to this method cacheable? It should be aligned
with POST, allowing for a 200 OK response which is cacheable, carrying
the modified entity.

Remember, HTTP caching is about how caches should react on later
GET/HEAD requests for the same resource. If the response to PATCH
carries the modified entity in the same manner as a GET would then it
should be allowed to cache that.

2.3 Advertising Support in OPTIONS

Why is Accept-Patch required. Or what is it that makes Accept unsuitable here?

Regards
Henrik

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 25 Jun 2007 16:04:53 -0700

On Jun 25, 2007, at 1:27 PM, Stefan Eissing wrote:

> Personally, I think this is not helpful. PATCH cannot require  
> servers to support such a format. For every format it is trivial to  
> think of an application where it does not make sense.

That's true.  To be more clear, what I had in mind was requiring a  
MTI diff format for one particular case, that of a server that stores  
resources exactly as the client PUTs them, and the GET result is also  
byte-for-byte identical.  This is a fairly common case, particularly  
among WebDAV servers.

For resources that are stored exactly the way they appear on the  
wire, I cannot think of a case where a binary diff is going to cause  
problems.

Thus, the language I'd proposed was something like:

	In order to improve potential interoperability, servers that store  
resources unchanged
	(or can apply deltas as if resources are stored unchanged) are  
RECOMMENDED to
	support [FOO] as a common-denominator approach.

The problem with this is not the desirability of it -- for any server  
that wants to support PATCH and returns byte-for-byte identical  
resources, it's desirable to have a PATCH format that clients are  
likely to know.  The problem is rather that there is no binary patch  
format with a legitimately registered MIME type.

Lisa

---

From: "Larry Masinter" <[email-masked]>
Date: Mon, 25 Jun 2007 16:22:54 -0700

# Why is Accept-Patch required. Or what is it that makes Accept unsuitable here?

Accept is currently a request header and not a response header.
What's acceptable depends on the method as well as the URI.

For example

(request)
OPTIONS /example/buddies.xml HTTP/1.1
Host: www.example.com

(response)
Allow: GET, PUT, POST, PATCH, OPTIONS
Accept-PATCH: application/diff, application/diff+xml
Accept-PUT: application/xml
Accept-POST: application/vcard

Accept-POST might be useful for forms submission URIs, to 
determine whether multipart/form-data, URL encoded, or other
submission formats might be acceptable.

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 25 Jun 2007 17:05:43 -0700

> with POST, allowing for a 200 OK response which is cacheable, carrying

That should be fine.  I wonder if it's worth the extra variation to  
allow the server to carry the entire modified entry.  In some cases  
that would remove the whole point of supporting PATCH (allowing  
authoring of large files without constant uploading and downloading  
of entire file) so returning the body at least has to be optional.

> Why is Accept-Patch required. Or what is it that makes Accept  

Accept is a request header.  I assumed that it would be viewed in bad  
taste to use it as a response header.  It might also in the long run  
be confusing -- the server might accept certain diff formats for  
PATCH, but accept other inputs for other purposes.

Lisa

---

From: James M Snell <[email-masked]>
Date: Mon, 25 Jun 2007 17:25:09 -0700

Alternatively, it would be interesting to allow the server to return
it's own diff of the changes it actually applied.

- James

Lisa Dusseault wrote:
> [snip]
> allow the server to carry the entire modified entry.  In some cases that
> would remove the whole point of supporting PATCH (allowing authoring of
> large files without constant uploading and downloading of entire file)
> so returning the body at least has to be optional.
> 
> [snip]

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 26 Jun 2007 03:35:16 +0200

> of entire file) so returning the body at least has to be optional.

The draft already talks about returning the modified entity, with an 200
example carrying it..

If the server do not want to return the modified entity then it can
return a 204.

The only question is if there is a need to have the server return status
messages on a successful PATCH other than the entity itself, or the
actual resulting diff if some server-side processing was done. If 200
returns the modified entity then what to use if the server do not want
to return the modified entity but instead need to return status messages
about the successful PATCH operation or perhaps a diff?

For as long as 200 returns the modified entity there is no reason not to
allow it to be cached.

> PATCH, but accept other inputs for other purposes.

Agreed.

But a more expressive name than Accept-<method> should probably be used
then. If not there is a risk for a name collision if/when other Accept-X
headers is added or new methods with similar names..

Also I don't see why the server should not be allowed to indicate
preference via the quality parameter.

So I propose using the same production as for Accept, and to name the
header somewhat differently to avoid conflicts later on. Possible
suggestions

   Patch-Accept
   Accept-On-Patch

Then there is also the Accept-Charset, Accept-Language and
Accept-Encoding metrics to worry about if trying to make a header scheme
where the server can indicate it's content preferences for specific
methods.

Regards
Henrik

---

From: James M Snell <[email-masked]>
Date: Mon, 25 Jun 2007 22:54:34 -0700

> If the server do not want to return the modified entity then it can

Yep. Returning the complete entity body is optional in the draft and is
likely only going to be useful when using structural deltas where things
like MD5 hashes are inadequate for determining the success of the delta.

> about the successful PATCH operation or perhaps a diff?

Good point. We would need some way of signaling that the returned entity
is not the modified entity but itself a delta.  Will have to think about
that a bit more.

Agreed.

> headers is added or new methods with similar names..

Hmm... I'm absolutely terrible at these kinds of discussions mainly
because I tend not to care what the heck we call it as long as it does
the job ;-).

- James

---

From: "Larry Masinter" <[email-masked]>
Date: Mon, 25 Jun 2007 23:11:14 -0700

> If the server do not want to return the modified entity then it can

Don't make this optional. The server shouldn't send the modified
entity unless the client needs it, and the server has no way to
determine whether the client needs it.  And the client can ask
for it by doing a GET.

Behavior should be predictable, and the fewer options you have,
the better.

I'm not entirely convinced that there is a demand for single client
multiple server implementations of PATCH, or that it is viable
without a MTI content-type for patching instructions. 
And if prior out-of-band agreement is needed, then you might as
well just use POST with constructed URLs (http://site/path ->
http://site/PATCHER/path for example), and you'd avoid the
problem of expecting infrastructure that never heard of
PATCH to quickly implement its POST-like caching rules.

Larry

---

From: Stefan Eissing <[email-masked]>
Date: Tue, 26 Jun 2007 09:45:31 +0200

> on most servers, therefore one or two recommendations on formats to  

Yes and no. I agree that *if* we had such document type formats,  
intellectual property free, it would help PATCH to reference them as  
recommendations.

But it seems that these formats need to be invented first, or at  
least defined, and that takes precious time. We have *now* http  
applications like AtomPub and Web3S which could make use of PATCH.  
So, instead of inventing their own methods or twisting PUT, I think  
everyone is better served with a well defined PATCH without  
recommended formats than no PATCH at all.

It worked for GET, PUT and POST.

Cheers,

Stefan

---

From: Julian Reschke <[email-masked]>
Date: Tue, 26 Jun 2007 12:26:14 +0200

> on most servers, therefore one or two recommendations on formats to use

Sort; that depends on the context. I do agree that it would be good if 
all WebDAV servers that support arbitrary binary content support the 
same binary patch format. Likely, it would be good if all AtomPub 
servers that do support PATCH agree on a patch format for entries.

But I just don't see how the PATCH spec can mandate that. And also 
consider that as of now there's not a single well-defined, IPR-free and 
media-typed format we *could* mandate or even recommended.

Let's de-couple these efforts. Trying not to was one of the reasons 
there hasn't been any progress on this for 2.5 years.

> resource should be created based on another "template" resource and a

That's interesting but seems to be a new requirement (new request 
header?). Also, it sounds that's already solved by COPY.

Independently from that, I think PATCH must allow servers to support 
patch formats that create new resources; insisting on a prior PUT of an 
empty body is just silly.

> question has it's own conflict resolution.

Sounds like overspecification. People will do the right thing without 
the spec making requirements here.

> implementations which overlooks this.

No problem with mentioning that.

> talk about creating a resource from a template + delta ofcourse..

Use cases:

- define a PATCH format that can bundle data and metadata (body + WebDAV 
properties, media resource + atom entry) into a single, atomic request

- create/append access

So no, I don't think a restriction to existing resources makes sense in 
general. See also RoyF's comment in 
<http://lists.w3.org/Archives/Public/ietf-http-wg/2004AprJun/0086.html>:

RF> There is no reason to require that the resource already exists
RF> (such a requirement is nonsensical in any case, since in HTTP the
RF> resource is the temporal invariance found in mapping of URI to content,
RF> not some file in storage).  The requirement should be that the PATCH
RF> media type define whether an existing representation is necessary
RF> or not, which is trivial for the server to discover when applying
RF> the patch (it is a conflict, like any other conflict).

> PATCH modifications, depending on the application.

Good point.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 26 Jun 2007 12:28:51 +0200

Lisa Dusseault wrote:
> That's true.  To be more clear, what I had in mind was requiring a MTI 
> diff format for one particular case, that of a server that stores 
> For resources that are stored exactly the way they appear on the wire, I 
> cannot think of a case where a binary diff is going to cause problems. 
> 
> resources, it's desirable to have a PATCH format that clients are likely 
> to know.  The problem is rather that there is no binary patch format 
> with a legitimately registered MIME type.  

And that's why we don't want to make a normative requirement here at 
all, right?

That being said, I'm happy to start work on a *simple* format that would 
work well in the WebDAV case.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 26 Jun 2007 12:36:25 +0200

> Behavior should be predictable, and the fewer options you have,

+1.

In the general case PATCH either fails with 4xx (Conflict) or succeeds. 
In the latter case, a client can always send a subsequent GET.

> without a MTI content-type for patching instructions. 

Yes. PATCH for atom entries is different from PATCH for arbitrary binary 
content, and that's different from Yaron's Web3S scenarios (I guess). I 
don't see how a single patch format would be helpful here...

> PATCH to quickly implement its POST-like caching rules.

Could you elaborate on this? If a POST to http://site/PATCHER/path 
affects the resource at http://site/path (for instance), how is a cache 
going to find out about that?

Best regards, Julian

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 26 Jun 2007 12:01:11 -0400

Hi James,

> Comments? Concerns?

As has been indicated PATCH will likely be used by WebDAV servers. 
Therefore I think it would be handy to have a "WebDAV Considerations" 
section that describes any issue specific to WebDAV. In particular the 
interaction with WebDAV ACL ought to be clarified (basically that use of 
PATCH will be tied to the same ACLs that enable use of PUT - assuming that 
we allow PATCH to create a new resource as well as modify an existing one). 
It might also be useful to define a "DAV:supported-patch-formats" property 
to allow the patch formats supported by a particular resource to be 
enumerated. Also, is it meaningful to PATCH a collection? e.g. could I 
PATCH a new collection and effectively create all the resources within that 
collection all in one go? Or could it be used to PATCH specific resources 
in the collection all in one go?

> properties, media resource + atom entry) into a single, atomic request

It would certainly be useful to have an atomic operation that creates a new 
resource, stores it body, initializes properties and initializes ACLs all 
in one go. In particular the initialization of ACLs would be very useful 
for the case where you want to create a resource with permissions that are 
more restrictive than the defaults you would otherwise get. In that case 
right now, a client is forced to first create an empty resource, then 
change ACLs, then store the resource data - a lot more work than should be 
needed.

-- 
Cyrus Daboo

---

From: James M Snell <[email-masked]>
Date: Tue, 26 Jun 2007 10:23:58 -0700

Cyrus Daboo wrote:
> PATCH will be tied to the same ACLs that enable use of PUT - assuming
> that we allow PATCH to create a new resource as well as modify an
> existing one). It might also be useful to define a
> "DAV:supported-patch-formats" property to allow the patch formats
> supported by a particular resource to be enumerated. Also, is it
> meaningful to PATCH a collection? e.g. could I PATCH a new collection
> and effectively create all the resources within that collection all in
> one go? Or could it be used to PATCH specific resources in the
> collection all in one go?
> 

I can understand why this would be desirable. I, however, am nowhere
near qualified to discuss any reasonable considerations for WebDAV.

Regarding the "DAV:supported-patch-formats" suggestion, why wouldn't the
Accept-Patch response header be enough?

- James

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 26 Jun 2007 13:38:26 -0400

Hi James,

> near qualified to discuss any reasonable considerations for WebDAV.

Right, but your co-author is :-)

> Accept-Patch response header be enough?

Typically WebDAV clients tend to prefer to get resource-specific 
information via PROPFIND (properties) rather than OPTIONS (response 
headers) - ETag is a good example of that: there is an ETag response header 
and a getetag WebDAV property. The cost of exposing patch format 
information as a WebDAV property is minimal and the benefits are several, 
including the fact that a client can do a Depth:1 PROPFIND to get all 
properties of all resources in a collection all in one go without having to 
do OPTIONS on each one separately.

-- 
Cyrus Daboo

---

From: Julian Reschke <[email-masked]>
Date: Tue, 26 Jun 2007 19:45:16 +0200

> near qualified to discuss any reasonable considerations for WebDAV.

Well, we can help with that; it's just not clear whether we want that in 
the same spec. Many people automatically ignore things just because the 
term WebDAV comes up.

> Accept-Patch response header be enough?

If you can get the data with PROPFIND, you may be able save another 
round trip.

Best regards, Julian

---

From: "Larry Masinter" <[email-masked]>
Date: Wed, 27 Jun 2007 21:44:04 -0700

I suggest multipart/byteranges as the basis for a possible MTI format for
partial updates.

---

From: James M Snell <[email-masked]>
Date: Thu, 28 Jun 2007 10:42:25 -0700

What would be the rationale for this?

- James

---

From: James M Snell <[email-masked]>
Date: Thu, 28 Jun 2007 10:44:20 -0700

> the same spec. Many people automatically ignore things just because the

Yep. It would make just as much sense to put in an Atompub
considerations section.  I'm just not sure we really should include it here.

- James

---

From: James M Snell <[email-masked]>
Date: Thu, 28 Jun 2007 10:47:59 -0700

Julian Reschke wrote:
>>[snip[

The only challenge with this is that the whole point of returning the
entity in the response is to verify that the resource was patched
successfully.  If the resource is modified between the time the PATCH
response is received and a subsequent GET is issued, then verifying the
result becomes problematic.  Using Etags we can obviously detect the
subsequent change, but it's harder to verify that our specific change
was applied correctly.  For byte/character based deltas, this is not so
much of a problem.  For structural deltas it can be a significant problem.

- James

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 28 Jun 2007 14:59:19 -0400

Hi James,

> much of a problem.  For structural deltas it can be a significant problem.

Yes - indeed I have run into a similar problem with CalDAV. In that case 
the server is a gateway to another calendar system and has to modify data 
that is PUT by a CalDAV client. Because of all the well-known issues with 
ETags on PUT, the client is currently forced to immediately turn around a 
do a GET to get the server-modified data back. It would be nice if there 
were an HTTP request header for PUT that told the server to return the 
actual stored entity (if a change actually occurred) with its corresponding 
ETag. That would avoid the need for the extra roundtrip.

-- 
Cyrus Daboo

---

From: "Larry Masinter" <[email-masked]>
Date: Thu, 28 Jun 2007 12:00:23 -0700

Better to start with something known than starting from scratch.
   No known IP claims.
   Range retrieval is a kind of "server patch client".

PATCH focuses on client-patch-server. But there's no reason not
to consider server-patch-client, and consider range retrieval
to be a special case of that.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of James M Snell
Sent: Thursday, June 28, 2007 10:42 AM
To: Larry Masinter
Cc: 'Julian Reschke'; 'Lisa Dusseault'; 'Stefan Eissing';
[email-masked]
Subject: Re: Required DIFF format [was Re: PATCH Draft]

- James

---

From: "Larry Masinter" <[email-masked]>
Date: Thu, 28 Jun 2007 12:06:20 -0700

What's the difference between a PUT that includes a header that says
"return the body" and a pipelined GET? Why is the pipelined
GET an 'extra round trip'?

Larry

-----Original Message-----
From: Cyrus Daboo [mailto:[email-masked]] 
Sent: Thursday, June 28, 2007 11:59 AM
To: James M Snell; Julian Reschke
Cc: [email-masked]; 'Henrik Nordstrom'; 'Lisa Dusseault'; [email-masked]
Subject: Re: PATCH Draft

Hi James,

-- 
Cyrus Daboo

---

From: "Larry Masinter" <[email-masked]>
Date: Thu, 28 Jun 2007 12:09:38 -0700

It makes sense to me to include application notes for a protocol
element that is hard to understand without more context of
how it will be used. If that includes examples from WebDAV
and Atompub, so be it.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of James M Snell
Sent: Thursday, June 28, 2007 10:44 AM
To: Julian Reschke
Cc: Cyrus Daboo; [email-masked]; Lisa Dusseault
Subject: Re: PATCH and WebDAV, was Re: PATCH Draft

- James

---

From: James M Snell <[email-masked]>
Date: Thu, 28 Jun 2007 12:42:23 -0700

Thank you for the clarification.

---

From: Yaron Goland <[email-masked]>
Date: Thu, 28 Jun 2007 13:07:25 -0700

Indeed, the "reverse" patch is a big scenario we are definitely planning on doing. It's just a question of what's the friendliest way to do it.
        Yaron

> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of James M Snell
> Sent: Thursday, June 28, 2007 12:42 PM
> To: Larry Masinter
> Cc: 'Julian Reschke'; 'Lisa Dusseault'; 'Stefan Eissing'; ietf-http-
> [email-masked]

---

From: Yaron Goland <[email-masked]>
Date: Thu, 28 Jun 2007 13:15:47 -0700

I'm having to dust off some very old memories but it is my recollection that HTTP does not guarantee end-to-end pipelining order.

Client ---> Proxy ---> Server

If the Client pipelines a PATCH and a GET to the Proxy it was my understanding that the proxy was free to handle those two requests anyway it likes including sending the GET before the PATCH or sending them on two separate connections in parallel or what have you. While it is true that the proxy has to return the results in the order the client requested this does not guarantee that the methods were processed in the order they were submitted. So the client could get a GET result that was executed before the PATCH. And with all the well known problems with dates the client can't just compare the dates on the two responses and so re-create the 'true' ordering.

      Yaron

> On Behalf Of Larry Masinter

> Sent: Thursday, June 28, 2007 12:06 PM

> To: 'Cyrus Daboo'; 'James M Snell'; 'Julian Reschke'

> Cc: 'Henrik Nordstrom'; 'Lisa Dusseault'; [email-masked]

> Subject: RE: PATCH Draft

> Cc: [email-masked]; 'Henrik Nordstrom'; 'Lisa Dusseault'; ietf-http-

> >> In the general case PATCH either fails with 4xx (Conflict) or

> succeeds.

> > response is received and a subsequent GET is issued, then verifying

> the

> > was applied correctly.  For byte/character based deltas, this is not

> so

> > much of a problem.  For structural deltas it can be a significant

> problem.

> Yes - indeed I have run into a similar problem with CalDAV. In that

> case

> the server is a gateway to another calendar system and has to modify

> data

> that is PUT by a CalDAV client. Because of all the well-known issues

> with

> ETags on PUT, the client is currently forced to immediately turn around

> a

> do a GET to get the server-modified data back. It would be nice if

> there

> actual stored entity (if a change actually occurred) with its

> corresponding

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 28 Jun 2007 16:19:54 -0400

Hi Larry,

> GET an 'extra round trip'?

One big issue is that if the PUT fails then you might not want to pay the 
price of the queued GET. If that is the case, clients wouldn't be 
pipelining.

-- 
Cyrus Daboo

---

From: Jeffrey Mogul <[email-masked]>
Date: Thu, 28 Jun 2007 13:24:22 -0700

Cyrus Daboo writes:

Larry Masinter writes:

Initially, I had the same reaction.  But I don't think this is
reliable w.r.t. the specification (although it might be reliable
for all existing implementations).

Remember, RFC 2616 section 8.1.2.2 does say "A server MUST send its
responses to those requests in the same order that the requests were
received."  However, it does NOT say "A server MUST completely
process one request on a persistent connection before processing
any subsequent request on the same connection."

So you could have a situation where the client issues a pipelined
PUT followed by a GET, but a multithreaded server cleverly decides
to process the PUT in thread X and to  start processing the GET in
thread Y before the PUT is done.  So the result from the GET,
while it gets to the client after the result from the PUT, shows
the state of the resource before the PUT (or worse, an inconsistent
state "during" the PUT).

CPU architects (and compiler writers) deal with this same problem
all the time, now that most memory systems do out-of-order operations.
The solution in this case is a "memory barrier" (MB) operation, which
the compiler inserts between any code sequences that have to
be properly serialized.  Then, in all other cases, the hardware
is free to reorder memory operations arbitrarily, which can really
improve performance.

In the case of HTTP, it seems less likely that we would want to
define a new "MB" method just for this purpose (although maybe
the DAV people see this problem in other cases) -- in particular,
in a CPU there's a single "session" between the CPU and memory,
but in HTTP, persistent connections come and go -- so to define
an "MB" method that works across connections and over shared
proxies seems like it would be way too complex.

Which means, I think, that the right way to solve Cyrus's 
problem is probably the one he suggested -- add an optional
method to the PUT request that causes PUT to return the resulting
entity.

-Jeff

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 28 Jun 2007 22:39:02 +0200

> GET an 'extra round trip'?

There is a race window between the two, with no guarantee that there
hasn't been any modification between the two.

Also, if there is proxies involved the situation gets even messier, and
it's possible the GET gets executed before the PUT is complete, or might
even get the old entity from a cache somewhere. While the PUT
invalidates the caches the PUT goes via, there is no guarantee the GET
will travel the exact same path..

Regards
Henrik

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 28 Jun 2007 22:43:07 +0200

> method to the PUT request that causes PUT to return the resulting

And the exact same method could be used in PATCH for the same purpose..

Regards
Henrik

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 28 Jun 2007 22:47:55 +0200

Good point.

Furthermore RFC2616 section 8.1.2.2 advises: "Clients SHOULD NOT  
pipeline requests using non-idempotent methods or non-idempotent  
sequences of methods (see Section 9.1.2)."

And 9.1.2 says: "However, it is possible that a sequence of several  
requests is non-idempotent, even if all of the methods executed in  
that sequence are idempotent. (A sequence is idempotent if a single  
execution of the entire sequence always yields a result that is not  
changed by a reexecution of all, or part, of that sequence.)"

While I am now not certain that "PUT+GET" count as idempotent  
sequence, any sequence containing PATCH has to be regarded as non- 
idempotent. I think.

A request header seems a good way to approach this for PUT and PATCH.  
But is it clear on seeing a 200 response with empty body that the  
server has honored the header? Is a response header needed here as well?

Cheers,

Stefan

--
Stefan Eissing

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

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 28 Jun 2007 22:49:13 +0200

> And the exact same method could be used in PATCH for the same  

Without any smugness: you mean header not method, right?

//Stefan

---

From: James M Snell <[email-masked]>
Date: Thu, 28 Jun 2007 13:51:11 -0700

Or.. leave the decision up to the server and the client can adapt
accordingly.

- James