Maven build cache extension behind a corporate proxy

Maven has its own proxy settings, and the Apache Build Cache Extension follows them. This page shows what the extension sent through a proxy, how it differs from Gradle, and what you see when the proxy says no. All of it was run for real with Maven 3.10.0, extension 1.2.3 and FosterStack Cache 0.2.1.

What was tested, and what was not

Tested: a small proxy I wrote for the test, which forwards plain HTTP, can refuse a host, and logs every request (I made it close each connection after one request so that none go unlogged). The cache was on a non-loopback address, over plain HTTP, with a password.
Not tested: HTTPS through a proxy for Maven, a proxy that asks for a password, other Maven or extension versions, and any real proxy product. Gradle is on its own page.

The settings

In ~/.m2/settings.xml, next to the cache's password entry:

<settings>
  <servers>
    <server>
      <id>fosterstack-cache</id>
      <username>maven</username>
      <password>your-password-or-CI-secret</password>
    </server>
  </servers>
  <proxies>
    <proxy>
      <id>corp</id>
      <active>true</active>
      <protocol>http</protocol>
      <host>proxy.example.com</host>
      <port>3128</port>
      <nonProxyHosts>cache.internal.example.com|localhost</nonProxyHosts>
    </proxy>
  </proxies>
</settings>

The cache itself is set up as in the Maven setup. The server id must still match the remote's.

What went through the proxy

With the proxy configured, all of the extension's cache traffic went through it: the lookups, the download that restores a build, and the uploads. This is what the proxy logged for two builds, the first filling the cache and the second restoring from it (the proxy also saw Maven's own traffic to repository.apache.org, which is not shown):

build 1 (stores)
GET http://<cache-ip>:18132/v1.1/demo/demo/<id>/buildinfo.xml
GET http://<cache-ip>:18132/v1.1/demo/demo/<id>/buildinfo.xml
PUT http://<cache-ip>:18132/v1.1/demo/demo/<id>/demo.jar
PUT http://<cache-ip>:18132/v1.1/demo/demo/<id>/buildinfo.xml
PUT http://<cache-ip>:18132/v1.1/demo/demo/<id>/build-cache-report.xml

build 2 (restores)
GET http://<cache-ip>:18132/v1.1/demo/demo/<id>/buildinfo.xml
GET http://<cache-ip>:18132/v1.1/demo/demo/<id>/buildinfo.xml
GET http://<cache-ip>:18132/v1.1/demo/demo/<id>/demo.jar
PUT http://<cache-ip>:18132/v1.1/demo/demo/<id>/build-cache-report.xml

The second build logged Found cached build, restoring demo:demo from cache.

Other cases

Setup	What happened
Proxy configured, cache URL is `127.0.0.1`	Still went through the proxy (4 requests logged). Unlike Gradle, Maven does not skip the proxy for loopback.
Proxy configured, the cache's address in `<nonProxyHosts>`	Nothing reached the proxy. The build still restored from the cache.
Proxy refuses the cache's host	Nothing was stored or restored. The build succeeded without the cache, and logged `Error downloading cache item` with `HTTP Status: 403`.
Proxy not running at all	The lookup failed with `Connect to 127.0.0.1:18131 ... Connection refused`. The build succeeded without the cache, and nothing was uploaded.

Things that catch people

A local test can fail because of the proxy. If you try the cache on 127.0.0.1 with a proxy configured in settings.xml, Maven sends it to the proxy, which may not be able to reach your machine's loopback. List it in <nonProxyHosts>.
A refusing proxy looks like a cache error. The 403 comes from the proxy, not from the cache. To check, run the same request from the build machine with and without the proxy; see the curl check on the Gradle page.
Failure does not break the build. A build behind a blocking proxy just stops using the cache, so look for Error downloading cache item and for missing Saved to remote cache lines.

Maven remote cache setup FosterStack home