RFC 7540 does not enforce any limit on the number of incoming reserved
streams (in RFC 7540 terms, streams in reserved (remote) state). This
only affects client side, since only server can push streams.
Malicious server can push arbitrary number of streams, and make
client's memory exhausted. The new option,
nghttp2_set_max_reserved_remote_streams, can set the maximum number of
such incoming streams to avoid possible memory exhaustion. If this
option is set, and pushed streams are automatically closed on
reception, without calling user provided callback, if they exceed the
given limit. The default value is 200. If session is configured as
server side, this option has no effect. Server can control the number
of streams to push.
With OpenSSL <= 1.0.1, openssl ocsp command still returns exit code 0,
even if verification was failed. If that happens certain string is
emitted in stderr, so check that string and if exists, treat it as
error. This issue was fixed in OpenSSL 1.0.2.
At least OpenSSL 1.0.2, openssl ocsp command still returns exit code
0, even if responder returned non-successful status code (e.g.,
trylater(3)). We are not sure this is intentional or not. To handle
this, we again check certain error string in stdout, and if it is
found, treat it as error.
The intention of this stream API is give server application about
stream dependency information, so that it can utilize it for better
scheduling of stream processing. We have no plan to add object
oriented API based on stream object.
We now use priority queue per stream, which contains the stream which
has ready to send a frame, or one of its descendants have a frame to
send. We maintain invariant that if a stream is queued, then its
ancestors are also queued (except for root). When we re-schedule
stream after transmission, we re-schedule all ancestors, so that
streams on the other path can get a chance to send. This is basically
the same mechanism h2o project uses, but there are differences in the
details.
Tatsuhiro Tsujikawa
Lucas Pardue
bxshi
Nora