What is an opaque response, and what purpose does it serve?

Question

I tried to fetch the URL of an old website, and an error happened:

Fetch API cannot load http://xyz.
No 'Access-Control-Allow-Origin' header is present on the requested resource.
Origin 'http://abc' is therefore not allowed access.
If an opaque response serves your needs, set the request's mode to 'no-cors'
to fetch the resource with CORS disabled.

I understood the message, and tried to do a request that returns an opaque response:

fetch("http://xyz", {'mode': 'no-cors'})

Ok, it now works... but I can't read it. =\

What's the purpose then, of an opaque response?

Costa

Note that although an opaque response appears to be an "empty box", it is indeed a "black box". For more information read this: https://mcmap.net/q/75230/-what-limitations-apply-to-opaque-responses – Shocking

Answer 1

Consider the case in which a service worker acts as an agnostic cache. Your only goal is serve the same resources that you would get from the network, but faster. Of course you can't ensure all the resources will be part of your origin (consider libraries served from CDNs, for instance). As the service worker has the potential of altering network responses, you need to guarantee you are not interested in the contents of the response, nor on its headers, nor even on the result. You're only interested on the response as a black box to possibly cache it and serve it faster.

This is what { mode: 'no-cors' } was made for.

Patnode

But the Status code is always 0, how to check if it was successful if status is never 200 ? – Provoke

You can not. It is part of the blackbox. – Patnode

If an opaque response is like a black-box, then what if it's a broken response? e.g., if we've cached it, then later when it's used, it will be a broken response used...? – Shocking

Yup. Part of the black-box concept is that you should not be able to extract information from it. Knowing it is an error is a way of gaining information about the system behind the endpoint. – Patnode

Answer 2

Opaque responses can't be accessed by JavaScript, but you can still cache them with the Cache API and respond with them in the fetch event handler in a service worker. So they're useful for making your app offline, also for resources that you can't control (e.g. resources on a CDN that doesn't set the CORS headers).

Flapper

Answer 3

There's also solution for Node JS app. CORS Anywhere is a NodeJS proxy which adds CORS headers to the proxied request.

The url to proxy is literally taken from the path, validated and proxied. The protocol part of the proxied URI is optional, and defaults to "http". If port 443 is specified, the protocol defaults to "https".

This package does not put any restrictions on the http methods or headers, except for cookies. Requesting user credentials is disallowed. The app can be configured to require a header for proxying a request, for example to avoid a direct visit from the browser. https://robwu.nl/cors-anywhere.html

Prepositor

aka cors proxy – Inheritrix

Answer 4

no-cors helped me once when I wanted to monitor the Internet availability for a Single Page Application. The page needed to access the Internet and I wanted to be informed when it could not (because the network failed or anything else).

I had access to a cloud-based monitoring service that accepted pushes, i.e. you could send an HTTP call to the service and it would alert you if it has not seen a call within X minutes. A heartbeat kind of monitoring.

The problem is that this service was not exposing any CORS headers (it was intended for backend applications) and a fetch from my page would fail.

no-cors to the rescue: with that option I could send my GET request but I did not care about any response. Either it reaches the monitoring service and everything is fine, or it does not and an alert is raised.

Fowl