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

Hey @Andy Kepr

Did you ever come to a conclusion on this? I am having the same thing now.

Answer 2

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 3

Solved the issue by deinstalling - installing gmail on Outlook.

Answer 4

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

Answer 5

I'm having the same problem with only one of my accounts. Can't link my work gmail account to my outlook....

It should be so simple as to login in my gmail when adding the account but the same message keeps appearing:

upstream connect error or disconnect/reset before headers. reset reason: connection failure