-
Notifications
You must be signed in to change notification settings - Fork 143
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
Conversation
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). |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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}
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 formatch-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 likeUse-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