5 ms·

WebSocket Protocol Updated

41 points by raju 16y ago

thamer 16y ago
Note: this means that with the new version of Chromium, none of the web applications using Web Sockets will work. The connection will fail with an error about a protocol mismatch.
- axod 16y ago
  It's pretty poor they couldn't work out how to make things backward compatible. Oh well, another job for me to do then... I just love reading through a billion pages of a spec to find the actual data I need which could have been written in a single page spec. bah. Would it be so hard for them to put the 'answer' somewhere? eg "To make your server work again, change "X" to "Y" in the headers". I'll say it again, the spec is simply insane. 18. Let /number_1/ be a random integer from 0 to /max_1/ inclusive. Let /number_2/ be a random integer from 0 to /max_2/ inclusive. EXAMPLE: For example, 777,007,543 and 114,997,259. 19. Let /product_1/ be the result of multiplying /number_1/ and /spaces_1/ together. Let /product_2/ be the result of multiplying /number_2/ and /spaces_2/ together. EXAMPLE: Continuing the example, 3,885,037,715 and 1,034,975,331.
  - jeiting 16y ago
    When you do figure it out post it on HN ;)
    - axod 16y ago
      Sure :) I'll try and implement the changes in the next day or 2 and write up a summary of the differences. So far looking over the spec, it's just bizarre incompatible silly changes that don't really improve much.
  - zokier 16y ago
    Backward compatibility to what? They are in progress of creating the first version now.
    - axod 16y ago
      Websockets have been in Chrome and in use for 6 months+. http://news.ycombinator.com/item?id=989680 http://news.ycombinator.com/item?id=989680 We have thousands of users using WebSocket every day. So this is kind of a pain in the neck.
      - mike-cardwell 16y ago
        This is what you get when you use an unfinished protocol which everybody knows is subject to change. Guess what, it might change again... They're still researching what is the best way to do this. You should be happy they're making improvements to the protocol you're using. If they say, "This is the finished product and there will be no further incompatible changes," and then make a change which breaks your app. Then you have a right to complain.
        axod 16y ago
        I'm looking through the spec now. There don't seem to be any improvements. Just incompatible changes made in bizarre ways. I'll post a summary of the changes tomorrow. These sort of things often seem like they're massively over engineered. You could figure out the best way to do websockets in an afternoon without too much fuss. Nothing is ever 'finished'. It's just a pain to break backward compatibility that's all.
        carussell 16y ago
        These sort of things often seem like they're massively over engineered. Until you're the edge case who gets pissed off because they didn't make it flexible enough, or the boilerplate is arcane and doesn't really make sense with much of the normal use.
  - sp332 16y ago
    It looks like someone wrote an AI to convert code into English, and threw in one of their units tests too.
judofyr 16y ago
Is it possible to write a server which supports both versions?
- jerf 16y ago
  Based on their description, it sounds like a bad idea even if it is possible. Why would you want a fundamentally insecure protocol on your website? This is "draft" for a reason, and note this is not a final protocol, it's another draft. That's for a reason too. Don't expect your -76 server to last forever with no changes either.
  - axod 16y ago
    You shouldn't rely on any protocol like this being 'secure'. You should have other security in other places. So I don't think that's a valid reason really. It's possible to support both, and that's what I'll personally be doing with my own web server. The changes I've seen don't add any obvious extra security as such, just make it a little more difficult. edit: Please give clear references when you say "Fundamentally insecure protocol". That's pretty much totally unfounded. What type of security are you talking about?
    - jerf 16y ago
      "Please give clear references when you say "Fundamentally insecure protocol". That's pretty much totally unfounded. What type of security are you talking about?" Directly from the article: "introduces nonce-based challenge-response to protect from cross protocol attacks." In my experience, when people identify a possible security attack it's usually correct. (The solution can be another matter, but I'm not looking at this enough to have even an uninformed position.) The problem the sort of people working out a protocol like this have is missing ones that are possible, not pointing out ones that don't exist. If you're comfortable with unnecessarily insecure lower layers, more power to you. Don't expect plaudits from me. Or expect me to be taking security advice from you after casually disregarding things like "security in depth".
      - 16y ago
Kilimanjaro 16y ago
This is the beauty of the web, change the server code, then serve the new client code and done. Automagically updated. The client will never know what hit them.
- papachito 16y ago
  Actually no, it says you need a new version of chromium, so the client will know in that case.
Raphael 16y ago
Mibbit said... Sorry but the spec for this is just ridiculous. It's insane. It contains the code to parse HTTP headers, translated into english. You could easily condense this spec down to a couple of pages, and it'd actually be usable. Once again, sorry, but this is just ridiculous. June 3, 2010 10:31 AM

41 points by raju 16y ago

Note: this means that with the new version of Chromium, none of the web applications using Web Sockets will work. The connection will fail with an error about a protocol mismatch.

axod 16y ago
It's pretty poor they couldn't work out how to make things backward compatible. Oh well, another job for me to do then... I just love reading through a billion pages of a spec to find the actual data I need which could have been written in a single page spec. bah. Would it be so hard for them to put the 'answer' somewhere? eg "To make your server work again, change "X" to "Y" in the headers". I'll say it again, the spec is simply insane. 18. Let /number_1/ be a random integer from 0 to /max_1/ inclusive. Let /number_2/ be a random integer from 0 to /max_2/ inclusive. EXAMPLE: For example, 777,007,543 and 114,997,259. 19. Let /product_1/ be the result of multiplying /number_1/ and /spaces_1/ together. Let /product_2/ be the result of multiplying /number_2/ and /spaces_2/ together. EXAMPLE: Continuing the example, 3,885,037,715 and 1,034,975,331.
- jeiting 16y ago
  When you do figure it out post it on HN ;)
  - axod 16y ago
    Sure :) I'll try and implement the changes in the next day or 2 and write up a summary of the differences. So far looking over the spec, it's just bizarre incompatible silly changes that don't really improve much.
- zokier 16y ago
  Backward compatibility to what? They are in progress of creating the first version now.
  - axod 16y ago
    Websockets have been in Chrome and in use for 6 months+. http://news.ycombinator.com/item?id=989680 http://news.ycombinator.com/item?id=989680 We have thousands of users using WebSocket every day. So this is kind of a pain in the neck.
    - mike-cardwell 16y ago
      This is what you get when you use an unfinished protocol which everybody knows is subject to change. Guess what, it might change again... They're still researching what is the best way to do this. You should be happy they're making improvements to the protocol you're using. If they say, "This is the finished product and there will be no further incompatible changes," and then make a change which breaks your app. Then you have a right to complain.
      - axod 16y ago
        I'm looking through the spec now. There don't seem to be any improvements. Just incompatible changes made in bizarre ways. I'll post a summary of the changes tomorrow. These sort of things often seem like they're massively over engineered. You could figure out the best way to do websockets in an afternoon without too much fuss. Nothing is ever 'finished'. It's just a pain to break backward compatibility that's all.
        carussell 16y ago
        These sort of things often seem like they're massively over engineered. Until you're the edge case who gets pissed off because they didn't make it flexible enough, or the boilerplate is arcane and doesn't really make sense with much of the normal use.
- sp332 16y ago
  It looks like someone wrote an AI to convert code into English, and threw in one of their units tests too.

judofyr 16y ago

Is it possible to write a server which supports both versions?

jerf 16y ago
Based on their description, it sounds like a bad idea even if it is possible. Why would you want a fundamentally insecure protocol on your website? This is "draft" for a reason, and note this is not a final protocol, it's another draft. That's for a reason too. Don't expect your -76 server to last forever with no changes either.
- axod 16y ago
  You shouldn't rely on any protocol like this being 'secure'. You should have other security in other places. So I don't think that's a valid reason really. It's possible to support both, and that's what I'll personally be doing with my own web server. The changes I've seen don't add any obvious extra security as such, just make it a little more difficult. edit: Please give clear references when you say "Fundamentally insecure protocol". That's pretty much totally unfounded. What type of security are you talking about?
  - jerf 16y ago
    "Please give clear references when you say "Fundamentally insecure protocol". That's pretty much totally unfounded. What type of security are you talking about?" Directly from the article: "introduces nonce-based challenge-response to protect from cross protocol attacks." In my experience, when people identify a possible security attack it's usually correct. (The solution can be another matter, but I'm not looking at this enough to have even an uninformed position.) The problem the sort of people working out a protocol like this have is missing ones that are possible, not pointing out ones that don't exist. If you're comfortable with unnecessarily insecure lower layers, more power to you. Don't expect plaudits from me. Or expect me to be taking security advice from you after casually disregarding things like "security in depth".
    - 16y ago

Kilimanjaro 16y ago

This is the beauty of the web, change the server code, then serve the new client code and done. Automagically updated. The client will never know what hit them.

papachito 16y ago
Actually no, it says you need a new version of chromium, so the client will know in that case.

Raphael 16y ago

Mibbit said... Sorry but the spec for this is just ridiculous. It's insane. It contains the code to parse HTTP headers, translated into english. You could easily condense this spec down to a couple of pages, and it'd actually be usable. Once again, sorry, but this is just ridiculous. June 3, 2010 10:31 AM