W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

Re: initial stream id from a client

From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 13 Aug 2013 21:36:07 +0100
Message-ID: <CABkgnnWGbh344og0HNLyPrucz2XA1h5OLOqc5vQDaJAdr9AE4g@mail.gmail.com>
To: Jeff Pinner <jpinner@twitter.com>
Cc: Alexey Melnikov <alexey.melnikov@isode.com>, Shigeki Ohtsu <ohtsu@iij.ad.jp>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC