Issue metadata
Sign in to add a comment
|
Service Worker not capturing fetch event inside Data: URI
Reported by
crb...@gmail.com,
Oct 26
|
||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36 Steps to reproduce the problem: 1. register service worker with 'fetch' interception 2. open any data: URI than includes iframe with SW-interceptable URL What is the expected behavior? response should be produced from service worker What went wrong? service worker was bypassed, response was served from server Did this work before? N/A Does this work in other browsers? Yes Chrome version: 69.0.3497.100 Channel: stable OS Version: 10.0 Flash Version: Also repoducible on Chrome Canary 72.0.3592.0; works as expected on Edge 18, FF 64
,
Oct 29
,
Oct 29
Does a blob URL iframe work?
,
Oct 29
Yes. Blob URL iframe -> service worker iFrame & srcset iframe -> service worker iFrame works as expected; it is only data: URL case
,
Nov 1
Thanks for the issue... Tried to reproduce the issue on latest chrome stable 70.0.3538.77 using Windows 10. Attaching screen-cast for reference. Steps: ------ 1. Launched reported chrome 2. Downloaded given given all attached file and kept in one folder 3. Opened the html file and >> Opened Dev tools >> Applications >> service Workers 4. With checked and unchecked the bypass >> observed the behavior as per attached screencast As we have observed the responses from server @Reporter: Could you please check the attached screen cast and please let us know if anything missed from our end also upgrade to latest chrome : https://www.chromium.org/getting-involved/dev-channel ". Let us know whether issue still persists. Thanks.!
,
Nov 1
My bad - added a bit of code in SW-generated page that was acting weird. I've changed a SW code a bit, to make it work. Updated sw.js to make a good demo. Checked on - 70.0.3538.77 (Official Build) (64-bit) - 72.0.3595.2, dev (64 bit) - 72.0.3598.0 (Official Build) canary (32-bit) I've recorded a video of what's happening on Chrome dev. and got same behavior everywhere
,
Nov 1
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 1
There was a change at some point to make data URL frame get an opaque origin instead of inheriting from the parent. I wonder if chrome is further restricting nested third parties as well for some reason.
,
Nov 1
Thanks for the explanation. From my point of view it's more bug rather than feature, as long as - behavior is inconsistent with other clientside-generated frames (blob & srcdoc) - behavior is inconsistent with all other browsers (FF, Edge, did not check Safari) - theoretically it can become a security/stability issue (if someone will decide that building a cross-domain API over service worker iframes is a good idea)
,
Nov 9
Action items: - Determine whether this is the expected behavior. - Add WPT tests for this if there are none. |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by dtapu...@chromium.org
, Oct 26