مختبِر طرق HTTP

بمساعدة الخادم جديد أدوات الويب المساعدة

اختر الطرق فيرسل خادم متقن كل واحدة منها مرة واحدة إلى الرابط — الطريقة والرابط ووكيل مستخدم ثابت وترويسة الوسيط X-Mutqan-Relay: 1 فقط، دون جسم ولا كوكيز ولا بيانات دخول ولا أي ترويسة منك، ودون تتبّع إعادة التوجيه — ثم يعرض رمز الحالة لكل إجابة، وترويسات Allow وCORS، وما يخالف فيها RFC 9110. وهو ليس وسيطاً لتمرير الطلبات: لا يمكنك إضافة جسم أو ترويسات، ولا توجد هنا إلا هذه الطرق السبع (لا تُرسل TRACE وCONNECT أبداً).

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

كيف يخبر الخادم بطرق HTTP التي يدعمها رابط ما؟

بالإجابة عن كل طريقة: يشترط RFC 9110 أن تحمل إجابة 405 Method Not Allowed ترويسة Allow تسرد الطرق المدعومة، و501 تعني أن الخادم لا ينفّذ الطريقة أصلاً، وقد يُجاب طلب OPTIONS بترويسة Allow أيضاً. ويجب على كل خادم عام الغرض دعم GET وHEAD، أما PUT وPATCH وDELETE فينبغي رفضها أو اشتراط المصادقة لها حيثما لم يُقصد استخدامها.

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

كيفية استخدام مختبِر طرق HTTP

  1. أدخل رابط المورد، مثل https://api.example.com/v1/items.
  2. حدّد الطرق المراد اختبارها. GET وHEAD وOPTIONS مفعّلة افتراضياً؛ ولا تحدّد POST أو PUT أو PATCH أو DELETE إلا لرابط تملكه أو مسموح لك باختباره.
  3. اضغط «أرسل الطرق» واقرأ «الإجابات حسب الطريقة»: الحالة ومعناها لكل طريقة.
  4. اقرأ «الاكتشافات» لترى ما يخالف RFC 9110، و«ترويسات Allow وCORS» لترى ما يعلنه الخادم.

مزايا مختبِر طرق HTTP

  • يرسل أياً من GET وHEAD وOPTIONS وPOST وPUT وPATCH وDELETE إلى رابط واحد، مرة واحدة لكل طريقة، ويعرض رموز الحالة جنباً إلى جنب
  • يشرح كل إجابة بكلمات واضحة: إجابة ناجحة، أو إعادة توجيه (لم تُتبع)، أو يتطلب مصادقة، أو ممنوع، أو الطريقة غير مسموحة، أو لا يدعمها الخادم، أو خطأ في الخادم، أو بلا رد
  • يعرض ترويسة Allow وقيم Access-Control-Allow-Origin و-Methods و-Headers كما حملتها الإجابات
  • ينبّه إلى ما يخالف RFC 9110: إجابة 405 بلا ترويسة Allow، أو رفض HEAD بينما يعمل GET، أو ترويسة Allow تناقض الإجابات
  • يشير إلى طرق الكتابة التي تجيب بـ 2xx عن طلب فارغ مجهول المصدر، لتتحقق هل كان ينبغي أن تشترط المصادقة
  • طرق الكتابة معطّلة افتراضياً، ولا يُرسل منك أبداً إلا الطريقة والرابط

المدخلات والمخرجات

المدخلات

  • الرابط المراد اختباره — رابط http:// أو https:// باسم مضيف عام؛ ويُضاف https:// إلى «example.com/path». وتُرفض أسماء المستخدمين وكلمات المرور داخل الرابط.
  • الطرق — GET وHEAD وOPTIONS مفعّلة افتراضياً، وPOST وPUT وPATCH وDELETE معطّلة حتى تحدّدها. ولا يمكن اختيار غيرها.

المخرجات

  • الملخص — عدد الطرق المرسلة، وما أجاب منها بـ 2xx، وما رُفض أو لم يُسمح به، وما بقي بلا رد.
  • الإجابات حسب الطريقة — رمز الحالة وسببه ومعناه، وترويسة Allow، وContent-Type، وزمن الإجابة لكل طريقة.
  • الاكتشافات وترويسات Allow وCORS — ما يخالف RFC 9110، وطرق الكتابة التي أجابت بـ 2xx، وقيم Allow وCORS المعلنة.
  • عن هذا الاختبار — ما أُرسل بالضبط، كي تُقرأ النتيجة على حقيقتها.

مثال على مختبِر طرق HTTP

نقطة نهاية API بصيغة JSON ترفض HEAD

الإدخال:

https://api.example.com/v1/items مع تحديد GET وHEAD وOPTIONS وPOST وDELETE

النتيجة:

الملخص: الطرق المرسلة 5 · أجابت بـ 2xx ‏2 · مرفوضة أو غير مسموحة 3 · بلا رد 0
الإجابات حسب الطريقة: GET ‏200 OK — إجابة ناجحة · HEAD ‏405 Method Not Allowed — الطريقة غير مسموحة (Allow: GET, POST, OPTIONS) · OPTIONS ‏204 No Content — إجابة ناجحة · POST ‏401 Unauthorized — يتطلب مصادقة · DELETE ‏405 Method Not Allowed — الطريقة غير مسموحة
الاكتشافات: يُرفض HEAD بينما يعمل GET؛ ويتوقع RFC 9110 أن يدعم كل خادم عام الغرض HEAD حيثما دعم GET. · لم تُرجَع أي ترويسات CORS. لا ترسل الطلبات ترويسة Origin…
ترويسات Allow وCORS: ترويسة Allow ‏GET, POST, OPTIONS · Access-Control-Allow-Origin لم تُرسل

كيف تقرأ نتائج مختبِر طرق HTTP

2xx تعني أن الخادم أجاب عن الطريقة لهذا الرابط. وفي POST أو PUT أو PATCH أو DELETE لا تعني أن شيئاً أُنشئ أو حُذف — فالطلب بلا جسم ولا بيانات دخول — بل فقط أن الخادم لم يرفضه.

405 أو 501 تعني أن الطريقة غير متاحة على هذا الرابط، و401 أو 403 تعني أنها قد تكون موجودة لكنها تتطلب مصادقة أو صلاحية. والسلوك المتوقع من الواجهة البرمجية أن ترفض الطرق التي لا تنفّذها بـ 405 مع ترويسة Allow.

إجابة 3xx تُعرض ولا تُتبع: قد تتصرف الطريقة بشكل مختلف عند الرابط الذي يشير إليه التوجيه، فاختبر ذلك الرابط أيضاً.

«بلا رد» تعني أن الطلب لم يتلقَّ إجابة خلال 8 ثوانٍ، أو أن الاتصال فشل، أو أن الاسم لم يُحَلّ؛ والجدار الناري الذي يُسقط بعض الطرق بصمت يبدو بالشكل نفسه.

متى تستخدم مختبِر طرق HTTP

  • التحقق من أن الواجهة البرمجية ترفض الطرق التي لا تنفّذها بـ 405 وترويسة Allow صحيحة.
  • اختبار أمني: التأكد من أن DELETE أو PUT أو PATCH على مورد ما لا تُقبل دون مصادقة.
  • تشخيص خطأ «405 Method Not Allowed» يظهر لعميل ما، بمعرفة ما يقبله الخادم فعلاً على ذلك الرابط.
  • التحقق من أن HEAD يعمل حيث يعمل GET، من أجل أدوات المراقبة والتخزين المؤقت التي تعتمد عليه.

استكشاف الأخطاء وإصلاحها

  • كل الطرق «لم يصل رد في الوقت المحدد»: المضيف بطيء أو يُسقط الاتصالات القادمة من الشبكات السحابية. أعد المحاولة، أو اختبر من حاسوبك باستخدام curl.
  • ترفض الصفحة الرابط لأنه ليس عاماً: لا يُتصل أبداً بالعناوين الخاصة والمحلية والمحجوزة ولا بعناوين هذا الموقع.
  • «لقد وصلت إلى حد الطلبات»: كل طريقة طلب صادر واحد يُحتسب من حصة الدقيقة. اختبر طرقاً أقل، أو انتظر دقيقة، أو سجّل الدخول لحصة أكبر.
  • كل الطرق تجيب بـ 403 أو بالصفحة نفسها: جدار حماية أو نظام مكافحة روبوتات أمام الموقع يجيب بدلاً من التطبيق، فتصف النتائج تلك الطبقة لا الواجهة البرمجية.

الأسئلة الشائعة حول مختبِر طرق HTTP

هل يمكنني إرسال جسم للطلب أو ترويسات خاصة بي؟

لا. المختبِر ليس وسيطاً لتمرير الطلبات: لا يستطيع الطلب أن يحمل جسماً ولا كوكيز ولا ترويسات منك، بل الطريقة والرابط ووكيل مستخدم ثابتاً وترويسة الوسيط X-Mutqan-Relay: 1 فقط. لكن مسار الرابط وسلسلة الاستعلام فيه يُرسلان كما تكتبهما، وقد تُحدث POST وPUT وPATCH وDELETE أثراً في مورد حقيقي، فلا تختبر إلا روابط تملكها أو مسموح لك باختبارها. ولإرسال طلب كامل من حاسوبك، يكتب لك محوّل طلب HTTP إلى cURL الأمر جاهزاً.

هل من الآمن إرسال DELETE أو PUT إلى واجهتي البرمجية؟

لا تحمل الطلبات جسماً ولا بيانات دخول، فينبغي لنقطة النهاية المحمية أن ترفضها بـ 401 أو 403 أو 405. أما نقطة النهاية التي تجيب بـ 2xx عن DELETE مجهول المصدر فقد تكون نفّذته فعلاً. لا تختبر إلا روابط تملكها أو مسموح لك باختبارها، ووجّه طرق الكتابة إلى مورد تجريبي لا إلى بيانات حية.

لماذا تظهر لطريقة ما إجابة 3xx ولا شيء غيرها؟

تُعرض إعادة التوجيه ولا تُتبع: يسجّل الطلب الحالة ويتوقف، لأن تتبّعها يعني إرسال الطريقة إلى رابط آخر. اختبر الرابط الذي يشير إليه التوجيه إن كان هو ما يهمك.

لماذا لا تظهر ترويسات CORS رغم أن واجهتي تدعم CORS؟

لا ترسل الطلبات ترويسة Origin، وكثير من الخوادم لا يضيف ترويسات Access-Control-Allow-* إلا لطلبات من أصل آخر تحمل هذه الترويسة. أما فاحص CORS فيرسل طلب تحقق مسبق حقيقياً بالأصل الذي تختاره.

كم مرة يمكنني تشغيله؟

كل طريقة طلبٌ صادر واحد يُحتسب من حصة دقيقة مشتركة مع الأدوات الأخرى التي تتصل بالمواقع نيابةً عنك. واختبار الطرق السبع كلها يستهلك معظم حصة الزائر غير المسجّل الدخول، ويرفعها تسجيل الدخول. وحين تنفد تخبرك الصفحة بمدة الانتظار.

ملاحظات تقنية

يعرّف RFC 9110 في القسم 9 الطرق: GET وHEAD آمنتان، وPUT وDELETE متساويتا الأثر عند التكرار، وPOST ليست هذا ولا ذاك، ويجب على كل خادم عام الغرض دعم GET وHEAD. ويجب أن تحمل إجابة 405 Method Not Allowed ترويسة Allow تسرد الطرق التي يدعمها المورد (§15.5.6 و§10.2.1)، أما 501 Not Implemented فتعني أن الخادم لا يعرف الطريقة أصلاً. ويعرّف RFC 5789 الطريقة PATCH.

كل اختبار طلبٌ واحد يجريه خادم متقن عبر وسيط التشخيص الخاص به: يُحلّ اسم المضيف عبر DNS-over-HTTPS ويُرفض ما لم تكن كل عناوينه عامة، ولا يحمل الطلب إلا الطريقة والرابط ووكيل مستخدم ثابتاً وترويسة الوسيط X-Mutqan-Relay: 1، ولا يُقرأ جسم الإجابة. أما TRACE (التي تعيد الطلب كما هو) وCONNECT (التي تفتح نفقاً) فليستا ضمن المجموعة ولا تُرسلان أبداً.

تُعرض ترويسات CORS ‏(Access-Control-Allow-Origin و-Methods و-Headers) كما حملتها الإجابات. ولا ترسل الطلبات ترويسة Origin، فقد لا يرسل الخادم الذي يغيّر إجابة CORS بحسب الأصل أي شيء هنا؛ وطلب التحقق المسبق الحقيقي من المتصفح هو OPTIONS يحمل Origin وAccess-Control-Request-Method، وهو ما يرسله فاحص CORS.

الحدود ومنهجية القياس

ليس وسيطاً لتمرير الطلبات: لا يمكن إرسال جسم ولا كوكيز ولا رموز دخول ولا ترويسات خاصة، فلا تجيب نقطة النهاية التي تشترطها إلا برفضها.

يُرسل الرابط كما تدخله، بمساره وسلسلة الاستعلام فيه، وقد تُحدث POST وPUT وPATCH وDELETE أثراً في مورد حقيقي حتى دون جسم: لا تختبر إلا روابط تملكها أو مسموح لك باختبارها.

لا توجد هنا إلا الطرق السبع المذكورة؛ ولا تُرسل أبداً TRACE وCONNECT ولا الطرق المخصّصة (PROPFIND وPURGE).

تخرج الطلبات من شبكة خادم متقن لا من حاسوبك؛ وقد تجيبك الخوادم التي تعامل حركة السحابة أو المناطق أو الروبوتات معاملة مختلفة بإجابة أخرى.

طلب واحد لكل طريقة لقطة لحظية: قد تغيّر حدود المعدل وموازنات الحمل ذات الخوادم الخلفية المختلفة والذاكرات المؤقتة الإجابةَ في الطلب التالي.

الأمان والخصوصية

يُرسل الرابط إلى خادم متقن، فيرسل الطرق المختارة إلى ذلك المضيف من شبكته؛ ولا يصل إلى المضيف شيء مما تكتبه سوى الرابط، ولا يُخزَّن شيء.

المراجع

  • RFC 9110: HTTP SemanticsIETF · 2022معاني أساليب HTTP وحقول الترويسات ورموز الحالة والتفاوض على المحتوى، بغضّ النظر عن إصدار البروتوكول.
  • Allow header — MDNMDN Web Docs (Mozilla)ترويسة الإجابة Allow: الطرق التي يدعمها المورد، ولماذا يجب أن ترسلها إجابة 405.
  • OPTIONS request method — MDNMDN Web Docs (Mozilla)الطريقة OPTIONS: سؤال الخادم عن الطرق التي يسمح بها الرابط، ودورها كطلب تحقق مسبق في CORS.