Subject: initial stream id from a client

From: Shigeki Ohtsu <[email-masked]>
Date: Tue, 13 Aug 2013 12:39:02 +0900

Please let me clarify the initial stream id from a client written in draft-05.

In 5.1.1 Stream Identifiers,
" A stream identifier of one (0x1) is used to respond to the HTTP/1.1 request which was specified during Upgrade (see Section 3.2); stream
identifier 0x1 MUST NOT be used by a client to establish a new stream. "

Is 0x1 always reserved for the implicit stream so that a stream from a client
should start from 0x3 even in a TLS connection?
And if a server receives a stream of 0x1 from a client, is it a connection error?

Or is it only the case of upgrade?

Regards,

---

From: Mike Bishop <[email-masked]>
Date: Tue, 13 Aug 2013 04:46:41 +0000

In the TLS case, or direct-to-2.0 case, there is no implicit stream, and so no need to reserve one.  The client opens a stream with an ID of its choosing and the server responds on it.

In Upgrade, though, the client request was sent as 1.1 with no stream ID, but the server has to respond to that request on a stream, so the spec arbitrarily states what stream the client's request was on.

-----Original Message-----
From: Shigeki Ohtsu [mailto:[email-masked]] 
Sent: Monday, August 12, 2013 8:39 PM
To: HTTP Working Group
Subject: initial stream id from a client

In 5.1.1 Stream Identifiers,
" A stream identifier of one (0x1) is used to respond to the HTTP/1.1 request which was specified during Upgrade (see Section 3.2); stream identifier 0x1 MUST NOT be used by a client to establish a new stream. "

Is 0x1 always reserved for the implicit stream so that a stream from a client should start from 0x3 even in a TLS connection?
And if a server receives a stream of 0x1 from a client, is it a connection error?

Regards,

---

From: Shigeki Ohtsu <[email-masked]>
Date: Tue, 13 Aug 2013 13:56:40 +0900

Thanks, I feel relieved that it is the same as draft-04.

The description of "stream identifier 0x1 MUST NOT be used" newly appeared in 05
so it would be helpful for me if its condition is written more clearly without depending on its context.

(2013/08/13 13:46), Mike Bishop wrote:
> " A stream identifier of one (0x1) is used to respond to the HTTP/1.1 request which was specified during Upgrade (see Section 3.2); stream identifier 0x1 MUST NOT be used by a client to establish a new stream."
>

---

From: Mike Bishop <[email-masked]>
Date: Tue, 13 Aug 2013 05:00:24 +0000

Hm.  Yes, I can see where that could be read both ways.  I agree, it would be good to clarify the spec, either way. 

-----Original Message-----
From: Shigeki Ohtsu [mailto:[email-masked]] 
Sent: Monday, August 12, 2013 9:57 PM
To: [email-masked]
Subject: Re: initial stream id from a client

The description of "stream identifier 0x1 MUST NOT be used" newly appeared in 05 so it would be helpful for me if its condition is written more clearly without depending on its context.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 13 Aug 2013 11:08:07 +0100

> Hm.  Yes, I can see where that could be read both ways.  I agree, it would be good to clarify the spec, either way.
For simplicity and consistency I prefer that the stream #1 is always 
reserved, so that client always starts with stream 3.
I don't think burning 1 stream id is going to be a big deal.

Returning connection error if stream #1 is used to create a new stream 
seems reasonable.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Aug 2013 18:24:58 +0100

> reserved, so that client always starts with stream 3.

This sounds like a reasonable motivation for option 3.  Does anyone
want to argue for using stream 1 when over TLS?

---

From: Jeff Pinner <[email-masked]>
Date: Tue, 13 Aug 2013 10:55:26 -0700

yes

---

From: Jeff Pinner <[email-masked]>
Date: Tue, 13 Aug 2013 10:58:27 -0700

sry, it return too early...

The upgrade case is the outlier and already has lots of special case logic.
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.

On Tue, Aug 13, 2013 at 10:55 AM, Jeff Pinner <[email-masked]> wrote:

> yes
>
>
> On Tue, Aug 13, 2013 at 10:24 AM, Martin Thomson <[email-masked]
> > wrote:
>

---

From: Michael Sweet <[email-masked]>
Date: Tue, 13 Aug 2013 14:30:29 -0400

Jeff,

With all due respect, I don't think we can consider HTTP/2.0 upgrade an "outlier". I rather suspect that it will get used quite often when a) security of the communications channel is not a concern and b) existing usage makes wholesale adoption of HTTP/2.0 impossible.

I'm a printer guy, so my first thoughts are IPP and IPP USB (which provides a HTTP/1.1 transport over USB), but I am sure there are other users of HTTP/1.1 that could benefit from using HTTP/2.0 when it is supported but can't otherwise require it.

On Aug 13, 2013, at 1:58 PM, Jeff Pinner <[email-masked]> wrote:

> 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.
> 
> 
> On Tue, Aug 13, 2013 at 10:24 AM, Martin Thomson <[email-masked]> wrote:

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Aug 2013 19:32:43 +0100

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

---

From: Jeff Pinner <[email-masked]>
Date: Tue, 13 Aug 2013 11:39:50 -0700

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.

---

From: Michael Sweet <[email-masked]>
Date: Tue, 13 Aug 2013 14:59:57 -0400

+1 for all of this... :)

On Aug 13, 2013, at 2:39 PM, Jeff Pinner <[email-masked]> 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).
> 
> 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 <[email-masked]> wrote:

---

From: Roberto Peon <[email-masked]>
Date: Tue, 13 Aug 2013 12:14:51 -0700

++

On Tue, Aug 13, 2013 at 11:39 AM, Jeff Pinner <[email-masked]> wrote:

> It is perfectly acceptable for a client implementation to always begin
> with stream-id 3 and reserve stream-id 1 for upgrade.
>
> On Tue, Aug 13, 2013 at 11:32 AM, Martin Thomson <[email-masked]
> > wrote:
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Aug 2013 21:36:07 +0100

On 13 August 2013 19:39, Jeff Pinner <[email-masked]> wrote:
> 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).

---

From: Roberto Peon <[email-masked]>
Date: Tue, 13 Aug 2013 13:38:32 -0700

Sgtm
On Aug 13, 2013 1:37 PM, "Martin Thomson" <[email-masked]> wrote:

> with
> direct-to-HTTP

---

From: Shigeki Ohtsu <[email-masked]>
Date: Wed, 14 Aug 2013 09:17:50 +0900

Yes, I agree this.
It's already in the half-closed state and no need to define an absolute prohibition.