Skip to content

--listen parameter lets one specify nonsensical behaviour #153

Closed
@jeremy-audet

Description

@jeremy-audet

I can start receptor like so:

poetry run receptor --data-dir="$(mktemp --directory)" node --listen=receptor://127.0.0.1:8888

This works fine. But let's say I start receptor like so:

poetry run receptor --data-dir="$(mktemp --directory)" node --listen=receptor://127.0.0.1:8888/foo

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:

>>> from urllib.parse import urlparse
>>> urlparse('receptor://127.0.0.1/0:8888')
ParseResult(scheme='receptor', netloc='127.0.0.1', path='/0:8888', params='', query='', fragment='')

The logic could be something like:

if res.path or res.params or res.query or res.fragment:
    raise InvalidListenArgumentError(...)

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingneeds_testThis item needs to be tested

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions