API /repos/{owner}/{repo}/raw/{filepath} fails if filepath is 40-char long #17179
Comments
|
Could you upgrade to latest stable version? |
we just deprecated this API, but this is a short fix to go-gitea#17179 A more minimal fix would be to check if len(parts) > 1 in line context/repo.go#L698
|
@danielemoroni this is a stupid bug, you can work around this by prefixing your filepath with However, this way to specify a ref will possibly be deprecated in 1.16, and the way you currently use this will be fixed in 1.16.0 and 1.15.4. As your Gitea version 1.12 does not receive fixes anyway, you're probably best off to update Gitea to >=1.15.4 once released, instead of adapting your API client. |
|
@noerw Thank you for the explanation, and the quick response. We tend to upgrade our gitea once a year, so we'll pick this up in our next round. I'll bear in mind the deprecation, it's not too bad to change the API calls on our side, so we might do both at the same time. |
...when path contains no hash-path-separator ('/')
This is a workaround to go-gitea#17179.
Entering this case when `path` does not contain a '/' does not really
make sense, as that means the tree path is empty, but this case is only
entered for routes that expect a non-empty tree path.
Treepaths like <40-char-dirname>/<filename> will still fail,
but hopefully don't occur that often. A more complete fix that avoids
this case too is outlined in go-gitea#17185, but too big of a change to backport
...when path contains no hash-path-separator ('/')
This is a workaround to #17179.
Entering this case when `path` does not contain a '/' does not really
make sense, as that means the tree path is empty, but this case is only
entered for routes that expect a non-empty tree path.
Treepaths like <40-char-dirname>/<filename> will still fail,
but hopefully don't occur that often. A more complete fix that avoids
this case too is outlined in #17185, but too big of a change to backport
|
This has been resolved by #17272 in v1.15.4 but not in 1.16. |
lunny
added
the
skip-changelog
wxiaoguang
removed
the
skip-changelog
|
And it is fixed in a special version, it is so strange. |
|
#17185 is the original PR but not merged. |
|
What I want to say is that why original PR was not merged but the backport was merged first. This is so strange. |
...when path contains no hash-path-separator ('/')
This is a workaround to go-gitea#17179.
Entering this case when `path` does not contain a '/' does not really
make sense, as that means the tree path is empty, but this case is only
entered for routes that expect a non-empty tree path.
Treepaths like <40-char-dirname>/<filename> will still fail,
but hopefully don't occur that often. A more complete fix that avoids
this case too is outlined in go-gitea#17185, but too big of a change to backport
|
You should use |
|
And it could be fixed like this: Refactor RepoRefByType #32413 |
|
For most use cases, this problem should have been fixed in 1.23 |
Gitea Version
1.12.3
Git Version
No response
Operating System
No response
How are you running Gitea?
I deployed an official download to my server
Database
No response
Can you reproduce the bug on the Gitea demo site?
Yes
Log Gist
No response
Description
The Gitea API GET /repos/{owner}/{repo}/raw/{filepath} fails with http error 404 (or "object does not exist" in the latest gitea version) if the filepath is 40-character long.
I replicated the issue on https://try.gitea.io/danielemoroni/raw_api:
. This fails:
https://try.gitea.io/api/v1/repos/danielemoroni/raw_api/raw/filename_40char_long_xxxxxxxxxxxxxxx.txt
. This succeeds:
https://try.gitea.io/api/v1/repos/danielemoroni/raw_api/raw/filename_41char_long_xxxxxxxxxxxxxxxx.txt
The files are actually identical. I can retrieve them both without problems with another API, e.g.
https://try.gitea.io/danielemoroni/raw_api/src/branch/master/filename_40char_long_xxxxxxxxxxxxxxx.txt
Screenshots
No response
The text was updated successfully, but these errors were encountered: