upstream connect error or disconnect/reset before headers. retried and the latest reset reason: protocol error

Question

Trying to curl to my deployed container app. As far as I see the container started successfully and the listener port is running evidently by running netstat -an within the container. But a curl to the health check endpoint fails.

Host: automatoraca-app.wittymeadow-****.azurecontainerapps.io

user-agent: curl/7.78.0

accept: /

• STATE: DO => DID handle 0x80007eec8; line 2068 (connection #0)
• multi changed, check CONNECT_PEND queue!
• STATE: DID => PERFORMING handle 0x80007eec8; line 2187 (connection #0)
• HTTP/2 found, allow multiplexing

< HTTP/2 502

< content-length: 110

< content-type: text/plain

< date: Fri, 31 Mar 2023 17:43:41 GMT

<

• nread == 0, stream closed, bailing
• STATE: PERFORMING => DONE handle 0x80007eec8; line 2386 (connection #0)
• multi_done
• Connection #0 to host automatoraca-app.wittymeadow-4cc63852.southcentralus.azurecontainerapps.io left intact
• Expire cleared (transfer 0x80007eec8)

upstream connect error or disconnect/reset before headers. retried and the latest reset reason: protocol error

Answer 1

Hello, @Andy Kepr - Sorry for the late reply. The error message "upstream connect error or disconnect/reset before headers" indicates that the connection between the client and the server was closed before the server could send a response. The error message "protocol error" indicates that there was an issue with the protocol used to communicate between the client and the server for the health check endpoint.

This could be caused by a number of issues, such as a misconfigured firewall (if any), a network issue, or a problem with the server itself.

Generally speaking, to troubleshoot this issue, you can try the following steps:

1. Check the firewall settings to ensure that the port used by the container app is open.
2. Check the network settings to ensure that there are no issues with the network.
3. Check the logs of the container app to see if there are any errors or issues that could be causing the problem.
4. Try accessing the container app from a different network or location to see if the issue is specific to your current network.

If the issue persists, we'll likely need to work with you on a 1:1 setting and take a closer look. In such a case, does your subscription carry a support plan? If not, let me know and I can help open one free of charge for resolving this issue.

Answer 2

I switched the Azure Container App transport mode from "http2" to "auto" to fix the issue.

Answer 3

For all of you struggling with this. If it's really something important, I found a workaround for this. But it's somehow complicated.

Let's assume, that you have your app at domain: https://myapp.com

Now, you need to create a simple Azure Function with http trigger and assign that domain to your function.

Next, you need to create a subdomain, for example: https://app.myapp.com and assign this subdomain to your container app.

Now, the only thing that Azure function needs to do is to wake up your application and redirect to it.

So you need to do something like (pseudocode)

int tryCount = 0;
while(tryCount < maximumTryCount) //just set this max to whatever you like, for example 3
{
  var result = await _httpClient.GetAsync("https://app.myapp.com");
  if(result.IsSuccess())
    break;
 
  await Task.Delay(500); //you can experiment with that delay
  tryCount++;
}

return Redirect("https://app.myapp.com");

Now, the thing is that when you scale your app down to zero and then try to run it, it first has to do some magic stuff like scale to one, do some initialization and so on. On the bottom of this magic there is Kubernetes. It seems like it's not properly configured for such applications. And then it returns an error.

So my workaround just calls your application several times until the container app is ready. You will get then success status code and can redirect your user to your app.

So, when user types in browser: https://myapp.com he will run your azure function which tries to wake up your real application. When it's done it will return the redirect response and then browser will redirect you to https://app.myapp.com, where your up is already running.

As I said - this is just temporary workaround. Microsoft should finally do something with this problem.

Answer 4

Solved the issue by deinstalling - installing gmail on Outlook.

Answer 5

My fix: change default browser from Safari to chrome. After authentification change it back of needed