Re: initial stream id from a client

On 13 August 2013 19:39, Jeff Pinner <jpinner@twitter.com> wrote:
> It is perfectly acceptable for a client implementation to always begin with
> stream-id 3 and reserve stream-id 1 for upgrade.
>
> I disagree with the requirement that if a client does ALPN or direct-to-HTTP
> is a connection error to send stream-id 1. I'd prefer to keep all the
> "special-case" logic for upgrade within the upgrade path.

So, to turn this into something actionable, let me propose:

OLD:
  A stream identifier of one (0x1) is used to respond to the HTTP/1.1
request which was specified during Upgrade (see <xref
target="discover-http"/>); stream identifier 0x1 MUST NOT be used by a
client to establish a new stream.
NEW:
  A stream identifier of one (0x1) is used to respond to the HTTP/1.1
request which was specified during Upgrade (see <xref
target="discover-http"/>).  After the upgrade completes, stream 0x1 is
"half closed (local)" to the client.  Therefore, stream 0x1 cannot be
selected as a new stream identifier by a client that upgrades from
HTTP/1.1.

There are plenty of existing MUST/MUST NOT statements around sending
different packets in this state.  No need to repeat them (and risk
messing something up).

Received on Tuesday, 13 August 2013 20:36:34 UTC