Re: initial stream id from a client

Sgtm
On Aug 13, 2013 1:37 PM, "Martin Thomson" <martin.thomson@gmail.com> wrote:

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