The previous wording implied that if send_callback doesn't return
NGHTTP2_ERR_WOULDBLOCK, this function would always send all
submitted requests / data. This is not the case, since flow control can
cause some data to remain queued until WINDOW_UPDATE is received.
Previously, if automatic window update is enabled (which is default),
after window size is set to 0 by
nghttp2_session_set_local_window_size, once the receiving window is
exhausted, even after window size is increased by
nghttp2_session_set_local_window_size, no more data cannot be
received. This is because nghttp2_session_set_local_window_size does
not submit WINDOW_UPDATE. It is only triggered when new data arrives
but since window is filled up, no more data cannot be received, thus
dead lock happens.
This commit fixes this issue. nghttp2_session_set_local_window_size
submits WINDOW_UPDATE if necessary.
https://github.com/curl/curl/issues/4939
It can be set via the `STATIC_LIB_SUFFIX` variable.
This fixes every existing dependent project that relied on the name
having no suffix and thus capable of using either a static or shared
flavour depending on which one is present on this or how the linker
is configured.
Ref: https://github.com/nghttp2/nghttp2/pull/1394
This commit fixes the bug that stream is closed with wrong error code
(0). This happens when STREAM or DATA frame with END_STREAM flag set
is received and it violates HTTP messaging rule (i.e., content-length
does not match) and the other side of stream has been closed. In this
case, nghttp2_on_stream_close_callback should be called with nonzero
error code, but previously it is called with 0 (NO_ERROR).
Renames the output of the ENABLE_STATIC_LIB library/archive output
to nghttp2_static.lib/.a to avoid filenames colliding with the output
name for ENABLE_SHARED_LIB library/archive, when both are enabled.
Signed-off-by: William A Rowe Jr <wrowe@pivotal.io>
Signed-off-by: Yechiel Kalmenson <ykalmenson@pivotal.io>
The maximum number of outgoing concurrent streams is initially
limited to 100 to avoid issues when the local endpoint submits
lots of requests before receiving initial SETTINGS frame from
the remote endpoint, since sending them at once to the remote
endpoint could lead to rejection of some of the requests.
This initial limit is overwritten with the value advertised in
SETTINGS_MAX_CONCURRENT_STREAMS setting by the remote endpoint,
but previously, it wasn't lifted if the remote endpoint didn't
advertise that setting (implying no limits), in which case the
limit of 100 was retained, even though it was never advertised
by the remote endpoint.
Signed-off-by: Piotr Sikora <piotrsikora@google.com>
Reza Tavakoli
Tatsuhiro Tsujikawa
Tatsuhiro Tsujikawa
Tomas Krizek
Asra Ali
James M Snell
Viktor Szakats
William A Rowe Jr
Don
Brendan Heinonen
Piotr Sikora