CORS preflight OPTIONS request to API returns 404

[salcedo]

• Gitea version (or commit ref): 1.6.1
• Git version: 2.20.1
• Operating system: OpenBSD 6.4
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist:

Description

I'm working on a project that will make some requests to Gitea's API. As my project is on a different origin, my browser sends a CORS preflight (an OPTIONS request).

Gitea doesn't handle an OPTIONS request, and returns 404.

How to fix?

Works:

curl -X GET https://git.example.com/api/v1/repos/search

Returns 404:

curl -X OPTIONS https://git.example.com/api/v1/repos/search

Screenshots

[techknowlogick]

Closed as duplicate of #5700

There is a PR in works to resolve this

[JuhoHeiskanen]

This issue is technically not a duplicate since #5700 deals with the git smart http protocol, not the Gitea API. Pull #5719 that closed the "duplicate" issue does not resolve this one.

[techknowlogick]

Access-Control-Allow-Origin header And OPTIONS method response were implemented with that ticket the users purpose may have been for different purposes but they indeed accomplished the same goal

[JuhoHeiskanen]

As far as I can tell, the Gitea API is unaffected by that change. The change does not seem to affect the /api/v1/repos/search endpoint.

[JuhoHeiskanen]

To be more clear, the pull did not implement CORS header support for the API, but it did implement support for them in git-over-http.

[techknowlogick]

That’s helpful information. Thanks :)

[FallingSnow]

It seems that Gitea doesn't add cors headers to non-option requests either. Cors headers are required on both preflight OPTION requests as well as the following intended requests.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

[klappy]

Has anybody made progress or found a functional work around for this issue?

[techknowlogick]

Current workaround would be to use a reverse proxy that intercepts the request needed and returns the appropriate response.

There is a pending PR for this, however it is awaiting updates from contributor.