UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36

Steps to reproduce the problem:
I've created a small test site in order to test this: https://serviceworkerfetchtest.firebaseapp.com/

This installs a service worker that listens the fetch.

1. Go to https://serviceworkerfetchtest.firebaseapp.com/ with the Dev tools open.
2. Reload (The first time it installs the service worker)
3. In the console you should see this:

======== CACHE:  https://bc.marfeel.com/statics16347/marfeel/widgets.s.js  =============
Date Tue, 22 Aug 2017 13:46:17 GMT
========== FETCH ============= https://altbc.marfeel.com/statics16347/marfeel/widgets.s.js  =============
Date null opaque

We try to load two resources from another domain with this headers:
access-control-allow-origin:*
access-control-expose-headers:Date

The first we load it from the cache and we are able to print the date, the second one makes a call with the fetch API and we get a opaque response so we cannot access to the date.

Why do we have two different behaviours with a rseponse from the cache and another from a fetch ? 
When we load this two resources from a normal script in the page both are basic responses, not opaque.

What is the expected behavior?
As both resources have these headers:
access-control-allow-origin:*
access-control-expose-headers:Date

They should have date attribute accessible and not an opaque response.

What went wrong?
fetch(event.request) from the serviceWorker returns an opaque.

caches.match(event.request) from the serviceWorker returns a basic one. (Originally comes from a fetch)

Both should have the same behaviour.

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 60.0.3112.101  Channel: stable
OS Version: OS X 10.12.5
Flash Version: