Werkzeug: Werkzeug لا يتوافق مع RFC2616

هذا السلوك ناتج عن مواصفات WSGI نفسها ، ومن المستحيل على Werkzeug التمييز بين هذين العنوانين مع الاستمرار في الالتزام بمواصفات WSGI. لا أعرف أي موقف حيث كانت هذه مشكلة في الممارسة.

تم إهمال RFC 2616 بالمناسبة ، لكن RFCs الأحدث لا تغير أي شيء في هذا الصدد على أي حال.

كما أن Werkzeug ليست مسؤولة عن تحليل أو كتابة طلبات أو استجابات HTTP على المستوى النحوي. يتم ذلك عن طريق أي خادم WSGI تختاره. لدى Werkzeug خادمًا مضمنًا ، لكن هذا يوسع خادم WSGI فقط من المكتبة القياسية.

لا ينتج السلوك عن مواصفات WSGI ، إذا كنت تشير إلى PEP 3333.
ينص PEP 3333 على ما يلي:
متغيرات HTTP_
المتغيرات المقابلة لرؤوس طلبات HTTP المقدمة من العميل (أي المتغيرات التي تبدأ أسماؤها بـ "HTTP_"). يجب أن يتوافق وجود أو عدم وجود هذه المتغيرات مع وجود أو عدم وجود رأس HTTP المناسب في الطلب.

لا يوجد شيء في المواصفات بخصوص التعامل مع الشرطات السفلية بشكل مختلف. في الواقع ، أنت لا تتوافق مع PEP 3333 إما لأنني لا أستطيع معرفة العنوان الموجود أو الغائب ، أي إذا كان "App_H" أو "App-H" موجودًا.

WSGI هو منفذ CGI خاص ببايثون. يشير PEP 0333 إلى مواصفات CGI لتعريف "متغيرات بيئة CGI" ، والتي تنص على:

The HTTP header field name is converted to upper case, has all occurrences of "-" replaced with "_" and has `HTTP_' prepended to give the meta-variable name.

راجع https://tools.ietf.org/html/rfc3875#section -4.1.18

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

هناك الكثير من الإرث من CGI هنا ، والذي ورثته WSGI ، وهو ما يحاول Werkzeug تنفيذه.

أنا حقًا لا أقصد بدء قتال ؛ لكنها مشكلة تتعلق بالآثار الأمنية ، خاصة لخوادم الويب التي تقع خلف بوابات التطبيقات "القديمة" التي تمر في معلومات حساسة / خاصة بالتطبيق في رؤوس تحتوي على شرطات سفلية دون تصفية الرؤوس الأخرى (لدي أمثلة ملموسة ، أي ، هذا هو في الواقع مشكلة في الممارسة العملية ، والتي رفضتها بتعليقك الأولي). يزيد عمر CGI عن 20 عامًا ، وبالتالي يجب أن تكون الأولوية لمواصفات WSGI و HTTP.

بالنسبة للتحليل الخام:
https://github.com/pallets/werkzeug/blob/03faf0569861e9d8c8c94785ad5560f735ba72da/werkzeug/serving.py#L123

(لدي أمثلة ملموسة ، أي أن هذه في الواقع مشكلة من الناحية العملية ، والتي رفضتها بتعليقك الأولي)

ثم كل ما يمكنني قوله هو أنني آسف أن لديك خادمًا كهذا. لا يستطيع Werkzeug فعل أي شيء حيال ذلك. المقتطف الذي عرضته هو بالتحديد سبب قول "في معظم الأحيان". يشتمل Werkzeug أيضًا على خادم اختبار بسيط يمكن استخدامه في التطوير (لتجنب الاضطرار إلى إعداد Gunicorn + Nginx / Apache ، على سبيل المثال). ولكن إذا كنت تعرض هذا الخادم للإنترنت ، فستكون المشكلة المحتملة التي ذكرتها هي أقل مشكلات (الأمان) لديك.

تم تصميم WSGI ليكون متوافقًا مع CGI إلى أقصى حد ممكن. لا يتجاوز WSGI أو يحل محل CGI. WSGI _is_ CGI. هناك القليل من العمل المتضمن في جعل تطبيق WSGI تطبيق CGI صالحًا. os.environ الخاص بنص Python CGI في الغالب مثل بيئة WSGI المكافئة. هناك الكثير من الإرث الذي يجب مراعاته عند تغيير أي شيء بخصوص هذا. Werkzeug كمشروع ليس له رأي في هذا ، ولا سيما أنا.

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