Shutting down after listenHTTP

[rikkimax]

listenTCP and listenUDP allow for e.g. shutting down once started.
However listenHTTP does not return these connections, instead it just discards them.

Use case:
Linux daemon + reloading of config. To allow for changing of ports/ip's.

[etcimon]

Yes, in the HTTP server the contexts are stored in g_contexts and have nothing to allow removing one.

The listenTCP return type TCPListener has a stop method but it's unused so far. I think we would need an HTTPContexts object to manage the listeners but I can't think of any use cases for changing the ip/port during runtime.

[rikkimax]

I wasn't meaning changing the ip/port on an already listening interface.
I was meaning the use case of e.g. a web server like Apache httpd.

So stop them all and create new based upon config.

[etcimon]

I wasn't meaning changing the ip/port on an already listening interface.
I was meaning the use case of e.g. a web server like Apache httpd.

So stop them all and create new based upon config.

Yes I've wanted to have that for a while now, I know what you mean. The only issue I see is the necessity to have r/w locks or maybe an atomic fence on every request because g_contexts now became a mutable shared array that can change at any time.

[rikkimax]

Would it be possible to refactor the API out, so that the control of the connection is by the end user?
e.g. they create the connection, on receive of data forward it to vibe.http.server function (possibly with some context involved) and with a hook get called with the request?

[etcimon]

Would it be possible to refactor the API out, so that the control of the connection is by the end user?
e.g. they create the connection, on receive of data forward it to vibe.http.server function (possibly with some context involved) and with a hook get called with the request?

Yes I've also imagined something like that. It would only require to pass the connectTCP and listenTCP as delegates to requestHTTP and listenHTTP respectively. This way the HTTP listener actually sends its void delegate(TCPConnection) handler over so that it can be used internally with your own streams.

I think the HTTPServerSettings would be a nice place to have this delegate, I was motivated mostly by a unit testing interface but your use case seems genuine too, not sure what Sönke would say about it

[rikkimax]

Yeah, that works. All I need is some way to stop them. It's a blocker for daemon support.
There is no way I could release the web server, even if I get e.g. PHP support if the damn demonisation doesn't work.
Something that should be so simple... Yeah, wouldn't look good.

[etcimon]

Yeah, that works. All I need is some way to stop them. It's a blocker for daemon support.

If you handle the listenTCP through a delegate you acquire the means to stop the listeners. The declaration is:

TCPListener listenTCP(ushort port, void delegate(TCPConnection conn) conn_callback, string address, TCPListenOptions options);

The TCPListener is defined as follows:

interface TCPListener {
    /// Stops listening and closes the socket.
    void stopListening();
} 

So this should allow some more control over the TCP layer I guess

[etcimon]

Thanks, I was thinking about quick workarounds to allow me to change the port/restart the server at runtime, before this feature came up =)