Subject: Time out error code for HTTP/2 stream?

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Fri, 21 Mar 2014 15:41:31 +0900

Currently we  don't have HTTP/2  error code specifically  telling that
stream is timed  out.  If an endpoint does not  receive the meaningful
data in the implementation defined timeout, it consider that something
bad happens  in the  remote endpoint  and it  will send  RST_STREAM to
cancel the stream and may resend the request or just terminate it.

At  the  moment, the  most  appropriate  error  code for  the  timeout
situation is INTERNAL_ERROR in RST_STREAM.   But time out condition is
very common to  networking program and it is sometimes  very useful to
debug if we know the cause of  reset.  So I propose new error code for
time out, say, STREAM_TIMEOUT or just TIMEOUT.

What do you think about this?

Best regards,
Tatsuhiro Tsujikawa

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 21 Mar 2014 20:55:30 +1300

> What do you think about this?

I think a simple timeout code does not clarify enough useful information
given that HTTP is a multi-hop protocol with several stages of operation
which can encounter timeout at each hop separately (DNS lookup timeout,
TCP handshake timeout, TCP data timeout, etc). The multiplexing of
streams by middleware makes the simple timeout code/flag even less
reliable for debugging.

For debugging purposes on these types of events I suggest instead that
there may be a case for adding an optional "Additional Debug Data" field
to RST_STREAM identical in nature to the GOAWAY field.

Additional to your timeout debugging case is the intermediary use-case
where a server connection fails with GOAWAY. The given a debug data
field in RST_STREAM the proxy could propigate the GOAWAY debug data and
error code using RST_STREAM fields for just the streams affected by that
GOAWAY without having to send GOAWAY itself up to its client and
ptentially affect unrelated streasm on the client connection.

Amos