Subject: Re: Updated PATCH draft

From: "Subbu Allamaraju" <[email-masked]>
Date: Sat, 8 Dec 2007 15:03:47 -0800

I have a comment on this paragraph of this draft.

"Clients are advised to take caution when sending multiple PATCH requests,
or sequences of requests that include PATCH, over a pipelined connection as
there are no guarantees that pipelined requests will be processed by the
server in the same order in which the client sends them."

Since 2616 says that clients SHOULD NOT pipeline non-idempotent methods, and
since PATCH is a  non-idempotent method, any reason why a similar
conformance level is not presented here? Secondly, are there cases when
pipelined requests will be processed out of order? 2616 explicitly prohibits
sending responses out of order (8.1.1.2).

Regards,
Subbu

On Oct 27, 2007 10:01 AM, James M Snell <[email-masked] > wrote:

>
> An updated PATCH draft is available.
>
>   http://www.ietf.org/internet-drafts/draft-dusseault-http-patch-10.txt
>
> Main changes include:
>
>  * Removing the Prefer header (now published as a separate I-D)
>  * Minor restructuring of the doc
>  * Some editorial changes
>
> - James
>
>

---

From: Robert Siemer <[email-masked]>
Date: Sun, 9 Dec 2007 03:42:21 +0100

On Sat, Dec 08, 2007 at 03:03:47PM -0800, Subbu Allamaraju wrote:
> conformance level is not presented here?

Because it is already in 2616 and the draft points to it, no?

> Secondly, are there cases when pipelined requests will be processed 
> out of order?

At least, could be processed in parallel or decomposed into 
non-pipelined requests in the proxy chain and overtake each other this 
way.

> 2616 explicitly prohibits sending responses out of order (8.1.1.2).

Of course, but that is _sending_ only, not processing nor forwarding.

My 2 cents,
		Robert

---

From: Subbu Allamaraju <[email-masked]>
Date: Sat, 8 Dec 2007 21:39:23 -0800

> Because it is already in 2616 and the draft points to it, no?

Or may be I am reading this too closely.
> non-pipelined requests in the proxy chain and overtake each other this

OK. That makes sense.

Subbu

---

From: James M Snell <[email-masked]>
Date: Sun, 09 Dec 2007 00:19:10 -0800

I've already removed this paragraph from the next version of the draft
because it is adequately covered by 2616.

- James

Subbu Allamaraju wrote:
> "Clients are advised to take caution when sending multiple PATCH
> requests, or sequences of requests that include PATCH, over a pipelined
> connection as there are no guarantees that pipelined requests will be
> processed by the server in the same order in which the client sends them."
> 
> Since 2616 says that clients SHOULD NOT pipeline non-idempotent methods,
> and since PATCH is a  non-idempotent method, any reason why a similar
> pipelined requests will be processed out of order? 2616 explicitly
> prohibits sending responses out of order ( 8.1.1.2 <http://8.1.1.2>).
> 
> Regards,
> Subbu
> 
> On Oct 27, 2007 10:01 AM, James M Snell < [email-masked]
> <mailto:[email-masked]>> wrote:
> 
>

---

From: Jamie Lokier <[email-masked]>
Date: Sun, 9 Dec 2007 18:23:46 +0000

Subbu Allamaraju wrote:
>    requests, or sequences of requests that include PATCH, over a
>    pipelined connection as there are no guarantees that pipelined
>    requests will be processed by the server in the same order in which
>    the client sends them."
> 
>    Since 2616 says that clients SHOULD NOT pipeline non-idempotent
>    methods, and since PATCH is a  non-idempotent method, any reason why a
>    similar conformance level is not presented here?

You're right, hence the advice to take caution :-)

>    Secondly, are there cases when pipelined requests will be
>    processed out of order?

Yes, a server may process the requests in parallel, or a load
balancing reverse proxy may forward the requests to different servers
to process in parallel, or the requests may be converted to HTTP/1.0
or otherwise de-pipelined by some ordinary proxy in the chain and
then subject to ordinary network reordering.

>    2616 explicitly prohibits sending responses out of order (
>    [1]8.1.1.2).

Yes, as there's no other way to associate responses with requests
(unfortunately, sometimes).

However, it does not prohibit the requests being processed and
responses being generated and stored temporarily out of order, and in
fact it couldn't prohibit that due to the de-pipelining mentioned
above.  Reliable controlled ordering of pipelined request processing
would require a non-trivial protocol extension.

-- Jamie