Subject: http/2 and non-safe http methods

From: James M Snell <[email-masked]>
Date: Tue, 3 Nov 2015 07:36:40 -0800

Quick non-trolling question: the HTTP/2 RFC currently deals with
replay of idempotent requests that likely have not yet been handled
but I note that the issue over multiplexing non-safe methods was never
addressed. Has a recommended best practice emerged among
implementations for ensuring that unsafe requests are not sent or
handled out of order? Or is it considered to simply be up to
individual implementations to figure out?

---

From: Martin Thomson <[email-masked]>
Date: Wed, 4 Nov 2015 09:10:51 +0900

On 4 November 2015 at 00:36, James M Snell <[email-masked]> wrote:
> Has a recommended best practice emerged among
> handled out of order?

I don't think that we're in any different a situation to where we were
in the past.  There are plenty of cases in HTTP/1.1 where non-safe
methods are multiplexed, they just happen to use connections rather
than streams.  I can infer from this pattern that the defacto approach
is that applications that care about ordering need to provide their
own ordering guarantees.

If pipelining were more widely used, or if it were the case that
people didn't use multiple concurrent connections to a server, I think
that this would more of an issue.

---

From: Patrick McManus <[email-masked]>
Date: Wed, 4 Nov 2015 09:14:39 +0900

Hey James,

In this respect h2 isn't a lot different than h1 with parallel connections
(which doesn't have any specified rules either). At least in my experience,
the application needs to figure out above http whether the two requests
need to be serialized (and hold back, if so).

---

From: James M Snell <[email-masked]>
Date: Tue, 3 Nov 2015 16:36:10 -0800

Ok. Will need to put together a few tests to verify if/how the
existing h2 clients are handling this case then.

Would I be correct in saying that, on the server side, a server
receiving intermingled safe and unsafe requests for the same resource
on the same connection likely ought to ensure that the handling of
those are either serialized or rejected? The best practice of using
Etags and conditionals should also be emphasized further.

On Tue, Nov 3, 2015 at 4:14 PM, Patrick McManus <[email-masked]> wrote:
> the application needs to figure out above http whether the two requests need
> to be serialized (and hold back, if so).
>

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 4 Nov 2015 07:36:08 +0100

> need to be serialized (and hold back, if so).

I'd say that H2 is even more robust regarding this. In H1 the problem was
caused by the fact that the connection could be closed between two requests
and that you had no idea whether the unresponded request was processed or
not. In H2, you have one new stream for your request, so you don't have
the problem of this stream being closed by a keep-alive timeout or whatever
before the request is processed.

Willy