Expose status of filtered opaque response?

[jeffposnick]

CC: @slightlyoff

The current specification for an opaque filtered response requires that the status always be set to 0. Could this be relaxed?

I understand that the restriction is in place to prevent leaking information that wouldn't otherwise be available for non-CORS requests/responses, but exposing either the actual HTTP response code or a boolean success/error would be very useful, and may not(*) leak more information that could already be inferred via the onerror/onload handlers for elements like <img> and <link>.

As it's currently implemented, when fetch()ing a non-CORS request from the context of a Service Worker, it's not possible to make an informed decisions about whether the filtered opaque response should be cached or not. Blindly caching a (possibly transient) error response isn't ideal, but the other extreme of not caching any filtered opaque responses runs counter to the utility of Service Workers.

(*It's entirely possible that I'm missing some important privacy implications.)

[slightlyoff]

Given that rough status is available this way, a status-code of 0 seems punitive to folks using fetch(). Can we revisit?

[jakearchibald]

We talked about this for failing cache.addAll on things like 404. It was decided that this is a security leak (since on things like Chrome Issues a 404 vs 200 can 'out' you as someone with permission to view non-public issues), and the fact that appcache can do it is a mistake. w3c/ServiceWorker#258 (comment)

[jeffposnick]

Thanks for the context, @jakearchibald, and sorry to rehash something that had already been decided.

Making each developer weigh the tradeoffs of caching vs. non-caching filtered opaque responses is a bummer, but so it goes.

[jakearchibald]

If we can find a safe way to do it (or decide it's safe) then I'll add a failOnNon200 (or whatever) option to cache.addAll