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