ArchiveOrangemail archive

Server-Initiated HTTP


hybi.ietf.org
(List home) (Recent threads) (189 other Internet Engineering Task Force (IETF) lists)

Subscription Options

  • RSS or Atom: Read-only subscription using a browser or aggregator. This is the recommended way if you don't need to send messages to the list. You can learn more about feed syndication and clients here.
  • Conventional: All messages are delivered to your mail address, and you can reply. To subscribe, send an email to the list's subscribe address with "subscribe" in the subject line, or visit the list's homepage here.
  • Low traffic list: less than 3 messages per day
  • This list contains about 9,900 messages, beginning Oct 2009
  • 2 messages added yesterday
Report the Spam
This button sends a spam report to the moderator. Please use it sparingly. For other removal requests, read this.
Are you sure? yes no

status of websockets drafts

Ad
Julian Reschke 1272871133Mon, 03 May 2010 07:18:53 +0000 (UTC)
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
Greg Wilkins 1272895337Mon, 03 May 2010 14:02:17 +0000 (UTC)
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
Simon Pieters 1272918719Mon, 03 May 2010 20:31:59 +0000 (UTC)
On Mon, 03 May 2010 16:01:48 +0200, Greg Wilkins 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,
Maciej Stachowiak 1272938366Tue, 04 May 2010 01:59:26 +0000 (UTC)
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
Greg Wilkins 1272988861Tue, 04 May 2010 16:01:01 +0000 (UTC)
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
Julian Reschke 1272989896Tue, 04 May 2010 16:18:16 +0000 (UTC)
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
Ian Fette (イアンフェッティ) 1272996557Tue, 04 May 2010 18:09:17 +0000 (UTC)
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 : > > 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 > > https://www.ietf.org/mailman/listinfo/hybi > >
Greg Wilkins 1273009820Tue, 04 May 2010 21:50:20 +0000 (UTC)
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
Julian Reschke 1272958184Tue, 04 May 2010 07:29:44 +0000 (UTC)
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
Greg Wilkins 1272990679Tue, 04 May 2010 16:31:19 +0000 (UTC)
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
James Graham 1272991166Tue, 04 May 2010 16:39:26 +0000 (UTC)
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
Vladimir Katardjiev 1272991839Tue, 04 May 2010 16:50:39 +0000 (UTC)
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
Greg Wilkins 1272995393Tue, 04 May 2010 17:49:53 +0000 (UTC)
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 > > https://www.ietf.org/mailman/listinfo/hybi
Maciej Stachowiak 1273038511Wed, 05 May 2010 05:48:31 +0000 (UTC)
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
Roberto Peon 1273043032Wed, 05 May 2010 07:03:52 +0000 (UTC)
On Tue, May 4, 2010 at 10:48 PM, Maciej Stachowiak 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 > > https://www.ietf.org/mailman/listinfo/hybi >
Greg Wilkins 1273045712Wed, 05 May 2010 07:48:32 +0000 (UTC)
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
Maciej Stachowiak 1273488147Mon, 10 May 2010 10:42:27 +0000 (UTC)
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
Mike Belshe 1273099553Wed, 05 May 2010 22:45:53 +0000 (UTC)
On Tue, May 4, 2010 at 10:48 PM, Maciej Stachowiak 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 > > https://www.ietf.org/mailman/listinfo/hybi >
Bjoern Hoehrmann 1273023358Wed, 05 May 2010 01:35:58 +0000 (UTC)
* 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.
Maciej Stachowiak 1273037811Wed, 05 May 2010 05:36:51 +0000 (UTC)
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
Julian Reschke 1273040413Wed, 05 May 2010 06:20:13 +0000 (UTC)
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
Greg Wilkins 1273062331Wed, 05 May 2010 12:25:31 +0000 (UTC)
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
Dave Cridland 1273051305Wed, 05 May 2010 09:21:45 +0000 (UTC)
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.
Julian Reschke 1273052425Wed, 05 May 2010 09:40:25 +0000 (UTC)
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
Ad
Home | About | Privacy