CORS and HTTP error responses

Some HTTP clients may wish to treat certain HTTP errors, for example 416
"Requested Range Not Satisfiable" errors, as non-fatal. For example, you may
initiate a download, abort it, then try to resume it using a Range request,
but it turns out that you'd already reached the end of the resource and the
connection just hadn't been closed by the server yet.

But suppose the download is a cross-origin request that the client would
normally deny. If the client does a Range request and gets a 416 response
with no CORS headers, then it should probably treat that as a fatal error
--- the same as if we got a 200 response with no CORS headers --- since we
don't want to leak information about the size of the resource cross-origin.
This suggests that the client should expect --- and the server should send
--- CORS headers such as Access-Control-Allow-Origin:* in HTTP error
responses for "public" resources. Does that make sense? The spec seems to be
silent on the issue.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]