The configuration httpHeaders in pom server settings is not working

[SGmuwa]

I have a project in gitlab, and for deploy to a gitlab maven registry, I need to set the custom http header in maven settings file (so-called ci_settings.xml):

<?xml version="1.0"?>
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">
    <servers>
        <server>
            <id>gitlab-maven</id>
            <configuration>
                <httpHeaders>
                    <property>
                        <name>Job-Token</name>
                        <value>${env.CI_JOB_TOKEN}</value>
                    </property>
                </httpHeaders>
            </configuration>
        </server>
    </servers>
</settings>

But when I try to deploy to the gitlab maven registry, I got a error 401 and I got a nothing for dependencies (404?). I tried open netcat server nc -l 7777 to see requests and I got this ❌ (fail):

GET /api/v4/projects/123/packages/maven/my/example/group/my-example-connector/1.0.0/my-example-connector-1.0.0.pom HTTP/1.1
Cache-Control: no-cache, no-store
Pragma: no-cache
Host: localhost:7777
Connection: Keep-Alive
User-Agent: Apache-Maven/3.8.6 (Java 11.0.16; Linux 6.5.0-28-generic)
Accept-Encoding: gzip,deflate

When I use 3.8.2, I got this ✅ (ok):

GET /api/v4/projects/123/packages/maven/my/example/group/my-example-connector/1.0.0/my-example-connector-1.0.0.pom HTTP/1.1
Cache-control: no-cache
Pragma: no-cache
Job-Token: ${env.CI_JOB_TOKEN}
Host: localhost:7777
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.5.13 (Java/11.0.16)
Accept-Encoding: gzip,deflate

For tests this issue, I manipulate this part of my pom.xml:

<properties>
    <app.runtime>4.4.0</app.runtime>
    <mule.maven.plugin.version>4.1.0</mule.maven.plugin.version>
</properties>

result	mule.maven.plugin.version	app.runtime
❌ FAIL	3.0.0	4.4.0
❌ FAIL	3.0.1	4.4.0
❌ FAIL	3.3.4	4.4.0
❌ FAIL	3.4.2	4.4.0
✅ OK	3.5.1	4.0.0, 4.4.0
✅ OK	3.5.3	4.4.0
✅ OK	3.6.3	4.4.0
✅ OK	3.7.3	4.4.0
✅ OK	3.8.0	4.4.0
✅ OK	3.8.2	4.4.0, 4.6.0
✅ OK	3.8.7	4.4.0, 4.6.0
❌ FAIL	4.0.0	4.4.0, 4.6.0
❌ FAIL	4.1.0	4.4.0, 4.6.0
❌ FAIL	4.1.2	4.4.0, 4.6.0

I did not check the build result to see if it actually runs on mule-runtime. I only checked whether the header was inserted or not.

When I disable the plugin, the dependencies are downloaded, but then there are difficulties with placing the jar in the gitlab maven registry. I have to use maven low level or even use curl.

Does anyone know

1. If mule-maven-plugin actually affects the maven settings file? Or is it some property or some dependency that does this?
2. Have I specified the http header settings correctly?
3. Is there any plan to support custom http headers?

[SGmuwa]

This issue is also discussed on gitlab: https://gitlab.com/gitlab-org/gitlab/-/issues/222365#note_1914375625

[lucianomx]

I've posted what I found out about that issue on Gitlab, but I think it could be more useful if it were here. So, I am posting a whole replica here (from https://gitlab.com/gitlab-org/gitlab/-/issues/222365#note_2771705364)

---

I found out it's because Mulesoft HTTPTransporter takes over all HTTP transporting on Maven, and it doesn't care at all to the <httpProperties> section on settings.xml. Apparently, it works only with HTTP <username> and <password> authentication properties set in settings.xml

I've intercepted all HTTP requests to a webhook, and the expected Gitlab token wasn't transported over HTTP header. It's definetly a Mulesoft issue. However, I wish it could be worked around if we could set a custom HTTP transporter on Maven settings turning that Mulesoft HTTP transporter off, or passing Gitlab authentication over <username> and <password> properties instead.

A regular project:

Projects using some Mulesoft plugins:

Maven logs for a regular project:

[DEBUG] =======================================================================
[DEBUG] Resolving artifact mydomain:myartifact:pom:4.15.1 from [myrepo (https://webhook.site/8800f585-1262-4a57-ae35-096703b2ac9f, default, releases+snapshots), central (https://repo.maven.apache.org/maven2, default, releases)]
[DEBUG] Using transporter WagonTransporter with priority -1.0 for https://webhook.site/8800f585-1262-4a57-ae35-096703b2ac9f
[DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for https://webhook.site/8800f585-1262-4a57-ae35-096703b2ac9f
Downloading from myrepo: https://webhook.site/8800f585-1262-4a57-ae35-096703b2ac9f/mydomain/myartifat/4.15.1/myartifact-4.15.1.pom

Maven logs when a Mulesoft plugin is in action:

[DEBUG] =======================================================================
[DEBUG] Resolving artifact mydomain:myartifact:pom:4.15.1 from [myrepo (https://webhook.site/8800f585-1262-4a57-ae35-096703b2ac9f, default, releases+snapshots), MuleRepository (https://repository.mulesoft.org/nexus-ee/content/repositories/releases-ee/, default, releases+snapshots), mule (https://repository.mulesoft.org/nexus/content/repositories/public/, default, releases+snapshots), central (https://repo.maven.apache.org/maven2, default, releases)]
[DEBUG] Using transporter HttpTransporter from ClassRealm[extension>org.mule.runtime.plugins:mule-extensions-maven-plugin:1.6.0, parent: jdk.internal.loader.ClassLoaders$AppClassLoader@1cf4f579] with priority 5.0 for https://webhook.site/8800f585-1262-4a57-ae35-096703b2ac9f
[DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for https://webhook.site/8800f585-1262-4a57-ae35-096703b2ac9f
Downloading from myrepo: https://webhook.site/8800f585-1262-4a57-ae35-096703b2ac9f/mydomain/myartifact/4.15.1/myartifact-4.15.1.pom
[DEBUG] CookieSpec selected: default
[DEBUG] Connection request: [route: {s}->https://webhook.site:443][total available: 0; route allocated: 0 of 50; total allocated: 0 of 100]
[DEBUG] Connection leased: [id: 0][route: {s}->https://webhook.site:443][total available: 0; route allocated: 1 of 50; total allocated: 1 of 100]
[DEBUG] Opening connection {s}->https://webhook.site:443
[DEBUG] Connecting to webhook.site/178.63.67.106:443
[DEBUG] Connecting socket to webhook.site/178.63.67.106:443 with timeout 10000
[DEBUG] Enabled protocols: [TLSv1.3, TLSv1.2]