Branch API get fails for branches with '.txt' suffix
Summary
When trying to use the branch API endpoint (/projects/:id/repository/branches/:name
), branches ending in .txt
return a bare string reference to a Ruby object, rather than actual JSON.
Steps to reproduce
- Try to use the
branches
API endpoint referring to a branch which ends in.txt
Example Project
https://gitlab.com/daniels/branch-dot-txt
Also observed on gitlab.freedesktop.org, currently 12.10.3 CE.
What is the current bug behavior?
- Push a branch not ending in
.txt
- Access the branches endpoint for this branch, observe JSON returned to API client
- Push a branch ending in
.txt
- Access the branches endpoint for this branch, observe a reference to a Ruby object returned to client as response e.g.
#<API::Entities::Branch:0xdeadbeef>
What is the expected correct behavior?
Actual JSON returned.
Relevant logs and/or screenshots
This is my branch-dot-txt
repository, returning correct JSON for branches named foo
and foo.html
, then returning a bare object-referencing string for the foo.txt
branch. I tried other suffixes like .json
, .yaml
, .rb
etc, but couldn't make it break on any other suffix.
>>> requests.get('https://gitlab.com/api/v4/projects/18657442/repository/branches/foo', headers={'PRIVATE-TOKEN': gt}).content
b'{"name":"foo","commit":{"id":"3784ddb6df9805a3f2eda7f701c5fb138e6747e3","short_id":"3784ddb6","created_at":"2020-05-08T10:08:02.000+01:00","parent_ids":[],"title":"foo","message":"foo\\n","author_name":"Daniel Stone","author_email":"daniels@collabora.com","authored_date":"2020-05-08T10:08:02.000+01:00","committer_name":"Daniel Stone","committer_email":"daniels@collabora.com","committed_date":"2020-05-08T10:08:02.000+01:00","web_url":"https://gitlab.com/fooishbar/branch-dot-text/-/commit/3784ddb6df9805a3f2eda7f701c5fb138e6747e3"},"merged":false,"protected":true,"developers_can_push":false,"developers_can_merge":false,"can_push":true,"default":true,"web_url":"https://gitlab.com/fooishbar/branch-dot-text/-/tree/foo"}'
>>> requests.get('https://gitlab.com/api/v4/projects/18657442/repository/branches/foo.html', headers={'PRIVATE-TOKEN': gt}).content
b'{"name":"foo.html","commit":{"id":"3784ddb6df9805a3f2eda7f701c5fb138e6747e3","short_id":"3784ddb6","created_at":"2020-05-08T10:08:02.000+01:00","parent_ids":[],"title":"foo","message":"foo\\n","author_name":"Daniel Stone","author_email":"daniels@collabora.com","authored_date":"2020-05-08T10:08:02.000+01:00","committer_name":"Daniel Stone","committer_email":"daniels@collabora.com","committed_date":"2020-05-08T10:08:02.000+01:00","web_url":"https://gitlab.com/fooishbar/branch-dot-text/-/commit/3784ddb6df9805a3f2eda7f701c5fb138e6747e3"},"merged":false,"protected":false,"developers_can_push":false,"developers_can_merge":false,"can_push":true,"default":false,"web_url":"https://gitlab.com/fooishbar/branch-dot-text/-/tree/foo.html"}'
>>> requests.get('https://gitlab.com/api/v4/projects/18657442/repository/branches/foo.txt', headers={'PRIVATE-TOKEN': gt}).content
b'#<API::Entities::Branch:0x00007f3685daca10>'
Output of checks
This bug happens on gitlab.com, as of 2020-05-08 10:00am UTC.
Possible fixes
gitlab-foss#31790 (closed) and gitlab-foss!13474 (merged) are probably relevant here, since it seems like the exact same Grape bear trap.