Talk:WebSocket/Archive 1

List of Implementations
This list is very important! Instead of deleting we should find another solution for the WP:NOTLINK "problem".--141.69.60.24 (talk) 14:02, 8 June 2010 (UTC)


 * Nope. We should just follow the WP:NOTLINK policy. Also WP:V. AlistairMcMillan (talk) 00:59, 12 June 2010 (UTC)


 * You don't see the point. At the moment there is no other list like this. So just be patient until we found another solution.--141.69.60.24 (talk) 11:31, 14 June 2010 (UTC)


 * Please read WP:NOTLINK and WP:V. AlistairMcMillan (talk) 14:25, 14 June 2010 (UTC)


 * You two are so funny... @Mr IP: so tell us, what's your great solution? @AlistairMcMillan: we all read WP:NOTLINK and WP:V, but maybe it helps if you tell us a third time... But back to the problem: we need this list, what can we do? Create a list in style of List of XMPP client software--84.157.112.228 (talk) 19:25, 14 June 2010 (UTC)


 * Thanks for pointing out List of XMPP client software. Now marked for deletion.


 * On the subject of this article, Wikipedia is an encyclopaedia, not a web directory. There are many web directories. Go and recreate the list on one of them. AlistairMcMillan (talk) 22:31, 14 June 2010 (UTC)


 * Okay, I've read through WP:NOTLINK several times and it doesn't seem obvious at all to me that a page about a standard should not describe how widely implemented the standard is. It seems like "Who implements this standard?" is going to be at least the second most asked question by people visiting this page. But anyways, caniuse.com is the best "directory" site for this type of thing is. See: http://caniuse.com/#feat=websockets Kanaka (talk) 19:32, 16 June 2010 (UTC)


 * You want to mention in the article that the standard is widely implemented, then cool mention in the article that the standard is widely implemented. With appropriate citations that back up that claim, per WP:V. Sticking a long list of "me too" external links into the article doesn't prove that. AlistairMcMillan (talk) 21:37, 16 June 2010 (UTC)


 * You actually deleted the references to other Wikipedia articles and the "appropriate citations" too... The solution could have been to write an article for each implementation. But I will not spend any more time for this nonsense.--141.69.60.24 (talk) 11:05, 17 June 2010 (UTC)


 * Other Wikipedia articles are never to be used as sources. And most, if not all, of the external citations pointed to primary sources. And again, WP:PRIMARY sources are never to be used as sources either. AlistairMcMillan (talk) 15:48, 17 June 2010 (UTC)

Compatibility with HTTP 1.1
What is unclear from the article is whether the WebSockets protocol is actually backwards compatible with HTTP. More concretely: If a WebSockets-client sends a WebSockets upgrade header, will a regular HTTP 1.1-server correctly ignore the upgrade request without a fatal error, resulting in regular HTTP 1.1-communication between client and server? -- Ernstdehaan (talk)


 * There is no reason you would want this. The use cases are pretty much non-intersecting. –jacobolus (t) 01:35, 31 July 2010 (UTC)

Standardization
What is not clear from the article is that the current state of standardization is quite vague. Chrome already ships an implementation based on a certain version of the draft standard, but different drafts exist at different organizations (W3C and IETF). -- Ernstdehaan (talk)


 * The standard is as far as I know nearly the same. Ask Ian Hickson directly on IRC or shoot an email to the IETF’s mailing list about the spec if you want details. –jacobolus (t) 01:36, 31 July 2010 (UTC)

Lacking features
I read somewhere (I don't remember where, exactly) that the current draft of the WebSockets standard does not allow binary as well as full-duplex communication. Both are considered very nice to have, also by me. -- Ernstdehaan (talk)


 * This really isn’t the place for such a discussion. By the way, when you sign your posts you should use four tildes, so that a date is added. –jacobolus (t) 01:37, 31 July 2010 (UTC)

Problems with proxy poisoning
According to:

http://hacks.mozilla.org/2010/12/websockets-disabled-in-firefox-4/

and

http://www.ietf.org/mail-archive/web/hybi/current/msg04744.html

There are security problems with current implementations of Websockets and Mozilla and are disabling it

Sorry for not formatting correctly, just wanted to give you a heads up, feel free to edit/delete. —Preceding unsigned comment added by 80.216.62.107 (talk) 00:34, 9 December 2010 (UTC)

More detail about security vulnerabilities
The article mentions security vulnerabilities, but provides no detail regarding them. It would be very useful to add a section to the article explaining these security vulnerabilities. Gilly3 (talk) 22:50, 2 February 2011 (UTC)

The security implications come from the fact that old proxy might be prone to cache poisoning. Which means that an malicious request might be stored in a old proxy and this "poisoned" data is then delivered to some other client. . I *think* that the Problem is resolved with the completely new draft 06?213.188.126.2 (talk) 21:57, 11 April 2011 (UTC)


 * Talk about "new draft" should be taken off entirely. We may have text for "code implementing draft version x or before are vulnerable", but... the article as it is, for instance, misleads the reader to think that we're in draft version 6 when v7 is already available and v8 on its way. This is a draft in such a volatile development stage that really makes no sense in having the article as it is... 195.23.92.1 (talk) 15:47, 16 May 2011 (UTC)

Right but not very helpful
This article may be technically correct and especially correct for a technical manual, however, it is not very helpful in explaining what is a websocket and how it is used, or for what it is used. Someone should take of their geek hat, and try to write it in a simpler language. WP should at least be able to manage a paragraph for dummies. billinghurst  sDrewth  18:11, 8 July 2010 (UTC)


 * At one time there was a long useful article at Comet (programming). Here’s a link to a version before it was chopped up and stripped of most of its content. That should hopefully give some idea about the purpose of WebSocket, even though it was written before the WebSocket spec. –jacobolus (t) 01:40, 31 July 2010 (UTC)


 * Thanks jacobulus, that Comet link was really useful. Much more useful than the current article, which is 100% jargon, and completely unfriendly to laymen. Can nobody write a simple paragraph explaining what the hell Websockets are and how we might use them? — Preceding unsigned comment added by 212.166.128.118 (talk) 22:16, 7 December 2011 (UTC)


 * I've taken the liberty of editing the intro section to emphasize the purpose, and get rid of the historical browser support since it's no longer relevant. Also, is there any section that talks a lot about the security issues, for example that the handshake is designed to prevent malicious scripts from talking to servers that do not permit such connection, for example having a webpage serve as a spam gateway by having clients connect to SMTP servers. Anyone want to read over this and fix it up some more? 24.7.27.209 (talk) 03:10, 30 January 2012 (UTC)

Too technical
The intro to this article really needs to be simplified. And at the same time the article (maybe the intro) needs to be expanded. Simple questions: what problem are WebSockets meant to solve? What was wrong with the existing technology? Who proposed this in the first place? When did they propose it? AlistairMcMillan (talk) 04:41, 8 June 2010 (UTC)

As someone involved with this, I entirely agree - moreover, so much of this article describes technical detail that is being actively worked upon at the moment, that it's actively misleading. I would strongly recommend stripping the technical detail entirely until it's stable, and concentrate on rationale and high-level features. 217.155.137.60 (talk) 09:04, 5 August 2010 (UTC)


 * To understand what a websocket is you need to understand what an ordinary socket is first. Nothing wrong with existing technology just as a result of firewalls blocking things that are not HTTP and therefore a tendency to do everything over HTTP in order to get around it. Towel401 (talk) 12:45, 11 August 2010 (UTC)

I do not think any part of the spec should be here, the spec should just be linked. — Preceding unsigned comment added by 128.233.16.196 (talk) 19:07, 26 June 2012 (UTC)

Browser support and Browser support
There is two sections called "Browser support". One containing a text description and one containing a table. Would it make sense to merge the two? — Preceding unsigned comment added by Superbjorn (talk • contribs) 08:33, 21 June 2012 (UTC)


 * I think merging the two with the table at the beginning of the section and maintaining a description of the history after that makes the most sense. I came to this page looking for information on browser support and almost edited the first section to add a table before I saw it later on. Sgaragan (talk) 13:57, 18 July 2012 (UTC)

Port 80
Currently, this article states:
 * In addition, the communications are done over TCP port number 80 [...].

Is port 80 the only possible port? Or is port 80 the default port and it is possible to explicitly state another port (e.g. wss://en.wikipedia.org:8080)? --Abdull (talk) 19:17, 20 December 2012 (UTC)

Circular explanation
...the communications are done over TCP port number 80... ... Like TCP, WebSocket provides for full-duplex communication. Websocket differs from TCP....

WebSocket uses TCP. So how is Websocket somehow different than TCP? It is TCP, underneath, like most modern non-streaming services.

This article is full of confusing and conflicting white-paper quasi-techno-babble, and is light on actual real functional details. It's written for a ten-thousand-foot-view web developer, but if it's a networking technology, shouldn't it also have accurate networking details?

- Keith D. Tyler &para; 20:40, 9 April 2013 (UTC)

Potential Error in the Sec-Websocket-Key to Sec-Websocket-Accept
A base64_encode of "0x1d29ab734b0c9585240069a6e4e3e91b61da1969" is yielding "MHgxZDI5YWI3MzRiMGM5NTg1MjQwMDY5YTZlNGUzZTkxYjYxZGExOTY5", not "HSmrc0sMlYUkAGmm5OPpG2HaGWk=" as the article claims.

-- Not an error. The base64 encoding of the binary value is as the article states.

$ echo -n 'x3JJHMbDL1EzLkh9GBhXDw==258EAFA5-E914-47DA-95CA-C5AB0DC85B11' | shasum 1d29ab734b0c9585240069a6e4e3e91b61da1969 -

$ echo -n 'x3JJHMbDL1EzLkh9GBhXDw==258EAFA5-E914-47DA-95CA-C5AB0DC85B11' | openssl dgst -sha1 -binary | openssl base64 HSmrc0sMlYUkAGmm5OPpG2HaGWk=

Serdagger (talk) 20:42, 28 November 2012 (UTC)

Maybe we need to add this commands to show how it was obtained?--PhoneixS (talk) 09:52, 13 May 2013 (UTC)

External links modified
Hello fellow Wikipedians,

I have just added archive links to 1 one external link on WebSocket. Please take a moment to review my edit. If necessary, add after the link to keep me from modifying it. Alternatively, you can add to keep me off the page altogether. I made the following changes:
 * Added archive https://web.archive.org/20110610191150/http://docs.blackberry.com:80/en/developers/deliverables/29271/Web_Sockets_support_1582781_11.jsp to http://docs.blackberry.com/en/developers/deliverables/29271/Web_Sockets_support_1582781_11.jsp

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

Cheers.—cyberbot II  Talk to my owner :Online 18:44, 31 December 2015 (UTC)

WebSocket vs WebSockets
Nitpicking: I know everyone calls it WebSockets, but the actual name of the protocol is WebSocket, singular. At the moment WebSocket redirects to WebSockets. Shouldn't this be reversed? Pjrich (talk) 19:02, 5 May 2011 (UTC)


 * Yes. Go for it. –jacobolus (t) 21:32, 5 May 2011 (UTC)


 * Actually, the technology is overwhelmingly known as Web Sockets or WebSockets (plural), in the same way that Berkeley Sockets are know by their plural name, not the singular version of that. A couple of references: WHATWG and Mozilla Developer Network. The fact that the technology is based on an interface called WebSocket (singufdfdlar) doesn't mean the protocol itself should be singular. Also, the fact that WebSocket is singular when used in the role of an adjective in compound nouns like "The WebSocket Protocol" follows English grammatical usage for plural nouns, and it doesn't mean the same word should be used in its singular form in other roles, particularly when it is used as a standalone noun as in the name of this article. The most authoritative reference in this regards, RFC 6455, clearly uses "WebSockets" (plural) in its text even if is uses "WebSocket" (singular) in compound nouns like its title. So clearly this article's name should be reverted to "WebSockets" (plural), and the text of this article should use "WebSockets" (plural) in general and "WebSocket" (singular) only when English grammar usage requires plural nouns to be used in their singular form... the use of "WebSocket" (singular) in most of this article makes it feel awkward an unnatural. I propose to edit this article accordingly if I don't hear any suggestions to the contrary over the next few days, so please let me know if I'm missing something. Thanks! –Tfjaa762 (talk) 21:28, 2 February 2016 (UTC)

compare/contrast with AJAX?
I'm no expert on this stuff, but it seems to me that WebSockets are (to some extent) an improvement on AJAX, and it seems to me that some comparison could be provided here. (But I don't know nearly enough to even take a stab at writing it.) —Steve Summit (talk) 20:59, 3 March 2016 (UTC)

Websockets over SPDY
The link attributed to the comment about websockets over SPDY no longer shows that chrome flag. I believe that comment and link should be removed from the article. 69.38.204.2 (talk) 17:33, 14 September 2016 (UTC)

让他一人呢 — Preceding unsigned comment added by 171.8.225.58 (talk) 01:12, 5 December 2016 (UTC)

Applications
This article should list applications of WebSockets, e.g. https://www.infoworld.com/article/2609720/application-development/9-killer-uses-for-websockets.html. — Preceding unsigned comment added by Jamesray1 (talk • contribs) 04:50, 5 June 2018 (UTC)