Re: [quicwg/base-drafts] Counting closed streams against the concurrent stream limit (#263)

[Martin Thomson <[e-mail]>]

@ianswett, I'm not sure what you mean when you say "partially buffered".  I would caution about saying things like "doesn't seem that large" without knowing precisely what that state is though.  I know that at least in a browser, the state we generate for a response likely far exceeds the size of the bytes transferred.  And I can't think that browsers are special in any way here.

As you say, this isn't a problem for servers responding to GET requests.  At the server, those are strictly limited by the server concurrent stream limit.  The server is never over-committed.  Where it is a problem is at the side that receives the second close.  So clients are more likely to be affected, given that they tend to close first.

It's certainly an argument for keeping the requirement for the "pointless" FIN on server push streams.  At least that way clients can ensure that there is an upper bound on the number of active pushes.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/263#issuecomment-277898100