initial stream id from a client

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

initial stream id from a client

Shigeki Ohtsu
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,






Reply | Threaded
Open this post in threaded view
|

RE: initial stream id from a client

Mike Bishop
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:[hidden email]]
Sent: Monday, August 12, 2013 8:39 PM
To: HTTP Working Group
Subject: initial stream id from a client

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,








Reply | Threaded
Open this post in threaded view
|

Re: initial stream id from a client

Shigeki Ohtsu
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:

> 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:[hidden email]]
> Sent: Monday, August 12, 2013 8:39 PM
> To: HTTP Working Group
> Subject: initial stream id from a client
>
> 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,
>
>
>
>
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

RE: initial stream id from a client

Mike Bishop
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:[hidden email]]
Sent: Monday, August 12, 2013 9:57 PM
To: [hidden email]
Subject: Re: initial stream id from a client

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:

> 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:[hidden email]]
> Sent: Monday, August 12, 2013 8:39 PM
> To: HTTP Working Group
> Subject: initial stream id from a client
>
> 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,
>
>
>
>
>
>
>
>




Reply | Threaded
Open this post in threaded view
|

Re: initial stream id from a client

Alexey Melnikov
On 13/08/2013 06:00, Mike Bishop wrote:
> 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.

> -----Original Message-----
> From: Shigeki Ohtsu [mailto:[hidden email]]
> Sent: Monday, August 12, 2013 9:57 PM
> To: [hidden email]
> Subject: Re: initial stream id from a client
>
> 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:
>> 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:[hidden email]]
>> Sent: Monday, August 12, 2013 8:39 PM
>> To: HTTP Working Group
>> Subject: initial stream id from a client
>>
>> 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,
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: initial stream id from a client

Martin Thomson-3
On 13 August 2013 11:08, Alexey Melnikov <[hidden email]> wrote:
> For simplicity and consistency I prefer that the stream #1 is always
> 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?

Reply | Threaded
Open this post in threaded view
|

Re: initial stream id from a client

Jeff Pinner
yes


On Tue, Aug 13, 2013 at 10:24 AM, Martin Thomson <[hidden email]> wrote:
On 13 August 2013 11:08, Alexey Melnikov <[hidden email]> wrote:
> For simplicity and consistency I prefer that the stream #1 is always
> 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?


Reply | Threaded
Open this post in threaded view
|

Re: initial stream id from a client

Jeff Pinner
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 <[hidden email]> wrote:
yes


On Tue, Aug 13, 2013 at 10:24 AM, Martin Thomson <[hidden email]> wrote:
On 13 August 2013 11:08, Alexey Melnikov <[hidden email]> wrote:
> For simplicity and consistency I prefer that the stream #1 is always
> 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?



Reply | Threaded
Open this post in threaded view
|

Re: initial stream id from a client

Michael Sweet-3
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 <[hidden email]> wrote:

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 <[hidden email]> wrote:
yes


On Tue, Aug 13, 2013 at 10:24 AM, Martin Thomson <[hidden email]> wrote:
On 13 August 2013 11:08, Alexey Melnikov <[hidden email]> wrote:
> For simplicity and consistency I prefer that the stream #1 is always
> 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?




_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

Reply | Threaded
Open this post in threaded view
|

Re: initial stream id from a client

Martin Thomson-3
In reply to this post by Jeff Pinner
On 13 August 2013 18:58, Jeff Pinner <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: initial stream id from a client

Jeff Pinner
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 <[hidden email]> wrote:
On 13 August 2013 18:58, Jeff Pinner <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: initial stream id from a client

Michael Sweet-3
+1 for all of this... :)

On Aug 13, 2013, at 2:39 PM, Jeff Pinner <[hidden email]> 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 <[hidden email]> wrote:
On 13 August 2013 18:58, Jeff Pinner <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: initial stream id from a client

Roberto Peon-2
In reply to this post by Jeff Pinner
++


On Tue, Aug 13, 2013 at 11:39 AM, Jeff Pinner <[hidden email]> 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 <[hidden email]> wrote:
On 13 August 2013 18:58, Jeff Pinner <[hidden email]> 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.


Reply | Threaded
Open this post in threaded view
|

Re: initial stream id from a client

Martin Thomson-3
In reply to this post by Jeff Pinner
On 13 August 2013 19:39, Jeff Pinner <[hidden email]> 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).

Reply | Threaded
Open this post in threaded view
|

Re: initial stream id from a client

Roberto Peon-2

Sgtm

On Aug 13, 2013 1:37 PM, "Martin Thomson" <[hidden email]> wrote:
On 13 August 2013 19:39, Jeff Pinner <[hidden email]> 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).

Reply | Threaded
Open this post in threaded view
|

Re: initial stream id from a client

Shigeki Ohtsu
In reply to this post by Martin Thomson-3
Yes, I agree this.
It's already in the half-closed state and no need to define an absolute prohibition.

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