I am creating this BUG to track HTML5 web socket (now it is IETF websocket protocol. I am able to see browsers such as 1. Mozilla Firefox (Websocket code is checked into the latest Trunk) 2. Google Chrome http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm 3. Webkit (Safari) http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh are going to support officially in few months. This entry is to make sure apache is not missing the web socket part.
Marking as enhancement since this is a request for new function.
I see Dan beat me to marking this as an enhancement request! I'd also note that this looks like a module, and could perfectly well be implemented independently by a third-party if none of the core devs find time for it. Or even if we do!
(In reply to comment #0) > I am creating this BUG to track HTML5 web socket (now it is IETF websocket > protocol. I am able to see browsers such as > 1. Mozilla Firefox (Websocket code is checked into the latest Trunk) just a note: it doesn't actually seem to be checked into Mozilla trunk yet. There's an open enhancement bug for it: https://bugzilla.mozilla.org/show_bug.cgi?id=472529 ...with a patch that seems to (sorta) be under review still
(In reply to comment #0) > I am creating this BUG to track HTML5 web socket (now it is IETF websocket > protocol. I am able to see browsers such as > 1. Mozilla Firefox (Websocket code is checked into the latest Trunk) > 2. Google Chrome http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm > 3. Webkit (Safari) http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh > are going to support officially in few months. > This entry is to make sure apache is not missing the web socket part. Please do not call it an "IETF" protocol. It's just an Internet Draft submitted by an individual. There is no IETF Working Group for this.
Can I file RFEs in bugzilla for all the application layer protocols listed in /etc/services until it we run out of disk space? Or can we keep the RFEs to stuff which is actually relevant to the server? Pretty please?
(In reply to comment #5) > Can I file RFEs in bugzilla for all the application layer protocols listed in > /etc/services until it we run out of disk space? > > Or can we keep the RFEs to stuff which is actually relevant to the server? > Pretty please? I am able to understand your curiosity here is my answer to all of your questions. http://pmsenthilkumar.blogspot.com/2009/07/apaches-html5-websocket-conundrum.html
(In reply to comment #4) > (In reply to comment #0) > > I am creating this BUG to track HTML5 web socket (now it is IETF websocket > > protocol. I am able to see browsers such as > > 1. Mozilla Firefox (Websocket code is checked into the latest Trunk) > > 2. Google Chrome http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm > > 3. Webkit (Safari) http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh > > are going to support officially in few months. > > This entry is to make sure apache is not missing the web socket part. > > Please do not call it an "IETF" protocol. It's just an Internet Draft submitted > by an individual. There is no IETF Working Group for this. Ok... I am not able to understand your question. Websocket is going change the web development paradigm and many companies and folks supporting it. New way of web development may be at least from circa 2005, especially comet which influenced Servlet 3.0 Spec. Is it a correct reason to omit something if it is proposed by a single person? Do you really going to support if Army of people suggested something useless? I tried to express my thoughts to answer all this question http://pmsenthilkumar.blogspot.com/2009/07/apaches-html5-websocket-conundrum.html
(In reply to comment #7) > Ok... I am not able to understand your question. Websocket is going change the > web development paradigm and many companies and folks supporting it. New way of > web development may be at least from circa 2005, especially comet which > influenced Servlet 3.0 Spec. Is it a correct reason to omit something if it is > proposed by a single person? Do you really going to support if Army of people > suggested something useless? I tried to express my thoughts to answer all this > question > http://pmsenthilkumar.blogspot.com/2009/07/apaches-html5-websocket-conundrum.html Don't put words in my mouth. All I said is thst it is incorrect to call it an "IETF protocol" at this point.
(In reply to comment #8) > (In reply to comment #7) > > > Ok... I am not able to understand your question. Websocket is going change the > > web development paradigm and many companies and folks supporting it. New way of > > web development may be at least from circa 2005, especially comet which > > influenced Servlet 3.0 Spec. Is it a correct reason to omit something if it is > > proposed by a single person? Do you really going to support if Army of people > > suggested something useless? I tried to express my thoughts to answer all this > > question > > http://pmsenthilkumar.blogspot.com/2009/07/apaches-html5-websocket-conundrum.html > > Don't put words in my mouth. All I said is thst it is incorrect to call it an > "IETF protocol" at this point. If you go back and read your comment "Please do not call it an "IETF" protocol. It's just an Internet Draft submitted by an individual. There is no IETF Working Group for this". I responded because you said "It's just an Internet Draft submitted by an individual". I think now you know why I said. It is the forum and many a people will visit. I don't want to this bug/enhancement request colored by stating the draft submitted by "individual". BTW, It is not my intention to put or pull anything from your mouth.
Hi, Just for your information, we've open sourced an experimental Web Socket extension for Apache HTTP Server: http://code.google.com/p/pywebsocket/ Please take a look if you are interested. Yuzo
(In reply to comment #10) > Hi, > > Just for your information, we've open sourced an experimental > Web Socket extension for Apache HTTP Server: > http://code.google.com/p/pywebsocket/ > > Please take a look if you are interested. > > Yuzo Thanks for posting. As I suggested in Comment #2 , we now have a third-party implementation. Do you plan to announce this more widely, for example on the users list?
(In reply to comment #11) > (In reply to comment #10) > > Hi, > > > > Just for your information, we've open sourced an experimental > > Web Socket extension for Apache HTTP Server: > > http://code.google.com/p/pywebsocket/ > > > > Please take a look if you are interested. > > > > Yuzo > > Thanks for posting. As I suggested in Comment #2 , we now have a third-party > implementation. > > Do you plan to announce this more widely, for example on the users list? Hi, Nick, Sorry for the very late response. I've forgotten to add me to CC. Can you recommend a list or two to which I can announce this? Yuzo
Request for comments: My proposal for WebSockets support Add a new Config directive "WebSocketsHandler <filenameExecutable>" with context VirtualHost or server config (same as DocumentRoot directive) If a connection comes in with "Connection: Upgrade" and "Upgrade: Websocket" (case insensitive), wait until the request header is complete and then hand the connection over to the executable. Proposal A: - If a request body was sent preliminary (before passing the FD to the executable) then close the connection because of a protocol error. - (A1) All request headers are passed to the executable via env like in CGI or (A2) All request headers are passed to the executable via STDIN - the id of the socket descriptor is passed as env "WEBSOCKET_FD" - The socket descriptor is left open when forking (FD_CLOEXEC clear) or Proposal B: - All request headers are passed to the executable via env like in CGI - Apache httpd needs to immediately pass all further received data to STDIN of the executable (because no new requests can be made in this connection), beginning with the request body - All data wrote in STDOUT of the executable need to be passed through to the client (the executable has to send the response header) - The Apache httpd connection timeouts need to be deactivated Advantages: - Maximum customizability in the client application. - No need of further modifications to Apache httpd - Easy to understand and implement - Proposal B is compatible with any Websocket specification (confirmed with draft-hixie and draft-ietf-hybi) - Proposal A needs at least rev. 04 of draft-ietf-hybi-thewebsocketprotocol - Proposal A allows finetuning of the socket FD - Proposal A reduces the system load of Apache httpd Disadvantages: - Like ordinary CGI scripts, a new executable has to be run for every request - Proposal A will have problems with SSL/TLS
You can find 2 modules on Internet that add websocket protocol support in Apache. The first is : PyWebSocket at http://code.google.com/p/pywebsocket/ but it use Python for the source code. I don't like to use Python on my production servers. I think that it is licensed under BSD licence (http://code.google.com/p/pywebsocket/source/browse/trunk/src/COPYING) when I look at http://en.wikipedia.org/wiki/BSD_licenses The secondth is : Apache WebSocket module at https://github.com/disconnect/apache-websocket. It use language C for the source code. It is licensed under the Apache License, Version 2.0 (https://github.com/disconnect/apache-websocket/blob/master/LICENSE) Today, October 07, 2011, this source code implemented the latest support for WebSocket protocol 13 (August 31, 2011 / http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-13). The latest IETF draft for websocket protocol is available at https://datatracker.ietf.org/doc/draft-ietf-hybi-thewebsocketprotocol/ Is it possible to add Apache WebSocket module (apache-websocket) in the official Apache HTTPD 2.3 source code ? And if possible in Apache HTTPD 2.2.x ? I think that now, it is the best candidate to add websocket protocol support in Apache HTTPD.
Hello from the future :) Has been there any progress? I really think this is a major feature missed on Apache. Websockets are getting more and more attention each day.
> Has been there any progress? Not really. There are some weird looking third-party modules you could research and report on.
(In reply to comment #16) > > Has been there any progress? > > Not really. There are some weird looking third-party modules you could > research and report on. Does this matter? There is already enough literature on the net about this third-party "weird" modules. If this code is still not merged after ~4 years I don't think another report saying: "yes, it works" will change the mind of the apache developers.
(In reply to comment #17) > (In reply to comment #16) > > > Has been there any progress? > > > > Not really. There are some weird looking third-party modules you could > > research and report on. > > Does this matter? To someone asking here about Websocket support in Apache, yes. > There is already enough literature on the net about this third-party "weird" > modules. By whose account? > If this code is still not merged after ~4 years I don't think another report > saying: "yes, it works" will change the mind of the apache developers. It's not a matter of changing the mind of anyone, it's a matter of documenting the requirements and the status quo. I don't think any patch or module has been contributed in any meaningful way, it's not like contributions are being ignored. If there was some patch or standalone module that anyone was considering spending their time working on, they'd surely want to track here what peoples experience with it is (along with the needs and requirements of others), and this is a reasonable place for it.
I have asked to the author of github.com/disconnect/apache-websocket to consider trying to merge his module in Apache upstream. If some of you want to review the code or help with the merge, here is the bug: https://github.com/disconnect/apache-websocket/issues/27
(In reply to Carlos Alberto Lopez Perez from comment #19) > I have asked to the author of github.com/disconnect/apache-websocket to > consider trying to merge his module in Apache upstream. Since self.disconnect appears to be AWOL, I've forked the repository at https://github.com/jchampio/apache-websocket. If, six years after this report was opened, there's still interest in making this happen, c'mon over to GitHub and let's get started.