Access-Control-Expose-Headers

[sonnyp]

Hey,

Thanks for your awesome work on remoteStorage, love it.

I couldn't find any mention of Access-Control-Expose-Headers in the current version of the spec. I did find mentions in previous version though https://github.com/remotestorage/spec/issues?q=Access-Control-Expose-Headers+is%3Aclosed .

See https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Expose-Headers

Is there any reason Access-Control-Expose-Headers was removed ? Without it browsers will not allow to get Content-Length and ETag headers.

[DougReeder]

Armadietto sends Access-Control-Expose-Headers: ETag

That probably should be in the spec.

[raucao]

I had a look at this, and it seems to me like it should indeed be part of the spec. I could not find a mention of it in any previous version of the RS spec, except as a header included in a Webfinger response example.

Regarding the exact headers to add, the situation is a bit unclear:

1. Access-Control-Expose-Headers exists only to specify additional safe headers that are not CORS-safelisted response headers, which include Content-Length according to MDN, but not according to the current Fetch spec.
2. If a runtime implements Fetch according to the spec, then Content-Type would also only be allowed in the case of a shortlist of a few types that are not commonly used for RS.
3. If a server supports range requests (optional), then Content-Range should also be added.

Looking at the server implementation that I help to maintain, it exposes these headers exactly:

ETag, Content-Length, Content-Range, Content-Type

[DougReeder]

Yes, I was looking at MDN, and am changing Armadietto to send
'Access-Control-Expose-Headers': 'Content-Length, Content-Type, ETag' (it doesn't currently support Range requests)