W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2014

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

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Fri, 21 Mar 2014 20:55:30 +1300
Message-ID: <532BF072.2070105@treenet.co.nz>
To: ietf-http-wg@w3.org
On 21/03/2014 7:41 p.m., Tatsuhiro Tsujikawa wrote:
> 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?

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.

Received on Friday, 21 March 2014 07:56:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:25 UTC