See branch rosuav/pre-listening-ports for a first attempt at this.
With Stdio.Port(), it's possible to receive an open socket as a file descriptor and start accepting connections on it. (Notably, this allows systemd to provide a socket as FD 3, allowing unprivileged programs to listen on privileged ports.) Currently, this isn't possible with Protocols.HTTP.Server.Port or its friends.
For unencrypted connections, this isn't too hard. Instead of having it construct a Port, it can receive one already listening. For SSLPort though, it inherits SSL.Port, so this doesn't work. What would be a good API for making this possible?
(Protocols.WebSocket.Port and Protocols.WebSocket.SSLPort inherit from their non-websocket equivalents, so they broadly "come along for the ride".)
Incidentally, this actually means it is easier to use opportunistic TLS than mandated, since a regular Port can, with a handful of lines of code, be enhanced to call on SSL.File directly. But API-wise it would be a bit quirky if Port supports this feature and SSLPort doesn't.
Recommendations?
ChrisA
Hi Chris.
See branch rosuav/pre-listening-ports for a first attempt at this.
With Stdio.Port(), it's possible to receive an open socket as a file descriptor and start accepting connections on it. (Notably, this allows systemd to provide a socket as FD 3, allowing unprivileged programs to listen on privileged ports.) Currently, this isn't possible with Protocols.HTTP.Server.Port or its friends.
This reminds me of the original lpc4 Spider webserver installation at Lysator.
For unencrypted connections, this isn't too hard. Instead of having it construct a Port, it can receive one already listening. For SSLPort though, it inherits SSL.Port, so this doesn't work. What would be a good API for making this possible?
Does SSL.Port()->listen_fd() not work?
(Protocols.WebSocket.Port and Protocols.WebSocket.SSLPort inherit from their non-websocket equivalents, so they broadly "come along for the ride".)
Incidentally, this actually means it is easier to use opportunistic TLS than mandated, since a regular Port can, with a handful of lines of code, be enhanced to call on SSL.File directly. But API-wise it would be a bit quirky if Port supports this feature and SSLPort doesn't.
/grubba
If I understand correctly, the problem is that while you can construct an Stdio.Port or an SSL.Port from a file descriptor, you can't do so with a Protocols.HTTP.Server.SSLPort, because the create function of this class (taking 1-6 arguments) unconditionally calls Port::socket::bind().
In which case I guess the solution would be to add a variant create() taking either zero arguments or an SSL.Context (to mimick the one of SSL.Port) while leaving the current one as it is for compatibility?
pike-devel@lists.lysator.liu.se
-
Chris Angelico -
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum -
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum