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.
To validate actual response body length against the value declared in
content-length response header field, we first check request method.
If request method is HEAD, respose body must be 0 regardless of the
value in content-length. nghttp2_session_upgrade() has no parameter
to indicate the request method is HEAD, so we failed to validate
response body if HEAD is used with HTTP Upgrade. New
nghttp2_session_upgrade2() accepts new parameter to indicate that
request method is HEAD or not to fix this issue. Although, this issue
affects client side only, we deprecate nghttp2_session_upgrade() in
favor of nghttp2_session_upgrade2() for both client and server side.
This function is useful for the client application to know that there
is a chance that request can be sent. If this function returns 0,
there is zero chance to make a request.
This commit also set error_code passed to
nghttp2_on_stream_close_callback to NGHTTP2_REFUSED_STREAM if request
is not sent.
Application can utilize this framework to send/receive user defined
extension frames. These frames are expected not to change existing
protocol behaviour.
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.
The existing nghttp2_session_consume() affects both connection and
stream level flow control windows. The new functions only affects
either connection or stream. There is some interesting use cases.
For example, we may want to pause a stream by not sending
WINDOW_UPDATE, meanwhile we want to continue to process other streams.
In this case, we use nghttp2_session_consume_connection() to tell
library that only connection level window is recovered. The relevant
discussion: https://code.google.com/p/chromium/issues/detail?id=473259
To avoid buffer copy in nghttp2_data_source_read_callback, this commit
introduces NGHTTP2_DATA_FLAG_NO_COPY and nghttp2_send_data_callback.
By using NGHTTP2_DATA_FLAG_NO_COPY in
nghttp2_data_source_read_callback, application can avoid to copy
application data to given buffer. Instead, application has to
implement nghttp2_send_data_callback to send complete DATA frame by
itself. We see noticeable performance increase in nghttpd and
tiny-nghttpd using this new feature. On the other hand, nghttpx does
not show such difference, probably because buffer copy is not
bottleneck. Using nghttp2_send_data_callback adds complexity, so it
is recommended to measure the performance to see whether this extra
complexity worth it.
Previously API reference is gigantic one rst file and it is a bit hard
to use, especially when browsing similar functions. This commit
splits API reference into smaller fine grained files. The macros,
enums, types are now in its own file. Each API function has its own
file now. API reference doc is now index to above documentation
files. The apiref-header.rst is renamed as programmers-guide.rst and
becomes standalone document.
Previously to create manual page for bundled programs, we use help2man
to create man page from program's help output. Then our man2rst.py
script converts man page to rst document. Sphinx generates html from
rst documents.
Now help2rst.py produces rst document from programs output. We use
Sphinx solely to produce both man pages and html files.
Previously, mkapiref.py required python2.6, as it used format strings,
but continued to use print as a keyword, not a function. But, since 2.6
is implicitly made a requirement, we can also count on print being
available as a function.
This change adds python2.6 as a soft requirement during ./configure,
and converts all print keywords to statements. There's no need to do
anything about the actual building of the doc since sphinx-build can
run under python2 and python3.
The net result is that it no longer matters whether 'python' points to
python2 or python3 (see PEP394), because both will be able to run
mkapiref.py successfully.
Tatsuhiro Tsujikawa
Alexis La Goutte
Dave Reisner