- From: Yoshisato Yanagisawa <notifications@github.com>
- Date: Thu, 30 Jan 2025 23:47:49 -0800
- To: w3c/ServiceWorker <ServiceWorker@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/ServiceWorker/pull/1752/review/2585892576@github.com>
@yoshisatoyanagisawa commented on this pull request. > @@ -3456,6 +3461,57 @@ spec: storage; urlPrefix: https://storage.spec.whatwg.org/ 1. Return true. </section> + <section algorithm> + <h3 id="check-router-registration-limit"><dfn>Check Router Registration Limit</dfn></h3> + + : Input + :: |routerRules|, a [=list of router rules=] + : Output + :: a boolean + + Note: Router conditions can be complex and nested using {{RouterCondition/_or}} and {{RouterCondition/not}}. To prevent excessive processing, this algorithm introduces two limits. First, the total number of conditions, counting all nested conditions, cannot exceed 1024. Second, the nesting depth is limited to 10 levels to avoid exponential computation. + + 1. Let |result| be a [=count router condition result=]. + 1. Set |result|'s [=count router condition result/total count=] to 0. + 1. Set |result|'s [=count router condition result/depth=] to 1. + 1. Let |maxCount| be 1024. I guess setting |maxCount| is to use the same value not only in check-router-registration-limit, but also in count-router-inner-conditions. However, do we need to ask the browser implementor to implement the early return? -- Reply to this email directly or view it on GitHub: https://github.com/w3c/ServiceWorker/pull/1752#pullrequestreview-2585892576 You are receiving this because you are subscribed to this thread. Message ID: <w3c/ServiceWorker/pull/1752/review/2585892576@github.com>
Received on Friday, 31 January 2025 07:47:53 UTC