Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Impossible to bind /only/ to unix socket #80

Open
wereHamster opened this issue Nov 3, 2015 · 3 comments
Open

Impossible to bind /only/ to unix socket #80

wereHamster opened this issue Nov 3, 2015 · 3 comments

Comments

@wereHamster
Copy link

If I start the server with a config where only the unix path is set, it automatically starts listening on the default TCP port (no port specified, defaulting to port 8000). This is an issue for me. I start potentially many servers, each listens on a unique unix socket. There is no way to reliably start them all without also allocating an unused TCP port for each one.

@gregorycollins
Copy link
Member

Hi,

You can do this but you might have to avoid using simpleHttpServe (which sets up a lot of these defaults for you) and instead write some config-twiddling code directly. You need to avoid calling completeConfig which is called by extendedCommandLineConfig, and so you'll probably have to configure the server by hand and handle your own command line arguments.

Snap 1.0 should hopefully be easier to configure here.

@wereHamster
Copy link
Author

Both simpleHttpServe and httpServe call completeConfig. I'm not very keen on reimplementing the logic inside simpleHttpServe which actually runs the server (rawHttpServe). So while technically possible, it's not what I'd call straight forward to use.

Furthermore, to be able to directly call rawHttpServe it appears one must import at least one function from the Internal module (snapToServerHandler).

@gregorycollins
Copy link
Member

I understand all of that -- but if you want it fixed for 0.9 you'll have to work around, and that's what you're going to have to do (internal module and all). I'll make sure that 1.0 supports this use case out of the box.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants