HTTP HEAD requests (eg. `curl -I`) not supported on the API

[qwerty287]

Gitea Version

Tried on codeberg.org and gitea.com

How are you running Gitea?

Only tried on Codeberg and gitea.com

Can you reproduce the bug on the Gitea demo site?

Yes

Description

Gitea returns an 405 error if trying to use curl with the -I option (only view headers).

Screenshots

No response

[zeripath]

Could you give an example of an URL which returns 405?

I suspect that this is not coming from gitea but from the proxies in front of Gitea.

[qwerty287]

I think it happens on all api pages.
E.g. https://gitea.com/api/v1/version
https://codeberg.org/api/v1/repos/gitnex/gitnex/issues


https://gitea.com/gitea/blog and https://gitea.com are both working

[zeripath]

OK so curl -I is HTTP HEAD - so really your query is about HEAD requests not being supported on the API.

Could you explain why you want to use HEAD on the API?

[qwerty287]

My usecase was to find out the http headers of a list (e.g. link and x-total-count).
Instead I had to use curl -i.

[wxiaoguang]

Is this still a problem? IMO by design Gitea API doesn't support general HEAD method.

[vasishath]

But according to this reply in issue #2081, HEAD request was supported by API atleast at that time.

But it returns 405 now

A valid use case for this is that gradle uses this request when fetching maven packages from package registry. Without that, it doesn't work. See this issue.

[Jaffex]

Can confirm the issue with the package repository:

Gradle uses HEAD calls to determine if the remote package has changed since the last download to determine if it has to download it again.

According to this comment in the issue mentioned by @vasishath over at gradle, package repositories that don't allow HEAD calls are not planned to be supported.

So currently if I try to use the gitea package repository with gradle, I'll get the error

Could not HEAD 'https://example.com/package/repository/version/package.pom'. Received status code 405 from server: Method Not Allowed

[afoo]

Just got really excited for the new package repository feature for a minute, until I found out it's unusable for us in its current state because all our projects use gradle, which, as @Jaffex pointed out, is not and will never be possible as long as the repository does not support HEAD requests.

@zeripath does that answer your question why somebody would want this supported?

The issue still has the state "needs feedback". What feedback do you need to be able to decide how to proceed?

[zeripath]

OK so we need to implement Head support for these package endpoints. Is it just the package endpoints that need this? Do we just need to support this for some of these endpoints and not all of them? Which ones?

The current way we hand HEAD requests is to essentially perform the GET which may be quite expensive on the API in general. So it would be helpful to avoid having to do that in general.

@KN4CK3R do you have any ideas here?

[KN4CK3R]

The package registries are implemented according their spec. If there is no HEAD endpoint, I did not implement one. For Maven there is no (public) spec, at least I could not find one, so it was mostly doing something with mvn and see what requests were received by Gitea. There were no HEAD requests, so I didn't know there was something missing.

Out of curiosity @afoo @Jaffex : Did you try gradle with the Gitlab Maven registry? I don't see HEAD in their spec too: https://docs.gitlab.com/ee/api/packages/maven.html
Looks like it's supported without explicitly implementing it.

I will create a PR for the maven registry part.