Hello @Michael Glover ,
Welcome to Microsoft Q&A Platform. Thank you for reaching out & hope you are doing well.
I understand that you are experiencing errors in your Azure App Service caused by Azure Front Door Premium instance not setting its session affinity cookies, ASLBSA/ASLBSACORS, on the initial browser requests.
Looking at the screenshot of the document response headers on the initial page load provided by you, I see that the response contains a cache-control header = no-cache, no-store.
As mentioned in the Azure Front Door Premium Session Affinity doc,
Session affinity will be established in the following circumstances beyond the standard non-cacheable scenarios:
- The response must include the Cache-Control header of no-store.
- If the response contains an Authorization header, it must not be expired.
- The response is an HTTP 302 status code.
- And lastly, the backend pools must be HEALTHY.
Below is an example of Successful session affinity:
Now, let's see the points when session affinity will not occur.
Session affinity will NOT occur:
- if the HTTP Response is a 304 (not modified)
- if the backend sends a CACHABLE Response (Example: Blank field)
- Cache Control-Header = NO-CACHE. This is because “no-cache doesn’t mean “don’t cache”, it means it must revalidate with the server before using the cached resource.
Cache-control explanation link: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control
Another important point: Public proxies may interfere with session affinity. This is because establishing a session requires Front Door to add a session affinity cookie to the response, which cannot be done if the response is cacheable as it would disrupt the cookies of other clients requesting the same resource. To protect against this, session affinity will not be established if the origin sends a cacheable response when this is attempted. If the session has already been established, it does not matter if the response from the origin is cacheable.
I see that you've mentioned "We have seen a few instances where the ASLBSA/ASLBSACORS cookies are explicitly set in the first call. This is the behavior I would expect". Though the screenshot is missing, I believe it works for you sometimes.
When I load the site on my end, I can see the ASLBSA/ASLBSACORS cookies present or set in the initial response.
Below is the screenshot of the initial page load response headers on my MS edge new in-private window:
I also tried to load the site on a new chrome In-Cognito browser, and I can still see the ASLBSA/ASLBSACORS cookies present or set in the initial response. Screenshot below:
I tried to load the site multiple times (every time with a new browser window, also tried with a colleague's machine) and each time I can see the ASLBSA/ASLBSACORS cookies set in the initial response.
I'm not really sure if it is the Cache-Control header on your end or some public proxy but were there any changes made? Could you please confirm if it is still not working on your end?
If it is still an issue on your end, could we make sure that the response only has the Cache-Control header of no-store
and try again?
And if the issue still happens, the best approach would be to raise a support request and engage the backend team for assistance. So, if you have a support plan, I request you file a support ticket, else please do let us know, we will try and help you get a one-time free technical support.
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.