- From: Ben Kelly <notifications@github.com>
- Date: Wed, 11 Dec 2019 09:33:10 -0800
- To: w3c/ServiceWorker <ServiceWorker@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Wednesday, 11 December 2019 17:33:12 UTC
> Ben's proposed match-rejects when a matched Response fails a CORP check. This would cause the most immediate/obvious breakage as matchAll() calls that might not look at the CORP-failing Response might now explode, although that use case seems wacky. This approach becomes more problematic if we allow Responses to be stored in IndexedDB. Application logic that invokes getAll is a thing that happens, and poisoned values would be a real problem in that case. I think these issues are only problematic for sites that want some contexts COEP protected and some other contexts non-COEP protected. This seems like an unusual use case. Also, IDB support for responses does not exist today and I haven't seen any movement towards making it happen. Its easier to relax the rejecting behavior if we need to support something like that in the future than it is to claw back the returned Response. I feel pretty strongly we should start by rejecting cache.match() and cache.matchAll(). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/ServiceWorker/issues/1490#issuecomment-564651278
Received on Wednesday, 11 December 2019 17:33:12 UTC