لماذا IE/عازف الكمان رؤية مختلفة كوكي إعداد/حذف من الكروم و FF/Live HTTP ؟

Question

لدي جزئيا ورثت تطبيق ويب في PHP و بعد التجول مع عازف الكمان لدي القليل من البيانات أكثر من قبل.المشكلة أنا أحاول حل غير المرغوب فيها logouts على IE6/8 ولكن ليس FF/Chrome.إذا ينقر المستخدم بين صفحات مختلفة, بيانات تسجيل الدخول الكوكيز تتلاشى.

سلوك مختلف في FF مقابلأي و ذكرت معلومات مختلفة تقريبا في نفس الطريق بين عازف الكمان(/IE) و يعيش رؤوس HTTP(/وما يليها).

في فايرفوكس الكوكيز تظهر أن يعامل مثل PHP تحدد:أنها يتم إنشاؤها عندما يقوم المستخدم بتسجيل الدخول و الشيكات "تذكرني" ، وهم حذف فقط إذا كان المستخدم بزيارة صفحة تسجيل الخروج ، ولديهم أسبوعين تاريخ انتهاء الصلاحية.Live HTTP Headers تقرير شيء مختلف:ملفات تعريف الارتباط هي أبدا كما ذكرت يتم تغييرها أو حذفها عندما ينقر المستخدم بين الصفحات.

ولكن مع أي أنها تختفي عندما ينقر المستخدم بين صفحات مختلفة و عازف الكمان التقارير ،

Cookies / Login
    Set-Cookie: *******=deleted; expires=Sun, 29-Jun-2008 21:07:46 GMT; path=; domain=.********.com
    Set-Cookie: *******=deleted; expires=Sun, 29-Jun-2008 21:07:46 GMT; path=; domain=.********.com

('حذف' حرفيا مقتبسة من عازف الكمان الانتاج.ليس لدي أي مكان في التعليمات البرمجية حيث يتم تعيين قيمة السلسلة السحرية من 'حذف'.)

ليس فقط IE و Firefox لديهم تفسيرات مختلفة كيف موقع قوله ولكن العابث و HTTP يعيش رؤوس التقرير في المقابل إصدارات مختلفة من ما يقوم به الموقع.

هل هناك شيء خاص حول أي و 'حذف'?قد يبدو هذا غريبا ولكن لا تريد أي ملفات تعريف الارتباط إلى إعادة تمكين مع كل صفحة عرض أو شيء كهذا ؟

وكيف يمكن استرضاء أي أن يبارك ملفات تعريف الارتباط في مسألة ما لا يتم حذف من قبل الملقم إلا إذا كان المستخدم يطلب ذلك من خلال زيارة الخروج عنوان الموقع ؟

Answer 1

وماذا أنا في نهاية المطاف وجدت كما يلي: فايرفوكس وإنترنت إكسبلورر كانوا يتصرفون بشكل مختلف لأنهم يعالجون التخزين المؤقت بشكل مختلف عندما كانت وثيقة في عداد المفقودين خلال اليوم 14 انتهاء مدة الصلاحية: الرؤوس التي كان من المقرر

. وعلى ما يبدو

وفايرفوكس فحص مرة واحدة لفقدان البيانات، ومن ثم لا يطلب ذلك مرة أخرى.

وIE، من ناحية أخرى، أبقى على التحقق من وجود عنصر وقدم ورقة أنماط الطريق الخطأ ل، وحصلت على 404 صفحة، والصفحة 404 المخصصة قام دعوة المتداول للدخول في هذا أثار المستخدم يتم تسجيل الخروج (ربما لا أفضل النمطي). أعتقد كان مؤقتا الأنماط، لكنها أبقت على IE يسأل عن العناصر التي في عداد المفقودين.

وهكذا كان التخزين المؤقت الاختلافات بالإضافة إلى إدراج غير مباشرة بالإضافة إلى 404 السلوك الصفحة.

وأنا ما زلت لا أعرف ما "حذف" أتوا. (هل PHP توريد كلمة "حذف" إذا قمت بتعيين سلسلة الكعكة إلى قيمة فارغة؟)

Answer 2

وسوف IE لا تعيين ملف تعريف ارتباط إذا كان المضيف لديه تسطير في ذلك، ولكن هذه ليست المشكلة هنا.

وعازف الكمان لا "يخترع" anything-- إذا كان يقول أنه حصل على رأس HTTP تعيين ملف تعريف الارتباط إلى القيمة "حذف"، وهذا يعني أن الملقم أرسل حرفيا ذلك.

وقد ترغب في إلقاء نظرة على ما إذا كان لديك أي طلبات المخطئين الخروج على السلك التي تسبب خادم لحذف ملفات تعريف الارتباط. على سبيل المثال، في موضوع آخر، لاحظ أحدهم أن علامة IMG مع مصدر "" (سلسلة فارغة) من شأنه أن يسبب IE لتقوم بإرسال طلب لجذر للموقع، وموقع على حذف ملفات تعريف الارتباط تسجيل الدخول إذا زار.

وIE6 / 7/8 لديها حاليا حدود 50 ملفات تعريف الارتباط لكل المضيف، ولكن هذا ليس ما كنت تصل هنا أيضا.

Answer 3

لا رابط الصفحة في السؤال تسطير في ذلك ؟ أنا أذكر أي مشاكل مع ملفات تعريف الارتباط من دوميناميس التي لا تتبع اسم المجال مواصفات (RFC 1035 تحقق من قسم 2.3.1).

أيضا هناك (أين؟) بعض القيود في أي وفيما يتعلق كوكي حجم و عدد من ملفات تعريف الارتباط في المجال.في IE6 أعتقد أن الحد هو الحد الأقصى لحجم جميع ملفات تعريف الارتباط في المجال 4095 بايت و 20 الكوكيز في المجال.

المشكلة قد تنشأ أيضا إذا كنت تستخدم رأس القائمة حيث توجيه أي يمكن أن تفقد المسار من الكعكة.

راجع للشغل.تاريخ المقدمة في تعيين ملف تعريف الارتباط توجيهات هم من السجل القديم أو الخادم حقا تعيين ملف تعريف الارتباط مع تاريخ إنتهاء الصلاحية في الماضي (وهو الطريق المعتاد أن أقول.."مرحبا المتصفح حذف ملف تعريف الارتباط هذا كما انتهت بالفعل منذ أيام")