Subject: [hybi] HTTP/2.0 framing and WebSocket multiplexing

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 25 Jul 2012 16:33:44 +0900

Thanks the authors for preparing this slide
http://tools.ietf.org/agenda/84/slides/slides-84-hybi-0.pdf for the next
f2f meeting.

As one of WebSocket multiplexing spec editors, I'd like to present my
thoughts about some of the issues supposing that we evolve WebSocket
multiplexing to resolve them and use it to realize HTTP/2.0 multiplexing.

* Efficiency of header data transfer
- Add SPDY style encoding to AddChannelRequest/Response's Enc type as
defined in
http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00#section-2.6.10 . This
makes WebSocket multiplexing as efficient as SPDY to convey HTTP traffic.

* Multiplexing with normal WebSocket channels
- Add a protocol type property to AddChannelRequest (as a new field or a
new handshake header)

* Masking
- We've defined MASK bit. Maybe we can just relax the restriction of
WebSocket/1.0 when the physical connection is negotiated as one for
HTTP/2.0 (same origin). But the problem is that there would be transparent
"WebSocket" intermediaries that don't allow unmasked frames.

* Server initiated stream
- Adopt odd/even ID separation as Scott suggested
-- e.g. "Sec-WebSocket-Extensions: mux; server-initiated; http20".
"server-initiated" introduces the rule, and "http20" depends on that.
- Use NewChannelSlot and AddChannelRequest/Response in reverse direction

* Flow control
- The difference is small among proposals. John designed one for WebSocket
multiplexing based on SPDY's one and me also now following the discussion
made on spdy-dev as Greg suggested. I'm picking up good points, adjusting
them for our purpose and defining commands/fields. I like the new channel
slot based throttling idea that is not from SPDY.

* Latency
- The latest multiplexing allows for pre-handshake data and simultaneous
issue of AddChannelRequests except for the physical connection setup time.
If NPN is used like SPDY instead of Upgrade, even physical connection may
allow for them since there's no risk of cross protocol attack. So,
WebSocket multiplexing based HTTP/2.0 doesn't add extra RTT compared to
SPDY.

* Priority
- Add a priority property to AddChannelRequest (as a new field or a new
handshake header)

* Encoding of channel/stream numbers
- Personally, I think we can use one encoding for channel ID and size
encoding in multiplex control block

Takeshi

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 25 Jul 2012 09:53:57 +0200

Hi Takeshi,

I have a few comments on your points below.

> "WebSocket" intermediaries that don't allow unmasked frames.

These intermediaries are not an issue right now since the HTTP/2
intermediaries don't exist yet. It will however probably be needed
for HTTP/2 to HTTP/1 gateways to support WS/1 as a client when
receiving a WS handshake over HTTP/2 compatible framing, and to add
masking when sending frames over HTTP/1.

> - Adopt odd/even ID separation as Scott suggested
+1 on this one.

> slot based throttling idea that is not from SPDY.

As you are probably aware of it, FC is something very difficult to get
right, and I from what I understood from past discussions, the SPDY team
is always open to improvement in this area. I think that your experience
combined with theirs should be useful for both protocols, as you're dealing
with very small frames and they're dealing with larger ones, possibly that
there are small differences which need to be compared, and then a common
flow control could be built.

> WebSocket multiplexing based HTTP/2.0 doesn't add extra RTT compared to

Note that NPN won't allow you to mix HTTP/2 and WS frames in the same
connection. I think that it's important to be able to convey both frame
types over the same connection, which probably means that they'll need
to be typed. Maybe instead of odd/even stream IDs we could use them with
(0,1,2,3) mod 4 for (req/resp HTTP, cli/srv WS) ? It saves a type.

Regards,
Willy

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 25 Jul 2012 17:49:05 +0900

Hi Willy,

> masking when sending frames over HTTP/1.

Agreed.

But sorry for lack or words. The concern I intended to show is that there
might be a transparent intermediary that understands only WebSocket/1.0
between HTTP/2.0 hosts, and it might terminate the HTTP/2.0 session without
masking.

> (0,1,2,3) mod 4 for (req/resp HTTP, cli/srv WS) ? It saves a type.

Yes. My idea was that we differentiate HTTP/2.0 and WS
on AddChannelRequest using some type field in it as I suggested in
"Multiplexing
with normal WebSocket channels" in my first mail. It's fine to use IDs as
you said, too.

Did you mean "normal HTTP / server-push HTTP" where you wrote "req/resp
HTTP" above?

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 25 Jul 2012 11:10:03 +0200

> between HTTP/2.0 hosts, and it might terminate the HTTP/2.0 session without

Until HTTP/2 is defined, we cannot have such intermediaries intercept HTTP/2
and extract WS information from there, because they simply won't know what
HTTP/2 is nor how to decode that stream. So in fact that's why we need to
define a correct framing for both, once and for all, before engaging in
work on intermediaries (let's void the mess we experienced here with pre-75
and post-75 framings).

> with normal WebSocket channels" in my first mail. It's fine to use IDs as

OK.

> Did you mean "normal HTTP / server-push HTTP" where you wrote "req/resp

Yes, sorry for the confusing name, you're right. I've been used for ages
to the req/resp model so it's hard to get it out of my head, and even when
I do so, my fingers are still trained to type this :-)

Best regards,
Willy

---

From: "Arman Djusupov" <[email-masked]>
Date: Wed, 25 Jul 2012 12:33:18 +0300

If HTTP/2 is a subprotocol of WS then why not use the WebSocket-Protocol
header field that is already there exactly for such cases?

With best regards,

Arman

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Takeshi Yoshino
Sent: Wednesday, July 25, 2012 11:49 AM
To: Willy Tarreau
Cc: [email-masked]
Subject: Re: [hybi] HTTP/2.0 framing and WebSocket multiplexing

Yes. My idea was that we differentiate HTTP/2.0 and WS on AddChannelRequest
using some type field in it as I suggested in "Multiplexing with normal
WebSocket channels" in my first mail. It's fine to use IDs as you said, too.

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 25 Jul 2012 18:48:29 +0900

Subprotocol is under control of scripts on browsers. It allows scripts to
send an arbitrary HTTP request. There might be some security risk.

It's ok if subprotocol is also exchanged, but for this case, help by
extension mechanism is necessary by which server can confirm that the
requests are controlled not by any script but by the user-agent.

On Wed, Jul 25, 2012 at 6:33 PM, Arman Djusupov <[email-masked]> wrote:

> header field that is already there exactly for such cases?****
>
> ** **
>
> With best regards,****
>
> Arman****
>
> ** **
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Takeshi Yoshino
> *Sent:* Wednesday, July 25, 2012 11:49 AM
> *To:* Willy Tarreau
> *Cc:* [email-masked]
> *Subject:* Re: [hybi] HTTP/2.0 framing and WebSocket multiplexing****
>
> ** **
>
> on AddChannelRequest using some type field in it as I suggested in "Multiplexing

---

From: "Arman Djusupov" <[email-masked]>
Date: Wed, 25 Jul 2012 13:04:29 +0300

Since HTTP/2 needs mux and flow control it appears to be reasonable to use
the WS mux and frame format for HTTP/2, so that HTTP/2 becomes a subprotocol
of WS. In this case the HTTP/2 frame can be stripped of unnecessary fields
such as the length and channelID. In this scenario NPN becomes unnecessary. 

Producing an additional mux protocol on top of HTTP/2 or SPDY doesn't seem
ideal. IMHO either SPDY/HTTP/2 should use WS frames and mux, or WS should be
muxed over SPDY and HTTP/2.

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Takeshi Yoshino
Sent: Wednesday, July 25, 2012 10:34 AM
To: [email-masked]
Subject: [hybi] HTTP/2.0 framing and WebSocket multiplexing

- Add SPDY style encoding to AddChannelRequest/Response's Enc type as
defined in
http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00#section-2.6.10 .
This makes WebSocket multiplexing as efficient as SPDY to convey HTTP
traffic.

If you mean compressing the  headers using zlib initialized with a
predefined dictionary then this would make sense, but we already have
integrated per-message compression for WS so this option should be enabled
only if WS compression is not used.

This is the right thing to do.

* Latency

- The latest multiplexing allows for pre-handshake data and simultaneous
issue of AddChannelRequests except for the physical connection setup time.
If NPN is used like SPDY instead of Upgrade, even physical connection may
allow for them since there's no risk of cross protocol attack. So, WebSocket
multiplexing based HTTP/2.0 doesn't add extra RTT compared to SPDY.

Agree, if NPN is used, both masking and this restriction can be lifted.

* Priority

Possible, but I'm skeptical that implementation would really observe these
fields. I don't think any prioritizing is currently being widely used by
HTTP servers.

Takeshi

With best regards,

Arman

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 25 Jul 2012 12:50:01 +0200

On Wed, Jul 25, 2012 at 01:04:29PM +0300, Arman Djusupov wrote:
> of WS.

This does not seam reasonable to me. It's hard for me to explain why
but it seems a bit reversed. In my opinion we should have a common
framing layer offering MUX and bidir-communications on top of which we
have HTTP for object retrieval and WS for short interactive exchanges
(could be seen as less typed data without headers and without buffering).

So you'd have :

         ---------+--------
          HTTP/2  |  WS/2
         ---------+--------
               framing
         ------------------
              transport
         ------------------

Regards,
Willy

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 25 Jul 2012 20:30:52 +0900

On Wed, Jul 25, 2012 at 7:04 PM, Arman Djusupov <[email-masked]> wrote:

> *Sent:* Wednesday, July 25, 2012 10:34 AM
> *To:* [email-masked]
> *Subject:* [hybi] HTTP/2.0 framing and WebSocket multiplexing****
>
> ** **
>
> * Efficiency of header data transfer****
>
> makes WebSocket multiplexing as efficient as SPDY to convey HTTP traffic.*
> ***
>
> ** **
>

Yes if that combination is efficient enough.

---

From: "Arman Djusupov" <[email-masked]>
Date: Wed, 25 Jul 2012 14:55:37 +0300

Alternatively browsers could prohibit scripts from using some values in the
sub-protocol header, for example the value "http/2", so that the existing
protocol negotiation mechanism can be reused.

Browsers anyway need to check the values provided by scripts, otherwise
scripts can still inject a header into the WS handshake.

With best regards,

Arman

From: Takeshi Yoshino [mailto:[email-masked]] 
Sent: Wednesday, July 25, 2012 12:48 PM
To: Arman Djusupov
Cc: Willy Tarreau; [email-masked]
Subject: Re: [hybi] HTTP/2.0 framing and WebSocket multiplexing

With best regards,

Arman

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 25 Jul 2012 21:14:05 +0900

> (could be seen as less typed data without headers and without buffering).

Forgetting what their original target applications are,

SPDY is a versatile multiplexing protocol with flow control
- for X key-value pairs + 1 (possibly endless) binary string
- simple encoding/field, int32 aligned
- more overhead

WebSocket multiplexing is one
- for X key-value pairs + Y (possibly unlimited number of) (possibly
endless) binary strings
- complicated encoding/field, not int32 aligned
- less overhead

I think this is what they are in the context of HTTP/2.0 framing discussion.

SPDY lacks message semantics necessary to lay WS semantics. But Takashi has
been trying to do it by using SPDY's HEADERS as message boundary signal. It
works. (See spdy-dev for detail)

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 25 Jul 2012 14:52:23 +0200

> I think this is what they are in the context of HTTP/2.0 framing discussion.

100% agree. What I meant was that SPDY is not *only* the framing and WS is
not *only* the fraiming either. Both share that huge part, but there are
semantics on top of this framing for application level usage, which is why
I've been saying for some time that we should make it clear that there is
a framing and a framed protocol. One is just about transporting frames, and
other ones are used to transfer information with semantics.

> works. (See spdy-dev for detail)

Probably that's the point where the split between framing and application
layer use would make sense.

In short, we would define what a frame should look like, how to open new
channels, how to mux channels, how to apply flow control. This is the framing
layer. Then on top of that we would describe how HTTP/2 and WS are transported.

Regards,
Willy

---

From: "Arman Djusupov" <[email-masked]>
Date: Wed, 25 Jul 2012 16:16:35 +0300

I don't see any practical reasons why not to reuse WS for HTTP/2. WS already
looks simply as a subset of HTTP/2, offering only "Mux and
bidir-communication" to which HTTP/2 has to add whatever extra is required.

The difference between a WS message and an HTTP message is only the presence
of the HTTP header, otherwise WS has everything needed to move HTTP requests
and responses in any direction. If WS/2 and HTTP/2 would be sharing the same
framing layer as mentioned by Willy Tarreau, then this common framing layer
will practically be the whole WS/2 because there is nothing extra WS/2 can
offer.

So during the handshake, instead of either WS/2 or HTTP/2, it would be more
like "raw WS/2 or WS/2 + HTTP/2".

With best regards,

Arman

From: Takeshi Yoshino [mailto:[email-masked]] 
Sent: Wednesday, July 25, 2012 3:14 PM
To: Willy Tarreau
Cc: Arman Djusupov; [email-masked]
Subject: Re: [hybi] HTTP/2.0 framing and WebSocket multiplexing

- more overhead

- less overhead

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 25 Jul 2012 15:42:12 +0200

Hi Arman,

> bidir-communication" to which HTTP/2 has to add whatever extra is required.

And minor variations such as no latency for WS messages as opposed to possible
buffering for HTTP, and possibly a different use meaning that the motivation to
analyse either of them differs (eg: an HTTP intermediary would not necessarily
be interested in processing short WS frames one at a time, and might probably
prefer to forward each byte it receives to the other side).

> will practically be the whole WS/2 because there is nothing extra WS/2 can

It's possible, but as you can see, the fact that there are discussions about
how to transport any on top of the other means that there is a huge common
part at the bottom layer.

> like "raw WS/2 or WS/2 + HTTP/2".

For the concept of using an entity called "WebSocket" as a generic socket for
web usage, I'm 100% for this. However, if we ever want to improve WS to become
WS/3 with richer services, we'll need to keep the bottom framing layer for
WS/* and HTTP/2. At this point it becomes clearer that we need a common layer
(which might or might not be the WS framing).

Also as was already said, WS can be manipulated by the application layer and
was made for this. So we want the application not to be able to manipulate
the lower layer and still manipulate the upper layer. That's another reason
to clearly define where the split is needed.

Regards,
Willy

---

From: "Arman Djusupov" <[email-masked]>
Date: Wed, 25 Jul 2012 17:52:09 +0300

Yes, an application can manipulate the WS connection and create its own sub
protocols. The protocol header in the WS handshake was introduced exactly to
identify the sub-protocol used by an application. But let's not forget that
a browser is also an application. A browser may have its own logical
channels isolated from the WS-API and may use these channels for any
purpose. Preventing a scripted application from using sub-protocols it's not
entitled to use is a matter of browser policy.

The WS handshake has sufficient negotiation features (sub-protocol and
extensions) so that the spec does not have to change when a new sub-protocol
or new extensions are created. But if you are suggesting to disassociate WS
as framing and mux protocol from the browsers and JS apps into a separate
and independent "common framing layer", that could be a good idea. But this
will require a new specification... which will practically obsolete the old
one.

With best regards,
Arman

-----Original Message-----
From: Willy Tarreau [mailto:[email-masked]] 
Sent: Wednesday, July 25, 2012 4:42 PM
To: Arman Djusupov
Cc: 'Takeshi Yoshino'; [email-masked]
Subject: Re: [hybi] HTTP/2.0 framing and WebSocket multiplexing

Hi Arman,

On Wed, Jul 25, 2012 at 04:16:35PM +0300, Arman Djusupov wrote:
> I don't see any practical reasons why not to reuse WS for HTTP/2. WS 
> already looks simply as a subset of HTTP/2, offering only "Mux and 

And minor variations such as no latency for WS messages as opposed to
possible buffering for HTTP, and possibly a different use meaning that the
motivation to analyse either of them differs (eg: an HTTP intermediary would
not necessarily be interested in processing short WS frames one at a time,
and might probably prefer to forward each byte it receives to the other
side).

> The difference between a WS message and an HTTP message is only the 
> presence of the HTTP header, otherwise WS has everything needed to 
> move HTTP requests and responses in any direction. If WS/2 and HTTP/2 
> would be sharing the same framing layer as mentioned by Willy Tarreau, 
> then this common framing layer will practically be the whole WS/2 
> because there is nothing extra WS/2 can offer.

> So during the handshake, instead of either WS/2 or HTTP/2, it would be 
> more like "raw WS/2 or WS/2 + HTTP/2".

For the concept of using an entity called "WebSocket" as a generic socket
for web usage, I'm 100% for this. However, if we ever want to improve WS to
become
WS/3 with richer services, we'll need to keep the bottom framing layer for
WS/* and HTTP/2. At this point it becomes clearer that we need a common
layer (which might or might not be the WS framing).

Regards,
Willy

---

From: Roberto Peon <[email-masked]>
Date: Wed, 25 Jul 2012 10:24:29 -0700

Note that the per-message compression is significantly suboptimal for
message routers.
Many message routers will wish to examine the contents of the message and
forward appropriately, especially on the outgoing side of an aggregating
proxy. Separate meta-data and content is far preferable when it can be
delimited this way.

Our current WS design considers basically none of the scalability needs of
intermediaries or servers.
That is improving, and improving it is essential, but the extensions will
continue be kludges.

-=R

On Wed, Jul 25, 2012 at 4:30 AM, Takeshi Yoshino <[email-masked]>wrote:

>> ****
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>
>

---

From: Bruce Atherton <[email-masked]>
Date: Wed, 25 Jul 2012 19:52:51 -0700

On 7/25/2012 12:33 AM, Takeshi Yoshino wrote:
> http://tools.ietf.org/agenda/84/slides/slides-84-hybi-0.pdf for the 
> next f2f meeting.

I read through the slides and I don't really understand the objections 
to using the Websockets framing for both, although I agree with Willy 
that the framing should be a separate layer that both Websockets and 
HTTP2.0 run on top of. The initial handshake to upgrade the connection 
should be changed to reflect that, although I have no suggestions what 
this framing/mux layer should be called. But once the upgrade is done, 
there is no need for an upgrade header or connection header in the 
channel handshake for either WS or HTTP2.0. Non-muxed WS could continue 
to use the WS 1.0 spec.

There were two main objections I saw to using WS framing:

1. Masking. I don't see why HTTP2.0 couldn't just turn off the masking 
bit. Websocket Message frames from the client sent over the shared 
framing layer would have the bit set but HTTP2.0 Request frames wouldn't.

2. Variable Length Encodings. Not quite sure what this refers to. Is it 
the extended payload length field? I can't see why it would be a problem 
for HTTP2.0 to support this.

I guess part of the issue is that the slides are complecting framing 
with mux, whereas WS has separated the two discussions out. Adopting WS 
framing does not imply adopting the WS mux proposal to my mind. 
Certainly we should make sure that both HTTP2.0 and WS have the same 
MUXing implementation as much as is sensible, but is there a good reason 
not to reuse the base framing?

One final point. This notion of dividing up a space based on modulo n 
ids is a pattern I find troubling. It automatically assumes there will 
only ever be n categories, but as this discussion has shown with n going 
from 2 to 4, that is a big assumption that often bites you down the 
road. Better to have a field that identifies the channel type, with some 
reserved bits available so that an extension of types can be designed in 
later if need be. Although this looks superficially the same (the lowest 
bits of the ID are defining the channel type) the fact that you use the 
bits for both the ID and the type means you are overloading the bits and 
can't easily alter anything later.

---

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 26 Jul 2012 13:51:35 +0900

> proxy. Separate meta-data and content is far preferable when it can be

Thanks for reminding this, Roberto. Yes, we discussed LB friendliness and
secured the option to compress each logical channel (i.e.
Sec-WebSocket-Extensions: compress, mux). In this case, per-message
compression doesn't cover mux commands (multiplex control blocks). So,
introducing SPDY's header format to AddChannelRequest is still important.

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 26 Jul 2012 09:24:03 +0200

> will require a new specification... which will practically obsolete the old

I agree, and that's why we were saying WS/2 :-)

There is a real opportunity for HTTP and WS to converge and work together,
if it happens once in 10 years it would be better not to miss this train.
WS wasted one year trying to find how to use HTTP precisely because the
transport layer of HTTP was not clearly split/implemented and was not 100%
safe to use. By building a common transport layer and application layers
on top of it, we have greater chances of getting things right with a clean
and safe design.

Regards,
Willy

---

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 26 Jul 2012 17:08:33 +0900

> entitled to use is a matter of browser policy.

Then, we need to introduce such a blacklist to all browsers before starting
HTTP/2.0 servers. I don't want to do that.

My claim is only that we can't use "Sec-WebSocket-Protocol" for this
purpose. I don't think your idea of layering HTTP as "subprotocol" over
WebSocket message semantics nonsense. It's still one of the candidates.

> will require a new specification... which will practically obsolete the old

My approach is trying to find the way to make WebSocket multiplexing good
enough taking care of HTTP traffic without making big change (just relaxing
masking rule) on WebSocket core protocol.

With the changes in my first mail and some more, I believe, WebSocket +
WebSocket multiplexing will deserve to be called "HTTP/2.0 framing".

---

From: Philipp Serafin <[email-masked]>
Date: Thu, 26 Jul 2012 10:46:17 +0200

I'd like to agree that a protocol blacklist would be a bad idea. In
addition the reasons stated, some browsers (e.g. Google Chrome) already
have WebSocket support enabled for the public web, after all.
Introducing such a blacklist now might cause security risks for users of
legacy browsers. (e.g. corporate environments or users who have disabled
auto-updating)

But since there might be more cases in the future where browsers might
want to exchange sensitive data via a websocket-based protocol, maybe it
would be useful to introduce some general kind of way to make certain
subprotocols unusable for scripting?

As the Sec-WebSocket-Extensions can't be manipulated by scripts, how
about introducing an additional "pseudo extension". During negiotation,
the extension string would contain the names of all "protected" sub
protocols as a parameter. Then, a websocket connection using a
particular "protected" sub protocol could only be opened if the client
announced the protocol both in the Sec-WebSocket-Protocol *and* in the
Sec-WebSocket-Extensions field via the pseudo extension. A malicious
script could not initiate such a connection since it could not set the
pseudo extension.

Example: If http/2.0 were a "protected" sub protocol, a valid opening
handshake would start like this:

GET / HTTP/1.1
Upgrade: websocket
Connection: Upgrade
( ... host, origin, ws-key, ws-version, etc ...)
Sec-WebSocket-Protocol: http2
Sec-WebSocket-Extensions:  protected-protocols;names=http2,  (other
extensions...)

Would such a thing be useful?

Regards,
Philipp Serafin

Am 26.07.2012 10:08, schrieb Takeshi Yoshino:
> On Wed, Jul 25, 2012 at 11:52 PM, Arman Djusupov <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> Then, we need to introduce such a blacklist to all browsers before
> starting HTTP/2.0 servers. I don't want to do that.
>
> purpose. I don't think your idea of layering HTTP as "subprotocol"
> over WebSocket message semantics nonsense. It's still one of the
> candidates.

---

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 26 Jul 2012 20:01:42 +0900

On Thu, Jul 26, 2012 at 11:52 AM, Bruce Atherton <[email-masked]>wrote:
snip

> But once the upgrade is done, there is no need for an upgrade header or
> connection header in the channel handshake for either WS or HTTP2.0.
> Non-muxed WS could continue to use the WS 1.0 spec.
>

I'll clean up on AddChannelRequest spec. Upgrade, Sec-WebSocket-Key, etc.
should be excluded from delta base.

> One final point. This notion of dividing up a space based on modulo n ids
> is a pattern I find troubling. It automatically assumes there will only
> ever be n categories, but as this discussion has shown with n going from 2
> to 4, that is a big assumption that often bites you down the road.

Good point.

> Better to have a field that identifies the channel type, with some

Separating the stream identifier space into two for each direction is
necessary since each end may initiate stream asynchronously. I don't come
up with any other attribute with a risk of collision.

By adding some string field, say "channel type", to the AddChannelRequest
command, each end can give some meaning like "http", "ws" to the new
channel, and then just use its ID for tagging. The other end knows what to
do with the channel.

I feel that reserving ID number space is over killing.

---

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 26 Jul 2012 20:51:42 +0900

On Thu, Jul 26, 2012 at 5:46 PM, Philipp Serafin <[email-masked]> wrote:
snip

> about introducing an additional "pseudo extension". During negiotation, the
> extension string would contain the names of all "protected" sub protocols
> as a parameter.
>

Maybe, you suggested this because it's worthwhile to have such a common
pseudo extension defined so that
- we can announce that it's NOP, so intermediaries don't have to worry
about it.
- we don't have to define extensions for each of such subprotocols.

Good idea, I think.

> Then, a websocket connection using a particular "protected" sub protocol
> could only be opened if the client announced the protocol both in the
> Sec-WebSocket-Protocol *and* in the Sec-WebSocket-Extensions field via the
> pseudo extension.
>

Is this matching necessary?

---

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 26 Jul 2012 21:03:54 +0900

It's ad-hoc, but we can also use presence of the Origin header. If the
application doesn't need it, clients can authenticate themselves as
non-browser by not sending it.

---

From: "Philipp Serafin" <[email-masked]>
Date: Fri, 27 Jul 2012 11:43:43 +0200

Well, this might theoretically allow clients to offer both protected and
non-protected protocols during negiotation. I realize though that  this
use-case is mostly already covered by extensions. So, on second thought,
it's probably not necessary.

This would work, too - however, wouldn't that make it harder to extend the
Origin security model to protocols like HTTP2? These protocols would then
have to define their own equivalent to the Origin header.

---

From: Takeshi Yoshino <[email-masked]>
Date: Fri, 27 Jul 2012 22:41:56 +0900

On Fri, Jul 27, 2012 at 6:43 PM, Philipp Serafin <[email-masked]> wrote:

> This would work, too – however, wouldn’t that make it harder to extend the
> have to define their own equivalent to the Origin header. ****
>

I assumed that in the idea that we realize HTTP/2.0 as a WebSocket
subprotocol as Arman suggested, the HTTP laid over WebSocket exchanges full
HTTP request data over WebSocket messages.

The Origin header of WebSocket (X) tells the origin of the application (Y)
right on top of X. I think Y should have its own header to provide security
model for the next application (Z) on top of Y as you say.

Y = HTTP as WebSocket subprotocol
Z = XHR request for example

Y's origin is the UA in this case. It's proven to the server by not sending
Origin of X. This is my suggestion above.

Y send its own Origin header for Z.

---

From: Bruce Atherton <[email-masked]>
Date: Tue, 31 Jul 2012 06:51:36 -0700

On 7/26/2012 4:01 AM, Takeshi Yoshino wrote:
> necessary since each end may initiate stream asynchronously. I don't 
> come up with any other attribute with a risk of collision.
>

Not with the two protocols currently proposed, but what of the future? 
Will other protocols be carried on this common framing layer? If a peer 
to peer protocol is added then the number of endpoints that could 
initiate the stream is unlimited.

Why can there not be a separate field to identify the endpoint that 
initiated the connection?

> I feel that reserving ID number space is over killing.

I'm not sure what you mean by "over killing". Are you agreeing that all 
the bits in the ID space should serve the single purpose of defining the 
ID, and not be overloaded to mean other things as well?