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 #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.

(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

(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.

(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.

This is ASF Bugzilla: the Apache Software Foundation bug system. In case
of problems with the functioning of ASF Bugzilla, please contact
bugzilla-admin@apache.org.
Please Note: this e-mail address is only for reporting problems
with ASF Bugzilla. Mail about any other subject will be silently
ignored.