Server does not comply W3C preflight-request specification

[Joxit]

Description

As stated in the CORS Protocol, in a preflight request, i.e. on an OPTIONS request, the server should return specific headers and 200 or 204 status code.

The headers can be configured with the configuration file, however, the server is always returning an HTTP/1.1 401 Unauthorized status code.

from 3.2.3. HTTP responses:

A successful HTTP response, i.e., one where the server developer intends to share it, to a CORS request can use any status, as long as it includes the headers stated above with values matching up with the request.

A successful HTTP response to a CORS-preflight request is similar, except it is restricted to an ok status, e.g., 200 or 204.

Any other kind of HTTP response is not successful and will either end up not being shared or fail the CORS-preflight request. Be aware that any work the server performs might nonetheless leak through side channels, such as timing. If server developers wish to denote this explicitly, the 403 status can be used, coupled with omitting the relevant headers.

Reproduce

Using the configuration:

version: 0.1
log:
  fields:
    service: registry
storage:
  cache:
    blobdescriptor: inmemory
  filesystem:
    rootdirectory: /var/lib/registry
http:
  addr: :5000
auth:
  htpasswd:
    realm: basic-realm
    path: /etc/docker/registry/htpasswd

1. docker run -ti --rm -p 5000:5000 -v $(pwd)/config.yml:/etc/docker/registry/config.yml registry:2.8.3
2. curl -vv -X OPTIONS http://127.0.0.1:5000/v2/_catalog

Expected behavior

The server should return a 200 status code.

registry version

registry github.com/docker/distribution 2.8.3

Additional Info

No response

[milosgajdos]

It returns 401 because of how the auth (check) works https://distribution.github.io/distribution/spec/auth/token/#how-to-authenticate

I don't think registry API has ever been designed to work with CORS in mind - you could probably smack some nginx in front and configure it to do that

[Joxit]

Hi, thanks for your response. As far as I know, we must return 401 on all protected resources for auth to work correctly, since the OPTIONS method isn't a protected resource, it could be exampt from the 401 status code.

In 2016 I created a user interface for private registries. Since the beginning I'm telling my users to bypass this issue with a nginx configuration as you suggested. I'm supporting both token and basic authentication via the interface and the nginx configuration is a good enough solution IMO.

I created the issue today because one of my users wanted a statement from the distribution project. So if the support of OPTIONS will not be added, you can close this issue as "not planned" and I'm OK with it 😊

[milosgajdos]

Honestly, I dont think we'll do anything about it anytime soon, no. I'm basically the only [somewhat] active person on this project, so don't hold your breath.

Feel free to keep this issue open; it's something that should probably be taken into account and done, so it's fine to keep it "visible"

[Suiram1701]

I'am not an expert in GO but wouldn't it be enough to add an exception for OPTIONS requests right here? As I understand it this function is responsible for handling HTTP requests so it could just passthough OPTIONS requests and if the user wants to use CORS he can configure it using the headers. Or am I missing something?