CORS headers not present on /api/healthz #10202

New Issue

GiteaMirror · 2025-11-02T09:00:55-06:00

GiteaMirror commented

2025-11-02 09:00:55 -06:00

Originally created by @Zokhoi on GitHub (Feb 1, 2023).

Description

I have a homer dashboard on another subdomain to check the health status of my self hosted services, and have found that with correct settings in my app.ini:

[cors]
ENABLED = true
ALLOW_DOMAIN = *
SCHEME = http
ALLOW_CREDENTIALS = true

the endpoint /api/v1/version respond with the correct CORS headers, while /api/healthz does not. The endpoints are requested without user authentication, so I have only checked these.

This behavior is reproduced at https://gitea.com, but https://try.gitea.io does not respond with CORS headers at all. Not sure if they have the CORS config set.

For reference, here is the relevant part of my homer config:

services:
  ...
  - name: "Gitea"
    icon: "fab fa-git-alt"
    url: "https://gitea.com"
    target: "_blank"
    type: Ping
    method: GET
    endpoint: "https://gitea.com/api/healthz"
    # endpoint: "https://gitea.com/api/v1/version"

Gitea Version

1.18.3

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

Ubuntu Server 22.04

How are you running Gitea?

official binary from https://dl.gitea.io, as service with systemd

Database

PostgreSQL

Originally created by @Zokhoi on GitHub (Feb 1, 2023). ### Description I have a [homer](https://github.com/bastienwirtz/homer) dashboard on another subdomain to check the health status of my self hosted services, and have found that with correct settings in my `app.ini`: ```ini [cors] ENABLED = true ALLOW_DOMAIN = * SCHEME = http ALLOW_CREDENTIALS = true ``` the endpoint `/api/v1/version` respond with the correct CORS headers, while `/api/healthz` does not. The endpoints are requested without user authentication, so I have only checked these. This behavior is reproduced at https://gitea.com, but https://try.gitea.io does not respond with CORS headers at all. Not sure if they have the CORS config set. For reference, here is the relevant part of my homer config: ```yaml services: ... - name: "Gitea" icon: "fab fa-git-alt" url: "https://gitea.com" target: "_blank" type: Ping method: GET endpoint: "https://gitea.com/api/healthz" # endpoint: "https://gitea.com/api/v1/version" ``` ### Gitea Version 1.18.3 ### Can you reproduce the bug on the Gitea demo site? Yes ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version _No response_ ### Operating System Ubuntu Server 22.04 ### How are you running Gitea? official binary from https://dl.gitea.io, as service with systemd ### Database PostgreSQL

GiteaMirror added the type/bug issue/not-a-bug labels 2025-11-02 09:00:55 -06:00

GiteaMirror closed this issue

2025-11-02 09:00:55 -06:00

GiteaMirror commented

2025-11-02 09:00:56 -06:00

@zeripath commented on GitHub (Feb 1, 2023):

But I don't understand why you want CORS headers on this endpoint. What would be the point?

@zeripath commented on GitHub (Feb 1, 2023): But I don't understand why you want CORS headers on this endpoint. What would be the point?

GiteaMirror commented

2025-11-02 09:00:56 -06:00

@delvh commented on GitHub (Feb 1, 2023):

CORS specifies where resources might be loaded from.
I don't even know why API requests should receive CORS headers at all.
They only return JSON, so there's nothing to load from somewhere else?
Or am I missing something fundamental?

@delvh commented on GitHub (Feb 1, 2023): CORS specifies where resources might be loaded from. I don't even know why API requests should receive CORS headers at all. They only return JSON, so there's nothing to load from somewhere else? Or am I missing something fundamental?

GiteaMirror commented

2025-11-02 09:00:56 -06:00

@Zokhoi commented on GitHub (Feb 2, 2023):

Well I have homer and gitea on different subdomains. I would argue the health check endpoint should make more sense to have CORS than the actual api endpoints, as there are quite a lot of sites that report on uptime statuses of services on different domains/subdomains, or even third party ones.

@Zokhoi commented on GitHub (Feb 2, 2023): Well I have homer and gitea on different subdomains. I would argue the health check endpoint should make more sense to have CORS than the actual api endpoints, as there are quite a lot of sites that report on uptime statuses of services on different domains/subdomains, or even third party ones.

GiteaMirror commented

2025-11-02 09:00:56 -06:00

@yardenshoham commented on GitHub (Feb 2, 2023):

See discussion in #22720

@yardenshoham commented on GitHub (Feb 2, 2023): See discussion in #22720

GiteaMirror commented

2025-11-02 09:00:57 -06:00

@Zokhoi commented on GitHub (Feb 2, 2023):

Alright then

@Zokhoi commented on GitHub (Feb 2, 2023): Alright then

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#10202