Классический ASP читает файлы cookie .NET в Firefox, но не IE

Question

Возникла проблема с ASP.NET при попытке установить cookie на subdomain1.mydomain.com для чтения на subdomain2.mydomain.com.

«subdomain1» - приложение ASP.NET , работающее на IIS 6. «subdomain2» - приложение ASP Classic , работающее на IIS6.

Чего я не понимаю, так это того, что когда я тестирую свою страницу .NET (ниже) в Firefox, она работает. Если я тестирую его под IE8, кажется, что cookie не сохраняется / передается на поддомен2. Я пробовал много вариантов кода ниже, но безрезультатно (включая добавление даты / времени истечения):

Dim k As Guid = Guid.NewGuid
Dim c As New HttpCookie("Interstitial")

With c
.Values("a") = 1
.Values("b") = 2
.Values("c") = 3
.Values("d") = 4
.Domain = ".mydomain.com"
End With

Response.AppendCookie(c) 'Have also used Response.Cookies.Add(c)

Dim url As String = String.Format("https://subdomain2.mydomain.com/?d={0}", k.ToString)

Response.Redirect(url)

Другая информация, которая может иметь отношение к делу:

• Приведенный выше код выполняется в ответ на обратную передачу (нажатие кнопки)
• В IE8, response.redirect (), по-видимому, приводит к тому, что запрос браузера никогда не завершается

Любые советы / идеи будут с благодарностью.

Спасибо

Answer 1

Вы пробовали запустить страницу через Fiddler ? Это замечательный инструмент, поскольку он показывает всю активность HTTP для запроса.

Раньше у меня были проблемы, когда возникали странные проблемы с браузером, которые в конечном итоге оказывались достаточно эзотерическими, как конфигурация сети. Fiddler отлично справляется с такими проблемами.

Answer 2

Я верю в это по замыслу (возможно, глючная конструкция). WinINET сознательно решает не пересылать файлы cookie, установленные в ответе на перенаправление в последующем запросе, если запрос не находится в том же домене.

Не цитируйте меня, но я полагаю, что это является результатом исправления безопасности для ошибки, при которой WinINET перенаправлял любые cookie в заголовки Set-Cookie ответа перенаправления на местоположение перенаправления, даже если пункт назначения не был в тот же домен.

Я подозреваю, что исправление этой ошибки более драконовское, чем нужно.