Dear Gitlab,
There seems to be a a bug in the http redirect system that is supposed to redirect the user’s browser to the GitLab sign-in page when the user attempts to access a private repository page while not logged in. Whenever the url ends in “.zip”, the redirect mechanism attempts to redirect the user’s browser to https://gitlab.com/users/sign_in.zip (notice the trailing “.zip”). It seems that the redirect system is mistakenly appending “.zip” to the url of the sign-in page. Because there is no resource named “sign_in.zip”, the user sees a 404 error instead of the expected Gitlab sign-in page. I call this problem the “sign_in.zip” bug.
This bug crops up most often when attempting to use the url for the zip archive of an entire commit (i.e. a url of the form https://gitlab.com//<repository_name>/-/archive/<branch_name>/<repository_name>-<branch_name>.zip ). The typical scenario is that I want to have one of my colleagues download the zip file of a commit. I send him the URL to the zip file, and he clicks the link, expecting to download the zip file, possibly being prompted for his GitLab credentials along the way, but instead he encounters the 404 error and concludes that the link is broken. The net effect of the sign_in.zip bug is that whenever I send my colleague a link to download the zip file of a commit, I must include a paragraph explaining that he needs to log into Gitlab.com before the link will work.
I suspect that I am not the only Gitlab user affected by this issue.
Questions:
- What is causing this bug?
- Is there any way that I can work around the problem (perhaps an alternate URL syntax that avoids the problematic terminal “.zip”)?
- Do the Gitlab developers know about the problem? Do they intend to fix it?
Thank you.
Sincerely,
Neil Jackson