Re: Stream limits draft posted

On Sat, Nov 11, 2023 at 08:50:51AM +0100, Martin Thomson wrote:
> On Fri, Nov 10, 2023, at 14:16, Stefan Eissing wrote:
> > +1
> >
> > I think clients will not wait for the MAX_STREAMS from the server. I 
> > assume they want to send right away instead of waiting for a while. The 
> > server might support it or not. How long are they willing to wait for 
> > this?
> 
> In the meeting, it was suggested that we require clients to wait for
> SETTINGS before opening streams.  I think that is a good idea and
> entirely possible, without significant performance penalties.
> 
> In TLS 1.3, the server can send SETTINGS immediately, which means that
> the client only needs to read a few more bytes before it can start
> sending.
> 
> The minor pain here, as David Benjamin will likely remind us, is that
> it is a little awkward sending data from the server before seeing the
> client Finished.  So we'd probably want to experiment here.

I have written a HTTP reverse proxy, which used to send SETTINGS
immediately in TLS 1.3[1]. Unfortunately, that caused some clients to
break[2], manifesting as fatal unexpected_message TLS alert immediately
after handshake completed. So I changed the code to always wait for
finished from client[3].


[1] If there was no client certificate request, for shortcomings of
the interface between TLS and HTTP layers.

[2] No information about what clients broke. However, mentions by
one user might indicate that some "anti-virus" products were
involved.

[3] There might still be option to re-enable the old behavior.




-Ilari

Received on Saturday, 11 November 2023 08:33:48 UTC