Nur einige Set-Cookie-Anweisungen in HttpWebResponse geehrt für das nächste HttpWebRequest

Question

Ich sehe einige sehr seltsame Verhalten hier:

Ich verwende HttpWebRequest/HttpWebResponse mit einem festen Objekt Cookie. .NET 4, Windows Server 2008 R2.

Auf einer Maschine (meine Dev-Maschine) Ich sehe das erwartete Verhalten:

eine Antwort enthält die folgenden:

Set-Cookie: m-aid=rm=false&un=systestseller&uid=68818c42-cb63-4d37-8daf-9e6e0130f72c&hp=true; expires=Fri, 31-Dec-9999 23:59:59 GMT; path=/; HttpOnly 
Set-Cookie: m-pc=sim=Normal; expires=Fri, 31-Dec-9999 23:59:59 GMT; path=/; HttpOnly 
Set-Cookie: m-f-auth=D8EC2D07743011DCC62EE52C968A649E419CDC3F476CC9EF04AE7D096E36CEE51DF2289E69C1D990809156CDD5DC6483DDFAAD101ED41E5890D4E6B7467E6F4F8705ED9BA7D358C9C878F5437CE9FC3FE47F8EB878E5CC8219B8767BD001AF7A; path=/; secure; HttpOnly 

Ergebnisse in der folgenden Anforderung enthält jedoch

Cookie: arr=2ce1b36a3ef29aa4c45128f8c08ac603debf2063c752e843291a90fb8936899d; m-aid=rm=false&un=systestseller&uid=68818c42-cb63-4d37-8daf-9e6e0130f72c&hp=true; m-pc=sim=Normal; m-f-auth=D8EC2D07743011DCC62EE52C968A649E419CDC3F476CC9EF04AE7D096E36CEE51DF2289E69C1D990809156CDD5DC6483DDFAAD101ED41E5890D4E6B7467E6F4F8705ED9BA7D358C9C878F5437CE9FC3FE47F8EB878E5CC8219B8767BD001AF7A 

auf einer anderen Maschine, sehe ich die nächste Anfrage enthalten nur

Cookie: arr=2ce1b36a3ef29aa4c45128f8c08ac603debf2063c752e843291a90fb8936899d; 

Mit anderen Worten, nur der arr-Cookie und nicht die anderen werden erstellt.

Beim Debuggen des Codes enthält die HttpWebResponse tatsächlich nur den arr cookie in seiner Cookies-Sammlung.

Wer hat irgendwelche Ideen? Es treibt mich in den Wahnsinn.

Answer 1

Dies bezieht sich eigentlich auf Zeitzonen.

Cookie-Ablauf wird in UTC angenommen, das bedeutet, dass .NET den Ablaufparameter für Ihre aktuellen lokalen Einstellungen anpasst. Da alle fehlenden Cookies einen Ablauf von DateTime.MaxValue haben und Ihr Produktionsserver höchstwahrscheinlich in einer Zeitzone von +1 oder mehr lebt, fügt .NET die lokale Zeitverschiebung hinzu, kommt zu einem ungültigen Datum und verwirft den Cookie als "nicht relevant".

Während dies schien nicht ein Problem mit .net 2.0 (entdeckte dieses Problem nach dem Upgrade Framework), Es ist offenbar hier zu bleiben, da ein Downgrade des Codes das Problem nicht beseitigt.

Answer 2

Meine Vermutung ist, dass das Problem etwas mit der Variation von URLs zwischen Ihrem Dev-Server und Ihrem Produktionsserver zu tun hat. Wenn sich der Hostname der Anfrage Nr. 1 vom Hostnamen der Anfrage Nr. 2 unterscheidet (selbst eine Weiterleitung von www.foo.com zu foo.com), werden die in einem Anruf von Anfrage Nr. 1 erhaltenen Cookies nicht an Anfrage Nr. 2 gesendet.

Können Sie die spezifischen URLs (für beide Anfragen), die erfolgreich auf Ihrem Dev-Server verwendet wurden, und die URLs, die in der Produktion fehlschlagen, auflisten?

Beachten Sie, dass eines Ihrer Cookies als sicher gekennzeichnet ist, dh dass es nicht an Nicht-HTTPS-Anfragen gesendet wird. Dies führt nicht zu dem Problem, das Sie sehen (weil in Ihrem Fall keines der Cookies beibehalten wird), würde aber ein Problem verursachen, bei dem zwei der Cookies an eine HTTP-Anfrage gesendet werden, die dritte jedoch nicht.

Auch ich bin fasziniert, dass ein Cookie, arr, an den Server gesendet wird, vermutlich von einer noch früheren Anfrage. Was macht diese vorherige Anfrage anders als Ihre nachfolgende fehlgeschlagene Anfrage?

BTW, wenn Sie das Problem nicht lösen können, können Sie immer manuell Cookies aus HTTP-Headern abrufen und setzen. Werfen Sie einen Blick auf meine Antwort auf this question für Beispielcode, um dies zu tun.