shrpx:
* Added an option to set the TLS SNI extension between shrpx and the
origin on the command line
spdycat:
* If the user set an explicit host header ( using --headers ) use that
name for the TLS SNI extension.
* Added the handshake completion time to the verbose output
* The gettimeofday call in get_time was using the incorrect structure
( I believe )
* In update_html_parser it was submitting the request regardless of
the return value of add_request.
Patch from Stephen Ludin
spdy_data_read_callback in SpdyDownstreamConnection calls
SpdyUpstream::resume_read() which submits WINDOW_UPDATE, but after
that they are not call SpdyUpstream::send(). This means that if no
pending outgoing data in upstream, then WINDOW_UPDATE is blocked until
SpdyUpstream::send() from somewhere. This change adds
SpdyUpstream::send() to resume_read() so that WINDOW_UPDATE is not
blocked.
This change fixes upstream RST_STREAM is blocked until
SpdyUpstream::send() is called. Now downstream REFUSED_STREAM is
propagated to upstream client so that client can reset request. The
RST_STREAM error code when downstream went wrong is changed from
CANCEL to INTERNAL_ERROR.
Now we set Downstream::set_response_connection_close(true) for
tunneled connections. Also call
Upstream::on_downstream_body_complete() callback when setting
MSG_COMPLETE in SpdySession when RST_STREAM is caught. Clean up EOF
handling in https_downstream_readcb.
Currently, resume_read() fails if on_read() returns -1 in case that
evbuffer_add failed, which means, most likely, memory allocation
failure. ClientHandler is marked "should be closed", but if
evbuffer_add is failed, write callback will not be invoked and its
marking is not evaluated. It will eventually be deleted when the
client is disconnected or backend failure though.
Specify proxy URI in the form http://[USER:PASS]PROXY:PORT. USER and
PASS are optional and if they exist they must be properly
percent-encoded. This proxy is used when the backend connection is
SPDY. First, make a CONNECT request to the proxy and it connects to
the backend on behalf of shrpx. This forms tunnel. After that, shrpx
performs SSL/TLS handshake with the downstream through the tunnel. The
timeouts when connecting and making CONNECT request can be specified
by --backend-read-timeout and --backend-write-timeout options.
Tatsuhiro Tsujikawa
moparisthebest
snnn