Re: [w3c/ServiceWorker] Add a static routing API support. (PR #1686)

@yoshisatoyanagisawa commented on this pull request.



> +
+      : Input
+      :: |rule|, a {{RouterRule}}
+      : Output
+      :: a boolean
+
+      1. If |rule|["{{RouterRule/condition}}"]["{{RouterCondition/urlPattern}}"] is the empty string, return false.
+      1. Let |urlPattern| be a result of [=urlpattern/parsing=] |rule|["{{RouterRule/condition}}"]["{{RouterCondition/urlPattern}}"]. If a <code>TypeError</code> is thrown, return false.
+      1. [=list/For each=] |part| of |urlPattern|:
+          1. If |part|'s [=urlpattern-part/type=] is "regexp", return false.
+
+              Note: Since running a user-defined regular expression has a security concern, it is prohibited.
+
+      1. Set |urlPattern| to |rule|["{{RouterRule/condition}}"]["{{RouterCondition/urlPattern}}"]'s associated [=hostname component=].
+      1. Return true.
+  </section>

If it is outside of acceptable patterns, I believe TypeError would be raised by https://wicg.github.io/urlpattern/#parse-a-pattern-string.  If not, since there should be components, and it might be fine to use it for pattern matching.

By the way, if you are talking about supporting URLPattern "field"? other than the pathname, I recently lean on using URLPatternInit instead of USVString.  I mean that if developers want to do something complicated, they should use URLPatternInit.  USVString is only usable for pathnames.  What do you think?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/pull/1686#discussion_r1266163536
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/pull/1686/review/1534093579@github.com>