Gitlab Integration: Could not validate URL. Got an unexpected answer. - unexpected end of stream

SonarQube Server / Community Build
1

Hello First time poster and very new to SonarQube. I’m running into an issue with the initial configuration for the integration with a privately hosted gitlab.

Issue:
When I attempt to integrate SonarQube with Gitlab I receive the following error in the GUI: Could not validate Gitlab url. Got an unexpected answer.

When I press the check configuration button this error is returned immediately. Checking the logs there is an end of stream error.

Version:
Version: 2025.1.0.102418
Date: 2025-04-28
Deployed: Docker

Relevant Logs:
[From Web.log] (the server_fqdn is 25 characters and is of the form: servername.domainpart1.domainpart2)

025.04.28 13:05:03 DEBUG web[7b558d3e-e8eb-446e-adb7-2fc9befee46a][o.s.a.c.g.GitlabApplicationClient] get projects : [https://<server_fqdn>/api/v4/projects]

2025.04.28 13:05:03 DEBUG web[7b558d3e-e8eb-446e-adb7-2fc9befee46a][o.s.w.c.OkHttpClientBuilder] --> GET https://<server_fqdn>/api/v4/projects

2025.04.28 13:05:03 DEBUG web[7b558d3e-e8eb-446e-adb7-2fc9befee46a][o.s.w.c.OkHttpClientBuilder] <-- HTTP FAILED: java.net.ProtocolException: unexpected end of stream

2025.04.28 13:05:03 INFO web[7b558d3e-e8eb-446e-adb7-2fc9befee46a][o.s.a.c.g.GitlabApplicationClient] Gitlab API call to [https://<server_fqdn>/api/v4/projects] failed with error message : [unexpected end of stream]

java.net.ProtocolException: unexpected end of stream

Stack trace has been omitted to make this post more readable, but I can include it

What I have Tried:
Have tried going to the above URL from the web browser on the SonarQube server and it works as expected.

Have logged into the gitlab server and used tcpdump with a source address of the servers IP to inspect the traffic. When I use the check configuration button no traffic is detected through tcpdump, where if I hit the same URL from the SonarQube host with a web browser I see the expected HTTPS traffic.

Have tried multiple personal access tokens without success.

Opened web debugging, looking at the headers, and have found that I am receiving a 400 Bad Request from the SonarQube API from the /api/alm_settings/validate function, not sure if this is a red herring or not but I’m thinking it’s not.

I’m assuming that the error is due to an issue with the formatting or length of the header but I’m not entirely sure.

2

Hi,

Welcome to the community!

This indicates there’s a problem communicating with your GitLab instance. This is not something that’s happening on the SonarQube side (but something that’s happening to SonarQube). As a first step, I would talk to your network folks to make sure there’s nothing “helpful” in between the two interfering.

 
HTH,
Ann

3

Hey Ann,

Thanks for your reply!

I thought the exact same thing, so I hopped on the server (it’s running windows with a GUI) and was able to hit the gitlab instance at the same URL using a web browser (https://<server_fqdn>/api/v4/projects) and received a valid response.

I’m assuming that the SonarQube is using the same protocol (https) to hit the server, so that test (afaik) should confirm that we don’t have anything “overly helpful” in between the SonarQube server and the Gitlab instance.

4

Hi,

Can you provide the full stacktrace from the log?

 
Thx,
Ann

5

sonarq_debug_with_stack_trace.txt (8.3 KB)
For sure, Have attached it (figured it’s the prettiest way to get the info here).

Thanks,

Robin

6

Hi,

Thanks for the log. I was expecting some Caused bys in there, but clearly not.

Coming back to this:

I don’t think it does, necessarily. You logged into the Windows machine as you, not the SonarQube user. And your permissions/headers were likely sent with the browser request.

I still think it’s worth talking to your network folks.

And in the meantime, can you curl this as the SonarQube user?

 
Ann

7

Hey Ann,

That’s fair, I was able to successfully curl the github server from the sonarQube server and received the expected objects back.

curl --header “PRIVATE-TOKEN: ” https://<server_FQDN>/api/v4/projects

I’ll see what I can do to chase this down on the network end.

Thanks,

Robin