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

Re: initial stream id from a client

From: Michael Sweet <msweet@apple.com>
Date: Tue, 13 Aug 2013 14:59:57 -0400
Cc: Martin Thomson <martin.thomson@gmail.com>, Alexey Melnikov <alexey.melnikov@isode.com>, Shigeki Ohtsu <ohtsu@iij.ad.jp>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-id: <16AD4892-247D-42E8-9629-3C412AD85F09@apple.com>
To: Jeff Pinner <jpinner@twitter.com>
+1 for all of this... :)

On Aug 13, 2013, at 2:39 PM, Jeff Pinner <jpinner@twitter.com> wrote:

> Michael, I meant an "outlier" from the stream perspective -- i.e. the "upgrade" stream is special and requires special case logic for things besides stream id (priority for example).
> Martin, I think the following:
> 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.
> On Tue, Aug 13, 2013 at 11:32 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
> On 13 August 2013 18:58, Jeff Pinner <jpinner@twitter.com> wrote:
> > The upgrade case is the outlier and already has lots of special case logic.
> I suspected that this would be the reason :)
> > If the upgrade is successful than the session handling will have to manage a
> > stream-ID of 1. It doesn't make sense to couple the session handling with
> > the wire format.
> I'll note that the last sentence could be construed as an argument for
> starting from 3 always.  I think that you instead want to say that you
> don't want to be affected by something you don't plan to implement.

Michael Sweet, Senior Printing System Engineer, PWG Chair

Received on Tuesday, 13 August 2013 19:00:28 UTC

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