Are there limitations in Episerver that prevents us from turning ARR Affinity off in an non DXC Azure webapp?
I also wonder this. We do not use session state in the application but I noticed that <location path="EPiServer"> has the session state enabled as default.
<pages enableEventValidation="true" enableViewState="true" enableSessionState="true" enableViewStateMac="true">
Even on DXP, the setting can be turn on/off on demand. I can't see any reason why you can't turn it off with your Azure website. I'm happy to learn that I'm wrong, but I don't see it otherwise
Thanks for the answer Quan. My concern is the following setting in the web.config. How will turning off the ARR Affinity in Production (DXP) affect the admin logins? In DXP Prod there're at least 2 servers, is there any risk of getting logged of when the ARR Affinity is turned off?
I don't have an definitive answer for that, but I'm quite sure it should just work. In theory, an admin is just an account. Normally visitors can be served by different instances and they are not automatically logged out.
Btw, you might want to limit admin access to one content authoring instance, that's kind of "best practice" to reduce attack limit.
I'm running my personal blog (on Episerver) with ARR Affinity turned off and sessionstate disabled. No problems.
Hosted in Azure, not DXP.
We've had ARR Affinity off in some Azure projects and also sessions off (who needs those? :D, unless you have some add-ons that rely on asp.net session).
I think one thing that might still require "sticky session" is the Episerver Export or I think it was like that. But it also matters how you have your setup - for example if you have separate single edit instance then the traffic is always anyways going to that instance so you don't need "sticky session" BUT if you have two or more instances serving both the browsing site and edit view then you need to have "sticky session" in some cases to the same instance (if something you use requires asp.net session / stores state there).