diff --git a/spec.bs b/spec.bs
index 8a7ee40..bf65012 100644
--- a/spec.bs
+++ b/spec.bs
@@ -25,6 +25,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
The shorthand "`https://example.com/:category/*`" corresponds to the following components:
@@ -1993,7 +1998,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.
@@ -2028,7 +2033,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]]
@@ -2036,7 +2041,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.
@@ -2044,7 +2049,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.
@@ -2059,6 +2064,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