diff --git a/spec.bs b/spec.bs index 4fc708a..1055ff5 100644 --- a/spec.bs +++ b/spec.bs @@ -23,6 +23,11 @@ spec: URL; urlPrefix: https://url.spec.whatwg.org/ type: dfn text: serialize an integer; url: #serialize-an-integer text: host serializer; url: #concept-host-serializer +spec: RFC8941; urlPrefix: https://httpwg.org/specs/rfc8941.html + type: dfn + text: structured header; url: top + for: structured header + text: string; url: string

URL patterns

@@ -31,7 +36,7 @@ spec: URL; urlPrefix: https://url.spec.whatwg.org/ A [=URL pattern=] consists of several [=components=], each of which represents a [=/pattern string|pattern=] which could be matched against the corresponding component of a [=/URL=]. -It can be constructed using a string for each component, or from a shorthand string. It can optionally be resolved relative to a base URL. +It can be constructed using a string for each component, or from a [[#constructor-string-parsing|shorthand string]]. It can optionally be resolved relative to a base URL.

The shorthand "`https://example.com/:category/*`" corresponds to the following components: @@ -1983,7 +1988,7 @@ typedef (USVString or URLPatternInit or URLPattern) URLPatternCompatible; JavaScript APIs should accept all of: * a {{URLPattern}} object * a dictionary-like object which specifies the components required to construct a pattern -* a string (in the constructor string syntax) +* a string (in the [[#constructor-string-parsing|constructor string syntax]]) To accomplish this, specifications should accept {{URLPatternCompatible}} as an argument to an [=operation=] or [=dictionary member=], and process it using the following algorithm, using the appropriate [=environment settings object=]'s [=environment settings object/API base URL=] or equivalent. @@ -2018,7 +2023,7 @@ This allows authors to concisely specify most patterns, and use the JavaScript APIs and accept both: * an object which specifies the components required to construct a pattern -* a string (in the constructor string syntax) +* a string (in the [[#constructor-string-parsing|constructor string syntax]]) If a specification has an Infra value (e.g., after using [=parse a JSON string to an Infra value=]), use the following algorithm, using the appropriate base URL (by default, the URL of the JSON resource). [[INFRA]] @@ -2026,7 +2031,7 @@ If a specification has an Infra value (e.g., after using [=parse a JSON string t To build a [=URL pattern=] from an Infra value |rawPattern| given [=/URL=] |baseURL|, perform the following steps. 1. Let |serializedBaseURL| be the [=URL serializer|serialization=] of |baseURL|. - 1. If |rawPattern| is a [=string=], then: + 1. If |rawPattern| is a [=/string=], then: 1. Return the result of [=creating=] a URL pattern given |rawPattern|, |serializedBaseURL|, and an empty [=map=].

It might become necessary in the future to plumb non-empty options here.
@@ -2034,7 +2039,7 @@ If a specification has an Infra value (e.g., after using [=parse a JSON string t 1. Otherwise, if |rawPattern| is a [=map=], then: 1. Let |init| be «[ "{{URLPatternInit/baseURL}}" → |serializedBaseURL| ]», representing a dictionary of type {{URLPatternInit}}. 1. [=map/For each=] |key| → |value| of |rawPattern|: - 1. If |key| is not the identifier of a dictionary member of {{URLPatternInit}} or one of its inherited dictionaries, |value| is not a [=string=], or the member's type is not declared to be {{USVString}}, then return null. + 1. If |key| is not the identifier of a dictionary member of {{URLPatternInit}} or one of its inherited dictionaries, |value| is not a [=/string=], or the member's type is not declared to be {{USVString}}, then return null.
This will need to be updated if {{URLPatternInit}} gains members of other types.
A future version of this specification might also have a less strict mode, if that proves useful to other specifications.
@@ -2049,6 +2054,24 @@ If a specification has an Infra value (e.g., after using [=parse a JSON string t Specifications may wish to leave room in their formats to accept options for {{URLPatternOptions}}, override the base URL, or similar, since it is not possible to construct a {{URLPattern}} object directly in this case, unlike in a JavaScript API. For example, Speculation Rules accepts a "`relative_to`" key which can be used to switch to using the [=document base URL=] instead of the JSON resource's URL. [[SPECULATION-RULES]] +

Integrating with HTTP header fields

+ +HTTP headers which include URL patterns should accept a string in the [[#constructor-string-parsing|constructor string syntax]], likely as part of a structured field [[RFC8941]]. + +
No known header accepts the dictionary syntax for URL patterns. If that changes, this specification will be updated to define it, likely by processing [[RFC8941]] inner lists.
+ +Specifications for HTTP headers should operate on [=URL patterns=] (e.g., using the [=URL pattern/match=] algorithm) rather than {{URLPattern}} objects (which imply the existence of a JavaScript [=ECMAScript/realm=]). + +
+ To build a [=URL pattern=] from an HTTP structured field value |rawPattern| given [=/URL=] |baseURL|: + + 1. Let |serializedBaseURL| be the [=URL serializer|serialization=] of |baseURL|. + 1. [=Assert=]: |rawPattern| is a [=structured header/string=]. + 1. Return the result of [=creating=] a URL pattern given |rawPattern|, |serializedBaseURL|, and an empty [=map=]. +
+ +
Specifications might consider accepting only patterns which do not [=URL pattern/has regexp groups|have regexp groups=] if evaluating the pattern, since the performance of such patterns might be more reliable, and may not require a [[ECMA-262]] regular expression implementation, which may have security, code size, or other implications for implementations. On the other hand, JavaScript APIs run in environments where such an implementation is readily available.
+

Acknowledgments

The editors would like to thank