status of websockets drafts

Just notices:

<http://krijnhoetmer.nl/irc-logs/whatwg/201005...>
> # # [09:04] <micheil> Hixie: is draft76 going to become draft76 on the ieft site?
> # # [09:06] * Quits: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net) (Quit: othermaciej)
> # # [09:08] * Joins: mpt (~mpt@canonical/mpt)
> # # [09:13] <Hixie> micheil: the ietf asked me to stop sending them updates because they couldn't cope with the volume of updates, so no idea
> # # [09:13] <Hixie> as far as i'm concerned, -75 is long dead
> # # [09:13] <micheil> oh, righteo
> # # [09:13] <Hixie> if i'd still been sending updates, -76 would actually be like -90 or so by now
> # # [09:13] <micheil> yeah, -75 is still the one supported by chrome (and other clients), so it's the one I must have work
After all, there might be a compromise between "too many" and "too little".

Best regards, Julian

Julian Reschke wrote:
> Just notices:
> 
> <http://krijnhoetmer.nl/irc-logs/whatwg/201005...>
> 
>> # # [09:04] <micheil> Hixie: is draft76 going to become draft76 on the
>> ieft site?
>> # # [09:06] * Quits: othermaciej
>> (~mjs@c-69-181-42-237.hsd1.ca.comcast.net) (Quit: othermaciej)
>> # # [09:08] * Joins: mpt (~mpt@canonical/mpt)
>> # # [09:13] <Hixie> micheil: the ietf asked me to stop sending them
>> updates because they couldn't cope with the volume of updates, so no idea
>> # # [09:13] <Hixie> as far as i'm concerned, -75 is long dead
>> # # [09:13] <micheil> oh, righteo
>> # # [09:13] <Hixie> if i'd still been sending updates, -76 would
>> actually be like -90 or so by now
>> # # [09:13] <micheil> yeah, -75 is still the one supported by chrome
>> (and other clients), so it's the one I must have work
> 
> After all, there might be a compromise between "too many" and "too little".
At the WG meeting it was the consensus that there is value
in starting with a document that at least roughly matches the many
implementations already shipping.   -75 is approximately that.

-76 has some good changes in it, but it also has some breaking
changes to the handshake that I believe go a lot further than
was generally agreed.   They are also against the widely supported
requirement that the protocol be compliant HTTP prior to the return
of the 101 upgrade response.

So I think it important that any bulk changes to the draft
are comprised of changes that have rough consensus.   Changes
that are not agreed should not be bundled with a batch of changes
that are.

regards

On Mon, 03 May 2010 16:01:48 +0200, Greg Wilkins <gre...@webtide.com> wrote:

> Julian Reschke wrote:
>> Just notices:
>>
>> <http://krijnhoetmer.nl/irc-logs/whatwg/201005...>
>>
>>> # # [09:04] <micheil> Hixie: is draft76 going to become draft76 on the
>>> ieft site?
>>> # # [09:06] * Quits: othermaciej
>>> (~mjs@c-69-181-42-237.hsd1.ca.comcast.net) (Quit: othermaciej)
>>> # # [09:08] * Joins: mpt (~mpt@canonical/mpt)
>>> # # [09:13] <Hixie> micheil: the ietf asked me to stop sending them
>>> updates because they couldn't cope with the volume of updates, so no  
>>> idea
>>> # # [09:13] <Hixie> as far as i'm concerned, -75 is long dead
>>> # # [09:13] <micheil> oh, righteo
>>> # # [09:13] <Hixie> if i'd still been sending updates, -76 would
>>> actually be like -90 or so by now
>>> # # [09:13] <micheil> yeah, -75 is still the one supported by chrome
>>> (and other clients), so it's the one I must have work
>>
>> After all, there might be a compromise between "too many" and "too  
>> little".
>
> At the WG meeting it was the consensus that there is value
> in starting with a document that at least roughly matches the many
> implementations already shipping.   -75 is approximately that.
>
> -76 has some good changes in it, but it also has some breaking
> changes to the handshake that I believe go a lot further than
> was generally agreed.   They are also against the widely supported
> requirement that the protocol be compliant HTTP prior to the return
> of the 101 upgrade response.
>
> So I think it important that any bulk changes to the draft
> are comprised of changes that have rough consensus.   Changes
> that are not agreed should not be bundled with a batch of changes
> that are.
Hi, this is my first email to this list. I just wanted to give a heads-up  
that we're implementing the latest draft at  
http://www.whatwg.org/specs/web-apps/current-... --  
not -75.

I've also sent some feedback on websockets to the whatwg list, some of  
which the editor has already addressed:

http://lists.whatwg.org/mmsearch.cgi/whatwg-w...

Cheers,
-- 
Simon Pieters
Opera Software

On May 3, 2010, at 1:31 PM, Simon Pieters wrote:

>
> Hi, this is my first email to this list. I just wanted to give a  
> heads-up that we're implementing the latest draft at http://www.whatwg.org/specs/web-apps/current-... 
>  -- not -75.
WebKit's implementation is in the process of being updated to the  
latest protocol draft. I believe this is the only browser-hosted  
implementation to have shipped so far (in Chrome). I don't think there  
is any interest in keeping it -75 compatible instead of continuing to  
update it to the latest. As far as I know, all browser-hosted client  
implementations are targeting the latest version, not -75, even Chrome  
which has already shipped -75 support.

Therefore I doubt Greg's argument that -75 is a better starting point  
because of existing implementations.

I also think -76 and its successors move in the right direction on  
http-compatibility of the handshake, to make it more practical to  
implement WebSocket servers hosted inside an http server. While not  
everything in it has full consensus, I don't see how reversing the  
progress so far would be helpful.

Regards,
Maciej

Maciej Stachowiak wrote:
> 
> On May 3, 2010, at 1:31 PM, Simon Pieters wrote:
> 
>>
>> Hi, this is my first email to this list. I just wanted to give a
>> heads-up that we're implementing the latest draft at
>> http://www.whatwg.org/specs/web-apps/current-...
>> -- not -75.
> 
> WebKit's implementation is in the process of being updated to the latest
> protocol draft. I believe this is the only browser-hosted implementation
> to have shipped so far (in Chrome). I don't think there is any interest
> in keeping it -75 compatible instead of continuing to update it to the
> latest. As far as I know, all browser-hosted client implementations are
> targeting the latest version, not -75, even Chrome which has already
> shipped -75 support.
> 
> Therefore I doubt Greg's argument that -75 is a better starting point
> because of existing implementations.
That is an entirely browser-centric view of existing implementations.

There are also 16 server implementations (according to wikipeadia).
Unfortunately the whatwg do not appear to consider server
implementations to be important, since when I brought this up
on the #whatwg IRC I was told:
  + server implementations are simple, so they are simple to change
  + servers are no good without clients, so you have to follow
    the client implementations.


I assume that there are also intermediary developers who are
looking at websockets as it is implemented in current clients
and servers.


The problem with -76 is not that it does not contain some good
improvements.  It is that it is the product of a process that
is exceedingly difficult for implementations to follow.  Basically
Ian put's into the draft his ideas, then we debate them, then
if we manage to convince him of changes, those go into the draft,
but along with other new speculative ideas from Ian.

That is an impossible process for implementations to follow, as
you don't know if something in the document is just an idea or
something for which there is consensus.   Even the existence
of -76 is hard to follow - it looks like a version of an IETF
draft, but it has not been submitted.  So it is only a
proposed-76 and has no status at the IETF.


The idea of starting the IETF process with 75 is that we can
first debate the changes and only once rough consensus is
achieved do they go into the draft.   Implementations can then
follow the drafts with knowledge that they are more likely not to
have to change again.

I'm not arguing against change, I'm arguing for a process to
manage change.
> I also think -76 and its successors move in the right direction on
> http-compatibility of the handshake, to make it more practical to
> implement WebSocket servers hosted inside an http server. While not
> everything in it has full consensus, I don't see how reversing the
> progress so far would be helpful.
It is the responsibility of an IETF editor to only put into a draft
text that has rough consensus.   76 will only exist once it is
submitted to the IETF, and to do so, the editor must obtain
a rough consensus for the changes.

There are some good changes in the proposed-76, but there are also
changes that are against the HTTP compliance requirements that do
have some consensus:

   + Sending random bytes after the upgrade request, but before
   a 101 has been received, will prevent a HTTP server using the
   HTTP connection should the upgrade not be accepted.  This will
   mean an extra RTT when websockets is not supported.  It also
   rules out any usage of HTTP authentication, redirection etc.

   + while the ordering of headers has been made arbitrary, there
   is not a restriction on the headers that can be sent in a
   handshake.

The changes in the proposed-76 do not need to be reversed.  They
need to be discussed and accepted into an IETF draft.

For example, I was discussing with hixie, the possibility of
only having random bytes sent after the response (and not
after the request).   This should keep the connection
HTTP compliant before the upgrade, will not involve an
extra RTT and will possibly have the fail fast semantics that
Hixie wants to achieve by sending non HTTP messages.

So by discussing/refining the ideas prior to the draft
being updated, we might be able to achieve some consensus
prior to many many man hours being consumed implementing
non consensus ideas.


regards

Hi Greg,

I do agree with your technical concerns.
On 04.05.2010 18:00, Greg Wilkins wrote:
> ...
> It is the responsibility of an IETF editor to only put into a draft
> text that has rough consensus.   76 will only exist once it is
> submitted to the IETF, and to do so, the editor must obtain
> a rough consensus for the changes.
> ...
Process-wise:

1) draft-hixie-websocket is a private submission, Ian can put into this 
draft whatever he wants. It's not a Working Group deliverable. Nor will 
a draft-hixie-websocket-76 be one.

2) According to the charter (<http://tools.ietf.org/wg/hybi/charters>)...:

   Apr 2010 - Submit a document as a working group item describing the 
Web Socket requirements (draft-hixie-thewebsocketprotocol will be used 
as a starting point for further work.)
   Apr 2010 - Submit 'The Web Socket protocol' as working group item 
(draft-hixie-thewebsocketprotocol will be used as a starting point for 
further work.)

...the WG will produce a requirements document, plus a protocol document 
*based* on draft-hixie-websocket. I think the WG is free to choose a 
specific version of that draft; it really doesn't matter a lot whether 
there were subsequent changes.

Also, unless I missed something, we don't even know yet who the editors 
for these two documents will be, right?

Best regards, Julian

Just to confirm from the Google perspective, we do not yet believe that Web
Sockets are at the point where breaking changes are yet a problem, as such
we are attempting to track the latest draft. That is, no significant
percentage of our users are actually using Web Sockets to connect to a Web
Sockets server via our browser, so we are working on making our client (and
server-side) implementations match the latest spec so that we do not get
locked in.

FWIW we will probably continue this path for the foreseeable future.
Am 3. Mai 2010 18:59 schrieb Maciej Stachowiak <m...@apple.com>:

>
> On May 3, 2010, at 1:31 PM, Simon Pieters wrote:
>
>
> Hi, this is my first email to this list. I just wanted to give a heads-up
> that we're implementing the latest draft at
> http://www.whatwg.org/specs/web-apps/current-... --
> not -75.
>
>
> WebKit's implementation is in the process of being updated to the latest
> protocol draft. I believe this is the only browser-hosted implementation to
> have shipped so far (in Chrome). I don't think there is any interest in
> keeping it -75 compatible instead of continuing to update it to the latest.
> As far as I know, all browser-hosted client implementations are targeting
> the latest version, not -75, even Chrome which has already shipped -75
> support.
>
> Therefore I doubt Greg's argument that -75 is a better starting point
> because of existing implementations.
>
> I also think -76 and its successors move in the right direction on
> http-compatibility of the handshake, to make it more practical to implement
> WebSocket servers hosted inside an http server. While not everything in it
> has full consensus, I don't see how reversing the progress so far would be
> helpful.
>
> Regards,
> Maciej
>
>
> _______________________________________________
> hybi mailing list
> <h...@ietf.org>
> https://www.ietf.org/mailman/listinfo/hybi
>
>

Ian Fette (イアンフェッティ) wrote:
> Just to confirm from the Google perspective, we do not yet believe that
> Web Sockets are at the point where breaking changes are yet a problem,
> as such we are attempting to track the latest draft. That is, no
> significant percentage of our users are actually using Web Sockets to
> connect to a Web Sockets server via our browser, so we are working on
> making our client (and server-side) implementations match the latest
> spec so that we do not get locked in.
> 
> FWIW we will probably continue this path for the foreseeable future.
Ian,

I'm not arguing against breaking changes and I agree that
implementations should track the latest draft of the document.

Because of that, we need to discuss changes and reach rough
consensus on them before they are put into the draft, rather
than after.


regards

On 03.05.2010 16:01, Greg Wilkins wrote:
> At the WG meeting it was the consensus that there is value
> in starting with a document that at least roughly matches the many
> implementations already shipping.   -75 is approximately that.
>
> -76 has some good changes in it, but it also has some breaking
> changes to the handshake that I believe go a lot further than
> was generally agreed.   They are also against the widely supported
> requirement that the protocol be compliant HTTP prior to the return
> of the 101 upgrade response.
I notice that there was a long discussion about this on the WhatWG IRC 
channel (<http://krijnhoetmer.nl/irc-logs/whatwg/201005...>). I 
think it would be great if somebody could summarize over here.
> So I think it important that any bulk changes to the draft
> are comprised of changes that have rough consensus.   Changes
> that are not agreed should not be bundled with a batch of changes
> that are.
I'd agree with that if this was a Working Group draft, but we're only 
talking about Ian's personal draft, right?

Best regards, Julian

Julian Reschke wrote:
> I notice that there was a long discussion about this on the WhatWG IRC
> channel (<http://krijnhoetmer.nl/irc-logs/whatwg/201005...>). I
> think it would be great if somebody could summarize over here.
I raised the issue in the #whatwg chat room that there are some
concerns about the HTTP compliance of the random bytes sent after
the handshake request and responses.

A long discussion followed, covering a lot of the same old ground...
but there were a couple of good bits of info to come of of it.

Firstly, the random bytes are positioned after the HTTP messages
not because of the security issues previously discussed, but to
try to fail fast when there are bad intermediaries in the path.
Hixie noted that in their experimentation, that there are many
failures where an upgrade was sent OK, but the first packet
afterwards failed to pass through an intermediary.

So while the random bytes do form part of the security algorithm,
their placement is for another purpose. I assume it would be
possible to have the random bytes entirely within the
HTTP request/response if some other method was found to detect
the fail fast criteria the Hixie described.

I made a proposal that a ping message be sent on the websocket
connection as soon as it was established, and the absence
of that message could be used in place of the random bytes.

Hixie pointed out that if the ping message was sent by the
client to the server, that would be an extra round trip.
So I suggest that the ping (or random bytes) be sent
only from the server to the client after the 101 response
(potentially in same packet) and the client would need
to see it before deciding the connection was open.

This would give fast (well as fast as a TCP timeout,
which can be long) failure.


There was also a lot of discussion about what constitutes
a legal HTTP request and if the random bytes are valid
body or not.   I maintain that section 4.4 of RFC2616
applies that that a request body needs to have either
a content-length, be chunked or a self limiting content-type.
Hixie believes that 4.4 is only a server side requirement
and thus the random bytes sent after the request do
not violate HTTP.

There was also a lot of discussion about why do I
want HTTP compliance.  I tried to make the point that
before the upgrade is accepted, the connection is
a HTTP connection and if client and server wish to
use it as such they should be able to.   So the
server should be able to send 401, 500, 302 responses
and the client can implement support for them
if they want to (most are browsers, so it should not
be hard).    I also expressed the desire to be able
to put the upgrade header onto a normal HTTP GET
that if the upgrade is not accepted, is able to
return useful content in a 200 response.   This
would allow clients to try to use websocket, but
to continue with another mechanism without an
extra RTT because the websocket upgrade failed.
I maintained that even if there was no immediate
use of such HTTP compliance, it is good to
allow it for future usage and/or extensions.

I think I failed completely to make my point.


The final worrying thing I took away from the
conversation is that the whatwg is entirely
focused on JS clients.  They don't consider
any usage of websocket by non JS clients - not
even by extensions implemented in the browser.
The mime still exists that non JS clients should
just open a TCP/IP socket (which if it was
possible, I'm sure the browsers would do).


regards

On 05/04/2010 06:28 PM, Greg Wilkins wrote:

> The final worrying thing I took away from the
> conversation is that the whatwg is entirely
> focused on JS clients.  They don't consider
> any usage of websocket by non JS clients - not
> even by extensions implemented in the browser.
> The mime still exists that non JS clients should
> just open a TCP/IP socket (which if it was
> possible, I'm sure the browsers would do).
I'm not sure who "the WHATWG" are (any more than I am sure who "the 
IETF" are) but I saw at least some agreement that non-browser clients 
would likely exist. Am I missing your point?

# # [23:43] <jgraham> FWIW it seems likely to me that non-browser 
clients for websockets will be used
# # [23:44] <Dashiva> Wouldn't they just connect directly with tcp 
without going via http?
# # [23:44] <jgraham> Because there is value in interacting with the 
websocket ecosystem outside the browser
# # [23:44] <jgraham> Dashiva: Connect to what?
# # [23:44] <jgraham> Assume some service is provided over websockets 
for browsers
# # [23:45] <jgraham> And someone wants to develop a custom non-browser 
app that connets to exactly the same service
# # [23:52] <othermaciej> then they couldn't use a general-purpose http 
client to talk to that service
# # [23:52] * Quits: workmad3 
(~workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com) (Remote 
host closed the connection)
# # [23:53] <gregw> but they want to be able to tunnel bidirectional 
communication through a HTTP infrastructure (eg firewalls, proxies and 
intermediaries)
# # [23:53] <gregw> plus browsers themselves might want to do websocket 
extensions
# # [23:54] <gregw> so the "can't do it in JS, so can't do it at all" 
argument is not that valid
# # [23:54] <jgraham> I'm not suggesting a non-browser-client would be a 
general purpose HTTP client
# # [23:54] <jgraham> It would be custom websockets code
# # [23:54] <othermaciej> I agree that this seems likely

On 4 maj 2010, at 18.38, James Graham wrote:

> On 05/04/2010 06:28 PM, Greg Wilkins wrote:
> 
>> The final worrying thing I took away from the
>> conversation is that the whatwg is entirely
>> focused on JS clients.  They don't consider
>> any usage of websocket by non JS clients - not
>> even by extensions implemented in the browser.
>> The mime still exists that non JS clients should
>> just open a TCP/IP socket (which if it was
>> possible, I'm sure the browsers would do).
> 
> I'm not sure who "the WHATWG" are (any more than I am sure who "the IETF" are) but I saw at least some agreement that non-browser clients would likely exist. Am I missing your point?
<snip>

I don't think anyone is contesting that non-browser clients will connect to WebSocket servers, obviously using WebSockets. Rather, I think Greg's point of contention is that there is a limitation on the WebSocket spec such that if it is impossible to do in JavaScript (e.g. send and receive binary data), the equivalent functionality has to be disabled in the protocol until such time JavaScript can do it.

There are pros and cons with either approach, really. If you assume the primary use case for WebSockets is a browser, then it's probably not a good idea to spec yourself in before the implementations can catch up. On the other hand, if the aspiration is to make a minimal protocol that goes through proxies, firewalls and nats, that, among other things, carries UTF-8 data for JavaScript, then transport of data is the primary target, and UTF-8 is just one form of data.

Personally, I think the binary track should be at least attempted. Otherwise I foresee a lot of Base64'd future.

Vladimir

James Graham wrote:
> I'm not sure who "the WHATWG" are (any more than I am sure who "the
> IETF" are) but I saw at least some agreement that non-browser clients
> would likely exist. Am I missing your point?
James,

firstly, my apologies for using collective descriptions
in my summary.  I know that there is no "they" and that
there are always a range of views.

There was some views agreeing that that there would
be non browser clients.

But I remain concerned that many of the arguments
expressed were very much focused on the java script
in browser use case as it exists today.

For example, when I suggested that a handshake might want to
try multiple protocols, so that if websocket was
not accepted then the connection and/or request
could still be used to avoid another RTT, the response
was:

   [23:01] <Hixie> no browser is ever going to do that

I pointed out that the SPDY guys are doing exactly
that, to which the responses were

   [23:02] <Hixie> the SPDY guys aren't using websocket

   [23:02] <othermaciej> running SPDY over WebSocket would be silly

Yet I've been party to discussions with the SPDY
guys, where they are at least interested in considering
if there could be common framing between SPDY and Websockets.

It may never be practical for SPDY to share a framing layer
with websocket, but I don't think it is such an outrageous
suggestion that it should not be given some consideration.
One thing is for sure - without any consideration then it
will be a self fulfilling prophecy and SPDY will never
run over websocket.


So my concern is about a reluctance to consider other use-cases
that is frequently accompanied with statements citing the
narrow use-case or simply a rejection of the other use case:

   [23:02] <othermaciej> neither the client protocol nor the JS client API support that use case

There is the frequent suggestion that other use-cases should not
use websocket and should go invent their own protocol:

   [23:38] <Hixie> the client is NEVER in HTTP
   [23:38] <gregw> there are other clients than JS
   [23:38] <Hixie> those clients should use TCP

Or that browser concerns outweigh server concerns:

   [23:07] <Hixie> gregw: server impls are far less important than clients, yes


Or that communicating concerns from the IETF WG are communicated (perhaps
badly), they are dismissed:

   [22:59] <gregw> but there is a reasonable level of support in the IETF WG to have that as an option
   [23:06] <gregw> well the IETF WG is pretty clear that HTTP compliance is a requirement - I guess it is debatable if -76 meets that or not
   ...
   [23:14] <gregw> or just make it legal HTTP as the IETF wants
   [23:16] <Hixie> gregw: argument from authority has no effect here (invoking the IETF's name won't win you the argument)


These kind of arguments represent a very tight focus on the HTML5
use-case and a disinclination to engage with other
concerns.

Perhaps that is the correct focus for the WHATWG?
But it is a concern for what we are trying to achieve here.

So I'm sorry if I have offended you by my summary raising
this concern.   It's not really meant as a criticism of
the WHATWG, as they are in a totally different phase of
development to the Hybi WG.   If anything, it is more a
criticism of this group, that we have not done a good
job of formulating and communicating the concerns that
many have about the protocol design of websocket.


regards
James Graham wrote:
> On 05/04/2010 06:28 PM, Greg Wilkins wrote:
> 
>> The final worrying thing I took away from the
>> conversation is that the whatwg is entirely
>> focused on JS clients.  They don't consider
>> any usage of websocket by non JS clients - not
>> even by extensions implemented in the browser.
>> The mime still exists that non JS clients should
>> just open a TCP/IP socket (which if it was
>> possible, I'm sure the browsers would do).
> 
> I'm not sure who "the WHATWG" are (any more than I am sure who "the
> IETF" are) but I saw at least some agreement that non-browser clients
> would likely exist. Am I missing your point?
> 
> # # [23:43] <jgraham> FWIW it seems likely to me that non-browser
> clients for websockets will be used
> # # [23:44] <Dashiva> Wouldn't they just connect directly with tcp
> without going via http?
> # # [23:44] <jgraham> Because there is value in interacting with the
> websocket ecosystem outside the browser
> # # [23:44] <jgraham> Dashiva: Connect to what?
> # # [23:44] <jgraham> Assume some service is provided over websockets
> for browsers
> # # [23:45] <jgraham> And someone wants to develop a custom non-browser
> app that connets to exactly the same service
> # # [23:52] <othermaciej> then they couldn't use a general-purpose http
> client to talk to that service
> # # [23:52] * Quits: workmad3
> (~workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com) (Remote
> host closed the connection)
> # # [23:53] <gregw> but they want to be able to tunnel bidirectional
> communication through a HTTP infrastructure (eg firewalls, proxies and
> intermediaries)
> # # [23:53] <gregw> plus browsers themselves might want to do websocket
> extensions
> # # [23:54] <gregw> so the "can't do it in JS, so can't do it at all"
> argument is not that valid
> # # [23:54] <jgraham> I'm not suggesting a non-browser-client would be a
> general purpose HTTP client
> # # [23:54] <jgraham> It would be custom websockets code
> # # [23:54] <othermaciej> I agree that this seems likely
> _______________________________________________
> hybi mailing list
> <h...@ietf.org>
> https://www.ietf.org/mailman/listinfo/hybi

On May 4, 2010, at 10:49 AM, Greg Wilkins wrote:

>
> For example, when I suggested that a handshake might want to
> try multiple protocols, so that if websocket was
> not accepted then the connection and/or request
> could still be used to avoid another RTT, the response
> was:
>
>   [23:01] <Hixie> no browser is ever going to do that
>
> I pointed out that the SPDY guys are doing exactly
> that, to which the responses were
>
>   [23:02] <Hixie> the SPDY guys aren't using websocket
>
>   [23:02] <othermaciej> running SPDY over WebSocket would be silly
>
> Yet I've been party to discussions with the SPDY
> guys, where they are at least interested in considering
> if there could be common framing between SPDY and Websockets.
For those who want more context, I suggest reading the logs starting  
at this line: http://krijnhoetmer.nl/irc-logs/whatwg/201005...
> It may never be practical for SPDY to share a framing layer
> with websocket, but I don't think it is such an outrageous
> suggestion that it should not be given some consideration.
> One thing is for sure - without any consideration then it
> will be a self fulfilling prophecy and SPDY will never
> run over websocket.
I don't believe anyone working on SPDY is interested in running it  
over WebSocket. However, perhaps the SPDY folks here would like to  
correct my impression, if it is wrong.
>
> So my concern is about a reluctance to consider other use-cases
> that is frequently accompanied with statements citing the
> narrow use-case or simply a rejection of the other use case:
>
>   [23:02] <othermaciej> neither the client protocol nor the JS  
> client API support that use case
This is a statement of fact about the current client protocol and JS  
API, not a statement of what use cases they *should* support.

  don't think it's valid to say a protocol is broken for interfering  
with a use case that it explicitly doesn't support. That doesn't mean  
it's invalid to make a feature request, of course, so long as there is  
a non-tautological basis for the use case.

Regards,
Maciej

On Tue, May 4, 2010 at 10:48 PM, Maciej Stachowiak <m...@apple.com> wrote:

>
> On May 4, 2010, at 10:49 AM, Greg Wilkins wrote:
>
>
>> For example, when I suggested that a handshake might want to
>> try multiple protocols, so that if websocket was
>> not accepted then the connection and/or request
>> could still be used to avoid another RTT, the response
>> was:
>>
>>  [23:01] <Hixie> no browser is ever going to do that
>>
>> I pointed out that the SPDY guys are doing exactly
>> that, to which the responses were
>>
>>  [23:02] <Hixie> the SPDY guys aren't using websocket
>>
>>  [23:02] <othermaciej> running SPDY over WebSocket would be silly
>>
>> Yet I've been party to discussions with the SPDY
>> guys, where they are at least interested in considering
>> if there could be common framing between SPDY and Websockets.
>>
>
> For those who want more context, I suggest reading the logs starting at
> this line: http://krijnhoetmer.nl/irc-logs/whatwg/201005...
>
>
>  It may never be practical for SPDY to share a framing layer
>> with websocket, but I don't think it is such an outrageous
>> suggestion that it should not be given some consideration.
>> One thing is for sure - without any consideration then it
>> will be a self fulfilling prophecy and SPDY will never
>> run over websocket.
>>
>
> I don't believe anyone working on SPDY is interested in running it over
> WebSocket. However, perhaps the SPDY folks here would like to correct my
> impression, if it is wrong.
If we have to, we may. It is fairly unlikely that we'll be able to allow
WebSocket through the loadbalancer at Google directly. We need something
that will multiplex. Connections at that scale are costly. Dealing with
loadbalancing, etc. at that scale is costly. If we accept WebSocket directly
at the loadbalancer, it would require speaking a subprotocol with well
defined framing and semantics such that one could interpret the data in a
less-than-opaque way.

Unfortunate, perhaps, but the reality is that we have to make it work at
scale.

-=R
>
>
>
>> So my concern is about a reluctance to consider other use-cases
>> that is frequently accompanied with statements citing the
>> narrow use-case or simply a rejection of the other use case:
>>
>>  [23:02] <othermaciej> neither the client protocol nor the JS client API
>> support that use case
>>
>
> This is a statement of fact about the current client protocol and JS API,
> not a statement of what use cases they *should* support.
>
>  don't think it's valid to say a protocol is broken for interfering with a
> use case that it explicitly doesn't support. That doesn't mean it's invalid
> to make a feature request, of course, so long as there is a non-tautological
> basis for the use case.
>
> Regards,
> Maciej
>
>
> _______________________________________________
> hybi mailing list
> <h...@ietf.org>
> https://www.ietf.org/mailman/listinfo/hybi
>

Roberto Peon wrote:

> If we have to, we may. It is fairly unlikely that we'll be able to allow
> WebSocket through the loadbalancer at Google directly. We need something
> that will multiplex.
Roberto,

Definitely websocket's framing in it's current form is insufficient to carry
SPDY.      That was the basis of my conversation with Mike Belshe, ie what
extra features would websocket need so that it was suitable to carry SPDY,
this conversation spawned the RTT conversations last month.

Of course there is another option for avoiding creating two framing layers
that will bidirectionally penetrate the internet.    That is that the
websocket API could use the framing layer that is being developed for
SPDY.

http://www.chromium.org/spdy/spdy-protocol/sp...

It appears more than capable of being able to carry websocket
datagrams and is intended to be implemented by the same set of browsers/servers
that are the target of websocket - with the exception of the simple
do-it-your-self servers that also appear to be an important use-case for
some.

While SPDY framing is not overly complex, there could perhaps be some
simplification to better support this use-case.

In 10 years time, I really don't see two protocols being widely used
for bidirectional communication between browsers and servers.  I think
SPDY has the scope to revolutionize the traffic on the internet a lot
more than Websocket does - so I'd put my money on something like SPDY
being the eventual winner.    We'd save ourselves a lot of grief in
the intervening years if we cooperated on a framing layer rather than
competed.

cheers

On May 5, 2010, at 12:03 AM, Roberto Peon wrote:

> If we have to, we may. It is fairly unlikely that we'll be able to  
> allow WebSocket through the loadbalancer at Google directly. We need  
> something that will multiplex. Connections at that scale are costly.  
> Dealing with loadbalancing, etc. at that scale is costly. If we  
> accept WebSocket directly at the loadbalancer, it would require  
> speaking a subprotocol with well defined framing and semantics such  
> that one could interpret the data in a less-than-opaque way.
>
> Unfortunate, perhaps, but the reality is that we have to make it  
> work at scale.
Are you talking about SPDY running on top of WebSocket, or WebSocket  
running on top of SPDY?

Regards,
Maciej

On Tue, May 4, 2010 at 10:48 PM, Maciej Stachowiak <m...@apple.com> wrote:

>
> On May 4, 2010, at 10:49 AM, Greg Wilkins wrote:
>
>
>> For example, when I suggested that a handshake might want to
>> try multiple protocols, so that if websocket was
>> not accepted then the connection and/or request
>> could still be used to avoid another RTT, the response
>> was:
>>
>>  [23:01] <Hixie> no browser is ever going to do that
>>
>> I pointed out that the SPDY guys are doing exactly
>> that, to which the responses were
>>
>>  [23:02] <Hixie> the SPDY guys aren't using websocket
>>
>>  [23:02] <othermaciej> running SPDY over WebSocket would be silly
>>
>> Yet I've been party to discussions with the SPDY
>> guys, where they are at least interested in considering
>> if there could be common framing between SPDY and Websockets.
>>
>
> For those who want more context, I suggest reading the logs starting at
> this line: http://krijnhoetmer.nl/irc-logs/whatwg/201005...
>
>
>  It may never be practical for SPDY to share a framing layer
>> with websocket, but I don't think it is such an outrageous
>> suggestion that it should not be given some consideration.
>> One thing is for sure - without any consideration then it
>> will be a self fulfilling prophecy and SPDY will never
>> run over websocket.
>>
>
> I don't believe anyone working on SPDY is interested in running it over
> WebSocket. However, perhaps the SPDY folks here would like to correct my
> impression, if it is wrong.
I never thought that made a lot of sense.  SPDY is about changing the way
content is delivered.  WebSockets is about an efficient, bi-directional app
protocol which tunnels over HTTP (largely to avoid the hanging GET problem).
 It is easy for me to see how WebSockets layers on top of SPDY (similar to
how WebSockets layers on top of HTTP), but I don't see any way that SPDY
makes sense over WebSockets.

Most importantly, however, I think the two projects are just different and
must have different schedules.  The WebSockets work is  well understood with
at least 3 deep investments from major browser vendors and even more server
vendors.  SPDY, however, is much more complicated and needs more time.  We
should not tie the WebSockets requirements to SPDY in any way, as to do so
would be holding WebSockets hostage to yet-undefined requirements.

Mike
>
>
>
>> So my concern is about a reluctance to consider other use-cases
>> that is frequently accompanied with statements citing the
>> narrow use-case or simply a rejection of the other use case:
>>
>>  [23:02] <othermaciej> neither the client protocol nor the JS client API
>> support that use case
>>
>
> This is a statement of fact about the current client protocol and JS API,
> not a statement of what use cases they *should* support.
>
>  don't think it's valid to say a protocol is broken for interfering with a
> use case that it explicitly doesn't support. That doesn't mean it's invalid
> to make a feature request, of course, so long as there is a non-tautological
> basis for the use case.
>
> Regards,
> Maciej
>
>
> _______________________________________________
> hybi mailing list
> <h...@ietf.org>
> https://www.ietf.org/mailman/listinfo/hybi
>

* Julian Reschke wrote:
>I notice that there was a long discussion about this on the WhatWG IRC 
>channel (<http://krijnhoetmer.nl/irc-logs/whatwg/201005...>). I 
>think it would be great if somebody could summarize over here.
I skimmed over that. My impression is that it is mostly confused; gregw
has different ideas than Hixie and othermaciej about the assumptions a
client makes when they attempt to initiate an Upgrade, and Hixie and
othermaciej have trouble reading the HTTP specification because it de-
fines when messages have a body by defining when they have a body,
rather than citing the steps implementations are required to take when
deciding whether messages have a body, or constructing messages with a
body [1].

Put differently, the main argument there seems to be whether the hand-
shake should deliberately attempt to break the HTTP protocol to disrupt
unintended communication (the proposal is to send a random string where
a HTTP request would be expected if the Upgrade fails) or handle failure
without disrupting the HTTP communication if the Upgrade fails (or, for
that matter, the handshake, if you do not expect an Upgrade to actually
take place, because you assume you are not talking HTTP to begin with).

So if I understood the discussion correctly, the question is what the
entities attempting to initiate a Websocket connection can assume about
the entities dealing with their attempts (or if it is okay to disrupt
certain communication). If the initiating entities may assume that they
are talking "Websocket protocol" all the way, or if it is okay for them
to send "junk" during a HTTP connection, then the random string is no
problem. If the initiating entities have to assume they are expected to
"talk HTTP" and disrupting the channel is not okay, then there is one.

[1] The argument there is essentially that you cannot write a specifi-
    cation for prime numbers simply by saying "A prime number is a
    natural number with exactly two distinct natural number divisors"
    because that is a definition and not a "conformance requirement";
    you would have to use "X MUST Y" statements to carry any meaning.
-- 
Björn Höhrmann · <mail...@hoehrmann.de> · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

On May 4, 2010, at 6:35 PM, Bjoern Hoehrmann wrote:

> * Julian Reschke wrote:
>> I notice that there was a long discussion about this on the WhatWG  
>> IRC
>> channel (<http://krijnhoetmer.nl/irc-logs/whatwg/201005...>). I
>> think it would be great if somebody could summarize over here.
>
> I skimmed over that. My impression is that it is mostly confused;  
> gregw
> has different ideas than Hixie and othermaciej about the assumptions a
> client makes when they attempt to initiate an Upgrade, and Hixie and
> othermaciej have trouble reading the HTTP specification because it de-
> fines when messages have a body by defining when they have a body,
> rather than citing the steps implementations are required to take when
> deciding whether messages have a body, or constructing messages with a
> body [1].
What statements in the HTTP RFC define when messages have a body? I'm  
not being facetious - I'd honestly like to know what you're basing  
your argument on.

Regards,
Maciej

On 05.05.2010 07:36, Maciej Stachowiak wrote:
>
> On May 4, 2010, at 6:35 PM, Bjoern Hoehrmann wrote:
>
>> * Julian Reschke wrote:
>>> I notice that there was a long discussion about this on the WhatWG IRC
>>> channel (<http://krijnhoetmer.nl/irc-logs/whatwg/201005...>). I
>>> think it would be great if somebody could summarize over here.
>>
>> I skimmed over that. My impression is that it is mostly confused; gregw
>> has different ideas than Hixie and othermaciej about the assumptions a
>> client makes when they attempt to initiate an Upgrade, and Hixie and
>> othermaciej have trouble reading the HTTP specification because it de-
>> fines when messages have a body by defining when they have a body,
>> rather than citing the steps implementations are required to take when
>> deciding whether messages have a body, or constructing messages with a
>> body [1].
>
> What statements in the HTTP RFC define when messages have a body? I'm
> not being facetious - I'd honestly like to know what you're basing your
> argument on.
> ...
<http://greenbytes.de/tech/webdav/rfc2616.html...>:

"The rules for when a message-body is allowed in a message differ for 
requests and responses.

The presence of a message-body in a request is signaled by the inclusion 
of a Content-Length or Transfer-Encoding header field in the request's 
message-headers. A message-body MUST NOT be included in a request if the 
specification of the request method (Section 5.1.1) does not allow 
sending an entity-body in requests. A server SHOULD read and forward a 
message-body on any request; if the request method does not include 
defined semantics for an entity-body, then the message-body SHOULD be 
ignored when handling the request.

For response messages, whether or not a message-body is included with a 
message is dependent on both the request method and the response status 
code (Section 6.1.1). All responses to the HEAD request method MUST NOT 
include a message-body, even though the presence of entity-header fields 
might lead one to believe they do. All 1xx (informational), 204 (no 
content), and 304 (not modified) responses MUST NOT include a 
message-body. All other responses do include a message-body, although it 
MAY be of zero length."


Best regards, Julian

Maciej Stachowiak wrote:

> What statements in the HTTP RFC define when messages have a body? I'm
> not being facetious - I'd honestly like to know what you're basing your
> argument on.
In regards to this issue about if the random bytes are content or not, you
asked on IRC:

# [22:48] <othermaciej> gregw: how is it a problem for HTTP servers? or
  rather, how is it more of a problem than the -75 version?

The problem for HTTP servers that offer websocket services,
is that they don't know it is a webserver upgrade request until
they are deep inside their normal HTTP handling.

In Jetty's case the calling stack is something like:

    Thread dispatched to handle a connection with IO activity
    SelectChannelConnector.handle()
    HttpConnection.handle()
    HttpParser.parseAll()
    HttpConnection.handleRequest()
    HttpServer.handle(request,response)
    ContextHandlerCollection.handle(request,response)
    WebAppContext.handle(request,response)
    SecurityHandler.handle(request,response)
    SessionHandler.handle(request,response)
    ServletHandler.handle(request,response)
    WebsocketServlet.service(request,response)
    MyWebsocketServlet.doWebSocketConnect(request,response)


The handling of the upgrade deep inside the application
context is a good thing, because it is only when
deep inside the normal HTTP handling that the application
scope is established for the request and we have
access to the application logic to decide if it
is acceptable or not; and access to the application
object that need to be plumbed into the websocket
endpoint to handle messages etc.

The MyWebsocketServlet indicates it's acceptance
by sending a 101 response.

But the MyWebsocketServlet has absolutely no access to the
raw TCP/IP socje that the handshake came over, so it cannot
read the random bytes.   The input stream that accompanies
the HttpRequest is not a raw stream from the socket,
but one that is processed via the HttpParser and that
obeys the RFC2616 rule about content.    If MyWebSocketServlet
read's the input stream, it will get EOF because according
to RFC2616 there is no body on that request.  On some
setups, the HTTP handling is on a different machine
to the applications handling of the request.

So the WebsocketServlet cannot fully process the handshake.
It has to delegate the completion of the handshake handling to
the WebSocketConnection object that will be created after
the HttpConnection has completed.

So we have to stop the HttpConnection sending the
101 response, and make the WEbSocketConnection send
it instead - so now the WebSocketConnection class,
which previously dealt only with established websocket
connections (which might eventually be established by
non-HTTP means), has to deal with:

   + a stateful wait for the random bytes, which
     might arrive 1 at a time or not at all.
   + sending a HTTP response
   + completing the handshake.
   + communicating back the the application layer
     failure if the random bytes don't arrive

Now all this is possible, but it represents a bit of a
horrid mixing of concerns.  Handshake handling is split
in two places, websocket code is handling HTTP responses
etc.    The random bytes that the websocket connection
has to handle and generate are not even framed as
websocket frames?  So the poor websocket connection
has to deal with HTTP, random-bytes and two types
of websocket framing.


So I want to know why is all this complexity
necessary.   We all originally discussed the
random bytes in the context of a security
mechanism that could be implemented entirely
in headers, yet when it appeared in the draft
it was using these extra bytes.

Hixie has put the random bytes outside
of the HTTP for an entirely different reason.
He wants fast failure if an intermediary
fails to forward packets.


So my question is, why do we need such a
special purpose fast failure mechanism that
is mixed in with the security mechanism.

We have already discussed the need for
pings and keep alives.   If we required
the websocket server to send a ping immediately
that the websocket is established, then the
client can wait for that ping before signalling
the application that the connection has been
accepted with onOpen.

This gives us fast fail (within bounds of TCP
timeouts... which might not be fast), allows
the websocket  connection code to deal only
with websocket frames and is part of a more general
mechanism that can detect failures long after
the handshake is completed.

We need to have discussions about such
alternative proposals after we've clearly
established the requirements and before
a proposed solution is put into the draft
and implemented by many parties.


regards

On Wed May  5 02:35:51 2010, Bjoern Hoehrmann wrote:
> [1] The argument there is essentially that you cannot write a  
> specifi-
>     cation for prime numbers simply by saying "A prime number is a
>     natural number with exactly two distinct natural number  
> divisors"
>     because that is a definition and not a "conformance  
> requirement";
>     you would have to use "X MUST Y" statements to carry any  
> meaning.
Minor aside - there's no requirement that "MUST" has to be used - a  
simple statement of fact carries just as much weight, and might  
actually be clearer.

IETF traditions are such that uncapitalised usage of must, should,  
may etc are somewhat frowned upon, however, especially in a document  
using RFC 2119 language.

An example of a relatively recent standards-track document which does  
not use RFC 2119 is RFC 4469.

Dave.
-- 
Dave Cridland - <mail...@cridland.net> - <xmpp...@dave.cridland.net>
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

On 05.05.2010 11:20, Dave Cridland wrote:
> ...
> Minor aside - there's no requirement that "MUST" has to be used - a
> simple statement of fact carries just as much weight, and might actually
> be clearer.
Absolutely.
> IETF traditions are such that uncapitalised usage of must, should, may
> etc are somewhat frowned upon, however, especially in a document using
> RFC 2119 language.
>
> An example of a relatively recent standards-track document which does
> not use RFC 2119 is RFC 4469.
> ...
Other examples are URI (RFC 3986, STD 66) and ABNF (RFC 5234, STD 68).

Best regards, Julian