Re: Limiting allowable pre-SETTINGS requests

There was, in fact, a draft about this several months back, driven primarily by the fact that it's more painful to reduce flow control window & number of allowed streams than to increase it.  Two different ALPN tokens, with two different initial stream counts; the "constrained" version started at 1 stream and 2K flow control window, while the "full" version started at 100 streams and 64K flow control window.  And of course, regardless of which you negotiated, you can always increase from that without an issue.

See http://tools.ietf.org/html/draft-montenegro-httpbis-http2-server-profiles.  The working group decided not to go this direction, because the driving issue was the pain of reduction, and the general consensus was that reduction wasn't painful enough to warrant the complexity.  If the server is overwhelmed, it can RST every stream it doesn't have the capacity to handle (though it still has to process the HEADERS frames to maintain state).

Ironically enough, I believe the only thing we've retained from that draft are the tokens "h2" and "h2c".

Sent from Windows Mail

From: Jason Greene<mailto:jason.greene@redhat.com>
Sent: ?Thursday?, ?June? ?5?, ?2014 ?12?:?14? ?PM
To: HTTP Working Group<mailto:ietf-http-wg@w3.org>

Recent threads have discussed how more limited servers, perhaps running on embedded devices, or resource constrained intermediaries, could use SETTINGS to reduce the decoding overhead both in terms of table size, and depending on the output of #485, potentially usage of huffman.

However, even with this capability, these servers are still required to process requests up until the client has received and processed the SETTINGS frame. I understand that this is purposefully not a full negotiation due to the RTT cost. However, since there is also no form of flow-control on HEADER frames, a client can (and likely will) send as much as it can when the connection is initially created. Depending on the stickiness of traffic patterns (or more precisely lack thereof), this could be a significant volume of traffic.

Should there perhaps be some cooperative limitation on the amount of request data that can be sent before receiving the first SETTINGS frame (i.e a temporary flow-control)?

An alternative could be for an implementation to ignore the request content and use Retry-After in some scheme to force adoption of the SETTINGS values. However, it becomes guess-work on specifying the time amount.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat