## Summary The repository archive endpoint (`/{user}/{project}/repository/archive.tar.gz?ref={tag}`) for **private** repositories returns HTTP 302 redirecting to `/users/sign_in`, which then returns HTTP 200 with the sign-in HTML page. This breaks automated tooling (notably npm/pacote) that expects either a valid tarball or a proper HTTP error (401/403). ## Steps to reproduce 1. Have a private repository on GitLab.com 2. Make an unauthenticated HTTP request to the archive endpoint: ```bash curl -sI "https://gitlab.com/{namespace}/{project}/repository/archive.tar.gz?ref={tag}" ``` 3. Observe HTTP 302 redirect to `/users/sign_in` ``` HTTP/2 302 location: https://gitlab.com/users/sign_in ``` 4. Following the redirect returns HTTP 200 with HTML content ## Expected behavior The archive endpoint should return **HTTP 401 or 403** for unauthenticated requests to private repositories, not a redirect to the sign-in page. This is consistent with how the API v4 endpoint behaves: ```bash curl -sI "https://gitlab.com/api/v4/projects/{namespace}%2F{project}/repository/archive.tar.gz?sha={tag}" # Returns: HTTP 404 ``` ## Actual behavior - Archive endpoint: 302 to 200 (sign-in HTML page) - API v4 endpoint: 404 (correct behavior) ## Impact npm's package fetcher (pacote) uses `hosted-git-info` to generate tarball URLs for `gitlab:` shorthand dependencies. When the archive endpoint returns 200 with HTML instead of a proper error, npm treats it as a successful tarball download and fails with `TAR_BAD_ARCHIVE: Unrecognized archive format` instead of falling back to git clone. This breaks `npm install` for any project that references private GitLab repos as git dependencies using the `gitlab:` shorthand syntax. It affects both CI/CD pipelines and local development. Related npm issues: - https://github.com/npm/cli/issues/3229 (open since 2021) - https://github.com/npm/cli/issues/2741 - https://github.com/npm/pacote/issues/476 ## Environment - GitLab.com (SaaS) - Observed starting around April 1-2, 2026 - Previously (March 31, 2026), the same CI pipelines with the same configuration succeeded