Closed Bug 602028 Opened 14 years ago Closed 14 years ago

Websockets -76 needs to be prefixed in experimental namespace

Categories

(Core :: Networking: WebSockets, defect)

Product:
Core
Component:
Networking: WebSockets
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
mozilla2.0b8
Tracking Flags:
Tracking Status
blocking2.0 --- -

People

(Reporter: mcmanus, Unassigned)

References

Details

The -76 implementation of websockets should be prefixed in an experimental namespace for ff 4, while the final websockets protocol is sorted out in the IETF.
So the two options we have is to prefix the API or prefix the protocol scheme. Seems like prefixing protocol scheme is technically more correct, but how would one do feature detection for it?
blocking2.0: --- → beta8+
We most certainly should not. Chrome and Safari have released -76 support unprefixed, and Opera will do the same. Prefixing in Gecko doesn't gain anybody anything, because any new version that wants to see adoption will have to be compatible with the shipped implementations, regardless of what we do. It only hurts us, because "Firefox doesn't implement HTML5".
The stable version of the protocol won't be compatible with -v76, AFAIK.
(And I agree, we should IMO ship -v76 and just warn in the error console or something about unstable protocol. But others don't agree with me.)
(In reply to comment #3) > The stable version of the protocol won't be compatible with -v76, AFAIK. Sounds like XHTML2 to me.
-v76 as such has at least one serious bug which needs to be fixed.
(In reply to comment #2) > We most certainly should not. Chrome and Safari have released -76 support > unprefixed, and Opera will do the same. Prefixing in Gecko doesn't gain anybody > anything, because any new version that wants to see adoption will have to be > compatible with the shipped implementations, regardless of what we do. It only > hurts us, because "Firefox doesn't implement HTML5". The reason that we want to prefix it is because we know, 100%, that it's going to change. We also know that other browsers will update it as well. We don't want it confused with a protocol that is anything other than experimental and the best way to do that is prefix it as such. The new version will not be compatible with existing implementations. It has a very different on-the-wire format and there's a good chance it will have a different handshake protocol as well.
What will other implementations do when they update to -v77 or whatever is "it"? There are always bugs and limitations that motivate new versions. Next time will differ how? Calling something that has bugs by its unprefixed name has tons of precedent on the web. Are we doing anyone any favors with the current plan of record? Even if so, answers to the two questions above would seem necessary, sooner or later. /be
(In reply to comment #8) > What will other implementations do when they update to -v77 or whatever is > "it"? Chrome has stated that they will update the standard namespace to v.next, a breaking change. Apple has said nothing, per their policy. > > Calling something that has bugs by its unprefixed name has tons of precedent on > the web. Calling something that does not enjoy consensus by a prefixed name has a lot of precedent on the Web as well. There is no pressing need to use the unprefixed version. WebSockets won't exit demoware status for a few years, and we can re-evaluate the name of the API to match whenever.
My "Next time will differ how?" question was about Web Socket's versioning story, or lack thereof. Any takers? It can't matter if it's demoware for years, but the who's-in-the-lead perception may trump all other considerations, and it may be stable over those years. We are (in spite of greater non-mobile market share) constantly eating WebKit's dust. I would lay a bet we'll do it again here (for some value of "WebKit", possibly the chromium one). /be
(In reply to comment #10) > My "Next time will differ how?" question was about Web Socket's versioning > story, or lack thereof. Any takers? > There's no versioning story on the Web. Only consensus on version 1. Then, there are backwards compatible changes. If you can't make a backwards compatible change, you give the thing a new name. > It can't matter if it's demoware for years, but the who's-in-the-lead > perception may trump Maybe. That's a marketing problem. > We are (in spite of greater non-mobile market share) constantly eating > WebKit's dust. I would lay a bet we'll do it again here (for some value of > "WebKit", possibly the chromium one). So the answer is to let WHATWG (let's pretend it's a group) plan our product for us? There are many -webkit-foo HTML5 demos where we are "eating dust", so I don't think namespacing is the salient issue here. However, I also don't think this particular API matters much either way. Given that ambivalence, I shouldn't have argued either way in the first place. My mistake.
(In reply to comment #11) > (In reply to comment #10) > > My "Next time will differ how?" question was about Web Socket's versioning > > story, or lack thereof. Any takers? > > > > There's no versioning story on the Web. That's not true for all protocols. I won't bore you with counterexamples but I hope you're being serious. > Only consensus on version 1. Then, > there are backwards compatible changes. If you can't make a backwards > compatible change, you give the thing a new name. This is the same as giving it a new version number, for some values of "thing". I was just asking whether Web Sockets has a version field of some kind. Dear LazyWeb... > Maybe. That's a marketing problem. Well, that settles it -- we are doomed :-P. > > We are (in spite of greater non-mobile market share) constantly eating > > WebKit's dust. I would lay a bet we'll do it again here (for some value of > > "WebKit", possibly the chromium one). > > So the answer is to let WHATWG (let's pretend it's a group) plan our product > for us? I don't know why you are asking me questions like that. I never advocated any such thing and you know it. I asked two questions (still no answer to #2) and suggested there are worse things than matching other implementations that will interoperate, even if only as "Demoware", for years. What's the best course for us to steer? I really don't care about WHATWG or Hixie or whatever is bugging you. > There are many -webkit-foo HTML5 demos where we are "eating dust", so I don't > think namespacing is the salient issue here. Those are big problems, not solved by marketing. Prefixes on CSS style props live too long and we play latecomer, or developers don't even know about the -moz- equivalent. This is a real downside to vendor prefixing. It's why we try to avoid it in JS (Ecma TC39 standards) land. > However, I also don't think this > particular API matters much either way. Given that ambivalence, I shouldn't > have argued either way in the first place. My mistake. Well, you wrote a lot anyway. Something is clearly at stake. /be
(In reply to comment #7) > The reason that we want to prefix it is because we know, 100%, that it's going > to change. We know that the IETF intends to publish a spec they'll call WebSockets. It's not clear anyone but Google will benefit from it, or that any browser but Chrome will implement it. > We also know that other browsers will update it as well. [citation needed] > We don't > want it confused with a protocol that is anything other than experimental and > the best way to do that is prefix it as such. I don't believe that's the best way, considering the other unprefixed implementations. Marketing may not be our greatest strength, but I think it is the better way to communicate that the protocol is "experimental". > The new version will not be compatible with existing implementations. It has a > very different on-the-wire format and there's a good chance it will have a > different handshake protocol as well. And that's why I doubt it will gain a lot of traction.
OS: Linux → All
Hardware: x86_64 → All
(In reply to comment #12) > I was just asking whether Web Sockets has a version field of some kind. Dear > LazyWeb... No, it does not; at least not yet. Recall? 'Versioning is an "anti-pattern".'
If the constructor for WebSocket's is prefixed with anything, then code that currently works in chrome/chromium and safari will be broken in gecko browsers. The result would almost be the same as if gecko browsers didn't have WebSockets implemented. Developers using WebSockets should understand that the protocol is still changing, it is still a draft. That said, at this stage, it would probably be best to implement draft-76, as it's the most widely implemented by Servers. That said, developers of servers can be expected to expect their server's will break as new versions of WebSockets are implemented in browsers. It'd be disappointing to see mozilla implement websockets but force developers to use a different API to other browsers which implement the protocol. Besides, when did mozilla have a problem with implementing experimental javascript API's (like __noSuchMethod__) ? It's best to have the developers deal with the versions, then the browsers. Keep things consistent.
AFAIK, the JS API (still developed in WHATWG while the wire protocol is by IETF) is pretty stable, at least until support for byte arrays is added to JS. That means that user-written code will work on top of v75, v76, etc WebSocket implementations without change, assuming the browser supports the same protocol version as the server. For user-written server-side code, at least the current implementation in Jetty 7 hides the wire protocol differences, so I believe it would be possible to upgrade the supported protocol in both the client and server and a user-written application would work without any changes. The framing of the wire protocol seems fairly well defined as of draft -02 -- there are extension points, but it was carefully written so that an implementation can ignore extensions it doesn't understand. The area where there is a lot of flux is in the handshake -- there are a lot of pretty radical proposals there, and it might be difficult to write an implementation that supports different versions. Even adding a version in the header doesn't help if the level above that is TLS-NPN or a hack based on the CONNECT method (most of the discussion about the handshake is trying to avoid cross-protocol attacks). So, my suggestion would be to leave the JS API unprefixed so user-written code can work unchanged, but just make clear in the release notes that the underlying protocol is going to change.
(In reply to comment #15) > Besides, > when did mozilla have a problem with implementing experimental javascript API's > (like __noSuchMethod__) ? It's best to have the developers deal with the > versions, then the browsers. Keep things consistent. While I agree there's no point in us prefixing the API, this __noSuchMethod__ comparison falls down on at least three points: 1. We originated __noSuchMethod__ (extensions are allowed by ECMA-262 Clause 16). 2. No other browser has ever had any such trap for us to differ from, motivating a prefix (presumably from the latecomer, but there haven't been any others). 3. There's no wire protocol version flux at stake, vs. surface syntax. Point 3 about API surface "syntax" invariance is good, and I agree with jat (comment 16). We should not add a prefix to the JS API. The "versioning is an anti-pattern" slogan is pattern-mongering, which can easily become cargo-cult science. Even in the best light, patterns are too often what people marry in order to work around bugs in their programming languages (protocols, etc.). Feature detection is great, and there is a lot for other (mostly failed, in comparison to the web) version-happy standards to learn from the web, but the idea that the web only grows compatibly, never breaking backward compatibility or painting into a corner, is false. In particular it is not true that HTML and CSS and JS have evolved since 1995 in only backwards-compatible ways. We had CSS table layout breaks, JS semantic breaks in ES1, ES2, ES3, and ES5, and others I'm forgetting. Versioning was used by developers to cope with these breaks (user-agent sniffing). The Web's interoperable intersection semantics *moves*, it does not merely *grow*. Old forms die off, sometimes with a stick from browsers using market power to break them, usually due to carrots leading developers away from the old forms so browsers can drop support without notice. Pretending otherwise is self-deceptive and it makes for bad engineering. The next version of ECMA-262 (JavaScript) will include opt-in versioning for new syntax (attempts to future-proof JS syntax in the past having failed). I'm sure WebSockets developers will cope without a protocol version. Probably by user-agent sniffing! /be
(In reply to comment #12) > I was just asking whether Web Sockets has a version field of some kind. Dear > LazyWeb... There's no version field, but the different protocols have different handshakes, so a server that supports multiple protocols can tell the wire protocols apart from the handshake. OTOH, trying to talk to a server that doesn't support a given protocol will fail early at the handshake stage. (If one wanted to make it possible for browsers to support side-by-side multiple protocols that provide the same service to the application, the natural way to do it would be giving incompatible protocols different URL schemes, like ws: and ietfws:. If one wanted to support side-by-side multiple protocols providing different services to the application, the natural way to do that would be giving the constructor of the new thing a new name like |new IETFWebSocket()|. Side-by-side support may not be desirable, though. For example, Atom failed to remove the problems of RSS 2.0 from the ecosystem. Instead, it just added itself to the ecosystem.)
IMHO prefixing the scheme makes sense, if we're going to prefix something. The API, as others have noted, is actually pretty stable, and Ian Fette (protocol editor) and I (API editor) have no plans to change anything at the API level, only the protocol level, and I'm not aware of any outstanding feedback on the API. So I would advise against prefixing the API. (In reply to comment #6) > -v76 as such has at least one serious bug which needs to be fixed. As far as I am aware, all of the bugs in -76 were fixed in this draft from August before I handed the spec over to Ian Fette: http://www.whatwg.org/specs/web-socket-protocol/ Also, for the record (in reply to comment #11): > So the answer is to let WHATWG (let's pretend it's a group) plan our product > for us? The WHATWG hasn't worked on the protocol for several months now, this is all happening at the IETF. Even when the WHATWG was working on the protocol, the highest priority was, has always been, and continues to be to document actual implemented practice, which puts browser vendors first and foremost in terms of control. So I really have no idea what this is supposed to mean.
> IMHO prefixing the scheme makes sense, if we're going to prefix something. Prefixing the scheme has the unfortunate disadvantage of not interoperating with the other WebSocket implementations of -76. When the WebKit community discussed this issue, we decided to keep the "ws" scheme rather than use "webkit-ws" or "x-ws". Our thought process at the time (which was before the HyBi working group started its work) was that the HyBi WG could just as easily pick a fresh scheme (e.g., "websocket") once they nailed down the protocol. At this point, it seems likely that Chrome, Safari, Opera, and Firefox will ship with an implementation of version 76 of the protocol. It's quite tempting to call that the protocol and move on with life.
(In reply to comment #19) > (In reply to comment #6) > > -v76 as such has at least one serious bug which needs to be fixed. > > As far as I am aware, all of the bugs in -76 were fixed in this draft from > August before I handed the spec over to Ian Fette: So the problem with reverse proxies is fixed? I guess chapter 6 overcomes that problem by effectively saying that servers need to change.
FWIW, Opera are considering prefixing the scheme if Firefox does it (i.e. use "x-ws" and "x-wss"). But ideally we'd also like WebKit to change to use the same prefix. Is there a corresponding WebKit bug?
> Is there a corresponding WebKit bug? The discussion was on webkit-dev and not in a bug. Feel free to file one and cc me. I suspect if there's a move to use x-ws and x-wss, WebKit would do the same. That said, this approach it more likely we'll be stuck with "x-" forever: http://tools.ietf.org/html/draft-saintandre-xdash-considered-harmful
OK, so it sounds like if we're willing to move to a private namespace others are as well. That's good news. I would prefer not to have to support one version of the protocol. And based on Ian's work - that Chrome would likely also not support more than one version of the protocol at a time. And that using x- (or experimental-!) indicates it will change. Sounds good to me for sure. Also totally agreed about not changing the API. No need to do that.
I'm not sure prefixing the scheme is any more useful than prefixing the JS API for WebSockets -- the point is that it is not a change visible to users writing their WebSockets app. If they use a ws:// URL and write some server component at that URL, it will work as long as the browser and the server (or library) they use support the same WebSocket protocol. If you use x-ws to mean the v76 protocol, then a working WebApp will stop working if the server is upgraded to support the final spec, and nothing the developer can do will change that as what needs to happen is the user needs to upgrade their browser.
My preference is to kill -76. We are starting to upgrade to -02 (possibly -03 if I can get that out this weekend, which I intend to). In Chrome at least, I intend to break -76. -76 should be taken out behind the shed and put out of its misery :) I am hoping to get -02/-03 into dev channel in November. As for prefixing with x-, I would prefer not to do that as we would then keep it around forever and probably not migrate. I think the best strategy is to just keep breaking people to force the expectation that this is still a work in progress, and if you're not aware of that you shouldn't be using it...
(In reply to comment #26) > As for prefixing with x-, I would prefer not to do that as we would then keep > it around forever and probably not migrate. I think the best strategy is to > just keep breaking people to force the expectation that this is still a work in > progress, and if you're not aware of that you shouldn't be using it... How do we indicate to developers that it's still under development and when it's finalized? I worry that you're assuming that the developers will have the perfect knowledge of everything that's happening on the web, what the status is of various standards are and if things are going to change. Given my personal experience that's a dangerous assumption. You're pretty heavily involved in this process and you agree that we shouldn't support older versions of the protocol. I'm just trying to make sure we aren't setting ourselves up to make a mistake where we can, as a group, prevent ourselves from having the breathing room to evolve the protocol.
I think the scheme is essentially part of the API, as it is visible to developers writing WebSockets code. As mentioned, there shouldn't be anything that such a developer would have to change in order to use v76 vs v02 -- it is strictly up to the browser and server. Its not like we are expecting to continue supporting various versions of the protocol and allowing developers to choose which one they want. The only value I see would be indicating that it is all experimental and likely to break at any time, so if that is what you want to convey then call the scheme x-this-will-break :).
Yes, the point is to communicate that it's experimental. To that end I guess x-ws is not so effective for the intended purpose, and something like experimental-ws or x-this-will-break are better names. (We could also whine in the error console so it's visible to developers who use a JS library that hides the experimental scheme.)
A final decision on this is needed before I will feel comfortable beginning documentation work on WebSockets.
(In reply to comment #23) > > Is there a corresponding WebKit bug? > > The discussion was on webkit-dev and not in a bug. Feel free to file one and > cc me. I suspect if there's a move to use x-ws and x-wss, WebKit would do the > same. That said, this approach it more likely we'll be stuck with "x-" > forever: > > http://tools.ietf.org/html/draft-saintandre-xdash-considered-harmful We'll be stuck with the old name, x-ws or ws or whatever, for as long as content on the Web seems populous enough that browsers don't want to risk "breaking the web" by dropping support. I created application/x-javascript by fiat for script type in 1995, and it is still there, but RFC4329 has standardized types, and there's hope some day we can drop the x- type. The x-javascript type will probably die some day well before the official types (and HTML4's by-Dave-Raggett-fiat text/javascript type) die. In the mean time, it's not a big deal. Small cost to mitigate risk of breaking some old content. Thought experiment: if I had claimed application/javascript then, but the language changed incompatibly (actually, it has, several times), would we be better off? Since browsers and web content do not all upgrade in lockstep, we would need RFC4329's ;version= parameter, or we would need an entirely new type. In point of fact, several now-deprecated techniques were used, including <script language="JavaScript1.1">, and (for some browsers) <script type="application/x-javascript;version=1.1">. And with RFC4329, there is a non-deprecated type and version parameter that even seem to work in IE9. Maybe "it's different this time" with WebSockets. They are young enough, perhaps, that browsers and the (relatively small, compared to the web) content and user population counting on them will upgrade more-or-less in lockstep. If something seems broken, users will get a new browser that supports the v02 or v03 protocol. But will it really be different this time? Are we going to synchronize Firefox's release cycle with Chrome's? Is Opera? Is Safari? To be blunt, this looks good for Google, not so good for everyone else, under the hypothesis that everyone in the minority-cohort using WS will upgrade to *some* browser (not necessarily a newer version of the browser they are currently using) to "get current". More likely, users won't switch browsers just to get ws-latest, so we'll end up with version skew in the field. I'm not arguing for x-ws now and ws later, or any particular names. I am arguing that in principle and based on plentiful history, we seem likely to end up with a requirement to distinguish WS versions, in order to interoperate across browsers in the field and in beta, loading content written this year and next, run by users who will not all want to jump to whatever browser supports the next version. Versioning happens. There is no benefit and a lot of mischief in denying this, or pretending some version-skew and last/next version support can be avoided. I agree we should avoid versionitis and try to keep experimental protocols "in the lab" (even if field-tested on beta users), so we can break them at official standardization and final release events. I'm skeptical this will happen in a coordinated way for WS. Did anyone file that webkit.org bug on prefixing? /be
My perception here is that this is different from javascript in one significant way: The two options that we are choosing between are: * Don't prefix. Break existing content once we upgrade the protocol, unless they take steps to support both protocols. * Do prefix. Support existing and new content for as long as we feel the need to. Only once we decide to drop the old protocol will we break existing content or force them to take steps to support both protocols. So if the lesson from the javascript example is "it's hard to deprecate something once it's released", then prefixing is the way to go here. The not-prefixing path more aggressively forces us to deprecate released stuff.
(In reply to comment #32) > The two options that we are choosing between are: > > * Don't prefix. Break existing content once we upgrade the protocol, unless > they take steps to support both protocols. > * Do prefix. Support existing and new content for as long as we feel the need > to. Only once we decide to drop the old protocol will we break existing > content or force them to take steps to support both protocols. What about the suggestion from comment 20 of the new protocol using a new scheme? That is a third option. > So if the lesson from the javascript example is "it's hard to deprecate > something once it's released", then prefixing is the way to go here. My point in comment 31 was more "what's in a name" than "hard to deprecate". It is hard to deprecate anything that sees adoption, no matter what its name. The counter-argument to "what's in a name" indifference is that an x-will-break name warns some developers. Maybe, but what is that x-string and can we get all the shipping browsers to agree quickly. > The > not-prefixing path more aggressively forces us to deprecate released stuff. No, there's a third way: take the comment 20 suggestion and use a new scheme for a new (future) protocol revision. /be
I find this all very academic to be honest. There are very few people shipping servers right now, and no one is really shipping them by default. If you can figure out how to install a websockets server in the current environment, you probably know enough to know that it's evolving and how to update. As long as the JS API doesn't change substantially (with the exception of additions) I really don't see this is a big issue.
Sigh, hit send too soon. Meant to say that from the browser perspective, my intent is to keep pushing out new revisions, with the assumption that we auto-update and will not have old versions lying around to deal with, and if the connection fails you have to deal with that case anyways b/c of proxies, so you have to have fallback either way. As long as the server can fail a mismatched (i.e. old) client, this shouldn't be an issue.
I already agreed with jat on not prefixing (in comment 17). So don't get me wrong here, I'm not trying to drag this out in an academic setting. If a server failing a mismatched client is good enough, triggering some non-WS fallback code in the client, then there must not be enough downrev clients to be worth supporting. But this depends on many things not in Google's control, even if Chrome is always updated to the latest protocol version promptly. The question comes down to this: what is the update story for other browsers? Who knows, but we can't settle that here in a bugzilla bug, or dictate it, and it is potentially (like, next year, once Firefox 4 is out in numbers) far from an academic question. /be
(In reply to comment #32) > The two options that we are choosing between are: > > * Don't prefix. Break existing content once we upgrade the protocol, unless > they take steps to support both protocols. > * Do prefix. Support existing and new content for as long as we feel the need > to. Only once we decide to drop the old protocol will we break existing > content or force them to take steps to support both protocols. FWIW, I don't see Opera supporting two versions even if we do prefix.
Hi... I wrote a C library supporting websocket serving for an embedded device. I tried it on Firefox 4.0b6 on Linux and Chrome; it works on Chrome OK using the -76 scheme but canvas update is broken there at the minute. Firefox completes the handshake but never receives data. I tried the -02 scheme but that doesn't solve the Firefox "no data" issue either. Anyway I just wanted to suggest why not get the browser to indicate its websocket protocol level it supports in the headers? It will automate simple support for several protocol versions that might be in the field (I don't mean selection of named protocols like "chat" inside websocket, but if it is -75, -76, -00, -01, -02, etc). Otherwise it seems this nice protocol's adoption might get crippled by counting on all servers to follow uplevelling protocol versions at the same speed as installed browsers... it seems a recipe for end-user disappointment going on.
(In reply to comment #38) > Hi... I wrote a C library supporting websocket serving for an embedded device. > I tried it on Firefox 4.0b6 on Linux and Chrome; it works on Chrome OK using > the -76 scheme but canvas update is broken there at the minute. Firefox > completes the handshake but never receives data. I tried the -02 scheme but > that doesn't solve the Firefox "no data" issue either. Please file a bug for this, hopefully with a testcase. CC me to the bug, please. The problem might be in Firefox or in the server implementation. Firefox supports -v76, not -02 (nor -03 or whatever is the latest IETF draft).
Sure. I added a simple testcase you can get from my git, and made bug #608249 Thanks for taking an interest.
Given the discusion here, I'm going to make a call on this. Reopen if absolutely necessary.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
I take it by the WONTFIX that the decision is not to prefix then?
Yes, the current status-quo is unprefixed.
based on virtual hallway conversation from just last night, jason is putting the prefix patch together so we can put this to bed for now.
Assignee: nobody → jduell.mcbugs
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
"Put this to bed" meaning what? I do not believe we *should* fix this bug, and apparently neither does brendan, which is why I marked it WONTFIX. Are you saying we should fix it, and if so by what logic?
I just took a poll of interested parties (biesi, bz, sicking, jst, patrick), and we're all in favor of prefixing. Note that this includes the necko owner and both peers. In a nutshell, we think that since 1) we know we're going to be switching to a new, incompatible protocol; and 2) we're not going to want to continue supporting the old one, since it's known to be insecure, we should prefix for now with 'x-ws{s}', and then remove support for the old protocol when we ship the new one.
Not to stir up trouble, but if the protocol is going to change to be incompatible, and there are security issues with the current one, have we considered just removing it for the time being?
I'm not aware the security issues you're talking about.
I was referring to comment 46: "we're not going to want to continue supporting the old one, since it's known to be insecure."
Clarification: it seems there isn't a security issue (I think I got confused with some v75-v76 changes). The issue is the protocol incompatibility issue, esp. since dynamic server-side detection of which protocol version is in use may not be easily possible. "Consensus" on this issue seems to be softening rapidly. Come chat on #content :)
(In reply to comment #49) > I was referring to comment 46: "we're not going to want to continue > supporting the old one, since it's known to be insecure." There are concerns in the IETF working group about the ability of -76 (or for that matter ietf -01 -> -03) to accidentally allow an attacker the ability to smuggle arbitrary HTTP requests routed from the browser especially via any HTTP/1.0 proxies that might be in the path. Last I checked, it was mostly theoretical but pretty convincing. the working group was considering a significant protocol change where every byte on the wire that could be influenced by the javascript be masked in some way to prevent the smuggling.. I am a touch out of date on my working group mail by a little bit - so maybe this isn't the latest news. If interested look in the archives for adam and eric's handshake proposal that they made a google doc, it outlines the attack.
I am still not sure what prefixing the scheme adds. At the point a WebSocket spec is finalized, existing servers will still support v76 since the majority of browsers will be using that version. Those servers will probably start being changed to support both the final version and v76 (probably via heuristics). If the JSAPI uses a prefixed scheme, then developers will have to use two different schemes depending on what browser the user is running, while their server will be the same (once it is upgrade to support the final spec). I don't see that prefixing the scheme does anything but make the developer have to sniff the browser version and choose different schemes. If instead, ws/wss means whatever version the browser currently supports whether v76 or the final version, then the only thing that needs to change is upgrade the server to support the final version.
I'm still failing to see what prefix the protocol actually achieves, anyone using WebSockets is likely to know that they are currently an experimental / draft protocol. Also, by adding the x- to the protocol in the DOM API, it doesn't actually change anything in the communication layer to describe versions. All that prefix means is that code that currently works on other draft-75 or draft-76 implementations will not work in firefox without modification, which would possibly have a similar effect to not supporting WebSockets at all. There's no reason to deliberately add in a complication/quirk to the browser. As for detecting changes, you can easily detect server side differences between draft-75 and draft-76 using the sec-* headers, and as for any future drafts, I believe the handshaking mechanisms will be changing post draft-ietf-03, which means you'll be able to detect the version of the protocol in that case too.
> Those servers will probably start being changed to support both the final > version and v76 (probably via heuristics). This is the part that doesn't make sense. If it were possible for servers to transparently and correctly work with both the old and the new version without resorting to UA sniffing, I think that's a clear case for not prefixing. But on IRC the consensus seems to be that the server would not be able to detect the different protocol versions.
(In reply to comment #54) > If it were possible for servers to > transparently and correctly work with both the old and the new version without > resorting to UA sniffing, I think that's a clear case for not prefixing. This is something which isn't clear yet, AFAIK. The handshake of the protocol may, probably will, change.
The point is that the servers will have to because there are a mix of user agents out there. For example, Jetty already supports multiple versions of the WebSockets drafts. I suspect that there will be some clear signal available to the server that the client is running the final version of the spec rather than v76/etc, if for no other reason than a number of people involved in the discussions are implementing WebSocket servers. As long as some UA isn't supporting every draft or proposal along the way (so they just support a subset of v75, v76, v03, and the final spec), I am confident that the server will be able to tell which version the client is using if it wishes to support multiple versions. Going forward, there is a clear bias against adding versioning information in the final protocol, with the plan being making use of defined extensibility mechanisms which the server is free to ignore. If we ever get to having to make an incompatible change in the future, we can have the argument then about adding versioning information to the handshake.
(In reply to comment #54) > This is the part that doesn't make sense. If it were possible for servers to > transparently and correctly work with both the old and the new version without > resorting to UA sniffing, I think that's a clear case for not prefixing. But on > IRC the consensus seems to be that the server would not be able to detect the > different protocol versions. It is possible to have the server adapt to different client protocol levels. The standard allows any kind of extra headers to be present during the handshake. All that's needed is to also send a header like x-websockets-client-protocol-version: 76 from the browser additionally, during the handshake, and the server can tag the connection as being of that vintage, or reject the handshake because it can't talk the needed version.
Current versions of the protocol do include a version (sec-websocket-draft:) That said, I would strongly discourage any browser from continuing to ship -76. Adam Barth and others have done research which shows that it does open up cross protocol attacks. That's why we're having so much fun debating the handshake right now. We are currently updating Chrome to -03 which still has some cross protocol attack issues, but at least breaks the expectation that -76 will continue to live. It should die. As soon as possible.
OK, so we should probably update to the -03 protocol (Patrick tells me this should be doable within a two week timeframe). I'll open a bug for that. But I still think we'll want to prefix even if we support -03. Why? We still know the protocol is going to break after -03. And assuming server-side sniffing is possible (it sounds possible--please comment if you have reasons to believe otherwise), we still have the problem that if web sockets become "too popular to break", browsers will have to wait until all servers upgrade in order to upgrade to a post-03 version. That's a recipe for stasis. (Or we'd have to do something gross and slow like try the new protocol, then fall back to -03 if it fails). Having a prefix would at least give us a way to know which version of the protocol a server expects, so we could easily/efficiently support both if that's what has to happen (if not, of course, we can just ditch support for older versions). Until such time as the web sockets spec is stable (or we at least have a version we're willing to live with as a de-facto standard), I don't see how we avoid the server upgrade issue, and I think we should prefix (possibly even with a version, like "x-ws-03://"). At this point I'd also be totally fine with not shipping ws at all in FF 4. Given the protocol instability, it's mainly an experimental toy, and the risk of a broken version becoming a de-facto standard may outweigh being able to check-off another "HTML 5 support" box on the marketing slides.
Added bug 611127 for upgrade to -03 issue.
With the extra header the browser can send (sec-websocket-draft: Ian mentioned) then unless the whole HTTP headers -> Websocket protocol upgrade handshake concept changes it'll be possible for servers to do the right thing based on what the client reports; they'll be able to serve 76 to 76 clients and 03 to 03 clients and so on at the same time. Which is great because then there'll be 04 or whatever clients to worry about and it can cope. This idea of changing ws:// and wss:// to have x- and protocol version suffixes makes all this transport protocol stuff visible up in javascript land when in fact the functionality is the same up there between -76 and -03, and is going to enforce people making a bunch of defensive weird code trying to ask for the right kind of name. It needlessly creates a new kind of quirk to stress over. It seems inappropriate because the situation is more like a web page should not have to know or care if it is on HTTP 1.0 or 1.1 transport. sec-websocket-draft: is enough to deal with all that unless the websockets javascript API itself changes; it just need to add the sec-websocket-draft: with the version the browser likes.
(In reply to comment #59) > Why? We still know the protocol is going to break after -03. And assuming > server-side sniffing is possible (it sounds possible--please comment if you > have reasons to believe otherwise), we still have the problem that if web > sockets become "too popular to break", browsers will have to wait until all > servers upgrade in order to upgrade to a post-03 version. That's a recipe for > stasis. (Or we'd have to do something gross and slow like try the new > protocol, then fall back to -03 if it fails). Having a prefix would at least > give us a way to know which version of the protocol a server expects, so we > could easily/efficiently support both if that's what has to happen (if not, of > course, we can just ditch support for older versions). > > Until such time as the web sockets spec is stable (or we at least have a > version we're willing to live with as a de-facto standard), I don't see how we > avoid the server upgrade issue, and I think we should prefix (possibly even > with a version, like "x-ws-03://"). > > At this point I'd also be totally fine with not shipping ws at all in FF 4. > Given the protocol instability, it's mainly an experimental toy, and the risk > of a broken version becoming a de-facto standard may outweigh being able to > check-off another "HTML 5 support" box on the marketing slides. I and others have already given the reasons why we think exposing the protocol differences to JS code is a bad idea, so I won't repeat those. I don't know where a developer writing WebSocket code and deploying it before the spec is final would get the idea that it isn't going to change. The developer of the client codelikely controls the server as well (even in the case of a shared provider, they could run something like pywebsockets on Apache), so they can control when it upgrades. Putting a note in the release notes like "This version supports the v76 WebSocket draft, and will be upgraded to the final spec when it is available, which will break any servers which do not support the final version. Use at your own risk." should be sufficient. I think the criteria for shipping a new version is not when there are no older servers still present, but rather when the spec is finalized. That will force developers to upgrade the servers if they want current browsers to keep working.
Everything below is with my DOM and Necko peer hats both on. > I don't know where a developer writing WebSocket code and deploying it before > the spec is final would get the idea that it isn't going to change. Developers generally assume that a browser's behavior isn't going to change. We have been burned by that too many times to count; assuming they will assume anything else is simply wishful thinking, sadly. This applies to web developers with 100% certainty; I would put the certainty for websocket server developers at 90+%. I think what people are being unclear on here is that the whole point is that we do NOT want to constrain the final version of the protocol by what we end up shipping and do NOT want to pollute the final name with an incompatible implementation. If we don't prefix, people _will_ write code to our current impl, and then when we change the impl their code _will_ break in subtle ways. Worse yet, they won't be able to fix things easily so that their code works in both the old Firefox version and the new one and other browsers that are also implementing websocket, without resorting to server-side UA sniffing or some such. And given that most people who do such sniffing completely fail to do it right, we do NOT want to encourage it. Prefixing means the breakage will be very obvious, and the migration path will be very clear: try the prefixed thing, and if unsupported try the standard thing. Yes, that means more client-side gunk if you want to support old browser releases. Whether you want to do so is up to you, but at least this way the option is present in a reasonable way. Jason, if we suspect we will be implementing other versions between what we ship in Fx4 and final, then I guess it makes sense to put the version in the prefix. Otherwise, I wouldn't bother.
(In reply to comment #63) > If we don't prefix, people _will_ write code to our current > impl, and then when we change the impl their code _will_ break in subtle ways. > Worse yet, they won't be able to fix things easily so that their code works in > both the old Firefox version and the new one and other browsers that are also > implementing websocket, without resorting to server-side UA sniffing or some > such. And given that most people who do such sniffing completely fail to do it > right, we do NOT want to encourage it. No. The DOM API for websockets has not changed and does not change in the different versions, the DOM API is independent of the network and protocol. So, in order to detect the version of the WebSocket protocol from a Server with which a client is connecting, the server checks for the existence of certain headers on the initial request. This is not UA sniffing and allows for websocket servers to easily accept multiple different versions of protocol clients. Example: Node-WebSocket-Server, which is being used by Mike Shaver at Mozilla automatically detects the various protocol versions and adapts per connection accordingly. (I should know it does, as I'm the author of it.) By making the Mozilla WebSocket implementation require users to initialise connections with: new WebSocket("x-ws://..." [, subprotocol]); it means that Mozilla clients will be incompatible with all existing WebSocket client connections, which don't prefix. This means that we'll actually have to rely on client-side UA sniffing to specially handle the "x-" addition to websocket URL's in Mozilla based clients. This is something we should really NOT do.
(In reply to comment #63) > Worse yet, they won't be able to fix things easily so that their code works in > both the old Firefox version and the new one and other browsers that are also > implementing websocket, without resorting to server-side UA sniffing or some > such. If the scheme is not prefixed, all they have to do for the exact same JS code to work on old FF, new FF, and other browsers is simply have their server speak the different versions in use, presumably v76, v03, and the final one. > And given that most people who do such sniffing completely fail to do it > right, we do NOT want to encourage it. The problem is you are explicitly requiring them to do sniffing. If they want their WebSockets app to work on FF4, they have to use a different scheme than elsewhere, so they have to detect that they are running on FF4. *Maybe* if all browsers had used the prefix from the beginning it would make sense (though developers would still have to code around the transition), but at this point the horse is out of the barn. There are lots of browsers out in user's hands implementing old versions of the protocol, and they are going to get upgraded slowly and sporadically. Servers are already going to have to deal with multiple versions in clients and the JS API is the same, so making the JS code have to deal with different protocol versions rather than leaving it up to the client and server just gives more places for things to go wrong. I think everyone's positions are entrenched at this point as we keep saying the same things over and over, so whoever is going to decide should just go ahead and make the decision.
Shaver probably has an opinion, as Micheil suggests in comment 64. I think the last two comments' point, that Firefox 4 using a prefix (while other browsers do not prefix) requires the very user-agent sniffing that such prefixing is supposed to avoid, is a good one. Content negotiation via the Accept: header is pretty much dead, but HTTP 1.0 to 1.1 worked under the JS and URI-scheme layers. WebSockets may well be able to do the same. It does not seem to me inevitable or even likely that failure to prefix will create an entrenched v76 or v03 or whatever version that fails to advertise its draft-iness and that cannot be handled by server WS implementations without user-agent sniffing. I wanted a version somewhere, we have one in the protocol layer, so I'm still with jat, et al. /be
You are assuming that people will correctly implement websocket servers which work both with whatever version we ship in FF4, and with whatever version we ship in next version of firefox. Our experience is that people are not that good. What seems more likely is that we'll end up being constrained in how we develop the final protocol such that it's either backwards compatible with what we ship in FF4, or that we for next release come up with some new scheme so that people can selectively opt in to the new protocol. Prefixing is simply planning ahead so that the new scheme can be "ws". Note that it'll likely be many months, our last few releases have taken between 6 and 12 months. It seems unlikely to me that people will remember for that long that the protocol isn't stable. I'm sure everyone in this bug are comitted and educated enough that they'd do things correctly. It's the people not following this bug that I'm worried about. Also, no-one is asking that you do browser sniffing. The recommended code would go something like: var w; try { w = new WebSocket("ws://...", ...); } catch (ex) { w = new WebSocket("x-ws://...", ...); } doFunStuffWith(w); Another possible alternative would be to update the protocol in a 4.0.x dot-release. If we could commit to doing that already now I would be more fine with shipping unprefixed as there would be less time for people to deploy non-experimental support for websockets. But breaking backwards compat in a dot-release is something we've never done before. This doesn't mean that we shouldn't ever do it in the future, but it does mean that we have no experience in how such things would work out in reality.
(In reply to comment #67) > You are assuming that people will correctly implement websocket servers which > work both with whatever version we ship in FF4, and with whatever version we > ship in next version of firefox. > > Our experience is that people are not that good. If servers do not support older (or newer) versions then the connection is just refused and closed, no harm done, the user just doesn't get to use websockets. Although, as already stated the main servers currently in use (node, ruby, python and Go) all support multiple versions of the protocol at once. As for the node-websocket-server, I explicitly coded this in, although have given the option to disable acceptance of certain protocol versions, if the end-developer so chooses. > What seems more likely is that we'll end up being constrained in how we develop > the final protocol such that it's either backwards compatible with what we ship > in FF4, or that we for next release come up with some new scheme so that people > can selectively opt in to the new protocol. > > Prefixing is simply planning ahead so that the new scheme can be "ws". No, if the server does not handshake correctly with the client, the the browser simple considers the connection a non-connection and closes the socket, as stated in the previous replies. > Note that it'll likely be many months, our last few releases have taken between > 6 and 12 months. It seems unlikely to me that people will remember for that > long that the protocol isn't stable. I expect that we will probably be beginning to phase out mainstream support for draft 75 by the middle of 2011, and draft 76 by the end of 2011. That should give Mozilla ample time to be able to release any updates or changes. (That's based on speculation as to what browsers/protocol versions are currently being used, considering Chrome, Chromium and Safari generally automatically update ). > I'm sure everyone in this bug are comitted and educated enough that they'd do > things correctly. It's the people not following this bug that I'm worried > about. Yes, correct, anyone who isn't implementing servers correctly will suffer, however, we should be documenting this enough so that they don't suffer. That said, if 5% of servers aren't implemented correctly, then we should NOT make it difficult for the remaining 95% of servers to work correctly. > Also, no-one is asking that you do browser sniffing. The recommended code would > go something like: > > var w; > try { > w = new WebSocket("ws://...", ...); > } > catch (ex) { > w = new WebSocket("x-ws://...", ...); > } > doFunStuffWith(w); > That would still require extra or duplicate code, and as the DOM API is not likely to change and hasn't already changed between versions, then it should not be changed just in one case for one browser. The only time that the DOM API is likely to change is when JavaScript gets native binary support (ByteArray and co, which is currently being worked on.) > Another possible alternative would be to update the protocol in a 4.0.x > dot-release. If we could commit to doing that already now I would be more fine > with shipping unprefixed as there would be less time for people to deploy > non-experimental support for websockets. > > But breaking backwards compat in a dot-release is something we've never done > before. This doesn't mean that we shouldn't ever do it in the future, but it > does mean that we have no experience in how such things would work out in > reality. I don't think you'd necessarily be breaking backwards compat in a dot release in this case, as it's noted that it's a protocol under active work and the changes are often for security enhancements. Is it okay to break backwards compatibility with servers for the sake of security? I'd say so.
(In reply to comment #68) > (In reply to comment #67) > > You are assuming that people will correctly implement websocket servers which > > work both with whatever version we ship in FF4, and with whatever version we > > ship in next version of firefox. > > > > Our experience is that people are not that good. > > If servers do not support older (or newer) versions then the connection is > just refused and closed, no harm done, the user just doesn't get to use > websockets. No, the *author* doesn't get to use it. The user gets to not use the wesite that they want to use. Or, if they are tech savvy enough, gets to downgrade to an older version of firefox, which doesn't have all the new niceness that we've added to the next release. > Although, as already stated the main servers currently in use (node, ruby, > python and Go) all support multiple versions of the protocol at once. You must have missed the messages above where it wasn't clear that this was possible for all future versions of the protocol. That's ok, you can go back and read them now. > > I'm sure everyone in this bug are comitted and educated enough that they'd > > do things correctly. It's the people not following this bug that I'm > > worried about. > > Yes, correct, anyone who isn't implementing servers correctly will suffer, > however, we should be documenting this enough so that they don't suffer. That > said, if 5% of servers aren't implemented correctly, then we should NOT make > it difficult for the remaining 95% of servers to work correctly. It's not the server authors I'm concerned about. They have the power to do something about their situation. My concern is the users trying to use servers that break, they don't have that luxury.
(In reply to comment #69) > No, the *author* doesn't get to use it. The user gets to not use the wesite > that they want to use. Or, if they are tech savvy enough, gets to downgrade to > an older version of firefox, which doesn't have all the new niceness that we've > added to the next release. Um. No, the end user does not get to use the site as the site's author would have intended due to the lack of the ability to create a websocket connection. Just like a user trying to use websockets on an iOS device at the moment. > You must have missed the messages above where it wasn't clear that this was > possible for all future versions of the protocol. That's ok, you can go back > and read them now. Currently it is looking highly likely that it will be possible to detect the various versions. I'm pretty sure draft-03 adds another header to the initial request or changes something therein, in which case we can detect it. > It's not the server authors I'm concerned about. They have the power to do > something about their situation. My concern is the users trying to use servers > that break, they don't have that luxury. If your server that you are using breaks, then you have a few options: 1) you fork the code to the server and make it work / try to make it work. 2) you report a bug to the project of which is that websocket server implementation complaining that it does not work properly. I'm thinking that's quite fine. And I'm still against any changes to the DOM API in only one specific browser.
> If the scheme is not prefixed, all they have to do for the exact same JS code > to work on old FF, new FF, and other browsers is simply have their > server speak the different versions in use, presumably v76, v03, > and the final one. By this logic, we could cook up a new HTTP 2.0 spec that is incompatible with HTTP 1.1, write a server that knows how to detect between the two, and change Firefox to speak HTTP 2.0 instead of 1.1. Why would this never happen (or at best, take a really long time)? Because every HTTP server out there would have to be updated before we could change Firefox to use 2.0, else we'd break every site still using 1.1 only. We're facing the same issue here. > If servers do not support older (or newer) versions then the connection is > just refused and closed, no harm done, the [web page] just doesn't get to use > websockets. It's true that this does mitigate the problem somewhat: assuming that sites will for the near future need to be written to fallback if websockets aren't present anyway, then we're talking about performance degradation if a server can't speak a newer version of ws, rather than total failure. But performance degradation could still be a fairly large obstacle to upgrading if it causes enough users to scream. And note that this performance degradation isn't just a matter of "ws not available, so instantly fall back to using long-polling": we'd actually first have to connect to the server (since all we'd know is that it wanted "ws", not which version), and have it fail. Only after that network round-trip could we either 1) throw an exception (and have the page do long-polling), or 2) try to fallback to using an older ws protocol version. (With prefixing we'd immediately be able to either throw an error or fallback to the older version of the protocol). > I'm still against any changes to the DOM API in only one specific browser. Well, Opera has indicated (comment 22) they may also prefix if we do... > we keep saying the same things over and over Indeed. I'll stop beating the dead horse now. Who gets to make the call? Biesi? Shaver? Brendan? Mitchell?
(In reply to comment #67) > var w; > try { > w = new WebSocket("ws://...", ...); > } > catch (ex) { > w = new WebSocket("x-ws://...", ...); > } > doFunStuffWith(w); Glad to hear x-ws-<version>:// has gone out of fashion because the javascript for that would be much uglier, and break the script every time the browser updates to a websocket protocol draft the script doesn't know to explicitly try. (Side note, if you want your script to automatically work in a wss:// context too, there's more code needed already but no worries). However, the above code requires the servers to participate in this x-ws scheme. By default what will happen is the websocket server on the other end will always say OK to ws:// (since that is in the standard) and you never reach x-ws://. So the above code and x-ws:// achieves nothing at all. From the server side, the things to do seem like this to me: 1) Emit sec-websocket-draft: 03 on the next update to this code; server-side guys can treat its omission as being -76 2) Leave it at just ws:// and wss:// and the client and server negotiate based on sec-websocket-draft: issued by the client... you either get a connection or not based on what the client wants and what the server is willing to work with. (Because you can only stick one draft number in there, the browser itself could retry underneath a single "new WebSocket()", say first with 03 and then with 76 before giving up, if the client supported multiple drafts.) To be clear javascript-land would stay unchanged from now. 3) Later, if the standard moves on and breaks things in javascript land so that workarounds are required, THE STANDARDS should define a way to be able to query the effective connection protocol level from javascript-land to enable surviving that in your script... as opposed to imposition on the turf of the standards by a client implementation.
> THE STANDARDS should define a way to be able to query > the effective connection protocol level That would be great. Except that there is no standard yet, just a series of working drafts, with incompatible handshakes, and no plan for an upgrade mechanism that doesn't simply cause servers using older handshakes to barf on newer ones. It's not like HTTP, where we can ask for 1.1 and an older server can still service the request but downgrade the version to 1.0. > The browser itself could retry [with older draft version(s) of the protocol] Yes, I agree, and this is the most plausible justification I've seen for rolling out w/o prefixing. But I still have the same performance concerns I mentioned in commment 71. Can you think of another Internet protocol that has used the upgrade path of "try the new version, and reconnect with a new TCP socket (per older version) until you find a version that the server likes"? I can't. I suppose since web sockets are generally meant to be somewhat persistent in a web page, we'd only hit the extra RTTs at connection time. So this might be tolerable. I'm trying this idea on for size. > By default what will happen is the websocket server on the other end > will always say OK to ws:// (since that is in the standard) and you > never reach x-ws://. Correction: for now, Mozilla would barf at "ws://", but then connect to the server when it saw 'x-ws', using whatever draft protocol version it associated with x-ws. The server would never see 'x-ws' on the wire. When the spec is finalized, Mozilla would recognize 'ws' and use the final protocol; if the server didn't speak it yet, the connection would fail and we'd then try to talk to it using the older x-ws protocol (unless/until we remove support for it). (If server authors wanted to guard against an extra-round trip in the case that they browser upgrades the protocol before their server does, they could ship the page with 'x-ws-version' with the most recent version they know that both the server and the UA support. Extra work, but probably appreciated by power users.) > Glad to hear x-ws-<version>:// has gone out of fashion because the > javascript for that would be much uglier I still think we ought to use 'x-ws-version.' Especially if we we can't get -03 in the codebase before FF4. But even then, it's not implausible that there'll be some new reason why everyone should upgrade to a more secure but still draft version of the protocol, and then we'll still have this same problem.
(In reply to comment #73) > > THE STANDARDS should define a way to be able to query > > the effective connection protocol level > > That would be great. Except that there is no standard yet, just a series of > working drafts, with incompatible handshakes, and no plan for an upgrade > mechanism that doesn't simply cause servers using older handshakes to barf on > newer ones. It's not like HTTP, where we can ask for 1.1 and an older server > can still service the request but downgrade the version to 1.0. Well what happened before -76 is ancient history. 76 and 03 seem to have compatible handshakes. I agree it's surprising that this draft version header arrived so late and that changes in the future are the issue. If the post-handshake protocol changes, as it has been doing, that's not really a problem now the draft ordinal the connection is working to is part of the handshake and the amount of code for that is small enough to keep multiple versions around. It only becomes painful if multiple incompatible kinds of handshake are in the wild, it's at that point the first connection can fail and you are left to infer you need to have another try on a new connection with the other kind of handshake. But that doesn't seem to be the case today with -76 and -03 (unless I missed something). > > The browser itself could retry [with older draft version(s) of the protocol] > > Yes, I agree, and this is the most plausible justification I've seen for > rolling out w/o prefixing. But I still have the same performance concerns I > mentioned in commment 71. Can you think of another Internet protocol that has > used the upgrade path of "try the new version, and reconnect with a new TCP > socket (per older version) until you find a version that the server likes"? I > can't. If I understood it, it'll only need more than one try in the case that a new draft comes out with an incompatible handshake and a browser was not updated to it yet wants to talk to a server that has been updated (and defaults) to it. When the guy updates his browser again the new protocol will be the first one tried and it'll work in one hit. If there is a latest supported version mismatch but the handshake is compatible, then the server will work with the first try again (assuming the server has the browser's latest supported version in its armoury). > I suppose since web sockets are generally meant to be somewhat persistent in a > web page, we'd only hit the extra RTTs at connection time. So this might be > tolerable. I'm trying this idea on for size. I think due to the above this is a hit that only happens transitionally between incompatible handshake versions; as browsers catch up the probability of needing more than one try starts to go away again. > > By default what will happen is the websocket server on the other end > > will always say OK to ws:// (since that is in the standard) and you > > never reach x-ws://. > > Correction: for now, Mozilla would barf at "ws://", but then connect to the > server when it saw 'x-ws', using whatever draft protocol version it associated > with x-ws. The server would never see 'x-ws' on the wire. When the spec is I see. > > Glad to hear x-ws-<version>:// has gone out of fashion because the > > javascript for that would be much uglier > > I still think we ought to use 'x-ws-version.' Especially if we we can't get > -03 in the codebase before FF4. But even then, it's not implausible that > there'll be some new reason why everyone should upgrade to a more secure but > still draft version of the protocol, and then we'll still have this same > problem. The x-ws-version thing would need a loop in Javascript with an array of version strings to try or what? Then if the browser updates to a new version and the script doesn't update that new version doesn't get tried? Tainting the javascript with knowledge about the versioning in the protocol name seems the wrong direction to me, it's like making the web deal with http1.1:// URLs as well as http:// ones. It should all be shoved under a carpet below that one.
Assignee: jduell.mcbugs → nobody
Component: DOM → Networking: WebSockets
QA Contact: general → networking.websockets
Assignee: nobody → jduell.mcbugs
Target Milestone: mozilla2.0b7 → mozilla2.0b8
So apparently it's hard to get consensus on prefixing the scheme... Independent of the outcome of that, I think it's still a good idea to whine in the error console whenever the WebSocket constructor is invoked. No? (Maybe someone should open a separate bug about that?)
We wouldn't block beta8 for this. I'm going to stick it in betaN, as if we do this we'd likely not just spring it in final.
blocking2.0: beta8+ → betaN+
LegNeato, I strongly disagree. This is something we should have dealt with before feature freeze in beta7, it's web-visible, and it's something that we need to make a decision on *now*. This not only affects extension compatibility, but website compatibility for a new feature which the webdev-outreach team has been talking about a lot.
See bug 616733: Completely disable and/or remove WebSockets due to security problems
See bug 616733. We're going to disable the websockets protocol until we get a new version so the prefixing issues are moot.
Status: REOPENED → RESOLVED
blocking2.0: betaN+ → ---
Closed: 14 years ago → 14 years ago
Resolution: --- → WONTFIX
> See bug 616733. We're going to disable the websockets protocol until we get a > new version so the prefixing issues are moot. Since we're disabling WebSockets with a pref means that we need to avoid exposing the API with the standard name. See Bug 616733 Comment 12. So, I think prefixing needs to be done at the same time WebSockets gets disabled.
Blocks: 616733
Severity: normal → blocker
blocking2.0: --- → ?
tracking-fennec: --- → ?
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
my opinion is that there is nothing to do here - Its not like there isn't a failure path that needs to be dealt with in any network protocol anyhow.
(In reply to comment #81) > my opinion is that there is nothing to do here - Its not like there isn't a > failure path that needs to be dealt with in any network protocol anyhow. I doubt every wrapper library that sees WebSockets support by feature detection will fall back to some other protocol when the first WebSockets call fails. More likely, they will retry the WebSockets call that failed, right/
(In reply to comment #81) > my opinion is that there is nothing to do here - Its not like there isn't a > failure path that needs to be dealt with in any network protocol anyhow. Failure path is fine, throwing an unexpected error is not. If I test for WebSockets, then use the constructor and it throws an error (when it is not supposed to) that's not cool. People don't try{}catch{} everything (which I'm not 100% sure is even possible for DOM_SECURITY_ERRORs).
(In reply to comment #83) > (In reply to comment #81) > > my opinion is that there is nothing to do here - Its not like there isn't a > > failure path that needs to be dealt with in any network protocol anyhow. > > Failure path is fine, throwing an unexpected error is not. If I test for > WebSockets, then use the constructor and it throws an error (when it is not > supposed to) that's not cool. People don't try{}catch{} everything (which I'm > not 100% sure is even possible for DOM_SECURITY_ERRORs). then what do you do when network.websockets.enabled = false? The effect is identical.
(In reply to comment #84) > then what do you do when network.websockets.enabled = false? The effect is > identical. You don't worry about power users that are snooping around about:config (and "voiding their warranty") :). That's how this works for everything else (e.g. audio/video, svg, etc.). Web developers trust the default value, beyond that, the user that makes the change probably knows what is going wrong on the website.
If WebSockets are disabled, it would seem better to not even expose the WebSockets symbol, so that code that tests for support by just seeing if the constructor exists will try what they would on a browser that never had WebSocket support.
> then what do you do when network.websockets.enabled = false? The effect is > identical. My point is that window objects shouldn't have a WebSocket member (when WebSockets is disabled) in B8. If there's another solution that has that effect then we can close this bug and implement the other solution.
> My point is that window objects shouldn't have a WebSocket member. I agree.
I agree that the property needs to go away. But this bug is really about just the protocol, so lets fix the property in bug 616733 instead. I r-'ed the patch there for now. So putting this back to WONTFIX
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → WONTFIX
Assignee: jduell.mcbugs → nobody
blocking2.0: ? → -
tracking-fennec: ? → ---
You need to log in before you can comment on or make changes to this bug.