Implement SPDY stream level timeout

[fcicq]

sadly I'm not sure why the server stopped responding if something is triggered in issue #107, so I often have to restart shrpx :(

[tatsuhiro-t]

You mean remote SPDY proxy stop responding?
Have you tried backend timeouts?

--backend-read-timeout=<SEC>
                 Specify read timeout for backend connection.
--backend-write-timeout=<SEC>
                 Specify write timeout for backend

I have fixed similar problems before. Are you using latest code?

[tatsuhiro-t]

Also providing complete log helps me understand the situation.

[fcicq]

shrpx -p -b 127.0.0.1,4443 -f 127.0.0.1,8001 -k -L INFO --backend-read-timeout=3 --backend-write-timeout=3

...
(curl --proxy 127.0.0.1:8001 www.sina.com.cn for many times, to trigger the remote spdy server stop responding, works well until here)
[INFO] [LISTEN:0x7fc322f23ff0] Accepted connection. fd=10
(shrpx_listen_handler.cc:97)
[INFO] [UPSTREAM:0x7fc322e00600] HTTP request started
(shrpx_https_upstream.cc:78)
[INFO] [UPSTREAM:0x7fc322e00600] HTTP request headers completed
(shrpx_https_upstream.cc:135)
[INFO] [UPSTREAM:0x7fc322e00600] HTTP request headers
GET HTTP://www.sina.com.cn/ HTTP/1.1
User-Agent: curl/7.30.0
Host: www.sina.com.cn
Accept: /
Proxy-Connection: Keep-Alive

   (shrpx_https_upstream.cc:156)

[INFO] [CLIENT_HANDLER:0x7fc322e004e0] Downstream connection pool is empty. Create new one
(shrpx_client_handler.cc:278)
[INFO] [DCONN:0x7fc322e00210] Attaching to DOWNSTREAM:0x7fc322e00670
(shrpx_spdy_downstream_connection.cc:103)
[INFO] [DCONN:0x7fc322e00210] HTTP request headers
(removed)

   (shrpx_spdy_downstream_connection.cc:354)

[INFO] [UPSTREAM:0x7fc322e00600] HTTP request completed
(shrpx_https_upstream.cc:227)
(waiting and waiting... tcp ack is received confirmed by tcpdump)

env:
macosx 10.9.2 / ubuntu linux 13.10

mac: brew list --versions
autoconf 2.69
automake 1.14.1
libevent 2.0.21
libtool 2.4.2
libxml2 2.9.1
openssl 1.0.1f
pkg-config 0.28
spdylay HEAD

ubuntu:
libevent 2.0.21-stable-1

hmm... please send a mail to fcicq at fcicq dot net and I'll give you the full command :(

[tatsuhiro-t]

Timeout for SPDY session was not implemented. This was deliberate decision since SPDY is long lived connection and we just rely on the server to disconnect. But our recent experience shows that timeout is useful especially when connection is unstable (e.g., mobile). The commit 0391a3d adds backend SPDY connection timeout. Note that this timeout is for TCP connection, not the SPDY stream. SPDY stream level timeouts have not been implemented in shrpx.

Meanwhile, from your writings, the remote SPDY proxy seems to swallow HTTP requests but does not respond at all. I'd like to know the problem may be in remote SPDY proxy or not.
Are you using shrpx as remote SPDY proxy? Or other products?

We may need log for remote SPDY server if you manages it.

You can reach me at t-tujikawa at users dot sourceforge dot net