On Thu, 2 May 2024 at 17:58, Henrik Grubbström (Lysator) @ Pike (-) developers forum 10353@lyskom.lysator.liu.se wrote:
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?
Inside HTTP.Server.Port, it kinda does, I think? I didn't run into any actual problems.
Inside HTTP.Server.SSLPort though, it doesn't, because omitting (or zeroing) the port number results in the default of 443 being used. So at best, you would have to pick a port and hope that it's not in use, listen on that, and then replace it with listen_fd(). I didn't try that but it seems rather inelegant.
On Thu, 2 May 2024 at 18:21, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum 10353@lyskom.lysator.liu.se wrote:
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?
This may be the solution to both problems. Let me see if I understand you correctly. The variant create would take just the Context, and then before the SSLPort becomes useful, you call listen_fd() and then set the callback?
ChrisA
This may be the solution to both problems. Let me see if I understand you correctly. The variant create would take just the Context, and then before the SSLPort becomes useful, you call listen_fd() and then set the callback?
Yes, or maybe set the callback before listen_fd(). In any case the callback field seems to be externally accessible, so there is nothing preventing you from setting it after create() returns.
Hi again Chris.
On Thu, 2 May 2024 at 17:58, Henrik Grubbström (Lysator) @ Pike (-) developers forum 10353@lyskom.lysator.liu.se wrote:
Does SSL.Port()->listen_fd() not work?
Inside HTTP.Server.Port, it kinda does, I think? I didn't run into any actual problems.
Inside HTTP.Server.SSLPort though, it doesn't, because omitting (or zeroing) the port number results in the default of 443 being used. So at best, you would have to pick a port and hope that it's not in use, listen on that, and then replace it with listen_fd(). I didn't try that but it seems rather inelegant.
Hmm... With your fixes, wouldn't it it work to just give an appropriate SSL.Port object to HTTP.Server.Port()? You would miss out on the generation of the default certificate, but otherwise it ought to behave the same.
/grubba
pike-devel@lists.lysator.liu.se