Requests: 418 أنا إبريق شاي

راجع للشغل ، أنا أدرك أن هذا تغيير جذري ؛ يعتبر الإهمال والتأخير إلى الإصدار الرئيسي التالي أمرًا جيدًا.

سطر الكود المعني: https://github.com/requests/requests/blob/master/requests/status_codes.py#L55

يرجى ملاحظة الإصدارات البديلة لـ 200 OK: https://github.com/requests/requests/blob/master/requests/status_codes.py#L13

هاه. الشيء الوحيد الذي يثير قلقي هو استخدام يونيكود والشرطة المائلة العكسية ؛ الطلبات لا تنبعث منها ، أليس كذلك؟

كلا ، هذا للبحث العكسي فقط - نفس الشيء مع إبريق الشاي.

حسنا هذا جيد. تكمن المشكلة في أنه يتم استخدام التنفيذ كدليل لمنع الاستخدام الفعلي لرمز الحالة ، والذي سيشكل مشكلة في النهاية.

يرجى الاطلاع على https://github.com/nodejs/node/issues/14644 و https://github.com/golang/go/issues/21326 للمناقشات المتعلقة بالتغييرات المماثلة.

لا مانع من إزالته ، إلا إذا أردنا إضافة رموز حالة أخرى مثل 420 والأصدقاء.

HTTPbin.org يحتفظ به على الرغم من :)

الخوادم الفردية ، أنا أقل قلقًا بشأن :)

إرسال العلاقات العامة!

اجعله مقابل الفرع 3.0.0 رغم ذلك ، سيكون هذا تغييرًا فاصلاً.

يتمسك! أنا الرجل الذي يقف وراء http://save418.com (https://github.com/WhataShane/save418). أنا ، مثل كثيرين آخرين ، أستمتع بالاطلاع على (تقريبًا) كمامات غير ضارة مثل 418. إنه نوع من الأشياء التي ستضع ابتسامة على وجهك حتى عندما يتم الضغط عليك للوفاء بالموعد النهائي للمشروع ورئيسك ينبح عليك مكتب واحد انتهى. سيكون من العار الحقيقي أن نراها تذهب.

للاقتباس من romellem من موضوع Go ، الذي يلخص ببلاغة الحجة لـ 418:

فقط للتوضيح ، هل حجتك أنه عندما / إذا نفذت الكتلة 400 ، فسنريد أن يتوفر رمز إضافي واحد لتوسيع فائدة الكتلة 400 أكثر قليلاً؟

ما لم أقرأها بشكل غير صحيح ، فإن الكتلة 400 من رموز حالة HTTP بها أكثر من 50 رمزًا متاحًا. مع وجود "مساحة" متاحة للكتلة 400 بأكثر من 50٪ ، قد يكون هذا تحسينًا ما قبل النضج لمشكلة قد لا تحدث أبدًا (400 كتلة تنفد من الرموز المتاحة ، أي).

لا أحاول أن أبدو قاسيًا ، لكني شخصياً أحب بيض عيد الفصح الصغير الممتع الذي تجده طوال مهنة البرمجة. بالنسبة لي ، هذا يُظهر أن كل شيء يستمر في جعل الكمبيوتر يقوم بعمله في الواقع لا يزال من صنع البشر ، والاحتفاظ بشرائح صغيرة من هذا العنصر البشري أمر رائع (في رأيي). حجتك سليمة ومنطقية ، لكن هذا التغيير المطلوب يقلل بشكل طفيف من "متعة" Go (وربما NodeJS) بروح الهندسة المتينة. في نهاية اليوم ، يجب أن أقول إنني لا أعتقد أن المقايضة تستحق العناء.

(أنا أقدر درس التاريخ رغم ذلك! اعتقدت دائمًا أن 418 جزء من مواصفات HTTP / 1.x ؛ لم أكن أعرف عن مواصفات "HTCPCP / 1.0". 🙂)

أوافق على أنها بيضة عيد فصح ممتعة.

تأخذ الطلبات نفسها على محمل الجد ، ولكن ليس على محمل الجد. :)

قد يكون هذا هو عبارة "على محمل الجد".

أليست الإجابة الواضحة هنا لجعلها جزءًا من المواصفات بالبدء بـ RFC جديد؟

تضمين التغريدة

على الرغم من أنني أدرك أن 418 ليس جزءًا من مواصفات رمز حالة HTTP في RFC 7231 ، إلا أنه موجود في البرية. حتى جوجل قامت بتطبيقه هنا . في الحالة غير المحتملة التي قررت IETF تنفيذ استخدام حقيقي لـ 418 ، سيكون لدينا الكثير من التحذير لمعالجة هذا الأمر. أنا أؤيد ترك هذا كما هو ما لم يكن هناك سبب مقنع لإزالته.

أعطني مفاتيحك.

فقط لأكون واضحًا ، أتفق مع بقية فريق الطلبات: يجب أن نحتفظ برسم الخرائط 418 هنا. لكن السبب الذي أوافق عليه هو عملي بحت ، ليس بسبب متعة بيضة عيد الفصح (على الرغم من أنها ممتعة): يستخدم codes.py لإنشاء تعيين من عبارة السبب إلى التعليمات البرمجية. لهذا السبب ، يجب أن تتضمن أي عبارة سبب من المحتمل إلى حد ما أن تظهر لكود معين. في الوقت الحالي ، أنا إبريق شاي. إذا تغير هذا ، فسنضيف أي عبارة أخرى تعيّنها IANA.

mnot ، لا تتردد في استخدام هذه الاستجابة كالتزام ينص على أن IETF / IANA يجب أن لا تتردد في إعادة استخدام 418 ، وليس حظره نيابةً عنا. 😉 أعتقد أن عبارات السبب غبية على أي حال.

تم تقديم طلب لتسجيل 418 إلى IANA برقم 979050.

موافق؛ هذا ليس منتدى مناقشة لمزايا 418.mnot إذا كنت تريد متابعة هذا يرجى مراسلتي عبر البريد الإلكتروني. لكل شخص آخر: نحن نقدر مساهمتك ، لكنني أشعر بالرضا حيال القرار الذي اتخذناه.