FreeToGenerate.com

ثلاث خصائص، والسجل لا يدوّن منها إلا اثنتين.

ابحث عن طريقة

آمنة
لا
متكافئة التكرار
لا
قابلة للتخزين المؤقت
بشروط
  • لا ينبغي لوكيل المستخدم أن يرسلها من تلقاء نفسه، وعليه تنبيه المستخدم قبل ذلك.
  • لا يجوز للوسيط أن يعيدها تلقائيًا، وهذا نص صريح في RFC 9110.
  • لا يجوز حفظها إلا إذا وسمها الخادم، ولا تُستعمل إلا للرد على GET أو HEAD لاحق.

قابلة للتخزين فقط مع معلومات طزاجة صريحة وترويسة Content-Location مطابقة، ولا تُستعمل إلا للرد على GET أو HEAD لاحق

معرَّفة في RFC 5789 §2

لا فرق بين الحروف الكبيرة والصغيرة. جرّب PATCH أو DELETE أو QUERY أو REPORT، فكل واحدة منها تفاجئ لسبب مختلف.

السجل بالأرقام

اسمًا مسجَّلًا
41
آمنة
9
متكافئة التكرار
36
قابلة للتخزين بلا شرط
3
لا تذكر شيئًا
9

الأمان وتكافؤ التكرار عمودان في سجل آيانا، أما القابلية للتخزين المؤقت فليست كذلك: كان لا بد من قراءتها في ثلاثة عشر معيارًا مختلفًا.

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

الطرق المسجَّلة الإحدى والأربعون

41 معروضة
الطريقةآمنةمتكافئة التكرارالتخزين المؤقتالمرجع
ACLلانعملم يُذكرRFC 3744 §8.1
BASELINE-CONTROLلانعملاRFC 3253 §12.6
BINDلانعملم يُذكرRFC 5842 §4
CHECKINلانعملاRFC 3253 §9.4
CHECKOUTلانعملاRFC 3253 §8.8
CONNECTلالالاRFC 9110 §9.3.6
COPYلانعملاRFC 4918 §9.8
DELETEلانعملاRFC 9110 §9.3.5
GETنعمنعمنعمRFC 9110 §9.3.1
HEADنعمنعمنعمRFC 9110 §9.3.2
LABELلانعملاRFC 3253 §8.2
LINKلانعملاRFC 2068 §19.6.1.2
LOCKلالالاRFC 4918 §9.10
MERGEلانعملاRFC 3253 §11.2
MKACTIVITYلانعملاRFC 3253 §13.5
MKCALENDARلانعملاRFC 4791 §5.3.1
MKCOLلانعملاRFC 4918 §9.3
MKREDIRECTREFلانعملاRFC 4437 §6
MKWORKSPACEلانعملاRFC 3253 §6.3
MOVEلانعملاRFC 4918 §9.9
OPTIONSنعمنعملاRFC 9110 §9.3.7
ORDERPATCHلانعملم يُذكرRFC 3648 §7
PATCHلالابشروطRFC 5789 §2
POSTلالابشروطRFC 9110 §9.3.3
PRIنعمنعملم يُذكرRFC 9113 §3.4
PROPFINDنعمنعمبشروطRFC 4918 §9.1
PROPPATCHلانعملاRFC 4918 §9.2
PUTلانعملاRFC 9110 §9.3.4
QUERYنعمنعمنعمRFC 10008 §2
REBINDلانعملم يُذكرRFC 5842 §6
REPORTنعمنعملم يُذكرRFC 3253 §3.6
SEARCHنعمنعملاRFC 5323 §2
TRACEنعمنعملاRFC 9110 §9.3.8
UNBINDلانعملم يُذكرRFC 5842 §5
UNCHECKOUTلانعملاRFC 3253 §4.5
UNLINKلانعملاRFC 2068 §19.6.1.3
UNLOCKلانعملاRFC 4918 §9.11
UPDATEلانعملاRFC 3253 §7.1
UPDATEREDIRECTREFلانعملاRFC 4437 §7
VERSION-CONTROLلانعملم يُذكرRFC 3253 §3.5
*لالالم يُذكرRFC 9110 §18.2

الأمان وتكافؤ التكرار من سجل طرق HTTP لدى آيانا. أما القابلية للتخزين المؤقت فمن معيار كل طريقة على حدة، منقولة ومدقّقة جملةً جملة.

متوفر أيضًا بلغات أخرى: English · Español · Português · Français

طرق HTTP: الآمنة والمتكافئة والقابلة للتخزين

كل طريقة سجّلتها آيانا، وماذا تعني كل واحدة لزاحف ولوسيط ولمخزن مؤقت.

ما طريقة HTTP؟

طريقة HTTP هي الفعل الذي يفتتح الطلب — GET أو POST أو DELETE — وتقول ما الذي يريد العميل فعله بالمورد الذي سمّاه. وعددها أكبر بكثير مما يصادفه المرء عادةً: يضم سجل آيانا واحدًا وأربعين اسمًا، تسعة منها فقط تأتي من مواصفة HTTP الأساسية، والبقية تصل من WebDAV ومن امتدادات الإصدارات ومن CalDAV ومن HTTP/2 ومن ثلاث مواصفات مستقلة.

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

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

طريقة الاستخدام

  1. اكتب اسم طريقة. لا فرق في حالة الأحرف. تحصل على الخصائص الثلاث، وعلى معنى كل واحدة عمليًا للعميل وللمخزن المؤقت، وعلى رابط إلى بند المعيار الذي ينص عليها.
  2. أو ابحث في السجل كله. يضم الجدول أدناه الأسماء الواحد والأربعين. والبحث برقم معيار — 9110 أو 4918 — يعيد كل ما يعرّفه ذلك المستند.
  3. أو ضيّقه إلى ما ستصادفه فعلًا. مربع اختيار واحد يترك الجدول على الأسماء التسعة التي يسجّلها RFC 9110 بنفسه، وهي كل ما ترسله معظم الواجهات البرمجية أصلًا.

الخاصية التي لا يدوّنها السجل

يعدّد البند 16.1.1 من RFC 9110 الحقول التي يجب أن يحملها تسجيل أي طريقة: الاسم، وهل هي آمنة، وهل هي متكافئة التكرار، ومؤشر إلى المواصفة. أربعة حقول، وليست القابلية للتخزين المؤقت من بينها. ومع ذلك يقول البند 16.1.2 من المستند نفسه إن تعريف أي طريقة جديدة يحتاج إلى بيان ما إذا كانت آمنة ومتكافئة التكرار وقابلة للتخزين المؤقت. ثلاث خصائص يفصل بينهما بند واحد، اثنتان منها مدوَّنتان.

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

وهذا الصمت ليس مجهولًا، وهذه هي الجملة التي تجعل الجدول تامًّا لا ناقصًا. البند 9.2.3: لكي يحفظ مخزن مؤقت استجابةً ويستعملها، يجب أن تسمح الطريقة بالتخزين صراحةً وأن تفصّل شروطه، والطريقة التي لا يفعل تعريفها ذلك لا يمكن تخزينها. فالصمت رفضٌ افتراضي، مكتوب في المعيار نفسه. ومع ذلك يعرض الجدول تلك الصفوف التسعة بوصف «لم يُذكر» لا «لا»، لأن ما ترفضه المواصفة وما لم تفكر فيه أصلًا حقيقتان مختلفتان، ولا يمكن الاستشهاد إلا بإحداهما في مراجعة شيفرة.

وتختلف الصياغات أيضًا اختلافًا يستحق النظر. ثماني طرق تقول إن الاستجابات يجب ألّا تُخزَّن مؤقتًا، وهذا يلزم المخزن. وعشر — عائلة الإصدارات ومعها MKCALENDAR — تشترط بدل ذلك أن يرسل الخادم الترويسة Cache-Control: no-cache، وهذا يلزم الخادم. وSEARCH تقول «ينبغي ألّا» فحسب. وPROPFIND تقول إن النتائج يجوز تخزينها، مع الحذر. والجدول يسجّل أي صياغة أنتجت كل جواب.

الصفوف التي يخطئ فيها الجميع

PATCH ليست متكافئة التكرار. تجدها إلى جانب PUT في كل درس عن REST وهي تتصرف تصرفًا آخر: تطبيق الرقعة نفسها مرتين قد لا يساوي تطبيقها مرة، فيسجّلها السجل غير آمنة وغير متكافئة، ويقول RFC 9110 إن الوسيط يجب ألّا يعيد طلبًا كهذا تلقائيًا. وأما DELETE فمتكافئة التكرار رغم أن اسمها أشد ما في القائمة تدميرًا: حذف الشيء مرتين يتركه محذوفًا.

والأمان لا يعني القابلية للتخزين. تسع طرق آمنة، وثلاث منها فقط — GET وHEAD وQUERY — قابلة للتخزين بلا شرط. أما OPTIONS وTRACE فهما للقراءة، واستجاباتهما غير قابلة للتخزين بنص صريح. وREPORT آمنة ومتكافئة التكرار، ولا تقول مواصفتها شيئًا عن التخزين المؤقت البتة.

والعكس يسقط كذلك: POST وPATCH ليستا آمنتين ولا متكافئتين، وكلتاهما قابلة للتخزين بشروط. فاستجابة POST يجوز حفظها إذا حملت معلومات طزاجة صريحة وترويسة Content-Location تطابق هدف الطلب، ولا تُستعمل عندئذ إلا للرد على GET أو HEAD لاحق، لا على POST آخر أبدًا. ويلاحظ RFC 9110 عرَضًا أن الغالبية الساحقة من المخازن المؤقتة لا تنفّذ سوى GET وHEAD على أي حال، وهو اعتراف من المعيار بأن الواقع سار في اتجاه آخر.

وطرفتان أخريان. صارت QUERY طريقةً على المسار المعياري في حزيران 2026: آمنة، متكافئة التكرار، قابلة للتخزين، وتحمل متن طلب — وهو تحديدًا ما يريده الناس كلما حاولوا حشر بحث طويل في GET. ومفتاح تخزينها يجب أن يضم المتن، وهذا بالضبط سبب تأخرها كل هذه المدة. ويضم السجل مدخلًا اسمه نجمة فحسب، وليس بطريقة: هو محجوز كي لا يسجّل أحد طريقة بهذا الاسم، لأنه يتعارض مع رمز الشمول في ترويسات مثل Access-Control-Request-Method.

ما لا تستطيع هذه الصفحة إخبارك به

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

والجدول كذلك لقطة لسجل ينمو. أُضيفت QUERY في 2026، ولا شيء هنا يتنبأ بما سيضاف بعدها. وحيث يقول صف إن مواصفةً صامتة، فذلك وصف للمستند كما هو اليوم لا وعد بأن يظل صامتًا.

وتسجيل الطريقة لا يقول شيئًا عن وجود ما يدعمها. فمعظم هذه الأسماء الواحد والأربعين يخص WebDAV وامتداداته، وسيردّ عليها خادم وِب عادي بالرمز 405.

لماذا هي مجانية؟

السجل كله بضعة كيلوبايتات تُشحن مع الصفحة ويجري البحث فيها داخل متصفحك. لا يُرفع شيء مما تكتبه، ولا يُسجَّل شيء، ولا حساب عليك إنشاؤه.

بلا تسجيل، وبلا حدود، وبلا علامة مائية على أي شيء تنسخه.