Closed Ichimonji10 closed 4 years ago
Alternately, receptor could provide parameters like --listen-scheme
, --listen-address
and --listen-port
. That'd be a much more verbose option, though, and it doesn't strike me as being as elegant.
I can get behind the idea of making it an error to provide path information in the URL that won't be used. That would deal with the receptor://0.0.0.0/0:8888 case.
Does path information possibly mean something in the case of a websocket listener?
Does path information possibly mean something in the case of a websocket listener?
Good question. I've no idea. :woman_shrugging: @matburt ?
Also worth thinking about: can we tell receptor to bind to an interface, and let it discover that interface' address at runtime? That functionality is both common and useful, and it might affect how this issue is addressed.
Fixed by #157. Automated tests added in #139.
I can start receptor like so:
This works fine. But let's say I start receptor like so:
In this case, receptor will (to the best of my knowledge) silently discard the path
/foo
. This seems problematic to me. The user might expect one thing ("receptor will nest its listen interface under the/foo
path"), but receptor will do something else. This could be a source of user confusion.If receptor is going to discard the path, then why does it allow a path to be specified in the first place? Perhaps receptor should reject
--listen
arguments with information that'd be dropped anyway. For example, the following URL could be rejected:The logic could be something like: