- From: Lukasz Anforowicz <notifications@github.com>
- Date: Mon, 07 May 2018 18:04:49 +0000 (UTC)
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Monday, 7 May 2018 18:05:15 UTC
anforowicz commented on this pull request. > <!-- file URLs end up here as they are not same-origin typically. --> + + <li> + <p>If <var>noCorsResponse</var> is not a <a>filtered response</a> and the <a>CORB check</a> + with <var>request</var> and <var>noCorsResponse</var> returns <b>blocked</b>, then: Maybe. @annevk - can you please help me understand why you've added "If <var>noCorsResponse</var> is a <a>filtered response</a>" in c4a5a28? Some filtered responses do not filter out the response body (e.g. a basic filtered response), so it seems to me that they should still be subject to CORB. What am I missing? :-) FWIW, I've removed the filtered-response wording and followed @jakearchibald's suggestion. Please note that in the current Chromium implementation CORB is applied across the board (possibly on top, or rather before any filtered-response processing, which AFAIK is happening inside Chromium's renderer processes). Please shout if you think that removing the filtered-response wording from the PR was a mistake. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/whatwg/fetch/pull/686#discussion_r186501037
Received on Monday, 7 May 2018 18:05:15 UTC