This option prevents the nghttp2 library from sending PING frame with
ACK flag set in the reply to incoming PING frame. To allow the
application to send PING with ACK flag set, nghttp2_submit_ping() now
recognizes NGHTTP2_FLAG_PING in its flags parameter.
Previously, we use session->next_stream_id to detect that given stream
ID was idle or not. But this was suboptimal, since it was updated
when stream ID was assigned, and it did not necessarily mean that it
actually has been sent to the peer. Now we introduced
session->sent_stream_id, which only updated when HEADERS/PUSH_PROMISE
has sent. Using sent_stream_id instead of next_stream_id tightens
idle stream detection, and misbehaved peer which sends frame with
stream ID that has not been generated.
This commit also overhauls test code which involves opening streams.
Now we have some wrapper functions for nghttp2_session_open_stream()
which also take care of updating next_stream_id and
last_recv_stream_id. They are crucial for some tests.
With the presence of idle stream related API (e.g.,
nghttp2_create_idle_stream()), it is more predictable for client to
create idle streams with its dependency to another idle stream.
Previously, we didn't create complete parent idle stream in this case.
Now we create idle streams as we do on server side.
Previously we scheduled the transmission of response HEADERS using
priority tree in the belief that it allows more better utilization of
bandwidth for prioritized streams. But to reduce the overhead of
reconstruction of priority queue when connection level flow control
window is depleted, we just don't check priority tree in this case.
This means that response HEADERS frames are not sent even though they
are not flow controlled. This could waste bandwidth. To improve this
situation, we stop scheduling response HEADERS with priority tree for
now. Now they are just sent in the order they submitted. The
response body DATA continued to be scheduled with priority tree as
before.
return session_inflate_handle_invalid_stream(...) case is for streams
for INITIAL state, but this is rare case. In general, we'd like to
reduce RST_STREAM transmission, and it is suffice to ignore this frame
for now.
Previously, we only updated stream's weight field when only weight was
changed by PRIORITY frame. If stream is queued, it would be better to
actually reschedule it based on new weight. This could be especially
useful if weight is increased.
Previously, stream object for pushed resource was not created during
nghttp2_submit_push_promise(). It was created just before
nghttp2_before_frame_send_callback was called for that PUSH_PROMISE
frame. This means that application could not call
nghttp2_submit_response for the pushed resource before
nghttp2_before_frame_send_callback was called. This could be solved
by callback chaining, but for web server with back pressure from
backend stream, it is a bit unnecessarily hard to use.
This commit changes nghttp2_submit_push_promise() behaviour so that
stream object is created during that call. It makes application call
nghttp2_submit_response right after successful
nghttp2_submit_push_promise call.
Previously, nghttp2_session_end_request_headers_received assumes
stream is still writable (in other words, local endpoint has not sent
END_STREAM). But this assumption is false, because application can
send response in nghttp2_on_begin_frame_callback. Probably, this
assumption was made before the callback was introduced. This commit
addresses this issue. Since all
nghttp2_session_end_*_headers_received functions are identical, we
refactored them into one function.
Previously, nghttp2_session_find_stream(session, 0) returned NULL
despite the fact that documentation said that it should return root
stream. Now it is corrected, and it returns root stream as
documented.
The added API is nghttp2_session_change_stream_priority(). This
provides the same functionality to re-prioritize stream when PRIORITY
frame. is received, but we do it without PRIORITY frame. This could
be useful for server to change pushed stream's priority silently.
It has no usecase at the moment. It is most likely that applications
know the flags when it submitted extension frame, no need to modify it
later. Possibly feature bloat.
Tatsuhiro Tsujikawa
kumagi