كيف تعرف متى إرسال 304 عدم تعديل الرد

Question

أنا أكتب مورد طريقة التعامل مع أين يمكنني التحكم في الوصول إلى مختلف الملفات ، أود أن تكون قادرة على الاستفادة من ذاكرة التخزين المؤقت للمتصفح.سؤالي ذو شقين:

1. والتي هي نهائي رؤوس HTTP أن كنت بحاجة إلى التحقق في الأمر أن نعرف بالتأكيد ما إذا كان يجب إرسال 304 رد ، و ما أنا أبحث عنه عندما لا تحقق لهم ؟

2. بالإضافة إلى ذلك, هل هناك أي الرؤوس التي أنا في حاجة الى ارسال عندما كنت في البداية إرسال الملف (مثل 'آخر تعديل') كما 200 الرد ؟

بعض الزائف رمز ربما يكون الجواب الأكثر فائدة.

---

ماذا عن رأس cache-control?يمكن أن مختلف القيم المحتملة التي تؤثر على ما كنت ترسل إلى العميل (أي max-age) أو ينبغي إلا إذا المعدلة منذ أن يطاع?

Answer 1

وهنا كيف أنا تنفيذه.الكود يعمل منذ أكثر من سنة مع متصفحات متعددة, لذلك اعتقد انها موثوقة جدا.ويستند هذا على RFC 2616 و من خلال مراقبة ما وعندما مختلف المتصفحات تم إرسال.

وهنا شبة الكود:

server_etag = gen_etag_for_this_file(myfile)
etag_from_browser = get_header("Etag")

if etag_from_browser does not exist:
    etag_from_browser = get_header("If-None-Match")
if the browser has quoted the etag:
    strip the quotes (e.g. "foo" --> foo)

set server_etag into http header

if etag_from_browser matches server_etag
    send 304 return code to browser

هنا مقتطف من الخادم المنطق الذي يتعامل مع هذا.

/* the client should set either Etag or If-None-Match */
/* some clients quote the parm, strip quotes if so    */
mketag(etag, &sb);

etagin = apr_table_get(r->headers_in, "Etag");
if (etagin == NULL)
    etagin = apr_table_get(r->headers_in, "If-None-Match");
if (etag != NULL && etag[0] == '"') {
    int sl; 
    sl = strlen(etag);
    memmove(etag, etag+1, sl+1);
    etag[sl-2] = 0;
    logit(2,"etag=:%s:",etag);
}   
... 
apr_table_add(r->headers_out, "ETag", etag);
... 
if (etagin != NULL && strcmp(etagin, etag) == 0) {
    /* if the etag matches, we return a 304 */
    rc = HTTP_NOT_MODIFIED;
}   

إذا كنت تريد بعض المساعدة مع etag الجيل سؤال آخر و سأبحث عن بعض التعليمات البرمجية التي تفعل ذلك أيضا.HTH!

Answer 2

304 عدم تعديل الرد نتيجة الحصول على أو رئيس الطلب إما إذا المعدلة منذ ("IMS") أو إذا-لا-مباراة ("المعهد") رأس.

من أجل أن تقرر ما يجب القيام به عندما تتلقى هذه الرؤوس ، تخيل أنك التعامل مع الحصول على الطلب من دون هذه المشروط رؤوس.تحديد ما هي القيم الخاصة بك ETag آخر تعديل رؤوس سيكون في هذا الرد واستخدامها لاتخاذ القرار.نأمل أن كنت قد بنيت النظام الخاص بك مثل أن تحديد هذا أقل كلفة من بناء إكمال الرد.

إذا كان هناك INM وقيمة هذا الرأس هو نفس قيمة كنت في ETag ، ثم يستجيب مع 304.

إذا كان هناك IMS قيمة تاريخ في الرأس في وقت لاحق من واحد كنت في مكان آخر تعديل ، ثم يستجيب مع 304.

آخر المضي قدما كما لو طلب لا يحتوي على تلك الرؤوس.

على الأقل جهد نهج الجزء 2 من السؤال معرفة أي من (تنتهي ، ETag و الأخيرة المعدلة) رؤوس يمكنك بسهولة وبشكل صحيح تنتج في تطبيق الويب الخاص بك.

المقترحة للقراءة:

http://www.w3.org/Protocols/rfc2616/rfc2616.html

http://www.mnot.net/cache_docs/

Answer 3

يجب عليك إرسال 304 إذا كان العميل قد ذكر صراحة أنه قد سبق الصفحة في الذاكرة المخبئية.وهذا ما يسمى المشروط الحصول عليها ، والتي ينبغي أن تشمل إذا المعدلة منذ رأس في الطلب.

في الأساس, هذا طلب رأس يحتوي على تاريخ من العميل الذي يدعي أن النسخة المخزنة مؤقتا.عليك التأكد من أن المحتوى قد تغير بعد هذا التاريخ وإرسال 304 إذا لم.

انظر http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.25 ذات الصلة القسم في RFC.

Answer 4

ونحن أيضا التعامل مؤقتا ، ولكن المضمون ، الموارد.إذا قمت بإرسال / توليد ETAg رأس (التي RFC 2616 القسم 13.3 يوصي عليك) ، ثم يجب على العميل استخدامه في المشروط الطلب (عادة في لو-لا شيء-مباراة - HTTP_IF_NONE_MATCH - رأس).إذا قمت بإرسال آخر تعديل رأس (مرة أخرى يجب عليك) ، ثم يجب عليك التحقق إذا المعدلة منذ HTTP_IF_MODIFIED_SINCE رأس.إذا كنت ترسل على حد سواء ، ثم يجب على العميل إرسال سواء ، ولكن يجب أن ترسل ETag.نلاحظ أيضا أن validtion هو مجرد تعريف التحقق المشروط رؤوس المساواة التامة ضد تلك التي كنت ترسل بها.أيضا, فقط قوي المصادقة (مثل ETag) سيتم استخدامها تراوحت طلبات (حيث لا يوجد سوى جزء من الموارد المطلوبة).

في الممارسة العملية ، حيث الموارد نحمي هي ثابتة إلى حد ما ، ومجموعة ثانية واحدة تأخر الوقت غير مقبول ، نحن القيام بما يلي:

1. تحقق لمعرفة ما إذا كان يسمح للمستخدم الوصول إلى الموارد المطلوبة

   إذا لم يتم إعادة توجيه لهم أو إرسال 4xx الاستجابة المناسبة.سوف تولد 404 الردود على الطلبات التي تبدو وكأنها محاولات الإختراق أو الصارخة يحاول أداء الأمن في نهاية المدى.

2. قارن إذا المعدلة منذ رأس آخر تعديل رأس نرسل (انظر أدناه) للحصول على المساواة التامة

   إذا كانت تطابق إرسال 304 عدم تعديل الرد والخروج معالجة الصفحة

3. خلق آخر تعديل رأس باستخدام تعديل الوقت من الموارد المطلوبة

   البحث عن HTTP تنسيق التاريخ في RFC 2616

4. إرسال رأس الموارد المحتوى جنبا إلى جنب مع نوع المحتوى الملائم

قررنا أن نتجنب ETag رأس لأنها مبالغة لأغراضنا.أعتقد أننا يمكن أيضا استخدام التاريخ والوقت الطوابع كما ETag.إذا ننتقل إلى صحيح ETag النظام ، فإننا على الأرجح متجر حسابها التجزئة على موارد استخدام هذه ETags.

إذا كان لديك الموارد التي تم إنشاؤها بشكل حيوي ، من قاعدة بيانات المحتوى ، ثم ETags قد يكون من الأفضل لتلبية الاحتياجات الخاصة بك لأنها مجرد نص بالسكان على النحو الذي تراه مناسبا.

Answer 5

فيما يتعلق cache-control:

لا يجب أن تقلق بشأن cache-control عندما يقضي بخلاف تعيين إلى قيمة معقولة.انها في الاساس تقول المتصفح وغيرها من المصب الكيانات (مثل وكيل) الحد الأقصى للوقت الذي يجب أن ينقضي قبل مهلة ذاكرة التخزين المؤقت.