This is a regression when we introduced SSL/TLS session resumption in
HTTP/2 backend. Before the introduction of session resumption,
conn_.tls.ssl is always nullptr when connection is made to proxy. But
we have to keep conn_.tls.ssl to enable session resumption, so our
code breaks when it is reused. This commit fixes this issue.
See GH-421
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.
By default, we check the length of response body matches
content-length. For HEAD request, this is not necessarily true, so we
sniff request method, and if it is HEAD, make sure that response body
length is 0. But this does not work for HTTP Upgrade, since
nghttp2_session_upgrade() has no parameter to tell the request method
was HEAD. This commit disables this response body length validation
for the stream upgraded by HTTP Upgrade. We will add new version of
nghttp2_session_upgrade with the parameter to pass the request method
information so that we can handle this situation properly.
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.
It seems that using ev_feed_event to signal write operation is much
faster than starting watcher. This is probably due to the fact that
we don't need to wait in event loop. The same thing cannot be done in
HTTP/2 frontend, since this will raise write operation for each stream
HEADER/DATA write, which leads to very small packets, hurting
performance. Interestingly, HTTP/1 frontend also suffers the same
performance hit.
