Match URLs should not allow full URLs - Raised by Ilari Liusvaara

[pmeenan]

Allowing absolute URLs in match is a footgun, since dictionaries are restricted to same-origin. I don't think any of the usual URI productions are suitable here.

I think most suitable would be 'segment *( "/" segment )', where segment is the production from RFC 3986.

Original listserv response

Moved from private ID issue #2

[pmeenan]

Even though the URLs must be same-origin, there's some benefit to allowing arbitrary URL formatting to allow for the clean use of relative URLs. They are all going to be expanded to absolute URLs anyway and it wouldn't break anything if someone chose to include the protocol and host parts (though there's no benefit to sending them).

Original listserv response

[pmeenan]

There is talk about using URLPattern with an implicit base URL.

The current plan would be to use the version that takes a patternString and have the baseUrl be set automatically to the URL of the request (and to limit the supported tokens). That mode would still allow for full URLs.

There is also the possibility to break up the path and search components into different use-as-dictionary keys in which case it would prevent full URLs. There's some discussion of what the default search pattern behavior should be if one isn't specified though (match all or only match an empty search string).

[royfielding]

It is really hard to imagine why we would go to all the trouble of optimizing data compression and yet not care about repeating the origin data in the header fields (even though the client is already known to have that data and is required to ignore it if provided). If we don't need it, don't send it on the wire.

It is a foot gun because a lazy implementer (the kind of person who never reads an RFC) will use the full URL provided for the match because it's easier than remembering (or finding) the request context. I know it's silly, but I have seen a lot worse.

[pmeenan]

Closing this now that we have switched to using URLPattern and the path and query components are explicitly split (and the only settable components).

[pmeenan]

Re-opening this because the URLPattern integration changes don't allow for explicitly preventing the origin from being included in the match string.

[pmeenan]

Closing this again as we are sticking with the URLPattern change. While it allows for users to waste bytes by specifying an origin, a hard requirement on not allowing it is not worth the complexity change of not using URLPattern.