Parsing with state override set to opaque path can make URLs not roundtrip

[Scripter17]

What is the issue with the URL Standard?

I'm not clear on if and when each state override is valid, but I noticed that the opaque path state doesn't reject, remove, or change trailing space literals. I first noticed this being an issue in the Rust URL crate (servo/rust-url#1123) and am unsure if the crate or spec is wrong here.

[annevk]

Not all overrides are valid. We should probably add an assert.

[Scripter17]

I am curious, actually, why there seems to be no "proper" way to set the path of a cannot-be-base URL? The pathname setter explicitly does nothing in that case.

As far as I know, nothing else in any URL is frozen like that. Except I guess not being able to change the specialness of a scheme but that's kinda a separate beast.

While it makes sense that not all state overrides are valid, maybe this one should be?

Edit: Btw, thank you for getting to my issues so quickly. Even if it's just triage it's nice to know at least someone's hearing me.

[annevk]

It could probably be made to work, but it would require special care and it's not entirely clear if it's worth the effort. Consider if you had opaque:path and then you'd do .pathname = "//newpath". The no-ops are usually because existing implementations already no-opped or did something bad.

[Scripter17]

It could probably be made to work, but it would require special care and it's not entirely clear if it's worth the effort. Consider if you had opaque:path and then you'd do .pathname = "//newpath". The no-ops are usually because existing implementations already no-opped or did something bad.

Theoretically you could just change leading / to %2F. There's already the thing where an opaque path's trailing space is only encoded if it's just before the query/fragment, even though always encoding it gives equivalent results with less complexity and further unblocks setting opaque paths.