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

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: 'mnot@mnot.net'

> Cc: Michael.Bishop@microsoft.com; ietf-http-wg@w3.org

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

> size 0

>

> On Tuesday,01 July 2014 09:15, mnot@mnot.net<mailto:mnot@mnot.net> wrote:

>

> > On 1 Jul 2014, at 1:46 am, K.Morgan@iaea.org<mailto:K.Morgan@iaea.org> <mailto:K.Morgan@iaea.org>

> 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.

Received on Friday, 1 August 2014 09:45:05 UTC