"HTTP code 413: Request entity too large" on upload report step in build pipeline

SonarQube version: 8.2.0.32929 running on Windows 2012 R2 using https and SSO to Azure AD
SonarQube Extension for Azure Devops version 4.9.0 (latest)

When the Run Code Analysis step is run in our build pipeline, we are getting the following error:

2020-04-15T11:40:02.2660555Z INFO: Analysis report generated in 15026ms, dir size=93 MB
2020-04-15T11:43:06.2158310Z INFO: Analysis report compressed in 183953ms, zip size=30 MB
2020-04-15T11:43:20.4228790Z INFO: ------------------------------------------------------------------------
2020-04-15T11:43:20.4230517Z INFO: EXECUTION FAILURE
2020-04-15T11:43:20.4234912Z INFO: ------------------------------------------------------------------------
2020-04-15T11:43:20.4235847Z INFO: Total time: 10:23.057s
2020-04-15T11:43:20.5354232Z INFO: Final Memory: 21M/420M
2020-04-15T11:43:20.5356028Z INFO: ------------------------------------------------------------------------
2020-04-15T11:43:20.5371987Z ##[error]ERROR: Error during SonarQube Scanner execution
2020-04-15T11:43:20.5372724Z ERROR: Error during SonarQube Scanner execution
2020-04-15T11:43:20.5373419Z ##[error]ERROR: Failed to upload report - HTTP code 413: The page was not displayed because the request entity is too large.
ERROR:
2020-04-15T11:43:20.5374401Z ERROR: Failed to upload report - HTTP code 413: The page was not displayed because the request entity is too large.
2020-04-15T11:43:20.5374687Z ERROR:
2020-04-15T11:43:20.6452268Z ##[error]The SonarQube Scanner did not complete successfully
2020-04-15T11:43:20.6455414Z The SonarQube Scanner did not complete successfully
2020-04-15T11:43:20.6509922Z ##[error]07:43:20.642 Post-processing failed. Exit code: 1
2020-04-15T11:43:20.6511557Z 07:43:20.642 Post-processing failed. Exit code: 1
2020-04-15T11:43:20.8144627Z ##[error]The process ā€˜D:\Agents\b1_work_tasks\SonarQubePrepare_15b84ca1-b62f-4a2a-a403-89b77a063157\4.9.0\classic-sonar-scanner-msbuild\SonarScanner.MSBuild.exeā€™ failed with exit code 1
2020-04-15T11:43:20.8227952Z ##[section]Finishing: Run Code Analysis

We changed the IIS setting uploadReadAheadSize to its maximum allowed value.
we have enable ā€œNegotiate Client Certificateā€ for the certificate bindings
we have set maxAllowedContentLength to its maximum value 4294967295

Hi there!

This issue is usually related to the configuration on a reverse proxy, as opposed to the SonarQube server. Are you using a reverse proxy setup by chance?

Yes, as I understand it, itā€™s the only way we can us https with SonarQube. As noted I have already made 3 changes that were suppose to address the proxy.

image001.jpg

Interesting. Can we double-check whatā€™s set for sonar.host.url to make sure weā€™re sending the analysis to the intended site? Those configuration changes usually solve the issue.

The value is set correctly

image001.jpg

I should point out that this in not failing on all scans. The general configuration is correct, since the build in question is successfully uploading scans of other components. Its just one
component with a 30MB Analysis report thatā€™s failing.

INFO: Analysis report generated in 17022ms, dir size=93 MB

INFO: Analysis report compressed in 195757ms, zip
size=30 MB

image001.jpg

If the 413 error is still present, the only cause I can think of is a failure for the configuration changes to take effect in IIS. I would recommend checking the IIS logs around the time of failure, and even around the time of changing to configuration to ensure the changes have been applied.

The changes were applied some time ago now, so I donā€™t think I would be able to locate the logs for when the configuration was changed. I did take a look at the logs and compared a successful
upload to a failed one. The failed one is below. I donā€™t know what to make of it as I have very little experience reading IIS logs. Any incites would be appreciated

2020-04-22 10:32:05 172.16.3.8 GET /batch/project.protobuf key=BM*******tion&X-ARR-CACHE-HIT=0&X-ARR-LOG-ID=aaa0c150-69b5-40af-854c-065464be488b&SERVER-STATUS=404 443 - 40.121.111.108 ScannerCli/4.2.0.1873

  • 404 0 0 15

2020-04-22 10:33:15 172.16.3.8 GET /api/metrics/search f=name,description,direction,qualitative,custom&ps=500&p=1&X-ARR-CACHE-HIT=0&X-ARR-LOG-ID=ac8d2ed0-0fb8-4119-83b3-ef3d591a3e0a&SERVER-STATUS=200
443 - 40.121.111.108 ScannerCli/4.2.0.1873 - 200 0 0 15

2020-04-22 10:35:52 172.16.3.8 POST /api/ce/submit projectKey=BMUI&projectName=BMUI&characteristic=branch%3Dfeature%2Fsupernovae%2Fmain&characteristic=branchType%3DBRANCH&X-ARR-CACHE-HIT=0&X-ARR-LOG-ID=28fb41bd-3ba8-4677-b316-6774de0013f1&SERVER-STATUS=200
443 - 40.121.129.40 ScannerCli/4.2.0.1873 - 200 0 0 2626

2020-04-22 10:41:45 172.16.3.8 POST /api/ce/submit projectKey=BM***********tion&projectName=BM*************tion&characteristic=branch%3Dfeature%2Fsupernovae%2Fmain&characteristic=branchType%3DBRANCH
443 - 40.121.111.108 ScannerCli/4.2.0.1873 - 413 1 0 0

#Software: Microsoft Internet Information Services 8.5

#Version: 1.0

#Date: 2020-04-22 11:21:27

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken

2020-04-22 11:21:27 172.16.3.8 HEAD / X-ARR-CACHE-HIT=0&X-ARR-LOG-ID=3616bb5b-359d-4e1b-9c14-43d0297db69b&SERVER-STATUS=200 443 - 138.246.253.15 Mozilla/5.0+(Windows+NT+6.1;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/40.0.2214.85+Safari/537.36

  • 200 0 0 156

image001.jpg

Thanks for that info. Iā€™m also a bit fuzzy on IIS logging, but I found a nifty guide that does a pretty good job of outlining. It looks like a sticking point for our 413 errors is that thereā€™s not much info on where that error is coming from, but we can dig a little deeper. If you set ā€œsonar.web.accessLogs.enableā€ to ā€œtrueā€ in your ā€œsonar.propertiesā€ file, SonarQube will write similar logging to ā€œaccess.logā€. A good next step would be to replicate the issue with the access log enabled, and then compare the IIS entry timestamp with the entries in ā€œaccess.logā€ around that time. Another option would be to bypass the reverse proxy and send the analysis at the SonarQube server. I recommend the latter as a sanity test.

Actually I think I fixed it.

I changed maxRequestEntityAllowed from 30000000 to 300000000 (approximately 28mb to 286mb, the file size that was failing was 30mb).

To summarize, I previously change the following.

The IIS setting uploadReadAheadSize to its maximum allowed value.

Enable ā€œNegotiate Client Certificateā€ for the certificate bindings

Set maxAllowedContentLength to its maximum value 4294967295

Iā€™m not sure the previous changes helped or not, but itā€™s working now so Iā€™m leaving them as is.

Thanks for the help!

image001.jpg

1 Like

Thatā€™s great to hear! maxRequestEntityAllowed seems like the one that would directly affect this, and I think that extra zero is most likely what fixed the issue. All that being said, Iā€™m definitely not an IIS expert, but itā€™s good to know we can read up on the other settings at our leisure.

Cheers!

I am also facing this issue.
What IIS setting and what exactly I need to do?

Hello @Shashank_Khandelwal,

This is nothing specific to SonarQube, you could have the same problem with any web app that posts big enough payloads through IIS. You should ask this to Microsoft or search elsewhere on the internet

Olivier