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

Re: initial stream id from a client

From: Roberto Peon <grmocg@gmail.com>
Date: Tue, 13 Aug 2013 13:38:32 -0700
Message-ID: <CAP+FsNeHTmwq3jPfNKHu_TN5ZS+s8mTkNSP1qP-0jmDriSj=QA@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Jeff Pinner <jpinner@twitter.com>, HTTP Working Group <ietf-http-wg@w3.org>, Shigeki Ohtsu <ohtsu@iij.ad.jp>, Alexey Melnikov <alexey.melnikov@isode.com>
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).
>
>
Received on Tuesday, 13 August 2013 20:38:59 UTC

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