Re: Retry safety of HTTP requests

• From: Martin Thomson <martin.thomson@gmail.com>
• Date: Wed, 23 Mar 2016 21:25:42 +1100
• To: Mark Nottingham <mnot@mnot.net>
• Cc: Subodh Iyengar <subodh@fb.com>, Mike Bishop <Michael.Bishop@microsoft.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
• Message-ID: <CABkgnnVrL3VS1zhn6PjCjeJ-7wWN+JmG_rU4wCTva-JOTN6gNA@mail.gmail.com>

On 23 March 2016 at 16:12, Mark Nottingham <mnot@mnot.net> wrote:
> It's even harder for a sequence of requests; that really is application-specific.

There, the onus is clearly on the application.  If request B depends
on request A, then a response to A needs to be seen before request B
can be sent.

HTTP/1.1 pipelining allows for a client to offload that to a server
for non-idempotent requests.  In theory.  In practice, pipelining was
fairly inconsistently implemented, particularly the bits around
serialization of requests.  I know of server implementations that
would process in parallel regardless of method; and client
implementations would happily pipeline non-idempotent requests.

HTTP/2 doesn't have the same "feature".  I think that's a good thing.

Received on Wednesday, 23 March 2016 10:26:13 UTC