HTTP प्रोटोकॉल में त्रुटि

लेख में मैं न केवल आरएफसी 2616 में त्रुटि के बारे में बताना चाहता हूं, बल्कि इसके फायदे और नुकसान दिखाने के लिए, HTTP संदेश पार्सर बनाने के लिए मेरे दृष्टिकोण के बारे में। मेरा दृष्टिकोण दो सिद्धांतों पर आधारित है: "एक घंटे खोना बेहतर है, फिर पांच मिनट में उड़ान भरें" और "कंप्यूटर को काम करने दें, और मैं आराम करूंगा" ।

और इसलिए एक पूरे के रूप में कार्य: विशेष रूप से एक HTTP सर्वर और एक HTTP पार्सर को लागू करें। प्रोटोकॉल संस्करण 1.1 RFC 2616 में वर्णित है। इस विनिर्देश में दो संस्थाओं को अलग किया जा सकता है: एक कथा और BNF नियम जो संदेशों के वाक्यविन्यास को परिभाषित करते हैं। बीएनएफ नियम एक अच्छी तरह से औपचारिक बात है, जिसके लिए आरएफसी 5234 भी है, जहां बीएनएफ व्याकरण में फिर से बीएनएफ नियमों का उपयोग करने का वर्णन किया गया है। RFC 5234 जारी की गई सच्चाई बाद में RFC 2616 (HTTP) से अधिक थी, और इसमें कई छोटे अंतर हैं।

BNF लघु यात्रा

BNF व्याकरण काफी सरल है, इसलिए मैं स्पष्टीकरण के साथ एक उदाहरण दूंगा, मुझे लगता है कि यह एक विचार बनाने के लिए पर्याप्त होगा (उन लोगों के लिए जो परिचित नहीं हैं)।

start-line = Request-Line | Status-Line generic-message = start-line *(message-header CRLF) CRLF [ message-body ] 

यदि रूसी में अनुवाद किया गया है, तो यह पता चला है:
1) स्टार्ट-लाइन एक रिक्वेस्ट-लाइन या स्टेटस-लाइन है (ये भी ऐसे नियम हैं जो कहीं वर्णित हैं)
2) जेनेरिक-मैसेज स्टार्ट-लाइन, * (मैसेज-हेडर CRLF), CRLF और संभवतः मैसेज-बॉडी ([...] ब्रैकेट्स वैकल्पिकता को परिभाषित करता है) का एक क्रम है। जहाँ * (मैसेज-हैडर CRLF) दो संदेश-हेडर और CRLF नियमों के संघटन के 0 या अधिक दोहराव की अनुमति देता है।
नियमित भावों की तरह कुछ, जो आश्चर्य की बात नहीं है।

गलती के बारे में

त्रुटि का पता लगाने के लिए, नीचे मैंने कई नियम दिए हैं। उनके माध्यम से एक त्वरित रन, आप निम्नलिखित देख सकते हैं: एक अनुरोध में एक अनुरोध-रेखा होती है और सीआरएलएफ द्वारा अलग किए गए हेडर (हेडर) को दोहराते हुए। हेडर समूहों के बीच, इकाई-हेडर है, जो सामान्य-हेडर और अनुरोध-हेडर के विपरीत, एक्सटेंशन-हेडर शामिल है। एक्सटेंशन-हेडर नियम गैर-मानक हेडर की अनुमति देता है, दूसरे शब्दों में, यह वह है जो अनुरोध में हेडर जोड़कर सॉलिसिट करता है

 My-Header: I am server 

हालाँकि, अनुरोध मान्य रहेगा। इसके अलावा, यह नियम प्रोटोकॉल एक्सटेंशन लिखने की संभावना को खोलता है। चूंकि एक्सटेंशन-हेडर किसी भी हेडर की अनुमति देता है, जिसमें मानक वाले (से, स्वीकार, होस्ट, रेफर, आदि) शामिल हैं, यह स्थिति उत्पन्न होती है: यदि संदेश में एक अमान्य मानक हेडर है, तो इसे वर्णन करने वाले नियम द्वारा अनुमति नहीं दी जाएगी, लेकिन एक्सटेंशन -याडर हैडर स्वीकार करेगा जो सही नहीं है।

 Request = Request-Line ; Section 5.1 *(( general-header ; Section 4.5 | request-header ; Section 5.3 | entity-header ) CRLF) ; Section 7.1 CRLF [ message-body ] ; Section 4.3 entity-header = Allow ; Section 14.7 | Content-Encoding ; Section 14.11 | Content-Language ; Section 14.12 | Content-Length ; Section 14.13 | Content-Location ; Section 14.14 | Content-MD5 ; Section 14.15 | Content-Range ; Section 14.16 | Content-Type ; Section 14.17 | Expires ; Section 14.21 | Last-Modified ; Section 14.29 | extension-header extension-header = message-header message-header = field-name ":" [ field-value ] field-name = token field-value = *( field-content | LWS ) field-content = <the OCTETs making up the field-value and consisting of either *TEXT or combinations of token, separators, and quoted-string> 

दुर्भाग्य से, बीएनएफ में "कुछ और नहीं सहित कुछ" जैसे नियम का वर्णन करने का कोई तरीका नहीं है। विनिर्देशन में, ऐसे नियमों को अनौपचारिक रूप से वर्णित किया गया है:

 ctext = <any TEXT excluding "(" and ")"> qdtext = <any TEXT except <">> 

सही फ़ील्ड-नाम नियम कुछ इस तरह दिखना चाहिए:

 field-name = <any token excluding "Accept", "Allow", ... all header names from rfc 2616, 2617 ...> 

मुख्य के बारे में

मैं बीएनएफ पर आधारित डीकेए का निर्माण करने वाली उपयोगिताओं के बारे में बात करना चाहता था। यही है, आदर्श रूप से, वे स्वचालित रूप से पार्सर उत्पन्न करते हैं। लेकिन किसी तरह यह पता चला कि हेडलाइन को ध्यान आकर्षित करने में बहुत समय लगा, इसलिए अगली बार टूल्स के बारे में।

UPD : जेंटलमैन माइनर्स, कृपया अपनी राय व्यक्त करें। अगर मैं गलत हूं, तो मैं जानना चाहूंगा कि क्या।