There is a discussion in httpbis mailing list which argues that
dependency tree is for client, and changing it in server side is not
what client expects.
https://lists.w3.org/Archives/Public/ietf-http-wg/2016JulSep/0416.html
Currently, we make pushed stream depend on the parent stream of
associated stream (that is main HTML in most of the cases), so that
associated stream and pushed stream become siblings. In this case, we
also observed that these resources complete each other to get its
parent weight. This means that the delivery of associated stream is
delayed by pushed streams.
So at this moment, it is not a good idea to change pushed stream
priority in a way we do currently.
Previously, in server side, we used closed streams to detect the error
that the misbehaving client sends a frame on the incoming stream it
explicitly closed. With this commit, we make a further step, and
detect one more error case. Since we retain closed streams as long as
the sum of its size and the number of opened streams are equal or less
than max concurrent streams, we can safely say that if we get a frame
which is sent on the stream that is not found in either closed or
opened stream, it is already closed or has not existed. Then we can
send GOAWAY.
The previous code shrinks closed streams when we closed another
stream, but now it is removed. It is enough to adjust closed streams
when new incoming stream is created.
While creating this commit, we noticed that
NGHTTP2_INITIAL_MAX_CONCURRENT_STREAMS is defined as INT32_MAX. But
since SETTINGS can contain value up to UINT32_MAX, it is not enough.
However, since the stream ID space is limited to INT32_MAX, it is high
enough. We could keep this value, but this time we deprecate
NGHTTP2_INITIAL_MAX_CONCURRENT_STREAMS macro. While it is in public
header, the effect of deprecating it is negligible because of the
reason we wrote above, and usually application sets much smaller value
(say, 100) as SETTINGS_MAX_CONCURRENT_STREAMS.
Tatsuhiro Tsujikawa
Wenfeng Liu
Wenfeng Liu