Re: Post before acking settings?

On 27/04/2016 3:25 p.m., Martin Thomson wrote:
> On 27 April 2016 at 12:22, Jesse Wilson wrote:
>> Should a well behaved HTTP/2 client wait to ack the server’s SETTINGS before
>> sending other frames?
> 
> No.  The protocol needs to operate correctly without settings, and
> blocking on the ack adds additional latency.
> 

My understanding was that endpoints should (MUST?) assume 100 streams
was permissiable up until the SETTINGS was received+ACK'd. After which
point whatever value was ACK'd is used as the limit.

If the limit was lower than the default 100 some streams the excess may
be delayed on responding or get RST_STREAM with corresponding re-try
being needed when space opened up again (possibly on other connections
for faster total latency).


> Though nginx is within its rights to refuse any stream; it should not
> be using a lack of settings acknowledgment as the basis on which it
> refuses.  Refusing in this context adds significant latency during a
> time when extra latency costs a lot.
> 
> In the end, I think that nginx might be at fault here.  However, while
> I get that the complexity of retry is awful, it's probably the nicest
> overall outcome for you, since you are going to encounter
> `REFUSED_STREAM` in future.  Consider also the other situations where
> retry helps, like GOAWAY:
> https://http2.github.io/http2-spec/index.html#Reliability
> 

Nod.

Amos

Received on Wednesday, 27 April 2016 04:29:35 UTC