Python3 CGI HTTPS server fails on Unix

Question

This Python3 CGI HTTPS server used to work a few weeks (or months) ago, but now no longer works under Linux (Ubuntu). I tried on Ubuntu 10.04 and Ubuntu 14.04 and the behavi

Answer 1

I found the answer at:
http://www.castro.aus.net/~maurice/OddsAndEnds/blog/files/d2baf24c48b972f18836cac7a27734e2-35.html

The solution is to add:

http.server.CGIHTTPRequestHandler.have_fork=False # Force the use of a subprocess

before starting the server.

This is required for Mac and Unix implementation because, for efficiency reasons, they employ a fork to start the process that executes the CGI rather than creating a subprocess as used by other implementations (i.e. Windows). In a non-wrapped CGI implementation the fork works fine and the output is sent to the socket correctly, however, when the socket is SSL wrapped things go terribly wrong.

The solution is to force the Unix and Mac implementations to use a subprocess leaving the SSL socket happily working and having the Python Server transfer the output of the CGI script to the client while translating the output into SSL.

I still have no clue why this used to work!

Answer 2

Although the OP found the solution already, here are a few more details why it behaves that way:

• Plain sockets are kernel only, but sslwraped sockets put an additional user-space layer on top.
• http.server does a fork (on platforms supporting fork, that is not on windows) and a remapping of the file descriptors to stdin/stdout before finally executing the cgi program. This way the executed program works on the plain (kernel only, no ssl) file descriptors
• All writes of the program thus go directly to the kernel socket, that is plain unencrypted data.
• The peer will croak on this plain data because it expects SSL frames. The kind of error it produces depends on the data it gets, e.g. ssl_error_rx_record_too_long or "wrong version number" or something like this.