- From: Lukasz Anforowicz <notifications@github.com>
- Date: Tue, 24 Apr 2018 15:12:34 +0000 (UTC)
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Tuesday, 24 April 2018 15:13:00 UTC
> Those error messages though only reach the console, they are not exposed to web content, so I don't think we need to care for them here. Ok - I've switched to just using "opaque-filtered response" (with no headers and body) rather than introducing a "CORB-filtered response" (with some headers preserved). > As for "opaque-filtered response", part of the point there is that some features, e.g., <img> will dig into the underlying response to get out the bits and display an image. CORB should prevent that for certain responses so I think you want to filter all of "no-cors"... Can you please help me understand what kind of changes you'd like to see? Are you saying that CORB should not only set "response" to a "opaque-filtered response", but should also clear headers and body of the "internal response"? What would you think about introducing a "corb" kind of "response tainting" (used in "no-cors" and "otherwise" clauses of step 5 if CORB algorithm returns "blocked") and handling this new kind of response tainting next to where "opaque" "response tainting" is used (the difference being that headers and body of an internal response would also be cleared). -- 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#issuecomment-383969551
Received on Tuesday, 24 April 2018 15:13:00 UTC