خطأ 405 عند فحص رابط: قارن HEAD وGET

لا تحكم بأن الرابط معطل من الرقم وحده

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

في سؤال على Stack Overflow، أدى تحويل الفحص من GET إلى HEAD إلى أخطاء 405. ويصف سؤال آخر على Reddit إنذارات خاطئة عند فحص الروابط ببرنامج. هذه مشكلات أبلغ عنها أشخاص، وليست دليلا على سبب حالتك. تقارن هذه الخطوات الطلبات وتتحقق من المحتوى قبل تقرير ما إذا كان التصحيح المطلوب في الرابط أو أداة الفحص أو إعداد الموقع.

ما الفرق بين HEAD وGET

يطلب GET تمثيلا للمورد، بينما يطلب HEAD البيانات الوصفية المقابلة لـGET من دون جسم تلك الاستجابة. توضح MDN هذا الفرق. قد يقلل طلب الترويسات فقط حجم النقل، لكنه لا يقرأ الصفحة ولا يؤكد وجود المستند المتوقع فيها. كما لا يضمن أن التطبيق أو النظام الوسيط يعالج الطريقتين بشكل صحيح. عند رفض الطلب، سجّل الطريقة المستخدمة فعليا، ولا تستنتجها من اسم الأداة فقط.

تفرض RFC 9110 أن تتضمن استجابة 405 ترويسة Allow بالطرق التي يدعمها المورد حاليا. افحصها إن كانت الأداة تعرضها. إذا غابت، سجّل غيابها؛ لا تخترع قيمتها ولا تفترض أن السماح بجميع الطرق سيحل المشكلة. الاستجابة المعروضة مثال توضيحي وليست لقطة من موقع حقيقي. ووجود Allow لا يغني عن تجربة الطريقة اللازمة للتحقق من النتيجة التي يحتاج إليها المستخدم.

HTTP/1.1 405 Method Not Allowed
Allow: GET

قارن طلبات تستطيع تفسيرها

إذا كنت تدير الموقع وتعرف استخدام الطرفية، فقارن HEAD وGET على العنوان العام نفسه المخصص للقراءة. تعرض الأوامر الترويسات، لكن الثاني يتخلص من الجسم بعد استلامه، وبالتالي قد ينزّل بيانات. استبدل example.invalid بصفحتك المصرح بفحصها؛ فهذا نطاق خيالي وليس خدمة متاحة للاختبار. لا تستخدم عمليات الشراء أو الحذف أو تسجيل الخروج أهدافا لهذه التجربة، واختر صفحة محتوى واضحة ومحددة.

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

curl --head --max-time 20 "https://example.invalid/guide"
curl --silent --show-error --max-time 20 --dump-header - --output /dev/null "https://example.invalid/guide"

فسّر النتيجة دون قفز إلى الاستنتاج

إذا لاحظت HEAD بحالة 405 وGET بحالة 200 في ظروف قابلة للمقارنة، يمكنك القول إن الطلبين تلقيا استجابتين مختلفتين. يبقى عليك فتح الصفحة والتحقق من محتواها. إذا تلقى GET أيضا 405، فلم تثبت مشكلة خاصة بـHEAD. وإذا أعاد 404، فإن اختبار HEAD السابق لم يثبت وجود الصفحة المطلوبة. أبق كل ملاحظة منفصلة عن الفرضية، حتى يستطيع شخص آخر مراجعة منطق التشخيص.

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

أضف فحص WikiURL

ألصق العنوان العام الكامل في أداة فحص URL لدى WikiURL، واحفظ حالة HTTP والعنوان النهائي المكتشف. هذه ملاحظة إضافية من خادم الخدمة. لا تفترض أنها تعيد ظروف متصفحك أو جلستك أو الأوامر السابقة. لا تتيح الواجهة اختيار HEAD أو GET يدويا؛ لذلك لا تنسب إليها مقارنة بين الطريقتين لا تعرضها، ولا تحول نتيجة واحدة إلى اختبار لم يُجر فعليا.

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

احفظ قرارا قابلا للتحقق قبل المشاركة

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

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