Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch to URLPattern for request matching #2646

Merged
merged 4 commits into from
Nov 9, 2023
Merged

Conversation

pmeenan
Copy link
Contributor

@pmeenan pmeenan commented Oct 9, 2023

This switches the custom wildcard matching to use URLPattern with regexp support disabled. URLPattern is being used by the service worker routing API's and is what the web side is standardizing on for anything that pattern-matches URLs.

This splits the match pattern into explicit path and search (query param) components and forces the origin to be inherited from the dictionary request URL.

Also included here is a new Use-As-Dictionary field for match-dest to allow for matching on request destinations. The biggest use case for that will be for allowing site-wide HTML dictionaries to do something like Use-As-Dictionary: match-path="/*", match-dest="document" and for the dictionary to not be sent for every request across the site (images, etc).

See issues #2639, #2638, #2625

provides an URL-matching pattern for requests where the dictionary can be used.
The "match-path" value of the Use-As-Dictionary header is a sf-string value
that provides the "pathname" of a URLPattern
(https://wicg.github.io/urlpattern/#dictdef-urlpatterninit).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Citing a WICG spec gives me the willies. A normative reference to a CG draft is sketchy, but WICG is in a class of its own.

It might be worth talking to @wanderview about whether this has any hope of turning into a REC, hopefully through a working group. It might be possible to get this particular piece of work done in the IETF, which might be easier than trying to find a home for it in W3C-land.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh yeah, I don't disagree: whatwg/urlpattern#180

It's absolutely on-path to move out of wicg and into a published spec - currently somewhere in w3c or whatwg though. I'll see if I can get a committment on exactly where it is destined to land and the timelines. @wanderview has moved on to other projects but there is a team within Chrome that has taken ownership and is going to be doing the work to complete standardization.

In the meantime, I added an editor's note to the top of the PR calling out the fact that this PR depends on a draft spec and that this ID can't be ratified until that spec is complete.

Copy link
Contributor Author

@pmeenan pmeenan Oct 10, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like this is the whatwg issue tracking the move (and consensus) from wicg to whatwg.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

URLPattern is a whatwg standard now (https://urlpattern.spec.whatwg.org/) so I updated the references to point to the new doc.

@pmeenan pmeenan merged commit 3e544ce into httpwg:main Nov 9, 2023
1 check passed
@pmeenan pmeenan deleted the urlpattern branch November 9, 2023 17:23
aarongable pushed a commit to chromium/chromium that referenced this pull request Feb 5, 2024
The spec of Compression Dictionary Transport has been changed by [1] to
use URLPattern [2] for the matching algorithm of dictionaries. Also [3]
changed the Use-As-Dictionary header’s "match" value to be parsed as a
constructor string of URLPattern.

This CL changes the behavior of Chromium to follow those spec changes
when V2 backend is enabled.

[1]: httpwg/http-extensions#2646
[2]: https://urlpattern.spec.whatwg.org/
[3]: httpwg/http-extensions#2689

Fuchsia-Binary-Size: Size increase is unavoidable.
Bug: 1413922
Change-Id: I6ffba1c8c016145822643a18bc4f18bb7f0ac35f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5232339
Reviewed-by: Patrick Meenan <pmeenan@chromium.org>
Commit-Queue: Tsuyoshi Horo <horo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1256029}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

2 participants