Details
Highest Description
This issue has been fixed with a new configurable property in Bitbucket DC. The property controls if the status code for Git HTTP requests is overridden to be 200, or if the true status code is to be sent.
When set to true (default) a status code of 200 is always sent. When set to false, a more accurate status code is sent, for example, 404 if the repository does not exist.
This property is useful because the standard Git client's behaviour will only process the content of HTTP responses is the status code is 200 OK. This means we can send meaningful error messages to Git, at the expense of sending a more accurate response code. When the property is set to false, Git will return it's own generic error message, instead of the one provided by Bitbucket.
http.scmrequest.process.error.response.status.override=<true|false>
Issue Summary
When cloning a repository, the git client will first make a request to the server so it can fetch the refs in the upload-pack. If a user tries to clone a repository that they don't have access to or that doesn't exist, the GET /scm/ccpp/test-repo.git/info/refs?service=git-upload-pack request made by the git client will respond with a 200 HTTP response.
This is reproducible on Data Center: (yes)
Steps to Reproduce
- Run export GIT_CURL_VERBOSE=1 to have visibility of the requests made in the cloning process.
- Attempt to clone a repository that doesn't exist.
Expected Results
Two requests will be made to /info/refs?service=git-upload-pack - the first request will return a 401 to let git knows it expects credentials, and the second one should return a 404 indicating that the repository does not exist.
Actual Results
The second request to /info/refs?service=git-upload-pack is returned with a 200 response, with a message on the body stating that the user doesn't have permission to access the repository or the repository does not exist.
Workaround
Currently, there is no known workaround for this behavior. A workaround will be added here when available