Re: Running an HTTP(S) server using an externally-provided file descriptor
On Thu, 2 May 2024 at 19:15, Henrik Grubbström (Lysator) @ Pike (-) developers forum <10...@lyskom.lysator.liu.se> wrote: > > Hi again Chris. > > > On Thu, 2 May 2024 at 17:58, Henrik Grubbström (Lysator) @ Pike (-) > > developers forum <10...@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. > Huh. That would be rather nice, if it works. Currently, the two codebases look pretty different. It would be rather neat if SSLPort could simply inherit Port and provide a default parameter. ChrisA
Re: Running an HTTP(S) server using an externally-provided file descriptor
Hi again Chris. > On Thu, 2 May 2024 at 17:58, Henrik Grubbström (Lysator) @ Pike (-) > developers forum <10...@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
Re: Running an HTTP(S) server using an externally-provided file descriptor
>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.
Re: Running an HTTP(S) server using an externally-provided file descriptor
On Thu, 2 May 2024 at 17:58, Henrik Grubbström (Lysator) @ Pike (-) developers forum <10...@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 <10...@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
