Intermittent OriginError from Front Door CDN misses

Russell Paine 0

We are having issues with Azure Front Doors CDN on one of our routes. The route is pointing towards a App service that's running a node with a Next.JS v13 application. The caching of SSR pages works fine most of the time but periodically the CDN misses before the "s-maxage" is up and the page 400s with no content on the page request. The "s-maxage" is set to 86400, but the cache misses start well before then.

Looking into the access logs for Front door, we can see that the request is being sent to the correct endpoint, the routing rule name is the same as the endpoint. And an error info of: "OriginError". Following the same request to the web app HTTP logs we can see that it has been requested fine and is passing back a 200 code. No issues from Next.JS. What is weird is that when the page is refreshed the CDN misses again but the page loads fine, but then if the page is refreshed again it errors. It does this continually in a loop; until the CDN hits again and returns fine from then on until the issue starts again. Another thing to note is the "routingRuleName" in the Front door access logs are different for when the cache miss happens it goes from the specific route name to the name of the endpoint. But the request still manages to end up going to the web app.

OriginError is marked as "Generic origin error" which isn't helpful to go off as what we can see from the App service is a 200 error and a success message.

Can someone help us figure out what is going wrong?

ChaitanyaNaykodi-MSFT 25,856 Reputation points Microsoft Employee

2023-11-10T01:52:51.08+00:00

@Russell Paine

Thank you for reaching out.

In order to help troubleshoot can you please share the screenshot of the routing rules set? (Please blackout any personally identifiable data).

Also can you please confirm if you observed any healthprobe issues? Thank you!
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Russell Paine 0 Reputation points

2023-11-10T10:58:18.9933333+00:00
@ChaitanyaNaykodi-MSFT

Hello, I tried to submit a response earlier today but it's still not appearing. So I will reiterate what I posted then.

In relation to the health probes. We do not currently have them turned on in the origin groups. Our understanding was they were only applicable when used for load balancing and as our App Service is a single server it wouldn't be needed. Would it be useful for our case and should be turned on?

We have 5 routes. Three under the same sub domain and two unrelated.

The route we are having an issue with is the web app:

The origin group has a origin host name that is Origin type App service. The host name is the web app (hosting Next.JS) with Certificate subject name validation turned on. The web app has access restrictions turned on. only allowing service tags: AzureFrontDoor.Backend, ApplicationInsightsAvailbility, and AzureMonitoring.

Another bit of information to note is when the page 400s on a TCP miss there are extra headers in the request. Them being:

If-Modified-Since: {time of previous request (that also missed on the CDN)} If-None-Match: "{Etag}"

If more context is needed I can post the other 2 routes using the same subdomain, but as my last response never appeared I will keep this one more brief.
Russell Paine 0 Reputation points

2023-11-10T11:02:59.16+00:00

@ChaitanyaNaykodi-MSFT

The other two relevant routes are:

API:

CMS:
ChaitanyaNaykodi-MSFT 25,856 Reputation points Microsoft Employee

2023-11-11T02:43:51.92+00:00
@Russell Paine

Thank you for getting back and providing the requested details.

Firstly, to answer your question above.

In relation to the health probes. We do not currently have them turned on in the origin groups. Our understanding was they were only applicable when used for load balancing and as our App Service is a single server it wouldn't be needed. Would it be useful for our case and should be turned on?

Your understanding is correct here. As there is only one backend server there is no need to turn on the health probe. This also listed in best practices document here.

Now regarding the issue faced, I do not see any particular issue with the routing rules above. As documented here Front Door always matches to the most-specific request and if there is no catch-all route Path (/*) then a request can end up with Error 400: Bad Request, but your routing rule does have the catch-all route Path (/*) and this should not be the issue here.

As OriginError is very generic and not much to troubleshoot with and as the page is loading correctly at first and then erroring out with cache miss. You can check the following points and see if that helps in pin-pointing the issue.

From the access logs you can get the POP information, you can check if the cache miss and the error is associated with any particular POP.

You mentioned that you are setting the "s-maxage" is set to 86400 but the cache misses start well before the expiry, when caching is enabled on Azure Front Door the cache behavior is as documented here. You can check if any particular rule set is not affecting this behavior.

If this does not help in determining the issue. I think we will need specialized 1:1 session, where a support engineer can have a screen share session to pin point the issue. If you have a support plan you may file a support ticket, else could you please send an email to azcommunity@microsoft.com with the below details.

Subject : Attn Chaitanya

Thread URL: Link to this thread.

Subscription ID

Please let me know once you have done the same.

Thank you!
Russell Paine 0 Reputation points

2023-11-11T14:16:48.9133333+00:00

@ChaitanyaNaykodi-MSFT

Thanks for getting back to me.

Checking through the access logs it appears we get always get the 400 issues from PoP of LON. It appears to happen when switching from LTS to LON as seen in the screenshot:

Whenever LTS is uses everything works as expected. Is there something different about the LON region that we should be accounting for?

In terms of the rule sets. There are currently no rules that use the action "Route configuration override". We simply have the caching tick box checked for our route. From what I understand Front door will always honour the origin headers then. And our response sends back "public, s-maxage=86400, max-age=0". Which can be seen on the page request in chromes network tab. Is my understanding correct?
ChaitanyaNaykodi-MSFT 25,856 Reputation points Microsoft Employee

2023-11-14T03:10:23.9833333+00:00

@Russell Paine

Thank you for getting back.

Whenever LTS is uses everything works as expected. Is there something different about the LON region that we should be accounting for?

I have reached out to the team internally regarding this issue and will make an update here as soon as I get a response.

Thank you!
ChaitanyaNaykodi-MSFT 25,856 Reputation points Microsoft Employee

2023-11-29T01:59:32.03+00:00

@Russell Paine

Just following up here. I had replied to your email, please let me know if you are able to see it. Thank you!

1 answer

Russell Paine 0 Reputation points

2023-12-06T09:44:45.56+00:00

After waiting over two weeks! For a response from the Microsoft support team; the issues was simply that our "Last-Modified" was not in the correct format. We were providing a format like: Wed Dec 06 2023 09:39:07 GMT+0000 (Greenwich Mean Time). When it should've been Wed, 06 Dec 2023 09:39:13 GMT.

Unfortunately; due to the slow response time from the support team we had to move on from using the Front Door cache to other solutions for our CDN. Hopefully this saves some one else the anguish of waiting for a response.

If only Front Door reported meaningful error messages, we could've solve this ourselves!

No idea how it took them so long to diagnose an incorrect header......
Please sign in to rate this answer.

0 comments No comments
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

Intermittent OriginError from Front Door CDN misses

1 answer

Your answer