Subject: RE: REFUSED_STREAM => RETRY_STREAM (editorial) was: RE: hpack table size 0

From: <[email-masked]>
Date: Fri, 1 Aug 2014 09:44:04 +0000

Hi Martin-

https://github.com/http2/http2-spec/pull/576

The definition of REFUSED_STREAM is somewhat contradictory with the definition of the word refused. The word refused is defined as: indicate or show that one is *not willing* to do something [1]. The definition of REFUSED_STREAM in Section 7 references section 8.1.4 which says that a REFUSED_STREAM is safe to retry. In other words the server is actually *willing* to process the stream, but *currently unable* (e.g. because the client overran settings and so the client needs to retry the stream with the new settings).

-keith

[1] https://www.google.at/

> -----Original Message-----

> From: MORGAN, Keith Shearl

> Sent: Wednesday,16 July 2014 15:44

> To: [email-masked]'

> Cc: [email-masked]; [email-masked]

> Subject: REFUSED_STREAM => RETRY_STREAM (editorial) was: RE: hpack table

> size 0

> On Tuesday,01 July 2014 09:15, [email-masked]<mailto:[email-masked]> wrote:

> > On 1 Jul 2014, at 1:46 am, [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

> wrote:

> >> How does the client know to retry the stream?  The spec never mentions

> >> that a client should retry.

> > This spec doesn't, but HTTP does...

> >   <http://httpwg.github.io/specs/rfc7230.html#persistent.retrying.requests<http://httpwg.github.io/specs/rfc7230.html#persistent.retrying.requests%20<http://httpwg.github.io/specs/rfc7230.html#persistent.retrying.requests>

> <http://httpwg.github.io/specs/rfc7230.html#persistent.retrying.requests<http://httpwg.github.io/specs/rfc7230.html#persistent.retrying.requests%20<http://httpwg.github.io/specs/rfc7230.html#persistent.retrying.requests>> >

> > That said, the layering here needs some cleaning up. We could either re-

> specify

> > this in HTTP/2, or make it clear when we re-factor 7230 to go to full Standard.

> > The latter is on the agenda for Toronto...

> I would like to propose renaming REFUSED_STREAM to RETRY_STREAM.

> IMO, REFUSED_STREAM doesn’t match the definition of the word “refused”

> because there is a time component i.e. the server decided, for whatever reason,

> to not accept the stream *right now*, but you can try again later.

> refuse /rɪˈfjuːz/

> verb

> past tense: refused; past participle: refused

>      indicate or show that one is not willing to do something. [1]

> From Section 7 [2]:

> REFUSED_STREAM (0x7):  The endpoint refuses the stream prior to performing

> any application processing, see Section 8.1.4 <http://http2.github.io/http2-<http://http2.github.io/http2-spec/#Reliability>

> spec/#Reliability<http://http2.github.io/http2-spec/#Reliability>>  for details.

> From Section 8.1.4 (emphasis added) [2]:

> The REFUSED_STREAM error code can be included in a RST_STREAM frame to

> indicate that the stream is being closed prior to any processing having occurred.

> Any request that was sent on the reset stream can be safely retried.

> …

> Requests that have not been processed have not failed; clients MAY

> automatically retry them, even those with non-idempotent methods.

> Proposed change:

> RETRY_STREAM (0x7):  The endpoint closed the stream prior to performing any

> application processing.  Any request that was sent on the reset stream can be

> safely retried, see Section 8.1.4 <http://http2.github.io/http2-spec/#Reliability>

> for details.

> [1] https://www.google.at/

> [2] http://http2.github.io/http2-spec/#ErrorCodes

> [3] http://http2.github.io/http2-spec/#Reliability

This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 1 Aug 2014 09:25:14 -0700

On 1 August 2014 02:44,  <[email-masked]> wrote:
> The definition of REFUSED_STREAM is somewhat contradictory with the
> definition of the word refused. The word refused is defined as: indicate or
> show that one is *not willing* to do something [1]. The definition of
> REFUSED_STREAM in Section 7 references section 8.1.4 which says that a
> REFUSED_STREAM is safe to retry. In other words the server is actually
> *willing* to process the stream, but *currently unable* (e.g. because the
> client overran settings and so the client needs to retry the stream with the
> new settings).

I'm not sure that I agree with this assessment.  Does anyone else?

---

From: <[email-masked]>
Date: Fri, 1 Aug 2014 17:31:23 +0000

Hi Martin-

Can you be more specific? Section 8.1.4 says a refused stream is safe to retry. Is there a case where the stream should be refused but not retried? If so, perhaps both refused_stream & retry_stream should exist.

-Keith

> On Aug 1, 2014, at 18:25, "[email-masked]" <[email-masked]> wrote:
>

---

From: Jeff Pinner <[email-masked]>
Date: Fri, 1 Aug 2014 10:33:53 -0700

could also be refused because that particular server is shutting down
and is thus "unwilling"

re-issuing it to the same virtual host may result in a server more "willing"

---

From: Mike Bishop <[email-masked]>
Date: Fri, 1 Aug 2014 18:02:17 +0000

I think the thing to clarify is the distinction between the stream and the request.  REFUSED_STREAM means that the *stream* is unacceptable to the server (for some reason), regardless of the request that it might have been carrying.  The server is, in fact, "unwilling" to open a stream at this time, so the name is accurate.  The client isn't told (but by the time it sees the RST_STREAM, hopefully has seen a SETTINGS frame that lets it understand with some accuracy) why the stream is unacceptable.

However, this is a transport-layer failure, which means the *request* is safe to retry.  In IE, we have exactly the same retry behavior if a TCP connection is RST before we've received any of the server's response, even if the request itself wasn't idempotent.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, August 1, 2014 10:31 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: REFUSED_STREAM => RETRY_STREAM (editorial) was: RE: hpack table size 0

Hi Martin-

-Keith

>> definition of the word refused. The word refused is defined as: 
>> indicate or show that one is *not willing* to do something [1]. The 
>> definition of REFUSED_STREAM in Section 7 references section 8.1.4 
>> which says that a REFUSED_STREAM is safe to retry. In other words the 
>> server is actually
>> *willing* to process the stream, but *currently unable* (e.g. because 
>> the client overran settings and so the client needs to retry the 
>> stream with the new settings).
>