This seems decent enough, but I was recently thinking about whether this crate might be used in wasm and be involved with client-side routing. If it does, then this would fail for a fragment containing a ? (e.g. /foo#bar?baz should have no query string and a fragment of bar?baz). And we would probably want to do something similar for the fragment.

An alternative might be to not do this and just document better that users need to be pre-parsing the url into components and only passing the path in to be routed, it looks like Tide at least is already doing this.

This seems decent enough, but I was recently thinking about whether this crate might be used in wasm and be involved with client-side routing. If it does, then this would fail for a fragment containing a ? (e.g. /foo#bar?baz should have no query string and a fragment of bar?baz). And we would probably want to do something similar for the fragment.

I did implement it as being optional, but on by default - so we could also potentially reverse the default too... but when implementing this I was checking out the specification for a URL in itself and the query string concept is only relevant to HTTP urls anyway. So on reflection I think you are correct in this:

An alternative might be to not do this and just document better that users need to be pre-parsing the url into components and only passing the path in to be routed, it looks like Tide at least is already doing this.

This is a library crate so it would be better to document that this is the expected input (and perhaps show an example of using it that way).

I'm planning on getting to the documentation this week - so I'll approach it in that way.