405 خطأ موضح: أسباب وإصلاحات ونصائح الوقاية

يروي كل رمز حالة HTTP قصة حول ما يحدث بين عميل (مثل متصفح الويب) وخادم.بعض القصص بسيطة.200 يعني النجاح ، 404 يعني أن الصفحة غير موجودة.ولكن عندما ترى طريقة 405 غير مسموح بها ، فإن القصة أكثر إثارة للاهتمام.

دعنا نقسم ما يعنيه خطأ 405 ، ولماذا يحدث ، وكيفية استكشاف الأخطاء وإصلاحها

ماذا يعني رمز الحالة 405

تحدث طريقة 405 غير المسموح بها عندما تحدث عميل (مثل المتصفح أو أداة API) طلبًا باستخدام طريقة HTTP التي لا يسمح بها الخادم لهذا المورد.

فمثلا:

• إرسال النموذج يرسل أ بريد طلب ، لكن الخادم يقبل فقط يحصل لهذا عنوان URL.
  
• يرسل نص يضع طلب ، ولكن يتم تكوين نقطة النهاية للسماح فقط بريد و يمسح.

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

ما قد يسبب خطأ 405

خطأ 405 ليس له دائمًا سبب واحد واضح.يمكن أن يأتي من الطريقة التي يتم بها تقديم الطلب ، وكيفية تكوين الخادم ، أو حتى من طبقات أمان إضافية في مكانها.فيما يلي المواقف الأكثر شيوعًا التي من شأنها أن تؤدي إليها:

1. طريقة HTTP خاطئة

يتم إعداد كل مورد على الخادم لقبول بعض أساليب HTTP.على سبيل المثال:

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

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

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

2. قواعد الخادم الخاطئة

تمنح خوادم الويب مثل Apache و Nginx و IIS السيطرة على أساليب HTTP المسموح بها.يمكن لتوجيهات التكوين مثل حد Apache أو Nginx's Limit_Except أن يحظر صراحة بعض الأفعال.

على سبيل المثال:

• قد يقوم مسؤول الخادم بتكوين موقع للسماح فقط يحصل و بريد، حظر يضع و يمسح للأمن.
  
• إذا كانت القواعد صارمة جدًا (أو خطيئة) ، فيمكن رفض الطلبات المشروعة بـ 405.

يمكن أن يحدث هذا في كثير من الأحيان بعد التغييرات على htaccess الملفات أو كتل الخادم أو إعدادات تصفية طلب IIS.حتى خطأ مطبعي صغير أو توجيه يتم تجاهله يمكن أن يؤدي إلى حظر طرق عن غير قصد.

3. قيود API

تم تصميم واجهات برمجة التطبيقات مع قواعد طريقة صارمة.في واجهة برمجة تطبيقات مريحة ، عادة ما تتوافق أفعال HTTP المختلفة مع إجراءات محددة:

• يحصل → استرداد البيانات
  
• بريد → إنشاء بيانات جديدة
  
• ضع/تصحيح → تحديث البيانات الحالية
  
• يمسح → إزالة البيانات

إذا قام مطور باستدعاء نقطة نهاية بالطريقة الخاطئة ، مثل إرسال أ يضع لعنوان URL الذي يسمح فقط بريد، يستجيب الخادم مع 405.

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

4. نموذج غير صحيح أو إعداد AJAX

تعد نماذج الويب وطلبات JavaScript (AJAX) مصدرًا شائعًا آخر لـ 405 خطأ:

• قد يكون الشكل الطريقة = "post" السمة ، لكن الخادم يسمح فقط يحصل على عنوان URL هذا.
  
• جافا سكريبت أحضر() أو xmlhttprequest قد يتم ترميزها لإرسال طلب PUT عندما تدعم الواجهة الخلفية وظيفة فقط.

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

غالبًا ما يواجه المبتدئون هذا عند تعلم إعداد النماذج في PHP أو عند العمل مع أطر العمل الأمامي التي تقوم بإجراء مكالمات API.

5. أدوات الأمن

حتى عند تكوين الخادم بشكل صحيح ، يمكن لطبقات الأمان التدخل وحظر الطلبات.تشمل الأمثلة:

• جدران حماية تطبيق الويب (WAFS): تراقب هذه الزيارات الواردة وقد ترفض طرقًا مثل PUT أو حذف أو تتبع لتقليل خطر الهجمات.
  
• المكونات الإضافية للأمن: في منصات مثل WordPress ، تقوم بعض الإضافات بتعطيل طرق معينة على مستوى الموقع لمنع الطلبات غير المصرح بها.

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

كيف يختلف 405 عن رموز الحالة المماثلة

للوهلة الأولى ، يمكن أن يخطئ خطأ 405 أخطاء العميل والخادم الأخرى.لكن التفاصيل مهمة ، ومعرفة الاختلافات ستساعدك على تشخيصها بشكل صحيح.

404 غير موجود

• ماذا يعني: لا يمكن للخادم العثور على المورد الذي تطلبه.
  
• مثال: تحاول زيارة example.com/page.html ، لكن الصفحة غير موجودة على الإطلاق.
  
• الفرق الرئيسي من 405: مع 404 ، فإن المشكلة هي أن المورد نفسه ليس موجودًا ، بينما مع وجود 405 ، يوجد المورد - أنت فقط تستخدم الطريقة الخاطئة للتفاعل معها.

403 ممنوع

• ماذا يعني: يوجد المورد ، لكن الخادم يمنعك من الوصول إليه.
  
• مثال: قد تحاول عرض دليل خاص دون أذونات مناسبة.
  
• الفرق الرئيسي من 405: 403 تدور حول حقوق الوصول ، في حين أن 405 تدور حول قيود الطريقة.

501 لم ينفذ

• ماذا يعني: لا يتعرف الخادم على أو يدعم طريقة HTTP على الإطلاق ، لأي مورد.
  
• مثال: الخادم الذي لا يدعم طلبات التصحيح سوف يرمي هذا الخطأ بغض النظر عن المورد الذي تحاول.
  
• الفرق الرئيسي من 405: ينطبق 501 على الخادم بأكمله ، بينما ينطبق 405 فقط على مورد معين.

تشخيص خطأ 405

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

1. تحقق من الأساليب المسموح بها

عندما يقوم الخادم بإرجاع 405 ، يجب أن تتضمن الاستجابة قائمة السماح للأساليب التي يتم دعمها لهذا المورد.هذه هي طريقة الخادم للقول ، "لا يمكنك فعل ذلك ، ولكن إليك ما يمكنك فعله".

مثال:

HTTP/1.1 405 Method Not Allowed
Allow: GET, POST

• إذا حاولت وضعه ، يخبرك هذا الرد أن الحصول على النشر و Post صالحان فقط.
  
• يمكنك رؤية ذلك باستخدام أدوات مطور المتصفح (علامة تبويب الشبكة) أو أداة مثل Postman.
  
• يمكن لأتمتة فحص الرأس في سير عمل تصحيح الأخطاء تسليط الضوء بسرعة على استخدام الطريقة غير المحسنة عبر نقاط نهاية متعددة.

2. مراجعة سجلات خادم

غالبًا ما تكون السجلات أسرع طريقة للكشف عن السبب حيث ستقدم عادةً شرحًا مباشرًا لسبب رفض الطلب وتأكيد أنه ليس مشكلة اتصال أعمق.

• اباتشي: افحص ال error_log ملف ، عادة في /var/log/apache2/ أو /var/log/httpd/.
  
• Nginx: مراجعة error.log و Access.log ، عادة في /var/log/nginx/.
  
• IIS: افتح عارض الحدث أو تحقق من ملفات سجل IIS تحت ٪ SystemDrive ٪ \ inetpub \ logs \ logfile \.

قد تظهر السجلات إدخالات مثل:

client sent an unsupported method (PUT) to /index.php

3. اختبر نقطة النهاية

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

باستخدام حليقة:

curl -i -X GET https://example.com/resource
curl -i -X POST https://example.com/resource
curl -i -X PUT https://example.com/resource

• إذا نجحت Get and Post ولكن تفشل مع 405 ، فقد حددت عدم التطابق.

يعطي Postman واجهة مرئية حيث يمكنك تبديل طرق الطلب وترى على الفور الردود ، مما يجعلها أكثر ملاءمة للمبتدئين.

4. تحقق من الرمز الخاص بك

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

الأشكال: تأكد من تطابق سمة طريقة <Porm> لعنصر ما يتوقعه الخادم.مثال:

 <form action="/submit" method="post">

أياكس/جلب: تحقق من ضبط طريقة الطلب بشكل صحيح في JavaScript:

 fetch('/api/data', {
  method: 'POST'
})

• الأطر: قد تتخلف بعض الأطر (مثل Angular أو React أو Django) عن طرق معينة إذا لم تقم بتعيينها بشكل صريح.تحقق مزدوجًا من جانب العميل والرمز من جانب الخادم لعدم التطابق.

ملحوظة: غالبًا ما تكون هذه الخطوة حيث يتعثر المبتدئون ، وإرسال البيانات إلى نقطة النهاية اليمنى ولكن مع الفعل الخاطئ.

5. فحص تكوين الخادم

إذا كان كل من الرؤوس والرمز يبدو جيدًا ، فقد تكون المشكلة قيودًا على مستوى الخادم.غالبًا ما يمنع المشرفون الأساليب لأسباب أمنية ، ولكن إذا تم إيقاف الطلبات المشروعة ، فمن الضروري ضبط هذه الإعدادات.

اباتشي: ابحث عن توجيهات الحد أو الحد الأدنى في .htaccess أو التكوين الرئيسي.مثال:

 <Limit GET POST>
   Require all granted
</Limit>

• إذا كان وضع مفقود هنا ، فإن أي طلب وضع سيعود 405.

Nginx: تحقق من توجيهات limit_except:

 location /api/ {
   limit_except GET POST {
      deny all;
   }
}

• هذا من شأنه أن يرفض أساليب بخلاف الحصول على و post.
  
• IIS: افتح مدير IIS ، انتقل إلى طلب التصفية ، ومراجعة علامة التبويب HTTP Verbs.الأفعال المحظورة مثل PUT أو DELETE سوف تظهر هنا.

إصلاح خطأ 405 حسب النظام الأساسي/البيئة

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

فحص سريع سريع (ينطبق على الجميع)

1. إعادة إنشاء الخطأ وقراءة الرؤوس

curl -i -X PUT https://example.com/path

2. إذا رأيت السماح ، اضبط طلبك/عميله للمطابقة.إذا لم تقم بذلك ، تابع أدناه.

اباتشي

1. التأكد من التكوين

• تكوين الموقع: /etc/apache2/sites-avivable/*.conf أو /etc/httpd/conf.d/*.conf
  
• قواعد لكل dir: المشروع htaccess

2. احتياطي الملف الذي ستحرره

sudo cp /etc/apache2/sites-available/site.conf /etc/apache2/sites-available/site.conf.bak

3. ابحث عن قيود الطريقة

• بحث <MIDAR ...>, <Mimitexcept ...>أو إعادة كتابة الأنماط التي تمنع الأفعال.

# Example: only GET/POST allowed here
<LimitExcept GET POST>
  Require all denied
</LimitExcept>

4. أضف الطريقة (الطرق) المطلوبة أو إزالة الكتلة التقييدية

<LimitExcept GET POST PUT>
  Require all denied
</LimitExcept>

5. التحقق من صحة وإعادة التحميل

sudo apachectl -t
sudo systemctl reload apache2   # or: sudo systemctl reload httpd

6. إعادة الاختبار مع حليقة

curl -i -X PUT https://example.com/path

7. إذا كان لا يزال محظورًا ، تحقق من طبقات الأمان (على سبيل المثال ، سجلات تدقيق MOD_SECURITY) وأسبقية VirtualHost.

Nginx

1. فتح كتلة الخادم لموقعك

• المسارات الشائعة: /etc/nginx/sites- available/، /etc/nginx/conf.d/*.conf

2. احتياطي الملف

sudo cp /etc/nginx/sites-available/site.conf /etc/nginx/sites-available/site.conf.bak

3. ابحث عن limit_except كتل

location /api/ {
  limit_except GET POST {
    deny all;
  }
}

4. أضف الطريقة (الطرق) المطلوبة أو قم بإزالة الكتلة إذا كان غير ضروري

location /api/ {
  limit_except GET POST PUT {
    allow all;
  }
}

5. الاختبار وإعادة التحميل

sudo nginx -t
sudo systemctl reload nginx

6. إعادة الاختبار مع حليقة

curl -i -X PUT https://example.com/api/resource

7. إذا كنت وكيلًا إلى خادم تطبيق ، فإن تأكيد Upstream يسمح أيضًا بالطريقة.

IIS (Windows Server)

1. افتح مدير IIS → حدد الموقع.
   
2. اذهب إلى طلب تصفية → أفعال http.
   
3. قم بإزالة أي إدخالات مرفض للأفعال التي تحتاجها (على سبيل المثال ، وضع ، حذف) أو إضافة إدخالات السماح إذا كانت سياستك تتطلب صريحًا.
   
4. التحقق من تعيينات المعالج: لو WebDav يتم تثبيته واعتراض الأفعال التي تحتاجها أو إزالة أو تعطيل معالج WebDAV لهذا الموقع (أو إلغاء تثبيت WebDAV إذا لم يكن الحاجة).
   
5. إذا كانت موجودة ، راجع web.config لـ:

<system.webServer>
  <handlers> ... </handlers>
  <security>
    <requestFiltering>
      <verbs>
        <!-- Remove Deny for verbs you need -->
        <add verb="PUT" allowed="true" />
      </verbs>
    </requestFiltering>
  </security>
</system.webServer>

6. قم بإعادة تدوير تجمع التطبيق أو إعادة تشغيل الموقع.

7. إعادة الاختبار مع حليقة/ساعي البريد.

WordPress وغيرها من منصات CMS

1. إعادة الرابط الرابط الثابت
   • الإعدادات ← الرابط الثابت ← حفظ التغييرات (هذا ينعش قواعد إعادة كتابة).
2. اختبار تعارضات البرنامج المساعد
   • تعطيل كل الإضافات مؤقتا.
     
   • يعد إعادة تمكين واحد تلو الآخر للعثور على الجاني (الأمن ، والراحة/واجهة برمجة التطبيقات ، والتخزين المؤقت ، وجدار الحماية هي أسباب شائعة).
3. تحقق من القواعد التي أنشأتها النظام الأساسي
   • اباتشي: .
     
   • Nginx: تم إضافة كتل الخادم لتخزين المؤقت/الأمان التي قد تحتوي على مرشحات limit_except أو طريقة.
4. إذا كنت تستخدم واجهة برمجة تطبيقات CMS REST ، فتأكد من الأساليب المقبولة في نقطة النهاية وضبط العميل أو تهيئة المسار وفقًا لذلك.
   
5. إعادة اختبار الإجراءات الرئيسية (النماذج ، تسجيلات تسجيلات ، إجراءات المسؤول) بعد كل تغيير.

APIs (عام)

1. تأكيد العقد

• تحقق من مستندات API للطرق المسموح بها لكل نقطة نهاية ومسارات متوقعة.

2 ، التحقيق في نقطة النهاية

# Discover allowed methods (if supported)
curl -i -X OPTIONS https://api.example.com/v1/items/123
# Then try the method you intend
curl -i -X PATCH https://api.example.com/v1/items/123

3. إصلاح العميل أو الخادم (أمثلة)

• إصلاح العميل: أرسل الطريقة التي تدعمها نقطة النهاية فعليًا (على سبيل المثال ، Post بدلاً من وضع).
  
• Express (node.js)

 app.post('/items', createItem);
app.put('/items/:id', updateItem);
// If PUT not defined, add it—or switch your client to POST if that's the design.

• قارورة (بيثون)

 @app.route('/items/<id>', methods=['GET','POST','PUT','DELETE'])
def item(id): ...

4. اضبط 405 مفيدًا مع السماح رأس (جانب الخادم)

• إذا لم يتم تعيين إطار عملك تلقائيًا ، فأضف أساليب قائمة الرأس المسموح بها.

5. إذا تم توسيعها بواسطة بوابة API/WAF ، فإن طريقة مراجعة القواعد هناك أيضًا.

6. إعادة اختبار مع ساعي البريد/حليقة وتأكيد تدفق 2xx/3xx/4xx المتوقع.

بعد الإصلاح: قائمة التحقق السريع

• يقوم الإجراء الآن بإرجاع النجاح أو الخطأ الصحيح (وليس 405).
  
• السماح للرأس يسرد الأساليب المسموح بها بدقة.
  
• السجلات تظهر التعامل العادي ، وليس الفعل المحظور.
  
• الاختبارات الآلية (إذا كان لديك) تغطي المسار والطريقة المصححة.

منع 405 خطأ في المستقبل

إن إصلاح خطأ 405 عندما يظهر هو نصف التحدي فقط - تحديد حدوثه مرة أخرى هو ما يوفر لك الوقت والإحباط على المدى الطويل.من خلال وضع الممارسات الصحيحة أثناء التطوير والتكوين ، يمكنك تقليل فرص المستخدمين أو التطبيقات التي تعمل في طرق غير مدعومة.فيما يلي العديد من الأساليب التي تساعد على منع 405 من الأخطاء من أن تصبح مشاكل متكررة.

التحقق من صحة الأساليب في الكود

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

قواعد خادم المستند

غالبًا ما تحتوي الخوادم على قيود طريقة محددة في ملفات التكوين الخاصة بها (مثل .htaccess أو nginx.conf أو API Gateway Settings).إن الاحتفاظ بسجل للأساليب المدعومة يجعل من السهل على كل من المطورين والمسؤولين فهم الحدود.هذه الوثائق مفيدة بشكل خاص في الفرق الكبيرة أو المشاريع طويلة الأجل ، حيث يمكن أن تضيع قواعد الخادم أو نسيانها بمرور الوقت.

معالجة الخطأ

حتى مع التخطيط الدقيق ، قد تفلت طلبات الطريقة غير المدعومة.لهذا السبب من المفيد توفير رسائل خطأ واضحة عند حدوث 405.بدلاً من "طريقة غير مسموح بها" غامضة ، قم بتخصيص الاستجابة بحيث يفهم المستخدم أو المطور الخطأ الذي حدث وكيفية تصحيحه - على سبيل المثال ، من خلال تضمين قائمة الأساليب المسموح بها في رأس الاستجابة أو اقتراح الطريقة الصحيحة في الوثائق الخاصة بك.

اتبع المعايير

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

تغليف

يخبرك خطأ 405 غير المسموح به أن الخادم يعرف أن المورد موجود ، لكنه لا يسمح بالطريقة التي جربتها.

الوجبات الرئيسية: تحقق من رأس السماح ، وسجلات المراجعة ، وتأكد من تطابق قواعد الكود والخادم مع الأساليب التي تنوي دعمها.