[Solved] Trying to understand how mod_cgi works when upgrading to websocket
I intend to write a CGI program that serves as a web proxy. For regular HTTP, I have a relatively clear idea on how this can be accomplished --- On the client side, a browser plugin will capture the request original url, and translate it to https://myproxy.example.com/cgi-bin/proxy.cgi?url=<original_url>&authtoken=<auth_token>. On the server side, the CGI program authenticate the client, extracts the original URL, reads the request body from stdin, relays it to the original URL using libcurl, and writes the response back to stdin.
Now I want extend this proxy to support websocket, but I'm unable to see how whole process would work. I imagine the client would initiate a websocket URL, which can be translated by the browser plugin to wss://myproxy.example.com/cgi-bin/proxy.cgi?url=<original_url>&authtoken=<auth_token>. This will cause the browser to initiate a HTTP upgrade request to the same URL as the regular HTTP case. The CGI backend sees the UPGRADE HTTP header, and respond with 101 switching protocol. But then the CGI program terminates. How should I go on to relay the websocket traffic?
Am I understanding the mod_cgi UPGRADE process correctly? Do I maybe need the help of some additional modules to achieve this?
Thanks.
Replies (3)
RE: Trying to understand how mod_cgi works when upgrading to websocket - Added by gstrauss 4 months ago
I intend to write a CGI program that serves as a web proxy.
It seems to me that you need to understand what that means and then do it. If you do it correctly, then lighttpd will work with it, including websockets, assuming you configure lighttpd mod_cgi to allow Upgrade, and assuming you are running a modern version of lighttpd. Current stable version of lighttpd is lighttpd 1.4.76.
For CGI, lighttpd creates a CGI process with a process ID. Once that process ID (PID) is reaped with waitpid(), lighttpd ends the response.
You posted that you want to write a CGI program that serves as a web proxy. You need to do exactly that. Your CGI needs to proxy the response, or to exec() a replacement process (using the same PID) to provide the response.
RE: [Solved] Trying to understand how mod_cgi works when upgrading to websocket - Added by timothy 4 months ago
The part I don't understand is how the CGI program receives data from lighttpd after the UPGRADE.
For HTTP, the HTTP request header is presented to the CGI program as environment variables and HTTP request body as stdin, and the response is hooked to stdout. Does websocket work the same way for CGI? How is the stdin and stdout hooked in the case of websocket? What would the CONTENT_LENGTH CGI variable be in the case of websocket?
I'm really confused.
RE: [Solved] Trying to understand how mod_cgi works when upgrading to websocket - Added by gstrauss 4 months ago
To answer all of your questions, please look at what your browser sends for an HTTP/1.1 Upgrade request.
After an HTTP/1.1 Upgrade request receives the HTTP/1.1 response HTTP/1.1 101 Switching Protocols, the protocol is switched. It is not longer the HTTP protocol. In the case of Upgrade: websocket, the protocol is websocket.
Read these sentences literally.