W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: GOAWAY and proxies (#458)

From: Daniel Sommermann <dcsommer@fb.com>
Date: Mon, 21 Apr 2014 16:26:22 -0700
Message-ID: <5355A91E.80901@fb.com>
To: "William Chan (陈智昌)" <willchan@chromium.org>
CC: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Thanks for the response!

On 04/21/2014 03:58 PM, William Chan (陈智昌) wrote:
> Just to be clear, this is a problem with HTTP/1.1 today, right?
Correct, this is an issue for HTTP/1.1 clients only. This is a blocker 
for HTTP/1.1 <-> 2.0 proxy interop in my mind. I'm all for 
REFUSED_STREAM in general for the future.
> When I think about what Chromium would upon receipt of a DRAINING 
> frame, I don't know.
Chromium should probably issue new HTTP requests on a different 
connection and not open streams on the connection that got a DRAINING 
frame (even before getting the GOAWAY). This could avoid extra RTTs due 
to retrying requests.
> What do you do today in this situation?
We are implementing the GOAWAY hack of acknowledging the last 
transaction id we saw plus MAX_CONCURRENT_STREAMS, but we don't use this 
for publicly facing connections since it is non-standard behavior.
> It seems like you could build this draining semantic at the 
> application layer on top of the proxy<=>backend connections, by using 
> magic path handlers (/doyouwanttoacceptrequests), which indeed is how 
> I would imagine doing it with HTTP/1.X connections to the backends. 
> This type of polling isn't exactly elegant, but mostly works today.
This would work for reverse proxies, but polling as you say is not very 
elegant (wasted bytes, 1 full RTT to update state). If your polling 
interval isn't frequent enough, you could still hit the race condition. 
We have seen this kind of polling hurt CPU of origin servers in other 
contexts. Finally, this is a bunch of repeated protocol-like work that 
every proxy/server pair would have to remember to implement as a 
consequence of the broken spec, or else they would run into this issue. 
For forward proxies, polling wouldn't work at all since random HTTP/2 
servers probably don't implement the /doyouwanttoacceptrequests 
endpoint. Imo, it is better to bake a solution into the spec so every 
implementor doesn't have to reinvent the wheel.
> So yeah, I'm open to it, but need more convincing.
Hopefully this is a start :)
Received on Monday, 21 April 2014 23:26:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC