添加链接
link管理
链接快照平台
  • 输入网页链接,自动生成快照
  • 标签化管理网页链接
Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Learn more about Collectives

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams

I'm looking for resources about interaction between client side web socket, web server and real application backend that works behind CGI, FastCGI or SCGI protocols.

It seems that this is impossible at this point as:

Request length is specifically defined in CONTENT_LENGTH variable so I can't expect that the data would continue to come from web server from stdin, or may I? as unset CONTENT_LEGTH defines no-request body.

Application require to read CONTENT_LEGTH bytes of date no-more and if less are read then it is considered as disconnected client.

  • Are there any resources on how (F|C)CGI is updated or can be used with WebSockets?
  • Are there any drafts of SCGI/FCGI/CGI specks for WebSockets support?
  • Are there any known web servers that support WebSockets?
  • If so, do they support *CGI protocols for them?
  • Have you had any experience with working with WebSockets and *CGI?
  • Thank you, all information would be appropriate.

    Artyom

    Anybody?

    You can find a mod_websocket module for lighttpd here . When building the module, be sure to specify the correct websocket protocol version you want to use (version -75 or -76). Starting with WebKit nightly build r59903 and Chrome 6.0.414.0 (r47952) only protocol version -76 is supported.

    Note that with using WebSockets, you no longer need CGI, FastCGI or SCGI protocols for connecting the web server with the application back end. Just implement a TCP listener in your application (for mod_websocket to connect to) and use the socket for asynchronous I/O.

    Interesting, but from what I can see it does not pass any HTTP Headers data like cookies etc to backend. So how should I manage sessions? I need to send such data explicitly instead of getting it from the web server. Artyom Jul 28, 2010 at 9:49 Your websocket connections are created in the context of your HTTP session, you don't have to care about that. Beside that, HTTP and websocket are of course completely different protocols, so in your websocket connection you don't have access to HTTP headers. Keep in mind that the websocket protocol only provides a minimal framing on top of TCP, so any application-specific data exchange between the application backend and the web client on top of a websocket connection you have to define and implement by yourself, just as you would do it using regular sockets. raffel Jul 28, 2010 at 11:56 Just for the record, AFAIK HTTP Headers are required fro several reasons: Know session data, know the URL is accessed, know the IP of remote host etc, etc, etc. So websocket is far from being just a socket. Artyom Jul 28, 2010 at 13:30 Uh.. after the websocket handshake is done, it is really very much like regular sockets. Even Joe Armstrong (of Erlang fame) says so :) armstrongonsoftware.blogspot.com/2009/12/… raffel Jul 28, 2010 at 18:12 After the handshake, yes. But the handshake itself is a valid HTTP request, and should arrive unmolested at the WebSocket server.RFC 6455 link says a client may send other headers, such as cookies or authentication related headers. You are right though, you don't need SCGI or FCGI when using WebSocket, you should just speak WebSocket in your application. If something is acting as a proxy in between, it depends on the proxy how the original client address is forwarded. It might be stored in the "X-Forwarded-For" header. Maarten May 4, 2012 at 8:25

    Thanks for contributing an answer to Stack Overflow!

    • Please be sure to answer the question . Provide details and share your research!

    But avoid

    • Asking for help, clarification, or responding to other answers.
    • Making statements based on opinion; back them up with references or personal experience.

    To learn more, see our tips on writing great answers .