Closed m90 closed 6 years ago
@mantoni Did you have a chance to look at this yet? I'm still a bit unsure about what this should be doing when both --url
and --https-server
are being passed.
@m90 Sorry, I completely forgot. Thanks for pinging and for making this change. It's a very nice improvement.
I have additional thoughts regarding your question, but those don't have to be adressed in this PR.
When specifying both, the --url
and the --https-server
options, it was / is the users responsibility to configure matching ports in both cases. This can stay as is for now. You'd basically have to specify the port that you're using in --url
or it won't work.
What would be awsome though, is if the automatic port feature could work with --url
as well. I can imagine this working like this: We parse the --url
for a port number and launch the server on the matching port. If the port is 0
(e.g. https://localhost:0/foo
), we let the OS find a free port and change the URL to point to that port.
Like I said, I think it's something we could keep as an issue if we feel this would be a good idea. This PR is good to be merged, if you don't have anything to add.
I think this is a good idea. I will add a comment to #164 about how it is only partially done. I also think I should find the time to add it soon-ish.
Will release this as 5.4.0
now.
When no port is given for the --https-server arg, pick a random free one. When a port is specified but already in use, fail with a meaningful error message.
This would solve #165 and #164.
I'm unsure about a few things, so I'll also leave comments in the diff.