v154 · background fetch
With and without CORS headers
The same background fetch aimed at a genuinely cross-origin URL, twice: once at a response that sends Access-Control-Allow-Origin and once at one that does not. Under enforcement the second is unreadable; without it, both come back — which was the bypass.
The cross-origin pair
http://localhost:8123 and http://127.0.0.1:8123 are the same server and different origins — the origin is the scheme, host and port as written, not where they resolve to. That makes a real cross-origin request available without leaving this machine, which is what lets this demo exist at all.
Fetch both ways
One at a time, and one per gesture. Chrome refuses a second background fetch from an origin with TypeError: This origin does not have permission to start a fetch — the API is gated on transient user activation and on not already having one in flight. Click one button, wait for its row to appear, then click the other. A scripted click will not do: the refusal below is what you get without a real gesture, which is the API working as designed.
| request | CORS header sent? | status | response type | readable? |
|---|---|---|---|---|
| Not run yet. | ||||
how to read the result
- Both readable — this build is not enforcing CORS for Background Fetch. The no-header response should not have been readable, and that is the bypass Chrome 154 closes.
- Only the CORS one readable — enforcement is on. The other request may still have been made, but its response is opaque or the record fails, exactly as it would through
fetch(). - Neither readable — read the steps above; the fetch may not have run at all in this environment.