Standard Microsoft CDN removes set-cookie header for ASP.NET_SessionId cookie RRS feed

  • Question

  • My site uses ASP.NET_SessionId cookies. This is standard ASP.NET header used for session management. CDN itself removes some headers from the response: in this case, the browser is not receiving "set-cookie" header for "ASP.NET_SessionId", despite the fact, it was sent by the web site (see screenshots below).

    The home page is dynamic and is not intended to be cached. Also, page sets "no-cache" header.

    This happens only with Azure CDN with Standard Microsoft profile.

    This is standard Microsoft ASP.NET session management header.


    Original response headers:

    Screenshot with two set-cookie headers, including ASP.NET_SessionId

    As you can see there are two "Set-Cookie" headers.


    CDN-ified response headers:

    As you can see only one "Set-Cookie" header left.


    I cannot find any documentation on how to allow all headers to pass-through.

    Could you please provide any ideas on how to solve this issue?

    Thank you!

    • Edited by SIGAN Friday, June 14, 2019 7:01 PM
    Thursday, June 13, 2019 4:20 PM


All replies

  • As a quick check please try with cookieless sessions by enabling them in your web.config file of your ASP.net app. If that doesn't help then please let us know for deeper investigation.



    Saturday, June 15, 2019 5:19 PM
  • I believe this is not normal behavior for CDN to remove some headers. It is also not documented on MSDN.

    Unfortunately, in this case I cannot use cookieless sessions.

    Tuesday, June 18, 2019 12:59 AM
  • I tried to reproduce this issue with ASP.net Web-application and generated a SET-Cookie header with session ID but haven't integrated this with azure CDN. Could you explain your architecture with azure CDN and asp.net web application? Just to understand the workflow on how your app is integrated with azure CDN.

    Thursday, June 20, 2019 5:45 PM
  • So I found a public website with similar cookies.

    I have created a Standard Microsoft CDN on my subscription on top of that site.

    The following is the link to the CDN: https://test-igor-cdn.azureedge.net

    Did the test and the same issue is still there.

    How to reproduce:
    1. cleanup cache & cookies
    2. open Telerik Fiddler2 or any other network monitoring tool, including browser development tool
    3. Navigate to https://www.pmi.org
    4. Check the root page request: two (!) set-cookie headers present in the response. (pic 1 below).
    5. cleanup cache & cookies
    6. Navigate to https://test-igor-cdn.azureedge.net
    7. Check the root page request: only one (!) set-cookie headers present in the response. (pic 2 below).

    I believe for such a simple and obvious scenario you don't need any architecture or any traffic flow.

    It is clear that Microsoft CDN truncates headers on its own, which is a really bad idea.

    Pic 1 (No CDN present):

    Pic 2 (With CDN present):

    Friday, July 19, 2019 8:04 PM
  • Got an answer from the support.

    Microsoft confirmed that issue (already know about it) and they are working on resolving it. No ETA or workaround provided.

    Monday, August 5, 2019 3:56 PM
  • Thanks for reaching out. Let me check with the respective team whether there is any ETA for this issue.
    Tuesday, August 6, 2019 5:49 AM
  • I have found that if the origin returns multiple Set-Cookie headers, Microsoft CDN will only respond with the last one sent. As far as I can tell, multiple Set-Cookie response headers are valid.

    In your case, it is the ASP.NET SessionId that is omitted, but I think that is only because it is the first of 2 Set-Cookie headers.

    I am unaware of how to circumvent this limitation of Microsoft CDN however.

    Wednesday, August 14, 2019 7:12 PM
  • The Azure Front Door has absolutely the same issue when caching enabled (I suppose the same Microsoft CDN is used internally there).

    Limiting HTTP response to just one cookie is VERY critical bug preventing a lot of business applications to operate behind Azure Front Door.

    Please provide ETA.

    Monday, August 19, 2019 7:20 PM
  • This issue has been fixed now. Please re-test and let us know if you find any issues.
    Tuesday, September 17, 2019 10:19 PM
  • Yes, it works now. Thank you!
    Thursday, October 24, 2019 9:34 PM