IE 8 and 9 does not send the cookie on the next request. It works in Chrome 14 and FF 6.

In my case I've got an ASP.NET 3.5 web app running that uses cookies for authentication. If the cookie is not present, the user gets redirected to the login page.

The infrastructure is the following. A parent application embeds my ASP.NET page in an iframe. The ASP.NET app is not targeted directly, but via a load balancer. Between the parent page and the load balancer a HTTPS connection is used. Load balancer it self goes via another IIS-Proxy to the actual ASP.NET app, but this connection is made via standard HTTP. The parent app and the ASP.NET app are not running in the same domain.

The cookie is marked as 'HTTP only'. Jeff Atwood has a good blog post about 'HTTP only'-cookies, but still does not say, if cookies get sent over HTTPs as well.

After I log into the ASP.NET page the response contains the cookie and a redirect. When the browser executes the redirect, the cookie is not included in the request. That is why the ASP.NET app is assuming a new user and redirects to the login page again.

So my question here is I guess, why is IE not sending the cookie. Is it because the cookie is marked as 'HTTP only'? If that's the case, can anybody tell me how to disable this ASP.NET feature? In the forums its said, that you can not turn this off. But I found a sort of clunky way of disabling it, which I would like to avoid, if possible.

BTW, it works fine, if I add the ASP.NET url to the trusted sites. I need to avoid these by any means.

UPDATE 1: Interesting enough, if I go straight to the load balancer via HTTPS, which sits in front of the ASP.NET page, the cookie will be sent correctly to the load balancer. Only if the site sits within an iframe in the parent page - that carries the invalid certificate - the cookies aren't sent.

UPDATE 2: To illustrate the scenario, I've added 2 pics describing the architecture. The first one explains the environment and the second one shows the process of the 2 requests beeing made by the IFrame. The response to the first request contains 2 cookies. The following request to the exact same app does not include the cookies. The cookies get send though, if I either a) add the load balancer (and the ASP.NET app at the end) to the trusted sites or b) go straight to the load balancer (and the ASP.NET app at the end) in the browser and not via the parent page that hosts the IFrame. Sorry, I would love to add the pics, but I don't have 10 reps, so Serverfault does not allow me...

UPDATE 3: The parent page and the ASP.NET page are hosted on different domains. Example: - Parent page yourapp.com - ASP.NET page hosted in iframe: myapp.com


It turns out IE does not send a cookie in a cross domain scenario over HTTPS.

To solve I had to add a custom P3P header. Scott Hanselman has an interesting article on that topic.

In an ASP.NET scenario you can either add the custom header via IIS or in your application in the Global.asax. Here is an explanation of that.

| improve this answer | |

It is because the cookie is marked HTTP only. IE assumes that an HTTP only cookie should only be sent back to precisely the source it came from. It does not consider HTTPS and HTTP sources equivalent. Arguably, this is more logical -- if I received an HTTP only cookie over a secure connection, why would I want to send it over an insecure connection?

There is a workaround -- don't set the cookie HTTP only on the HTTPS page. Instead, on the redirected HTTP page, set the cookie again, but this time set it HTTP only. This should resolve the problem.

(Just for grins, double-check that the URL links to the exact same hostname. Don't redirect www.mydomain.com to mydomain.com for example.)

| improve this answer | |
  • Interesting enough, if I go straight to the load balancer via HTTPS, which sits in front of the ASP.NET page, the cookie will be sent correctly to the load balancer. – derSteve Oct 5 '11 at 14:08
  • BTW, why did you vote the question down? That seems very odd. – derSteve Oct 5 '11 at 14:08
  • That wasn't me. – David Schwartz Oct 5 '11 at 14:17
  • Ok, sorry :-) My fault – derSteve Oct 5 '11 at 14:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.