/api/server/version returns HTML gibberish

SonarQube Cloud
, ,
1

Hi,

we have a Sonar server in version 2025.1.1.104738. We use a dotnet core C# console app for tooling to make REST calls to this server with dotnet standard HttpClient. Authorization is carried out as follows:

request.Headers.Authorization = new AuthenticationHeaderValue("Basic", Convert.ToBase64String(Encoding.ASCII.GetBytes($"{SonarQubeToken}:")));

Where SonarQubeToken is a token of type User Token.
When we call any API with this on a local dev machine, it works perfectly.

Unless we call the endpoint GET api/server/version with our console app on local dev machine. There we get a 200 as the ResultCode and HTML content that looks like a loading screen to us. The expectation is plain text server version like 2025.1.1.104738

We also tried to achieve a different result by creating a token of the type Project Analysis Token and use it in the SonarQubeToken for authorization. However, this was also unsuccessful.
We have also tried various Accept headers, but that didn’t work either.

What particularly confuses us is that when we make a call using httpyac from VS Code and use the same token, we get the expected result.

We think it has something to do with permissions. Which is strange, because we get a 403 error when calling some APIs where we actually don’t have permission.

Does anyone have any idea what could be causing this? Does this API require any special permissions? Or is there another API where we can find out the server version?

2

Hi Daniel,

This behavior usually occurs when the wrong URL is being called. For example, if you call http://localhost:9000/server/version instead of http://localhost:9000/api/server/version, or if you forget to include the web context (for example, http://localhost:9000/sonarqube/api/server/version if your SonarQube instance is running under a web context).

In these cases, the server may return an HTML page rather than the expected plain text API response. This could explain why you’re seeing an HTML response with a 200 result code instead of the server version.

See below:

colin@MAC-L0251 user-interview-data % curl http://localhost:9000/server/version
<!doctype html>
<html lang="en">
  <head>
    <script type="module" crossorigin src="/js/polyfills-yvRrEsK3.js"></script>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8" charset="UTF-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <link rel="apple-touch-icon" href="/apple-touch-icon.png" />
    <link rel="icon" type="image/x-icon" href="/favicon.ico" />
    <meta name="application-name" content="SonarQube" />
    <meta name="msapplication-TileColor" content="#FFFFFF" />
    <meta name="msapplication-TileImage" content="/mstile-512x512.png" />
    <title>SonarQube</title>
    <script>
      window.__assetsPath = function (filename) {
        return '/' + filename;
      };
...

I’d encourage you to double-check the exact URL your console app is using in the final call. It sounds super obvious, but I don’t think the isse could be anything else. Considering that GET api/server/version doesn’t require any authentication, you can remove that bit entirely to make sure it isn’t getting in the way.

Let me know if this helps!

3

You’re absolutely right. There was a typo. It should actually be https://sonar.com/api/server/version. But it was https://sonar.com//api/server/version. Just a small slash. I didn’t notice it even after looking at it ten times. Thanks for pointing out that there might be an error in the URL. :slightly_smiling_face:

1 Like