Re: #38 - HTTP2 min value for server supported max_concurrent_streams

On Feb 27, 2013, at 12:31 AM, Roberto Peon <grmocg@gmail.com<mailto:grmocg@gmail.com>>
 wrote:

On Tue, Feb 26, 2013 at 2:15 PM, Yoav Nir <ynir@checkpoint.com<mailto:ynir@checkpoint.com>> wrote:
Hi

Thinking it over, even a minimal server that can only handle one request at a time can be accommodated by the current document. Such a server would send a SETTINGS frame ASAP, and would process incoming streams one by one. Streams where we get frames before the FLAG_FIN of a previous stream would get a RST. But GETs are more numerous than POSTs, so bodies tend to be empty. Until its SETTINGS is processed by the client, the requests will mostly be just SYN_STREAM frames with the FLAG_FIN set, and they can be handled sequentially. Depending on how the MUSTs and SHOULDs are phrased, this may or may not be compliant, but it would be interoperable with any HTTP/2 client.

Back to the issue, I don't think any number makes sense other than 1. So if we can't wait the round-trip, we might as well set no initial limit, and leave it up to the application (client) to decide how many are prudent initially.

As a server owner, that (unlimited) makes me a bit afraid-- I want to set a high enough default that we don't cause additional latency most of the time, but also small enough that I can catch misbehaving or malicious parties in bad behavior as quickly as possible.

OK. But suppose we set the default to 100 and a client opens 101 concurrent streams. What would a server do? It's very rare that a server can do anything interesting in real-time to enforce RFC requirements.

We picked 100 originally as it was the nearest power-of-something-familiar where the limit was greater than the average number of resources on a page, and it is reasonable for a server to reject what it needs to.
Sadly, we have experience with this already-- we have at least one domain where the maximum concurrency is limited to 10, and so we do already have experience in the scenario where the default is higher than we intend to run with. It causes no real problems.

A paragraph that ends with "causes no real problems" should not begin with "Sadly" :-)


But instead the spec should make it clear that having a stream reset with REFUSED_STREAM or some such is not a fatal error, and the client should try again with a new stream. Servers should be advised to send the SETTINGS frame before sending any RST, so that the client doesn't retry when too many (in the server's opinion) streams are open.

Agreed-- if the spec isn't already clear about it must be fixed!

The spec is currently silent about why a server might want to close a stream with REFUSED_STREAM, or what a client should take that to mean. All it says is this:

   Upon receipt of a SYN_STREAM, the recipient can reject the stream by
   sending a stream error (Section 3.4.2<http://tools.ietf.org/html/draft-ietf-httpbis-http2-01#section-3.4.2>) with the error code
   REFUSED_STREAM.  Note, however, that the creating endpoint may have
   already sent additional frames for that stream which cannot be
   immediately stopped

So the server "can reject", but it's not clear why it would or what this means to the client.

Yoav