Hi Henning, On Fri, Dec 06, 2024 at 01:01:34AM +0100, Henning Meyer wrote: > it is the Cross-Origin-Resource-Sharing mechanism explained at > https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
Thanks, this might be a good URL to include in a comment so others know what the extra headers are there for. > 1. by default > JavaScript code from Website A cannot request arbitrary resources > from website B, these are called cross-origin-requests 2. The > browser performs what is called a preflight check, this the OPTIONS > method 3. the response allows website B fine-grained control over > what the web browser should allow 4. Setting > "Access-Control-Allow-Origin: *" tells the web browser to allow all > access, e.g. the same behavior you get with curl or debuginfod-find Right and then when the browser sents an OPTION request we reply with Access-Control-Allow-Origin: * to indicate that is fine from everywhere. A Access-Control-Allow-Methods: GET, OPTIONS to allow both request methods. And a Access-Control-Allow-Headers: cache-control to indicate the browser script may use the cache-control header. Is that the only header we want to expose to scripts? Also we only return these three headers for an OPTION request. Why are we setting the Access-Control-Allow-Origin also on GET requests? Is that necessary? Why not the other Access-Control-Allow headers? > The website mentions that the corresponding spec has been changed, > such that preflight requests are no longer necessary, but in the > browsers I use today (Firefox 132 and Chromium 131) they are still > necessary. That is not how I read it. I looks like the OPTION request is always necessary, but some older browsers didn't do it. I do understand now why you would like to see these headers. But might it be an idea to just let a proxy do this for us? Cheers, Mark
