Hello,

I started using your proxy because I quite often had the problem that github/packagist messed up some dependencies for a short time (which is already quite annoying).

Now, I'm caching dependencies nearly forever. This solved my issue with broken dependencies.

Caching dependencies forever has the bad taste of not knowing what happens with the dependency on the remote site. I would like to know what happens to the dependency.
Is it possible to add some kind of monitoring to the proxy which informs the plugin during an install, whenever a dependency gets deleted or is not available for some reason?

Regards
Max

Thanks for this great project.

I had a question around expiry of repo packages.

I have not set the MIRROR_{name}_CACHE_EXPIRY parameter on the Docker image but although I downloaded some packages from a repo yesterday, when I go to fetch them today via the cache, they are all listed as upstream ... [EXPIRED].

Would specifying MIRROR_{name}_CACHE_EXPIRY override the repo set expiry?

Hey,

I experience issues with GitLab again. I'm not sure if that's due to a GitLab change or a setup change on my side.

I get a 404 all the time when I try to require a private gitlab-provided package. GitLab returns a 404 whenever the authentication fails.
So I tried it by myself. Adding basic auth -> 404. I had to create a new access token and had to add it as a get parameter or header:

private_token=XYZ
--header "PRIVATE-TOKEN: XYZ"

Could you take a look at this, please?

Thanks!

Hi all.

First at all thank you for this aweseome project.

My setup:

• Proxy is running as docker image
• It is using https
• Secured by basic auth
• I activated the gitlab mirror and added my bearer token

When opening the mirrors.json page the following json is returned:

{
    "mirrors": [
        {
            "url": "//gitlab.com/",
            "path": "/mirror/gitlab/"
        },
        {
            "url": "//codeload.github.com/",
            "path": "/mirror/github-codeload/"
        },
        {
            "url": "//repo.packagist.org/",
            "path": "/mirror/packagist/"
        }
    ]
}

For packages downloading from packagist there is no issue
But when trying to download my private package from gitlab it always fails with 404 not found.

When I try to download it manually via postman providing the bearer token, everything works.

Url which I get in composer when doing composer install:
Failed to download package/mypackage from dist: The "https://myproxy.domain.com/mirror/gitlab/api/v4/projects/my-project/mypackage/repository/archive.zip?sha=12342523" ...

And when I try to open the url directly in the browser following json is returned:

{"error":"404 Not Found"}

When I try it via postman directly:
https://gitlab.com/api/v4/projects/my-project/mypackage/repository/archive.zip?sha=12342523

So I checked the proxy loggs and found where it tries to download the package:

proxy_1  | X.X.X.X - myuser [22/Nov/2023:08:19:12 +0000] "GET /mirror/gitlab/api/v4/projects/my-project/mypackage/repository/archive.zip?sha=12342523 HTTP/1.1" 404 25 "-" "Mozilla/5.0 (X11; Linux x86_64) ..." "X.X.X.X"

proxy_1  | X.X.X.X - myuser [22/Nov/2023:08:19:12 +0000] upstream gitlab.com - [STALE] GET /mirror/gitlab/api/v4/projects/my-project/mypackage/repository/archive.zip?sha=12342523 HTTP/1.1 [-] -ms -b

The request to gitlab always ends in the status "STALE".

Please help me!

Thank you in advance!

Some private repositories (eg. composer.amasty.com) also require that the User-Agent (eg. Composer/1.9) is sent to the origin in order to grant access. Otherwise the request is rejected with 401.

So the http headers need to be proxied to the origin as well.

Hey,

gitlab.com has adjusted the API interface with one of the latest releases. If no Accept-Encoding header is defined, GitLab uses the Content-Encoding header with the value "br", which is used by Composer or libcurl.

curl error 61 while downloading URL: Unrecognized content encoding type. libcurl understands deflate, gzip content encodings.

If gitlab.com receives the Accept-Encoding header with the value gzip, then the correct Content-Encoding header with gzip is also returned.

GitLab:

Response Header:

Velocita -> Gitlab:

Response Header:

Composer error:

Could you help me with this issue, please?

Regards
Max

Do you have any thoughts on how authentication could be approached? I am considering putting velocita on a public facing URL so that cloud builds can take easy advantage of it.

Possibly creating a Docker image that includes some of the vouch-proxy setup?

Just throwing this out there at the moment for discussion.

This can be confirmed by configuring a proxy for https://packages.drupal.org/8/.

Reported by Deji Akala.

I noticed my velocita-proxy docker image was failing to start, and it turns out that there was a new image posted 3 days ago.
Unfortunately that image is arm64 only, no x86 image at all.

https://hub.docker.com/r/isaaceindhoven/velocita-proxy/tags

That'll likely disrupt anyone pulling that image.

When the password contains special chars (eg. = or :), auth fails and velocita responds with 401.
When having = in the password, whole password in docker-compose must be quoted (").
As the password is working (request works with postman and with composer without velocita), I think there is a bug in velocita.