W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2016

Re: Retry safety of HTTP requests

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Tue, 22 Mar 2016 23:38:32 +1300
To: ietf-http-wg@w3.org
Message-ID: <56F120A8.3080502@treenet.co.nz>
On 22/03/2016 9:44 p.m., Subodh Iyengar wrote:
> Realized I forgot to answer one more question of yours:
> 
>> Why not use the REST semantics of HTTP itself as the signal?

> We have several POST mutations from the app, however the realistic
> scenario is that a lot of these requests will fail in bad networks,
> most times without a HTTP/2 GOAWAY. In that case what should we do?
> We have 2 choices, give up and assume that the server might have seen
> the data and leave the user with a bad experience, or build an
> application layer idempotency.


Ah. This is where I would expect the application to use a unique ID in
the client POST and the server to ignore repeated IDs.

That is simple, relatively efficient and very much an application-layer
thing not related to the protocol itself.


> The retry safety property allows our
> HTTP library to know that certain requests even mutating ones have
> idempotent properties and it is free to retry the requests even if
> the underlying request fails.

I get the idea that this "library" is part of the client or server
endpoints. If that is correct, then from the HTTP protocol viewpoint it
is classified as part of the application-layer. Which in turn means that
the signal is only going between the library and some other layer within
the application itself.

In other words: The signal is not relevant to the protocol, just very
relevant to how that library portion of the application uses the protocol.

Which is very reasonable. But maybe not worthwhile extending the protocol.


> 
>> I'm certainly interested to find out why HTTP semantics are
>> suddenly so insufficient that its needed. IME Facebook was turning
>> into one of the better HTTP participants before it abandoned for
>> HTTPS-world.
> 
> I'm not sure I understand what you mean. I'm reaching out well
> intentioned way and asking for feedback.

I meant only that I'm curious where is the new hole that you can see in
HTTP. As an old protocol with a wide amount of use-case testing it is a
bit of a surprise to find something so fundamental as retriability
falling short without already being a known problem for years.

You have somewhat clarified that with your responses. Thanks.


Yes, IMO this WG is the right place to discuss the topic. At least until
the powers that be says things have gone too far off-topic.

Amos
Received on Tuesday, 22 March 2016 10:39:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 22 March 2016 12:47:11 UTC