R2 replying with 401 to OPTIONS requests
# r2
s
Have a problem with a public bucket on R2, it connected to public domain. Users are allowed to reuse images from our site (due to a Creative Common licence) - so they use 'copy image url', then paste the URL into file open diaglog (ie from a Choose File with ). Example URL:

http://s1.geograph.org.uk/photos/08/35/083525_9a106acb_393x300.jpg

The problem is Windows, make a OPTIONS request initially. But r2 is responding with 401, which causes Windows to display a login diaglog (persumably so could then send with Basic-Auth)
> OPTIONS /photos/08/35/083525_9a106acb_393x300.jpg HTTP/1.1 > Host: s1.geograph.org.uk > User-Agent: curl/7.74.0 > Accept: / > * Mark bundle as not supporting multiuse < HTTP/1.1 401 Unauthorized < Date: Sat, 16 Dec 2023 17:43:54 GMT < Content-Type: text/html < Transfer-Encoding: chunked
k
Have you seen this 401 in an actual browser or when manually sending an
OPTIONS
request?
If there's no
Origin
request header then it won't be treated as a CORS preflight, and won't get a 204.
s
I dont think windows is technically doing a CORS request, it just (it seems) using OPTIONS to see if exists etc. heres a real request from windows:
(sorry reposting, copy/pasted the wrong one) OPTIONS

http://s1.geograph.org.uk/photos/08/35/083525_9a106acb_393x300.jpg

HTTP/1.1 Connection: Keep-Alive User-Agent: Microsoft-WebDAV-MiniRedir/10.0.22631 translate: f Host: s1.geograph.org.uk HTTP/1.1 401 Unauthorized Date: Sat, 16 Dec 2023 17:27:30 GMT Content-Type: text/html
notice the request from windows, has the full url (starting http:// in the OPTIONS line, not just the path!
u
What exactly are you doing that causes the request?
s
Its pasting the URL into the 'File name' in the Windows Open Diaglog. Admittedly kinda wierd, but its a quick way of copying a file. Windows, will download the file from the URL into a temporally folder, which can then upload to another site.
because windows only gets 401 responce from Cloudflare/R2, it prompts for password:
u
I didnt even know that was possible
s
Can copy this file:

https://t0.geograph.org.uk/stamped/083525_9a106acb.jpg

- even though it via cloudflare as well, our origin responds with 200 to the OPTIONS request, which windows, the follows up with standard GET to actully grab the file.
u
Not sure if you can really fix that with the R2 service itself but you could proxy through a worker and if the request is an OPTIONS respond with whatever cors options you want.
s
As say dont think it anything to do with CORS as such, the OPTIONS is used for WebDav checking. Out of interest checked what AWS/S3 does, they respond with 400 to all the OPTIONS, and windows doesnt seem to mind that. 400 (or 405) seems like would be a better responce to the the OPTIONS than 401.
I've wondered about a worker. Although we using Sippy, not sure if that compatible.
k
A 400/405 is more appropriate - a 401 indicates missing auth but there is no auth to provide here.
cc @Sid | R2
If you have a paid plan, you might want to open a support ticket.
s
Ok thanks. Alas only using free plan. Seems like a worker might work. I've been able to deploy a worker, and it responds with 405 to the OPTIONS request. basically a copy/paste of the demo worker from R2 docs, but removed the PUT/DELETE responders! Seem to be able to paste this URL into the Open dialog - windows ignores the 405, and makes the final GET correctly.

https://worker-long-rain-6cc6.webmaster-9e7.workers.dev/Capture-compass.JPG

(it connected to a different test bucket for now, so doesnt have the above image in it)
Of will need to make the worker, actually respond to proper CORS preflights, that have the Origin header.
s
So TL;DR is that Windows doesn’t send an Origin header in its OPTIONS request, and you’d like R2 to respond with a 400 instead of a 401? That sounds reasonable.
Thanks for reporting this! I’d never have found this myself. I’ve made this change, but it might be a while till this gets released.
We’ll return a 400 for OPTIONS requests without an Origin header