- From: Charles Reis <notifications@github.com>
- Date: Fri, 13 Apr 2018 20:46:48 +0000 (UTC)
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/fetch/pull/686/c381256391@github.com>
Thanks @anforowicz. I'm catching up on this myself, and it seems like the main remaining area of discussion is around net errors vs empty responses. In terms of whether it's observable for link preload, the difference seems to be between the spec language that @annevk pointed to and the Blink implementation that @anforowicz pointed to. The spec seems to say link rel=preload as=image should fire a load event and not an error event if an empty (i.e., non-decodable) image response is received. Blink seems to fire an error event in that case, based on local testing. Is this a bug in Blink, and do other browsers behave differently? I think Blink's behavior here may have been part of the reason @nick-chromium closed https://crbug.com/827633 as WontFix. That left our CORB implementation as an empty response since the effort to change to net error didn't seem worth it if it wasn't observable. Nick did have a CL to change to net errors, but it posed a risk that preloaded responses would not be fully loaded into the cache (using Chrome's DetachableResourceHandler) as they should be. It also seemed to break our console messages for blocked responses, but that might be fixable. Just to clarify, if we switched to net errors, we would still expect preload to load the entire response in the browser's network cache, correct? I assume that would matter in cases where one page preloads URLs that the next (possibly cross-site) page will need to use-- those URLs should be cached for the next page even if they end up being opaque to the current page. > FWIW, @csreis pointed out that the initial CORB implementation intentionally avoided injecting network errors to avoid disrupting cases where a webpage issues a request that 1) the webpage expects to succeed, but where 2) the webpage doesn't care about the response. I am guessing that the focus was on XHR / fetch cases in no-cors mode, but maybe @csreis can provide more specific examples. Yes, we started with empty responses in our initial prototypes (years ago) because they seemed less likely to generate observable behavior and because net errors caused more layout tests to fail, but those may have been mistaken assumptions and implementation issues, based on the discussions here. Let's (1) determine if Blink needs to change its link preload behavior, and (2) decide if there are reasons to switch to net errors. -- 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-381256391
Received on Friday, 13 April 2018 20:47:18 UTC