Consider responding with a 401 instead of 404 on unauthenticated request to`GET /api/:version/project/:project_id_or_path/*`
This issue is very similar to this accepted issue.
It would be helpful if the same principles from that issue were applied more broadly, or, at the very least, to /project/*
requests.
I understand that GitLab considers evidence of the existence or non-existence of a project to be secure data. I think the response code should reflect that correctly with a 401, and not a 404.
My specific use case:
I'm hoping to see self-hosted private GitLab projects working seamlessly with SourceLink at some point in the not-too-distant future.
This issue was raised to address the lack of a Basic Authentication code-retrieval endpoint, but it is extremely stale, and shows no signs of ever being implemented.
So it appears that only the GitLab API can be used to access raw code from projects.
Now, while SourceLink and GitCredentialManager are trying to cope with this, SourceLink-enabled debuggers (e.g. Visual Studio, VSCode, JetBrains Rider, etc) won't go down the authentication route unless an initial _un_authenticated request returns a 401 or 403 error. As things stand, the 404 from unauthenticated requests brings the entire process to a grinding halt.