- From: Patrick Meenan <notifications@github.com>
- Date: Thu, 01 Dec 2022 07:47:37 -0800
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Thursday, 1 December 2022 15:47:50 UTC
@pmeenan commented on this pull request. > @@ -7346,6 +7357,10 @@ constructor steps are: <li><p>If <var>init</var>["{{RequestInit/signal}}"] <a for=map>exists</a>, then set <var>signal</var> to it. + <li><p>If <var>init</var>["{{RequestInit/priority}}"] <a for=map>exists</a>, then use + it appropriately in setting <var>request</var>'s <a for=request>internal priority</a> + to an <a>implementation-defined</a> object. I tweaked the logic to only update the existing internal priority if one was already set. If it is null then the existing fetching logic will take all of the inputs available to construct one. If an existing one is updated, the additional signals aren't explicitly copied so I left it vague for implementations to decide how much state they need to maintain with the implementation-defined object to be able to modify an existing internal priority with a (possibly) new priority signal. I think this walks the line without having to require that all of the underlying signals in an existing Request be copied over while still allowing for priority to tweak it. -- Reply to this email directly or view it on GitHub: https://github.com/whatwg/fetch/pull/1523#discussion_r1037280387 You are receiving this because you are subscribed to this thread. Message ID: <whatwg/fetch/pull/1523/review/1201246798@github.com>
Received on Thursday, 1 December 2022 15:47:50 UTC