manight

"Implements caching of the principal on the server side (aka session mode) if configured in an AppSetting."

Why cache if you can access the cookie? To avoid let's say 16/20kb roundtrip on the wire right? Does it use sessions to cache?

So this means that you only put an identifier in the cookie and then the actual bulk of user info/claims are in-memory on the server (like the dedault session state with all its warts). Again, sometimes you don't want all that bulk in a cookie since even with simple claims I've seen it need at least 2 cookies for overflow).

It does not use session state for the caching and that's the comment about "extensible" -- you can implement your own caching so you can support web farms, app domain recycles, etc.

manight

OT: One question (since you've been so kind with me in the other posts too!) is an empty asp.net session 5kb as it used to be in classic asp or an empty session would just be some bytes for the sessionid?

Session isn't really 'allocated' until you store something in it, so across multiple requests from the same user you won't get a cookie and the server side session ID will be different on multiple requests. I know this isn't what you asked, but it seemed somewhat relevant.

As for the overhead (once you've put something into session), I don't know. I never use session state.

manight

The second things I'm concerned about is the multiple cookies. Shouldn't be 4kb TOTAL per domain considered safe? Or the actual browser will tolerate multiple 4kb cookies? (btw this won't be an issue since I won't exceed the 4kb limit for my purprose)

The spec says 4K per cookie, 20 cookies per host.