Review host matching behaviour

[itowlson]

I had a modules.toml that I assumed would not care about where it was served from - it specified routes and handlers but no hosting.

I ran my WAGI server on localhost:32768 and pointed it at this modules.toml. The routes failed to load, as far as I can tell because they did not match the default_host of localhost:3000.

Am I misunderstanding? Is this expected behaviour? It surprised the heck out of me.

On the plus side, it did give us much better tracing of the handler mapping logic.

[itowlson]

Relevant logs (using logging PR):

[2021-05-31T01:46:26Z TRACE wagi] Processing request to /
[2021-05-31T01:46:26Z DEBUG wagi] Module::handler_for_host_path: host=localhost:32768, url_fragment=/
[2021-05-31T01:46:26Z TRACE wagi] Module::handler_for_host_path: trying route host=None, path/
[2021-05-31T01:46:26Z TRACE wagi] Module::handler_for_host_path: default host localhost:3000 did not match
[2021-05-31T01:46:26Z ERROR wagi] error: No handler for //localhost:32768/

[itowlson]

If we feel it's important to have a host match, could we have a command line arg similar to the --listen arg, that says where host-agnostic modules or bindles should be considered to be hosted?

[technosophos]

The default_host setting in modules.toml is for this. But I have no objection to doing a CLI argument that specifies one. Would the CLI argument override the one defined in modules.toml or vice versa?

[itowlson]

The CLI would have to override I think. The issuer of the CLI command would know where they told it to listen.

Basically if I create a bindle for my application, my bindle should NOT have to know where my users are going to serve it.

[technosophos]

Related to #58

Also, we did add a --default-host flag this week.

[technosophos]

Closed by #72