Werkzeug: Werkzeug RFC2616 के अनुरूप नहीं है

को निर्मित 26 मई 2016 · 6टिप्पणियाँ · स्रोत: pallets/werkzeug

विशेष रूप से, आंतरिक रूप से Werkzeug "ट्रांसफर-एन्कोडिंग" या "X-PoweredBy" प्रकार के हेडर को क्रमशः "HTTP_TRANSFER_ENCODING" और "X_POWERED_BY" में परिवर्तित करता है। हालाँकि, यदि दो शीर्षलेख "App-Header-1" और "App_Header_1" दोनों अनुरोध में मौजूद थे - या यहां तक कि केवल "App_Header_1" - दोनों को आंतरिक रूप से एक ही तरह से संग्रहीत किया जाएगा, इसके अलावा Werkzeug दोनों के बीच अंतर नहीं करता है . यह व्यवहार RFC2616 HTTP 1.1 युक्ति के अनुरूप नहीं है, जहां हेडर का नाम नियंत्रण या विभाजक वर्णों के बिना कोई भी मान्य टोकन हो सकता है। इसमें कई मुद्दे हैं, जैसे कि "App_Header_1" के साथ कोई अनुरोध आया तो इसे "HTTP_APP_HEADER_1" में बदल दिया जाएगा, अब फ्लास्क जैसे फ्रेमवर्क इसे "ऐप-हेडर -1" के रूप में व्याख्यायित करेंगे, जो समान नहीं है, और उन मानों को पास कर रहा है। जो सिस्टम सही व्यवहार पर निर्भर करते हैं, वे किसी भी समझदार तुलना रणनीति के तहत "App_Header_1" != "App-Header-1" के रूप में विफल हो जाएंगे।

स्रोत

Nessphoro

👍3

सबसे उपयोगी टिप्पणी

यदि आप पीईपी 3333 का जिक्र कर रहे हैं तो व्यवहार डब्लूएसजीआई स्पेक के कारण नहीं होता है।
पीईपी 3333 कहता है कि:
HTTP_ चर
क्लाइंट द्वारा आपूर्ति किए गए HTTP अनुरोध शीर्षलेखों से संबंधित चर (अर्थात, वेरिएबल जिनके नाम "HTTP_" से शुरू होते हैं)। इन चरों की उपस्थिति या अनुपस्थिति अनुरोध में उपयुक्त HTTP शीर्षलेख की उपस्थिति या अनुपस्थिति के अनुरूप होनी चाहिए।

अंडरस्कोर को अलग तरह से व्यवहार करने के बारे में युक्ति में कुछ भी नहीं है। वास्तव में, आप पीईपी 3333 के अनुरूप नहीं हैं क्योंकि मुझे नहीं पता कि कौन सा हेडर मौजूद है या अनुपस्थित है, यानी यदि "App_H" या "App-H" मौजूद है।

Nessphoro 26 मई 2016

👍3

सभी 6 टिप्पणियाँ

यह व्यवहार स्वयं WSGI युक्ति के कारण होता है, और Werkzeug के लिए WSGI युक्ति का पालन करते हुए उन दो शीर्षलेखों के बीच अंतर करना असंभव है। मैं ऐसी किसी भी स्थिति के बारे में नहीं जानता जहां व्यवहार में यह एक मुद्दा रहा हो।

आरएफसी 2616 वैसे भी बहिष्कृत है, लेकिन नए आरएफसी वैसे भी उस संबंध में कुछ भी नहीं बदलते हैं।

untitaker 26 मई 2016

👎2 👍1

इसके अलावा Werkzeug एक वाक्यात्मक स्तर पर HTTP अनुरोधों या प्रतिक्रियाओं को पार्स करने या लिखने के लिए ज़िम्मेदार नहीं है। यह आपके द्वारा चुने गए WSGI सर्वर द्वारा किया जाता है। Werkzeug में एक अंतर्निहित सर्वर है, लेकिन यह केवल मानक पुस्तकालय से WSGI सर्वर का विस्तार करता है।

untitaker 26 मई 2016

👎2 👍1

Nessphoro 26 मई 2016

👍3

WSGI CGI का एक पायथन-विशिष्ट पोर्ट है। पीईपी 0333 "सीजीआई पर्यावरण चर" की परिभाषा के लिए सीजीआई स्पेक का संदर्भ देता है, जिसमें कहा गया है:

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 वातावरण का उत्पादन नहीं करता है। यह डब्लूएसजीआई पर्यावरण को पार्स करता है। मुझे समझ नहीं आ रहा है कि आप इस विशेष कार्यान्वयन के खिलाफ इस मुद्दे को क्यों दर्ज कर रहे हैं। दूत को गोली मत मारो।

मूल रूप से यहाँ CGI से बहुत सारी विरासत है, जो WSGI द्वारा विरासत में मिली है, जिसे Werkzeug लागू करने का प्रयास कर रहा है।

untitaker 26 मई 2016

मेरा मतलब वास्तव में लड़ाई शुरू करने का नहीं है; लेकिन यह सुरक्षा निहितार्थों के साथ एक समस्या है, विशेष रूप से वेब सर्वरों के लिए जो "विरासत" के पीछे बैठते हैं-आश एप्लिकेशन गेटवे जो अन्य शीर्षलेखों को फ़िल्टर किए बिना अंडरस्कोर वाले शीर्षलेखों में संवेदनशील/अनुप्रयोग विशिष्ट जानकारी में गुजरते हैं (मेरे पास ठोस उदाहरण हैं, यानी यह है वास्तव में व्यवहार में एक मुद्दा है, जिसे आपने अपनी प्रारंभिक टिप्पणी से खारिज कर दिया है)। CGI 20 वर्ष से अधिक पुराना है, इसलिए WSGI और HTTP विनिर्देशों को प्राथमिकता दी जानी चाहिए।

कच्चे पार्सिंग के लिए:
https://github.com/pallets/werkzeug/blob/03faf0569861e9d8c8c94785ad5560f735ba72da/werkzeug/serving.py#L123

Nessphoro 26 मई 2016

(मेरे पास ठोस उदाहरण हैं, यानी यह वास्तव में व्यवहार में एक मुद्दा है, जिसे आपने अपनी प्रारंभिक टिप्पणी से खारिज कर दिया है)

तब मैं केवल इतना कह सकता हूं कि मुझे खेद है कि आपके पास ऐसा सर्वर है। Werkzeug इसके बारे में कुछ नहीं कर सकता। आपके द्वारा दिखाया गया स्निपेट ठीक यही था कि मैंने "अधिकांश भाग के लिए" क्यों कहा। Werkzeug में एक साधारण परीक्षण सर्वर भी शामिल है जिसका उपयोग विकास में किया जा सकता है (उदाहरण के लिए Gunicorn + Nginx/Apache को स्थापित करने से बचने के लिए)। लेकिन अगर आप उस सर्वर को इंटरनेट पर उजागर कर रहे हैं, तो आपके द्वारा उल्लेखित संभावित समस्या आपकी (सुरक्षा) समस्याओं में से कम से कम होगी।

डब्ल्यूएसजीआई को यथासंभव सीजीआई के साथ संगत होने के लिए डिजाइन किया गया था। WSGI CGI को ओवरराइड या सुपरसीड नहीं करता है। डब्ल्यूएसजीआई _is_ सीजीआई। डब्लूएसजीआई एप्लिकेशन को वैध सीजीआई एप्लिकेशन बनाने में बहुत कम काम शामिल है। पायथन सीजीआई स्क्रिप्ट का os.environ ज्यादातर समकक्ष डब्लूएसजीआई पर्यावरण की तरह दिखता है। इस बारे में कुछ भी बदलते समय विचार करने के लिए बहुत सी विरासत है। एक परियोजना के रूप में Werkzeug का इसमें कोई कहना नहीं है, और विशेष रूप से मुझे नहीं।

फिर, इस परियोजना के लिए यह मुद्दा व्यर्थ है। इस व्यवहार में Werkzeug अकेला नहीं है। पिछली बार मैंने संपूर्ण अस्पष्टता समस्या के कारण डिफ़ॉल्ट रूप से nginx HTTP शीर्षलेखों को अंडरस्कोर के साथ चेक किया था। अधिकांश अन्य उपकरण शायद उन्हें भ्रमित करते हैं। यदि अधिकांश उपकरण डैश और अंडरस्कोर के बीच अंतर नहीं बता सकते हैं, तो मानक के अनुसार एक होने पर इससे कोई फर्क नहीं पड़ता। हर किसी को साथ खेलने के लिए मजबूर किया जाता है, और अंततः अंडरस्कोर वाले हेडर उत्सर्जित करने वाले टूल को दोष देना है।

untitaker 26 मई 2016

👍2 👎1

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

Werkzeug: Werkzeug RFC2616 के अनुरूप नहीं है

सबसे उपयोगी टिप्पणी

सभी 6 टिप्पणियाँ

संबंधित मुद्दों