Hello @Jeremy Schotte
Welcome to Microsoft Q&A Platform. Thank you for reaching out & hope you are doing well.
I understand that you have an azure app service and an Azure CDN in front of it and when trying to load the next assets, intermittently you receive an ERR::HTTP2_PROTOCOL_ERROR.
Let us first understand what is ERR_HTTP2_PROTOCOL_ERROR?
This error happens when a client browser has network issues that interrupt the request/response, and the browser fails to read the response due to the network issues, or the response received had an HTTP protocol problem that the browser was unable to interpret. These are typically client-side issues that are related to bugs in individual browsers and using a different browser will clear up the problem. However, sometimes the received response itself has issues. When this happens usually the issue is reproducible and happens in different browsers on different machines using a variety of operating systems.
To troubleshoot this issue, we would need to collect logs and identify the cause.
We can use netlogs generated from the browser to identify the reason for these errors. To capture this data, follow these steps:
- Open a new tab and go to chrome://net-export/
- Select include raw bytes to see all the data in the stream.
- Click the "Start Logging To Disk" button. It will create a json file, select a directory/path where you would like to save these logs to.
- A lot of data is generated using this option, so be sure to set a maximum log size. enter image description here
- Reproduce the network problem in a different tab (the chrome://net-export/ tab needs to stay open or logging will automatically stop.)
- Click Stop Logging button.
Once you've the logs ready, please share them over email to us and we will take a look.
Requested you to send an email with subject line "ATTN gishar | Getting ERR::HTTP2_PROTOCOL_ERROR on Azure CDN using React App" to AzCommunity[at]Microsoft[dot]com with the following details, I will follow-up with you.
- Reference this Q&A thread
- Your Azure Subscription ID
- Attach the collected logs
This was done in another thread : https://learn.microsoft.com/en-us/answers/questions/1319859/getting-err-http2-protocol-error-on-azure-cdn-usin
And you shared the requested logs as advised.
I investigated the logs and found the below error:
HTTP2_SESSION_RECV_RST_STREAM
--> error_code = "2 (INTERNAL_ERROR)"
--> stream_id = 3
"description":"Server reset stream.","net_error":"ERR_HTTP2_PROTOCOL_ERROR","stream_id":3
I performed a CURL on your origin URL which was resulting in error.
And from the CURL, we could see that you were getting HTTP 206 Partial Content instead of 200.
The Content-Range header was set to bytes 0-352716/352717 but the data received by CDN was just 101 KB.
The size of the response was 101 KB, but the Content-Range header indicated that the response size should be about 352 KB. When CDN gets this header, it expects the origin to send 352 KB. It quickly gets 101 KB, and then waits for the rest. It eventually times out while waiting for the origin to deliver the rest of the response.
There was a similar thread on this issue in the past: Intermittent ERR_HTTP2_PROTOCOL_ERROR / HTTP2_STREAM_ERROR / Server reset stream on App Service with Azure Front Door - Microsoft Q&A
The customers created support cases for these issues, so, I checked internally and found the below solution shared by the backend team for this issue:
Issue Description:
[Invalid range header] - http2 protocol error through CDN
Cause:
Problem is not with CDN but rather with the customer origin. If CDN sends a range request to the origin and the origin compresses the response (e.g., with gzip), the origin returns an incorrect Content-Range header.
Resolution:
The customer must fix their origin to send a correct Content-Range header.
The customer can do one of the following as a work-around:
- Disable caching in their CDN profile. This will cause CDN to not send range requests to the origin.
- Change the origin to ignore range requests (treating them as regular non-range requests and returning 200s instead of 206s).
- Disable compression at the origin.
Hence, requested you to try one of the above workarounds.
You used the solution of ignoring range request and it seems to work on your preprod CDN and confirmed that the issue is now fixed.
Kindly let us know if the above helps or you need further assistance on this issue.
Please "Accept the answer" if the information helped you. This will help us and others in the community as well.