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

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: [] 
Sent: Friday, August 1, 2014 10:31 AM
Subject: Re: REFUSED_STREAM => RETRY_STREAM (editorial) was: RE: hpack table size 0

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.


> On Aug 1, 2014, at 18:25, "" <> wrote:
>> On 1 August 2014 02:44,  <> 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?
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 18:02:59 UTC