حالة HTTP 304 Not Modified

الخلاصة — تعني استجابة 304 Not Modified أن الخادم يقول: «لديك هذه النسخة بالفعل، وما زالت صالحة؛ لا تنزلها مرة أخرى». إنها ليست خطأ، ورغم وجودها في عائلة 3xx «إعادة التوجيه» فإنها لا ترسل أحدًا إلى عنوان جديد. ولا تحدث إلا عندما يرسل العميل (متصفحًا أو زاحفًا) أولًا طلبًا مشروطًا يسأل: «هل تغير هذا منذ آخر مرة؟». لا تنقل ترتيبك في SEO، لكنها في المواقع الكبيرة قد تساعد محركات البحث على استخدام مواردها بكفاءة أكبر.

ما هي 304 فعلًا؟

تبدأ كل استجابة يرسلها خادمك برمز حالة من ثلاثة أرقام. تعني 200 OK: «هذه هي الصفحة، بالجسم وكل شيء». أما 304 Not Modified فتعني شيئًا أكثر تحديدًا: أرسل العميل طلبًا مشروطًا يقول «أعطني هذه الصفحة، لكن فقط إذا تغيرت»، وقرر الخادم أنها لم تتغير؛ لذلك، بدل 200 التي كان سيرسلها، يرد بـ304 بلا جسم إطلاقًا. وهذه هي القاعدة الفعلية: لا تكون 304 إلا جوابًا عن طلب GET أو HEAD مشروط انتهى شرطه إلى false.

تُعد الزيارة الثانية الطريقة الشائعة لحدوث ذلك، وهي صورة مفيدة للفهم: في المرة الأولى التي يجلب فيها متصفح أو زاحف صفحة، يحصل على 200 عادية بالمحتوى الكامل، ومعها رأسا «بصمة» صغيران. وفي الزيارة التالية يعرض العميل تلك البصمة على الخادم ويسأل: «هل ما زالت هي نفسها؟». إذا لم يتغير شيء، يجيب الخادم 304 ولا يرسل جسم الصفحة، ويعيد العميل استخدام النسخة الموجودة لديه. لكن «الزيارة الثانية» مثال لا قاعدة بروتوكول؛ والمحفز الحقيقي لـ304 هو الطلب المشروط نفسه مهما كانت طريقة وصوله. Evidence for this claim RFC 9110 defines 304 Not Modified as the response to a conditional GET or HEAD when the selected representation has not changed and says the response cannot contain content. Scope: HTTP semantics for 304 conditional responses. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.4.5 — 304 Not Modified

لماذا تقع في عائلة «إعادة التوجيه» من دون أن تكون إعادة توجيه؟

تبدأ 304 بالرقم 3، وهو الفئة التي يستخدمها HTTP لإعادة التوجيه، ولذلك تربك الناس باستمرار. لكن 304 لا تحمل رأس Location ولا ترسلك إلى عنوان مختلف؛ فلا ينتقل أحد إلى أي مكان. إنها تعيد العميل ببساطة إلى نسخته المحفوظة لديه. لذلك فـ«عائلة إعادة التوجيه» حيلة ترقيم لا وصفًا لوظيفتها.

هل 304 مشكلة؟

لا. إن رؤية 304 في تبويب Network في متصفحك أو في تقرير زحف علامة على أن التخزين المؤقت يعمل، وهذا ما تريده بالضبط. تتعامل نصائح كثيرة عن «خطأ 304 وكيفية إصلاحه» مع الحالة كأن شيئًا معطلًا لديك. لكنها ليست كذلك؛ إنها النتيجة الصحيحة المقصودة لذاكرة تخزين مؤقت تعمل جيدًا.

هل تساعد SEO؟

ليس ترتيبك مباشرة. تملك Google المحتوى من آخر مرة زحفت فيها إلى الصفحة؛ وتؤكد 304 فقط أنه لم يتغير، فتواصل Google استخدام ما خزّنته (وقد يعيد Search حساب إشارات عنوان URL، لكن 304 نفسها ليست مكافأة ترتيب أو فهرسة). أما ما تساعد فيه فعلًا فهو كفاءة الموارد: إذا لم تضطر محرك البحث إلى إعادة تنزيل صفحات لم تتغير، وفرت النطاق الترددي والحساب على الجانبين، وهو ما تقول Google إنه قد يساعد الزحف على العمل بكفاءة أكبر بصورة غير مباشرة؛ لكنه ليس ضمانًا لإعادة توجيه الجهد الموفر تلقائيًا إلى صفحاتك الجديدة أو المحدثة. وتهم هذه الفائدة أكثر في المواقع الكبيرة ذات الصفحات الكثيرة التي نادرًا ما تتغير.

إذا أردت الآلية الحقيقية — ETags وIf-None-Match وvalidators القوية والضعيفة وكيفية التنفيذ وما قالته Google فعلًا — فانتقل إلى تبويب Advanced.

الخلاصة — 304 هي استجابة GET أو HEAD مشروط انتهى شرطه إلى false، وكان سيحصل على 200 لولا ذلك (RFC 9110 §15.4.5). وهي من فئة 3xx لكنها ليست إعادة توجيه: لا Location ولا عنوان جديد، وبحسب النص المعياري لا جسم («لا يمكنها أن تحتوي على محتوى أو ذيول»). يحمل الشرط If-None-Match مقابل ETag و/أو If-Modified-Since مقابل Last-Modified؛ فإذا ظل validator مطابقًا، يعيد الخادم 304 ويعيد العميل استخدام التخزين المؤقت. لا تأثير مباشر لها في الترتيب؛ فـGoogle تملك المحتوى أصلًا، مع احتمال إعادة Search حساب إشارات عنوان URL، وتوفر الموارد في المواقع الكبيرة (تقول Google إنه قد يحسن كفاءة الزحف بصورة غير مباشرة، لكنها لا تضمن إعادة توزيع ميزانية الزحف). تدعم بنية زحف Google كلا validator وتوصي بـETag بوصفه الأساسي لأنه لا يعاني من مشكلات تنسيق التاريخ. قارنها بـ301/302/307/308 التي تنقل عنوان URL، وبـ204 التي تخلو من الجسم لأن لا شيء موجودًا للإرسال.

ما معنى 304 في المواصفة؟

تعرّف RFC 9110 (دلالات HTTP) §15.4.5 الحالة بدقة: “The 304 (Not Modified) status code indicates that a conditional GET or HEAD request has been received and would have resulted in a 200 (OK) response if it were not for the fact that the condition evaluated to false.” (ترجمة) «تشير حالة 304 (غير معدّل) إلى أن طلب GET أو HEAD مشروطًا وصل، وكان سيؤدي إلى استجابة 200 (OK) لولا أن الشرط قيّم على أنه خاطئ.» هذا هو المحفز المعياري الفعلي: طلب GET أو HEAD مشروط قيّم شرطه على أنه خاطئ، وكان سيحصل بخلاف ذلك على 200. بعبارة عملية، طلب العميل الصفحة فقط إذا تغيرت، فقرر الخادم أنها لم تتغير وتجاوز إرسال الجسم. Evidence for this claim RFC 9110 defines 304 Not Modified as the response to a conditional GET or HEAD when the selected representation has not changed and says the response cannot contain content. Scope: HTTP semantics for 304 conditional responses. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.4.5 — 304 Not Modified

تستخدم المواصفة نفسها كلمة “redirecting” في هذا القسم — “the server is therefore redirecting the client to make use of that stored representation as if it were the content of a 200 (OK) response” (ترجمة) «يقول الخادم إنه يعيد توجيه العميل ليستفيد من التمثيل المخزن كما لو كان محتوى استجابة 200 (OK).» لكن اقرأها بعناية: إنها تعيد العميل إلى ذاكرته المؤقتة، لا إلى عنوان URL آخر. فلا توجد ترويسة Location ولا عنوان جديد؛ ولهذا يلتبس على الناس ما إذا كانت 304 إعادة توجيه. وهي ليست كذلك بالمعنى الخاص بـHTTP.

تهم نقطتان معياريتان إضافيتان:

• لا جسم أبدًا. تقول RFC 9110: “A 304 response is terminated by the end of the header section; it cannot contain content or trailers.” (ترجمة) «تنتهي استجابة 304 عند نهاية قسم الترويسات؛ ولا يمكنها أن تحتوي على محتوى أو ذيول.» والاستجابة 304 التي تحمل جسمًا تخالف المواصفة وقد تربك بعض العملاء؛ وهذه قاعدة حازمة لا تفضيل أسلوبي.
• تحمل البيانات الوصفية نفسها التي كانت ستحملها 200. يجب على الخادم إنشاء حقول الترويسة التي كانت ستُرسل في استجابة 200: “MUST generate any of the following header fields that would have been sent in a 200 (OK) response to the same request: Content-Location, Date, ETag, and Vary” (ترجمة) «يجب أن ينشئ أيًا من حقول الترويسة التالية التي كانت ستُرسل في 200 للطلب نفسه: Content-Location وDate وETag وVary»، إضافة إلى Cache-Control وExpires عند الاقتضاء. وهكذا تكون 304 ترويسات 200 من دون الحمولة.

كيف تعمل 304 فعلًا: الطلبات المشروطة

لا يرسل الخادم 304 من تلقاء نفسه. إنها دائمًا استجابة لـطلب مشروط؛ أي طلب يجعله العميل مشروطًا بإرفاق validator حفظه من استجابة سابقة. وهناك نوعان من validators.

ETag وIf-None-Match

إن ETag (وسم الكيان) رمز معتم يرفقه الخادم باستجابة 200؛ فكر فيه كبصمة إصدار للتمثيل الدقيق لعنوان URL. وفي الطلب التالي لذلك العنوان، يرسل العميل القيمة المحفوظة في رأس If-None-Match. يقارن الخادم: إذا ظل ETag الحالي مطابقًا، فلم يتغير شيء، فيعيد 304؛ وإذا اختلف، فيعيد 200 جديدة بالمحتوى الجديد وETag جديدًا.

Last-Modified وIf-Modified-Since

البديل القائم على التاريخ: يرسل الخادم طابع Last-Modified مع 200. وفي المرة التالية يعيده العميل في رأس If-Modified-Since، ويقارن الخادم التواريخ؛ فإذا لم يتغير المورد منذ ذلك الطابع، يعيد 304. وهذا أبسط لكنه أقل دقة (بدقة الطابع الزمني فقط) وحساس لتنسيق تاريخ HTTP الدقيق، وهو مصدر شائع للأخطاء. وعند وجود validator الاثنين، يتقدم If-None-Match (أي ETag) على If-Modified-Since.

ETags قوية وضعيفة

يمكن أن يكون ETag قويًا أو ضعيفًا، ويهم الفرق. وفق إرشادات MDN للطلبات المشروطة، «يتكون التحقق القوي من ضمان أن المورد مطابق، بايتًا ببايت، للمورد الذي يُقارن به». ويُسبق ETag الضعيف بـW/ (مثل ETag: W/"abc123") ولا يثبت إلا التكافؤ الدلالي؛ ومثال MDN أن «صفحة تختلف عن أخرى فقط بسبب تاريخ مختلف في تذييلها أو إعلان مختلف ستُعد مطابقة للأخرى عند التحقق الضعيف». وتلزم ETags القوية (من دون بادئة) لأشياء مثل طلبات النطاق التي تحتاج تطابقًا بايتيًا؛ وتفيد الضعيفة عندما لا ينبغي للاختلاف في الضغط أو المسافات البيضاء أو فروق تافهة غير جوهرية أن يفرض جلبًا كاملًا جديدًا. والفخ العملي: إذا تغير ETag كلما أعيد ضغط المحتوى بـgzip أو Brotli، أو اختلف بين خوادم موازنة الحمل، فستطلق عمليات زحف غير ضرورية؛ اختر القوي أو الضعيف عمدًا وحافظ على استقرار القيمة للمحتوى الذي لم يتغير فعلًا.

المصافحة الكاملة خطوة بخطوة

1. الطلب الأول → يعيد الخادم 200 OK مع المحتوى، وETag و/أو Last-Modified.
2. يخزن العميل المحتوى وvalidator تلك.
3. الطلب التالي → يرسل العميل If-None-Match و/أو If-Modified-Since مع القيم المخزنة.
4. يقرر الخادم: لم يتغير → 304 Not Modified بلا جسم، ويعيد العميل استخدام التخزين المؤقت؛ تغير → 200 OK بالجسم الجديد وvalidator حديث.

إذا أردت المعالجة الأعمق للتخزين المؤقت وvalidators بوصفها وسيلة لكفاءة الزحف — قصة الطلبات المشروطة كاملة وصلتها بميزانية الزحف — فهذا موضوع مرافق؛ أما هذا المقال فيركز على رمز الحالة.

304 وSEO: لا أثر في الترتيب، وأثر حقيقي في كفاءة الزحف

هذه هي قصة SEO كاملة، وهي أضيق مما توحي به كثير من العبارات الجاهزة في المدونات. لا أثر مباشر لـ304 في الترتيب، كما أن إرشادات Google حول تأثير رموز الحالة في الزحف والفهرسة تحد أثر الفهرسة أيضًا: قد يعيد Search حساب إشارات عنوان URL، لكن 304 لا تغير بخلاف ذلك طريقة فهرسة الصفحة. تملك Google المحتوى من الزحف السابق؛ وتؤكد 304 فقط أنه لم يتغير، فتواصل استخدامه. ولا توجد مكافأة ترتيب لإعادة 304.

ما تمنحك إياه 304 فعلًا هو توفير موارد قد يحسن كفاءة الزحف بصورة غير مباشرة. ففي منشور Google Search Central عن تخزين HTTP المؤقت في ديسمبر 2024، قال Gary Illyes بوضوح: «خصوصًا إذا كان لديك موقع كبير ذو محتوى نادر التغير تحت عناوين URL فردية، فقد يساعد السماح بالتخزين المؤقت محليًا على زحف موقعك بكفاءة أكبر. وتدعم بنية زحف Google التخزين المؤقت الاستدلالي في HTTP كما تحدده مواصفة التخزين المؤقت، وبخاصة عبر رأس استجابة ETag ورأس طلب If-None-Match، ورأس استجابة Last-Modified ورأس طلب If-Modified-Since».

وفي آلية 304 الدقيقة، يوضح المنشور نفسه لماذا يمثل الجسم الفارغ النقطة الأساسية: إذا كانت قيمة ETag التي يرسلها الزاحف «تطابق القيمة الحالية التي أنشأها الخادم، فعلى خادمك إعادة رمز حالة HTTP 304 (Not modified) من دون جسم HTTP»، وتهم عبارة «من دون جسم HTTP» لأن «خادمك لا يضطر إلى استهلاك موارد الحساب في إنشاء المحتوى فعلًا» ولا «إلى نقل جسم HTTP»؛ فتوفّر الحساب والنطاق الترددي على الجانبين. وصياغة Google للفائدة اللاحقة مشروطة: قد تؤدي وفورات الموارد إلى تحسين كفاءة الزحف بصورة غير مباشرة. وليست وعدًا بإعادة توزيع الجهد الموفر تلقائيًا إلى عناوينك الجديدة أو المحدثة؛ تعامل معها كآلية توفير موارد ذات فائدة محتملة لا مضمونة.

لماذا يهم ذلك أكثر في المواقع الكبيرة؟

إذا كان لديك بضع مئات من الصفحات، فهذه مسألة نظرية إلى حد كبير؛ ستزحف Google إلى موقعك كله بسهولة في جميع الأحوال. وتتوسع الفائدة مع الحجم: فالموقع الذي يملك مئات الآلاف أو ملايين عناوين URL، وكثير منها نادر التغير، يستفيد ماديًا عندما تتجنب الزواحف إعادة جلب كل النسخ التي لم تتغير. وهذا هو الجمهور الذي يستهدفه منشور Google؛ وهي الصياغة الصادقة التي ينبغي الحفاظ عليها، فلا تبالغ في بيع 304 كتكتيك للمواقع الصغيرة.

ETag أم Last-Modified، وما الذي يعد «تغيرًا»؟

توصي Google بـETag بوصفه validator الأساسي: «نوصي بشدة باستخدام ETag لأنه أقل عرضة للأخطاء والهفوات (فقيمته غير منظمة، بخلاف قيمة Last-Modified)». ولا بأس باستخدام الاثنين بل هو مشجع. وإذا استخدمت Last-Modified، «فيجب تنسيق التاريخ وفق معيار HTTP»؛ وتوصي Google بصيغة «Weekday, DD Mon YYYY HH:MM:SS Timezone»، مثل «Fri, 4 Sep 1998 19:15:56 GMT»، وإلا فقد يتم تجاهله بصمت. وتقترح Google أيضًا ضبط حقل max-age في Cache-Control لمساعدة الزواحف على تقرير وقت إعادة الزحف. وتحفظ هذه الوحدة العبارات المصدرية: “We strongly recommend using ETag because it’s less prone to errors and mistakes (the value is not structured unlike the Last-Modified value).” (ترجمة) «نوصي بشدة باستخدام ETag لأنه أقل عرضة للأخطاء والهفوات (فقيمته غير منظمة، بخلاف قيمة Last-Modified).» و*“Weekday, DD Mon YYYY HH:MM:SS Timezone,”* (ترجمة) «Weekday, DD Mon YYYY HH:MM:SS Timezone،» و*“Our recommendation is that you require a cache refresh on significant changes to your content; if you only updated the copyright date at the bottom of your page, that’s probably not significant.”* (ترجمة) «نوصي بأن تشترط تحديث التخزين المؤقت عند حدوث تغييرات مهمة في المحتوى؛ وإذا لم تكن قد حدثت إلا سنة حقوق النشر في أسفل الصفحة، فذلك على الأرجح غير مهم.» و*“If my server returns 304, Google will use stale content forever.”* (ترجمة) «إذا أعاد خادمي 304، فستستخدم Google المحتوى القديم إلى الأبد.»

قرار ما يعد تغييرًا يستحق إبطال التخزين المؤقت يعود إليك، لكن نصيحة Google هي حصره في التغييرات الجوهرية: «نوصي بأن تشترط تحديث التخزين المؤقت عند حدوث تغييرات مهمة في المحتوى؛ وإذا لم تكن قد حدثت إلا سنة حقوق النشر في أسفل الصفحة، فذلك على الأرجح غير مهم».

ماذا يفعل Googlebot وBingbot فعلًا؟

ليست كل طلبات الزواحف مشروطة. توضح وثائق زحف Google أن دعم التخزين المؤقت يختلف بين زواحف Google وجالباتها بحسب المنتج الذي تخدمه؛ فـGooglebot يدعم التخزين المؤقت عند إعادة الزحف إلى عناوين URL للبحث، بينما لا تدعمه بعض جالبات Google الأخرى إلا في شروط معينة. لذلك، حتى مع ضبط الرؤوس صحيحًا، لا تتوقع أن تحمل 100% من الطلبات If-None-Match أو If-Modified-Since. وبالنسبة إلى Bing، فالطلبات المشروطة ليست ميزة خاصة بـGoogle؛ إذ يدعم زاحف Bing طلب GET مشروطًا (يرسل If-Modified-Since و، عند توفره، If-None-Match ويقبل 304 عند عدم تغير المحتوى) منذ تدوينة Live Search في 2008 على الأقل، مع أن Bing لم ينشر نظيرًا حديثًا لتدوينة Google في 2024. تعامل مع الآلية كسلوك HTTP عام ينطبق على المحركين.

كيف تنفذ دعم 304؟

1. أرسل validators مع 200. اضبط الخادم أو CDN أو التطبيق لإرفاق ETag (موصى به) و/أو رأس Last-Modified منسقًا صحيحًا باستجابات 200 العادية. تنشئ خوادم وأطر كثيرة ETags تلقائيًا للملفات الثابتة؛ أما الاستجابات الديناميكية فعادةً فتحتاج إلى تفعيل ذلك.
2. احترم الرؤوس المشروطة عند العودة. عندما يصل طلب يحمل If-None-Match أو If-Modified-Since، قارن بالقيمة الحالية وأعد 304 (بلا جسم) إذا ظلت مطابقة، أو 200 جديدة إذا لم تعد مطابقة. وغالبًا ما تتولى خوادم الملفات الثابتة ذلك، أما مسارات التطبيق وعمّال الحافة فكثيرًا ما لا يفعلونه إلا إذا وصلتهم الأسلاك صراحةً.
3. قرر معنى «تغير» وحافظ على ثبات ETag للمحتوى الذي لم يتغير فعلًا؛ ولا تدع إعادة الضغط أو اختلاف الخادم يقلبه بلا حاجة.
4. راقب الإعدادات الخاطئة الكلاسيكية:
   • Always-200 — عدم إرسال validators أبدًا، فلا يصبح أي طلب مشروطًا ولا تحصل على فائدة الكفاءة.
   • ETags غير مستقرة — قيمة تتغير رغم عدم تغير المحتوى (بسبب موازنة الحمل أو إعادة الضغط)، فتفرض عمليات جلب مستمرة.
   • 304 قديمة — الأخطر: خادم يستمر في إعادة 304 (أو ETag غير متغير) بعد تغير المحتوى فعلًا، فلا تلتقط الزواحف وذاكرات التخزين التحديث. هذه مشكلة يجب التقاطها في تحليل السجلات وليست عيبًا ملازمًا لـ304.

304 مقابل رموز الحالة الأخرى

304 مقابل 301 و302 و307 و308

تلك هي إعادة التوجيه الفعلية. تحمل 301 أو 308 (دائمة) أو 302 أو 307 (مؤقتة) رأس Location وتنقل العميل إلى عنوان URL مختلف؛ كما تمرر 301 و308 إشارة canonical. لا تحمل 304 Location ولا تنقل أحدًا ولا تمرر إشارة ترتيب. إنها من عائلة 3xx نفسها بالرقم، لكن وظيفتها مختلفة تمامًا. وتوجد تفاصيل كل إعادة توجيه في مقالاتها الخاصة (راجع قطعة 301 redirect ومركز redirects الفرعي).

304 مقابل 204 No Content

كلتاهما بلا جسم، لكن لأسباب مختلفة تمامًا. إن 204 No Content نجاح من فئة 2xx بجسم فارغ عمدًا لأن الخادم لا يملك شيئًا يرسله فعلًا؛ مثل DELETE أو PUT ناجح في API أو beacon تحليلات. كما لا ترسل 304 جسمًا، لكن ليس لعدم وجود شيء يرسل؛ بل لأن «لديك النسخة بالفعل وما زالت صالحة». لا تخلط بينهما: قد تعامل 204 في عنوان URL لصفحة كـsoft 404 لعدم وجود محتوى قابل للفهرسة، بينما 304 تأكيد لصلاحية محتوى تملكه Google أصلًا. ويتناول مقال 204 No Content ذلك الرمز كاملًا.

خرافات شائعة عن 304

1. «304 إعادة توجيه». لا رأس Location ولا انتقال لأحد. يعيد العميل استخدام نسخته المخزنة مؤقتًا. وتعني عبارة RFC 9110 «إعادة توجيه العميل للاستفادة من التمثيل المخزن» إعادته إلى الذاكرة المؤقتة، لا إلى عنوان URL آخر.
2. «304 خطأ يجب إصلاحه». إنها النتيجة الصحيحة المقصودة لإعداد طلبات مشروطة يعمل. إن رؤية 304 في زحف أو DevTools علامة على عمل التخزين المؤقت؛ وهي أكثر المفاهيم الخاطئة شيوعًا في نتائج البحث.
3. «304 تساعد الترتيب». لا يوجد أثر مباشر في الترتيب، كما تحد Google أثر الفهرسة أيضًا؛ فقد يعيد Search حساب إشارات عنوان URL، لكن 304 لا تغير الفهرسة بخلاف ذلك. الفائدة توفير الموارد الذي تقول Google إنه قد يحسن كفاءة الزحف بصورة غير مباشرة في المواقع الكبيرة جدًا، وليس إشارة ترتيب ولا ضمانًا لانتقال الجهد الموفر إلى عناوين أخرى.
4. «إذا أعاد خادمي 304، فستستخدم Google المحتوى القديم إلى الأبد». “If my server returns 304, Google will use stale content forever.” (ترجمة) «إذا أعاد خادمي 304، فستستخدم Google المحتوى القديم إلى الأبد.» لا تعمل 304 إلا ما دام validator مطابقًا. وما إن يتغير المحتوى فعلًا حتى يعيد الخادم المنفذ صحيحًا 200 جديدة مع validators جديدة. أما الخطر الحقيقي فهو خادم معد بطريقة خاطئة يستمر في إعادة 304 بعد تغير المحتوى؛ وهذا خلل، لا خاصية في 304.

5. «ETag وLast-Modified قابلان للتبادل». كلاهما validator، لكن Last-Modified حساس لتنسيق التاريخ ولا يملك إلا دقة طابعه الزمني، بينما ETag معتم ودقيق (وقد يختلف على نحو مزعج بين الخوادم أو بعد إعادة الضغط إذا نُفذ بإهمال). توصي Google بـETag أساسيًا، وباستخدام الاثنين إن أمكن.

الأسئلة الشائعة

هل HTTP 304 خطأ؟ لا؛ إنها إشارة نجاح تدل على عمل التخزين المؤقت. وتعني أن النسخة المخزنة لدى العميل ما زالت صالحة.

هل 304 Not Modified إعادة توجيه؟ لا. هي من فئة 3xx بحكم الترقيم، لكنها لا تحمل رأس Location ولا تنقل العميل إلى عنوان URL جديد.

هل تساعد 304 SEO أو الترتيب؟ لا أثر مباشر في الترتيب، ولا أثر في الفهرسة عدا احتمال إعادة Google حساب إشارات عنوان URL. إنها توفر النطاق الترددي والحساب عبر تمكين الزواحف من تخطي الصفحات التي لم تتغير، وهو ما تقول Google إنه قد يحسن كفاءة الزحف بصورة غير مباشرة في المواقع الكبيرة.

ما الفرق بين ETag وLast-Modified؟ ETag بصمة إصدار معتمة تُطابق عبر If-None-Match؛ وLast-Modified طابع زمني يُطابق عبر If-Modified-Since. وتوصي Google بـETag لأنه أقل عرضة للأخطاء.

ما هو ETag الضعيف مقابل القوي؟ يثبت ETag القوي تطابق المحتوى بايتًا ببايت؛ أما ETag الضعيف (ذو البادئة W/) فيثبت التكافؤ الدلالي ويتسامح مع فروق تافهة مثل الضغط أو تغير تاريخ التذييل.

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

كيف أجعل خادمي يعيد 304 بصورة صحيحة؟ أرسل ETag أو Last-Modified مع 200، ثم احترم If-None-Match أو If-Modified-Since في الطلب التالي بإعادة 304 بلا جسم عندما يظل validator مطابقًا.

ما الفرق بين 304 و204؟ كلتاهما بلا جسم؛ 204 لأن لا شيء موجودًا للإرسال، و304 لأن العميل يملك نسخة ما زالت صالحة.

هل يرسل Googlebot رؤوسًا مشروطة في كل طلب؟ لا؛ يختلف دعم التخزين المؤقت بين الزواحف، لذلك لا يكون كل طلب مشروطًا حتى مع ضبط الرؤوس.

هل يمكن أن تحمل استجابة 304 جسمًا؟ لا. وفق RFC 9110، «لا يمكنها أن تحتوي على محتوى أو ذيول». واستجابة 304 ذات جسم مخالفة للمواصفة.

ملخص الذكاء الاصطناعي

خلاصة مركزة من نسخة Advanced:

• 304 Not Modified هي استجابة GET أو HEAD مشروط انتهى شرطه إلى false وكان سيحصل على 200 لولا ذلك (RFC 9110 §15.4.5). إنها من فئة 3xx لكنها ليست إعادة توجيه: لا رأس Location ولا عنوان جديد، وبحسب المواصفة لا جسم: «لا يمكنها أن تحتوي على محتوى أو ذيول». والزيارة الثانية مثال شائع لتحول الطلب إلى مشروط، لا قاعدة البروتوكول.
• إنها جواب عن طلب مشروط. يحمل GET أو HEAD If-None-Match مقابل ETag و/أو If-Modified-Since مقابل Last-Modified. فإذا ظل validator مطابقًا، يعيد الخادم 304 ويعيد العميل استخدام نسخته المخزنة مؤقتًا.
• كلمة المواصفة «إعادة التوجيه» مجازية؛ فهي تشير بالعميل إلى ذاكرته المؤقتة، لا إلى عنوان URL آخر، ومن هنا يأتي معظم الالتباس.
• ETag مقابل Last-Modified: ETag رمز إصدار معتم (يُطابق عبر If-None-Match)؛ وLast-Modified تاريخ (يُطابق عبر If-Modified-Since، ويحتاج تنسيق تاريخ HTTP دقيقًا). ويتقدم If-None-Match عند وجود الاثنين. وETag القوي = تطابق بايتي؛ والضعيف (بادئة W/) = تكافؤ دلالي.
• لا أثر مباشر في الترتيب ولا أثر في الفهرسة عدا احتمال إعادة Google حساب إشارات عنوان URL. تملك Google المحتوى؛ وتؤكد 304 فقط عدم تغيره. وكما صاغ Gary Illyes، قد يساعد التخزين المؤقت على زحف الموقع بكفاءة أكبر؛ والفائدة توفير موارد قد يحسن كفاءة الزحف بصورة غير مباشرة في المواقع الكبيرة، لا إعادة توزيع مضمونة لميزانية الزحف ولا إشارة ترتيب.
• توصي Google بـETag أساسيًا (لأنه “less prone to errors and mistakes” (ترجمة) «أقل عرضة للأخطاء والهفوات»)، ولا بأس بضبط الاثنين؛ ويجب أن يستخدم Last-Modified صيغة “Weekday, DD Mon YYYY HH:MM:SS Timezone,” (ترجمة) «Weekday, DD Mon YYYY HH:MM:SS Timezone،»؛ ولا تُبطل التخزين المؤقت إلا عند التغييرات المهمة، لا عند تغيير تاريخ حقوق النشر في التذييل.
• يختلف دعم التخزين المؤقت بين الزواحف؛ فلا يكون كل طلب من Googlebot مشروطًا. ويدعم Bing GET المشروط منذ منشور Live Search في 2008؛ وهي آلية HTTP عامة.
• لا تخلطها مع 301/302/307/308 (إعادة توجيه فعلية تنقل عنوان URL) أو 204 No Content (بلا جسم أيضًا، لكن لعدم وجود شيء يرسل).
• الخطر الحقيقي ليس 304 نفسها، بل خادم معد بطريقة خاطئة يعيد 304 بعد تغير المحتوى؛ التقط ذلك في تحليل السجلات. وقد تبدو 304 صحيحة كخطأ في بعض مكتبات العميل أو طبقات تخزين المنصة حتى عندما لا يوجد خلل فعلي.

الوثائق الرسمية

مراجع المصادر الأولية لمعنى 304 وكيف تستخدمها محركات البحث.

مواصفة HTTP ومرجع المتصفح

• RFC 9110 §15.4.5 — 304 Not Modified — التعريف المرجعي: طلب مشروط، بلا جسم، ورؤوس مطلوبة.
• MDN — 304 Not Modified — شرح مبسط، ومحفز If-None-Match/If-Modified-Since، وقائمة الرؤوس التي يجب أن تحملها 304.
• MDN — طلبات HTTP المشروطة — شرح التحقق القوي والضعيف.
• MDN — ETag — رأس ETag، بما في ذلك صيغة W/ الضعيفة مقابل القوية.

Google Search Central

• Crawling December: HTTP caching — منشور Gary Illyes في 9 ديسمبر 2024 عن كيفية تشغيل ETag/If-None-Match وLast-Modified/If-Modified-Since ل304 ولماذا تساعد كفاءة الزحف.
• نظرة عامة على Google Crawler (User Agent) — الزواحف التي تدعم التخزين المؤقت وتوصية ETag على Last-Modified.
• كيف تؤثر رموز حالة HTTP في زواحف Google — صف Google الحالي لـ304، بما في ذلك احتمال إعادة Search حساب إشارات عنوان URL رغم عدم وجود أثر فهرسة آخر.
• استكشاف أخطاء زحف Google Search وإصلاحها — مصدر الصياغة المشروطة بأن وفورات الموارد «قد تحسن كفاءة الزحف بصورة غير مباشرة» وأن Google لا ترسل رؤوسًا مشروطة في كل محاولة زحف.

Bing

• إعلان تحسينات الزاحف في Live Search — منشور Bing/Live Search القديم الذي يؤكد دعم GET المشروط (If-Modified-Since/If-None-Match ← 304) منذ 2008.

اقتباسات من المصدر

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

مواصفة HTTP

• “The 304 (Not Modified) status code indicates that a conditional GET or HEAD request has been received and would have resulted in a 200 (OK) response if it were not for the fact that the condition evaluated to false.” (ترجمة) «تشير حالة 304 (غير معدّلة) إلى تلقي طلب GET أو HEAD مشروط، وكان سيؤدي إلى استجابة 200 (OK) لولا أن الشرط قيّم على أنه خاطئ.» — RFC 9110، دلالات HTTP، §15.4.5. اقرأ القسم
• “A 304 response is terminated by the end of the header section; it cannot contain content or trailers.” — RFC 9110، §15.4.5 (القاعدة المعيارية «لا جسم، مطلقًا»). اقرأ القسم

MDN Web Docs

• “The HTTP 304 Not Modified redirection response status code indicates that there is no need to retransmit the requested resources.” (ترجمة) «تشير استجابة إعادة التوجيه HTTP 304 Not Modified إلى عدم الحاجة إلى إعادة نقل الموارد المطلوبة.» الانتقال إلى الاقتباس
• “Strong validation consists of guaranteeing that the resource is, byte to byte, identical to the one it is compared to.” — MDN، «طلبات HTTP المشروطة». اقرأ الدليل

Gary Illyes، Google — «ديسمبر الزحف: التخزين المؤقت لـHTTP» (9 ديسمبر 2024)

• “Especially if you have a large site with rarely-changing content under individual URLs, allowing caching locally may help your site be crawled more efficiently. Google’s crawling infrastructure supports heuristic HTTP caching as defined by the HTTP caching standard, specifically through the ETag response- and If-None-Match request header, and the Last-Modified response- and If-Modified-Since request header.” (ترجمة) «خصوصًا إذا كان لديك موقع كبير ذو محتوى نادر التغير تحت عناوين URL فردية، فقد يساعد السماح بالتخزين المؤقت محليًا على زحف موقعك بكفاءة أكبر. وتدعم بنية زحف Google التخزين المؤقت الاستدلالي في HTTP كما تحدده مواصفة التخزين المؤقت، وبخاصة عبر رأس استجابة ETag ورأس طلب If-None-Match، ورأس استجابة Last-Modified ورأس طلب If-Modified-Since.» اقرأ المنشور
• “We strongly recommend using ETag because it’s less prone to errors and mistakes (the value is not structured unlike the Last-Modified value).” (ترجمة) «نوصي بشدة باستخدام ETag لأنه أقل عرضة للأخطاء والهفوات (فقيمته غير منظمة، بخلاف قيمة Last-Modified).» اقرأ المنشور
• “If the ETag value sent by the crawler matches the current value the server generated, your server should return an HTTP 304 (Not modified) status code with no HTTP body.” (ترجمة) «إذا طابقت قيمة ETag التي يرسلها الزاحف القيمة الحالية التي أنشأها الخادم، فعلى خادمك إعادة رمز حالة HTTP 304 (غير معدّل) بلا جسم HTTP.» اقرأ المنشور
• “Our recommendation is that you require a cache refresh on significant changes to your content; if you only updated the copyright date at the bottom of your page, that’s probably not significant.” (ترجمة) «نوصي بأن تشترط تحديث التخزين المؤقت عند حدوث تغييرات مهمة في المحتوى؛ وإذا لم تكن قد حدثت إلا سنة حقوق النشر في أسفل الصفحة، فذلك على الأرجح غير مهم.» اقرأ المنشور

Patrick Stox — Ahrefs

• “304 Not Modified – Says the page hasn’t been modified. Typically used for caching.” (ترجمة) «تقول 304 إن الصفحة لم تتغير، وتُستخدم عادةً للتخزين المؤقت.» — من دليلي رموز حالة HTTP وتأثيرها في SEO (وهذا المقال هو التعمق الذي لم تحظَ به تلك المدخلة). الانتقال إلى الاقتباس

304 في سياقها: الرموز الخالية من الجسم ورموز 3xx التي تختلط بها

304 وشبيهاتها

الفخ أن 304 و204 بلا جسم، وأن 304 و301 و302 و307 و308 كلها 3xx؛ لكن 304 هي الغريبة على المحورين. إنها 3xx الوحيدة التي لا تنقل أحدًا، ورمز الجسم الفارغ الوحيد الذي يعني «لديك النسخة بالفعل» بدل «لا شيء للإرسال».

الـvalidators الاثنان

عند وجودهما معًا، يتقدم If-None-Match على If-Modified-Since.

حقائق سريعة

• لا جسم لـ304 أبدًا — تجعل RFC 9110 ذلك قاعدة معيارية.
• 304 رمز من فئة 3xx لكنها ليست إعادة توجيه (لا Location ولا عنوان جديد).
• لا أثر مباشر في الترتيب ولا أثر في الفهرسة عدا احتمال إعادة Google حساب إشارات عنوان URL؛ وفائدتها توفير الموارد الذي قد يساعد كفاءة الزحف بصورة غير مباشرة في المواقع الكبيرة.
• توصي Google بـETag بوصفه الأساسي؛ ولا بأس بضبط ETag وLast-Modified معًا.
• يجب أن يستخدم Last-Modified صيغة «Weekday, DD Mon YYYY HH:MM:SS Timezone» وإلا فقد يُتجاهل.
• أبطل التخزين المؤقت عند التغييرات المهمة في المحتوى، لا عند سنة حقوق النشر في التذييل.
• ليست كل طلبات الزواحف مشروطة؛ فدعم التخزين المؤقت يختلف بين الزواحف.
• يدعم Bing GET المشروط ← 304 منذ 2008؛ إنها آلية HTTP عامة.
• الخطر الحقيقي هو 304 القديمة (إعادة الخادم 304 بعد تغير المحتوى)؛ التقطها في تحليل السجلات.

مصافحة الطلب المشروط في HTTP الخام

سلاسل طلب واستجابة ملموسة توضح كيف تنشأ 304. (قيم الرؤوس توضيحية.)

ETag / If-None-Match — الجلب الأول (200)

GET /blog/my-article/ HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Content-Type: text/html
ETag: "a1b2c3d4"
Cache-Control: max-age=3600

<full page body here>

يخزن العميل الجسم وقيمة ETag.

ETag / If-None-Match — الجلب التالي، والمحتوى لم يتغير (304)

GET /blog/my-article/ HTTP/1.1
Host: example.com
If-None-Match: "a1b2c3d4"

HTTP/1.1 304 Not Modified
ETag: "a1b2c3d4"
Cache-Control: max-age=3600

لا جسم. تطابق ETag، فوفر الخادم حساب إنشاء الصفحة ونطاق نقلها. ويعيد العميل استخدام النسخة المخزنة مؤقتًا.

Last-Modified / If-Modified-Since — البديل القائم على التاريخ

GET /blog/my-article/ HTTP/1.1
Host: example.com
If-Modified-Since: Fri, 4 Sep 1998 19:15:56 GMT

HTTP/1.1 304 Not Modified
Last-Modified: Fri, 4 Sep 1998 19:15:56 GMT

لاحظ تنسيق تاريخ HTTP الدقيق — «Weekday, DD Mon YYYY HH:MM:SS Timezone» — الذي توصي Google به لتجنب مشكلات التحليل.

عندما يتغير المحتوى — 200 جديدة، لا 304

GET /blog/my-article/ HTTP/1.1
Host: example.com
If-None-Match: "a1b2c3d4"

HTTP/1.1 200 OK
Content-Type: text/html
ETag: "e5f6g7h8"          ← new value: content changed

<updated page body here>

لم يعد ETag المخزن مطابقًا، فيرسل الخادم المحتوى الجديد وvalidator جديدًا. ويحدّث التخزين المؤقت. ولهذا لا تستطيع 304 المنفذة صحيحًا «حبس» زاحف على محتوى قديم؛ فما إن يتغير المحتوى حتى يتغير validator ويحصل الطلب التالي على 200 حقيقية.

ETag ضعيف مقابل قوي

ETag: "a1b2c3d4"      ← strong: asserts byte-for-byte identity
ETag: W/"a1b2c3d4"    ← weak: asserts semantic equivalence (the W/ prefix)

قاعدة تقريبية: إذا كنت تدير موقعًا كبيرًا ذا عناوين URL كثيرة نادرة التغير، فإن إرسال ETag ثابت (واحترام If-None-Match) مع 200 يتيح للزواحف تأكيد «ما زالت هي نفسها» عبر 304 رخيصة بلا جسم؛ فتوفّر النطاق الترددي والحساب اللذين تقول Google إنهما قد يحسنان كفاءة زحف بقية موقعك بصورة غير مباشرة. وإذا انقلب ETag مع كل إعادة ضغط أو بين خوادم موازنة الحمل، فقدت هذه الفائدة.

أخطاء 304 التي تكسر التخزين المؤقت المشروط

تغيير ETag رغم عدم تغير التمثيل

يهزم ETag المرتبط بنسخة الخادم أو دورة الضغط أو طابع الطلب وظيفة validator؛ إذ يستمر المحتوى غير المتغير في إعادة 200 كاملة. أنشئ validator ثابتًا من التمثيل، أو استخدم ETag ضعيفًا عمدًا عندما لا تكون الفروق البايتية مهمة.

إعادة 304 بعد تغير المحتوى

قد يخفي validator قديم تحديثًا حقيقيًا عن العملاء والزواحف. أبطل ETag أو قدم Last-Modified كلما تغير التمثيل، ثم أكد أن الطلب المشروط القديم يتلقى 200 جديدة وجسمًا جديدًا.

إرسال 304 من دون طلب مشروط مطابق

لا ينبغي للخادم أن يفترض أن لدى العميل نسخة مخزنة. أعد 304 فقط بعد تقييم If-None-Match أو If-Modified-Since؛ أما الطلب الأول العادي فيحتاج إلى استجابة كاملة.

معاملة 304 كإعادة توجيه أو صفحة فارغة

لا تحمل 304 رأس Location ولا جسم استجابة. لا تمررها عبر منطق إعادة التوجيه، ولا تستبدل موردًا فارغًا حقيقيًا بـ304؛ استخدم الحالة التي تصف الاستجابة الفعلية.

مشكلات 304 الشائعة

يعيد الخادم 200 دائمًا

العَرَض: تنزّل الطلبات المتكررة الجسم الكامل حتى عندما لا يتغير شيء. السبب المحتمل: لا تحمل الاستجابة الأولى validator، أو يتجاهل التطبيق رؤوس الطلب المشروط. الإصلاح: أرسل ETag و/أو Last-Modified صالحًا، ثم نفّذ فحص If-None-Match أو If-Modified-Since المطابق. أكد أن الطلب غير المتغير يعيد 304 بلا جسم.

تنتج خوادم الأصل المختلفة ETags مختلفة

العَرَض: يتناوب عنوان URL نفسه الذي لم يتغير بين 200 و304 خلف موازن حمل. السبب المحتمل: ينشئ كل عقدة validator الخاص بها. الإصلاح: اشتق ETag من حالة المحتوى المشتركة، لا من العقدة التي تخدم الطلب، وكرر الطلب المشروط نفسه مقابل عدة استجابات.

يعيد المحتوى المحدث 304 رغم تحديثه

العَرَض: يحتفظ متصفح أو زاحف بتمثيل قديم بعد النشر. السبب المحتمل: لم يُبطل validator مع المحتوى. الإصلاح: صحح منطق مفتاح التخزين أو النشر، وامسح التخزين المتأثر عند الحاجة، وأثبت أن ETag القديم يتلقى الآن 200 مع validator جديد.

يبدو أن Last-Modified مُتجاهل

العَرَض: لا ينتج If-Modified-Since أي 304. السبب المحتمل: تاريخ HTTP غير صالح، أو دقة طابع زمني غير كافية، أو ETag يتقدم عليه. الإصلاح: افحص الرؤوس الخام، وصحح تنسيق التاريخ، واختبر كل validator منفصلًا.

تبدو 304 كخطأ في كود التطبيق

العَرَض: يطرح نص أو تطبيق استثناءً أو يسجل «خطأ» في طلب تلقى 304 فعلية. السبب المحتمل: تعامل بعض مكتبات عميل HTTP أي حالة غير 200 — ومنها 304 الصالحة — كحالة شبيهة بالاستثناء ما لم تضبطها صراحةً لاتباع إعادة التوجيه أو قبول استجابات not-modified؛ وهذه خصلة في مكتبة العميل لا مشكلة في البروتوكول أو الخادم. الإصلاح: افحص معالجة مكتبة العميل لـ304 تحديدًا (لا معالجة أخطاء 4xx/5xx فقط)، وأكد أن استجابة HTTP الخام 304 صحيحة وبلا جسم قبل اتهام الخادم.

تخلط طبقة تخزين منصة (مثل تخزين IIS المؤقت للمخرجات) الصورة

العَرَض: يبدو تطبيق الأصل صحيحًا، لكن سلوك 304 ما زال خاطئًا. السبب المحتمل: تقف طبقة تخزين خاصة بالمنصة — وتخزين مخرجات IIS مثال موثق — بين التطبيق والعميل، وقد تنشئ استجابات 304 أو تعترضها بنفسها. الإصلاح: عاملها كطبقة محتملة بين عدة طبقات (تطبيق الأصل وCDN وموازن الحمل وتخزين المنصة)، لا المشتبه الافتراضي؛ واعزلها باختبار مضبوط يغير validator في كل طبقة على حدة قبل تحديد الطبقة المسؤولة.

طلب: دقق أثر طلب مشروط

ألصق رؤوس الطلب والاستجابة من جلب أول ومن جلب متكرر.

Act as an HTTP caching reviewer. I will paste two request/response header traces for
the same URL: an initial fetch and a conditional repeat. Identify the validator used,
check whether If-None-Match or If-Modified-Since was evaluated correctly, verify that
a 304 has no body or Location header, and flag unstable or stale-validator risks.
Return: observed flow, pass/fail checks, likely cause of each failure, and the exact
next request I should run. Do not infer headers that are not present.

[PASTE BOTH TRACES]

طلب: راجع تنفيذ ETag

ألصق إعداد التطبيق أو CDN أو الخادم ذا الصلة.

Review this ETag/Last-Modified implementation for conditional GET correctness. Trace
the 200 -> conditional request -> 304 path, explain what causes the validator to
change, and test mentally for multiple origin nodes, compression variants, and real
content updates. Separate protocol violations from efficiency issues. Give a minimal
fix and a curl-based validation plan. Do not invent platform behavior.

[PASTE CONFIGURATION OR CODE]

Shell: أعد تشغيل ETag كطلب مشروط

شغّل هذا في طرفية macOS أو Linux. انسخ ETag تمامًا، بما في ذلك علامات الاقتباس.

URL='https://example.com/page'
curl -sS -D - -o /dev/null "$URL"
curl -sS -D - -o /dev/null -H 'If-None-Match: "PASTE_ETAG_HERE"' "$URL"

ينبغي أن تكشف الاستجابة الأولى validator. وينبغي أن تعيد الثانية 304 عندما لا يتغير التمثيل، و200 عندما يكون ETag الملصق قديمًا.

PowerShell: اختبر Last-Modified

شغّل هذا في PowerShell بعد استبدال عنوان URL والطابع الزمني.

$url = 'https://example.com/page'
$headers = @{ 'If-Modified-Since' = 'Tue, 14 Jul 2026 12:00:00 GMT' }
Invoke-WebRequest -Uri $url -Headers $headers -SkipHttpErrorCheck

وحدة تحكم DevTools: اعرض validators لموارد الصفحة

شغّل هذا في وحدة تحكم المتصفح. فهو يعرض إدخالات توقيت الموارد؛ استخدم لوحة Network لفحص رؤوس ETag وLast-Modified والحالة الفعلية.

console.table(performance.getEntriesByType('resource').map(r => ({name: r.name, transferSize: r.transferSize, encodedBodySize: r.encodedBodySize})));

أدوات لفحص سلوك 304

• HTTP Header Checker: افحص ETag وLast-Modified وCache-Control وVary وبصمات CDN/الحافة في الاستجابة العادية قبل إعادة validator.
• لوحة Network في DevTools: عطّل «Disable cache»، وأعد التحميل، وقارن رؤوس الطلب والاستجابة. كما تجعل DevTools سلوك HSTS والتخزين المحلي ظاهرًا، فميّز بين سلوك المتصفح وما أرسله الأصل.
• curl: أرسل رأس If-None-Match أو If-Modified-Since دقيقًا من دون أن تتدخل حالة التخزين المؤقت في المتصفح.
• سجلات الوصول: قِس طلبات الزواحف المشروطة وحدد هل انتهت إلى 304 أم 200 كاملة.

أثبت عمل الاستجابات المشروطة بعد التغيير

اختبار التمثيل غير المتغير

الاختبار: اجلب عنوان URL، وانسخ ETag، ثم كرر الطلب باستخدام curl -I -H 'If-None-Match: "VALUE"' URL. النتيجة المتوقعة: 304 وvalidator المطابق ومن دون جسم أو Location. تفسير الفشل: تجاهل الخادم الشرط أو أنشأ validator غير ثابت. نافذة المراقبة: فورية. محفز التراجع: تسبب تغيير التخزين المؤقت في فقدان استجابة 200 الكاملة للطلبات العادية.

اختبار التمثيل المتغير

الاختبار: انشر تغييرًا حقيقيًا في المحتوى، ثم أعد تشغيل ETag القديم. النتيجة المتوقعة: 200 بالجسم المحدث وvalidator جديد. تفسير الفشل: إبطال التخزين المؤقت قديم. نافذة المراقبة: فور وصول النشر إلى كل أصل. محفز التراجع: استمرار أي أصل في إعادة 304 لـvalidator القديم بعد اكتمال النشر.

اختبار الاستقرار بين الأصول

الاختبار: كرر الطلبات العادية والمشروطة نفسها مرات كافية للوصول إلى مجموعة الخدمة، وسجل ETag والحالة. النتيجة المتوقعة: تستخدم التمثيلات غير المتغيرة validators متوافقة وتنتج 304 باستمرار. تفسير الفشل: اختلاف validators بين العقد أو الترميزات بلا استراتيجية Vary مطابقة. نافذة المراقبة: فورية، عبر مجموعة النشر. محفز التراجع: تقديم منطق validator محتوى قديمًا أو خلط تمثيلات بين العملاء.

قِس صحة التخزين المؤقت المشروط

معدل نجاح إعادة التحقق المشروط

المقياس: الطلبات المشروطة التي تنتهي إلى 304 مقابل 200 كاملة. ما يخبرك به: هل تتجنب الموارد غير المتغيرة عمليات النقل غير الضرورية. طريقة الاستخراج: اجمع طلبات سجلات الوصول التي تحمل If-None-Match أو If-Modified-Since بحسب حالة الاستجابة وفئة عنوان URL. خط الأساس/النطاق الواقعي: أنشئ خط أساس بحسب نوع المحتوى؛ لا ينبغي إجبار الصفحات كثيرة التغير على معدل الأصول الثابتة. الوتيرة: أسبوعيًا أثناء الإطلاق، ثم شهريًا.

البايتات التي تم تجنبها في الجلب غير المتغير

المقياس: عدد بايتات جسم الاستجابة المقدرة التي لم تُنقل بسبب استجابات 304 صالحة. ما يخبرك به: جانب النطاق الترددي من فائدة كفاءة الزحف. طريقة الاستخراج: اربط عدد 304 بحجم آخر استجابة كاملة لنفس فئة عنوان URL. خط الأساس/النطاق الواقعي: قارن بخط أساس الموقع نفسه قبل التغيير؛ فلا يوجد هدف عالمي يناسب كل مزيج محتوى. الوتيرة: شهريًا.

إخفاقات validator القديمة

المقياس: عناوين URL المتغيرة التي ما زالت تقبل validator قديمًا. ما يخبرك به: هل تأتي الكفاءة على حساب الحداثة. طريقة الاستخراج: نفذ عينة صغيرة بعد النشر تعيد تشغيل ETags قبل النشر. خط الأساس/النطاق الواقعي: أي استجابة قديمة مؤكدة تحتاج إلى تحقيق. الوتيرة: مع كل نشر يغير التخزين المؤقت أو منطق إنشاء validator.

اختبر نفسك: 304 Not Modified

خمسة أسئلة سريعة عن معنى 304 وكيف تعمل. اختر إجابة كل سؤال ثم تحقق منها.

سجل التغييرات