💹 🍧 💔 कैसे mod_rewrite वास्तव में काम करता है। जारी रखने के लिए मैनुअल 🐓 ⛹🏿 👃🏼

यह लेख mod_rewrite के साथ काम करने पर हमारे तकनीकी सहायता कर्मचारियों के लिए उन्नत प्रशिक्षण के विचार से विकसित हुआ। अभ्यास ने दिखाया है कि रूसी में बड़ी संख्या में पाठ्यपुस्तकों में उपलब्ध अध्ययन के बाद, टेम्पलेट समस्याओं को हल करने के लिए समर्थन अच्छी तरह से काम करता है, लेकिन नियमों का आत्म-संकलन परीक्षण और बड़ी संख्या में त्रुटियों के कारण होता है। समस्या यह है कि mod_rewrite के संचालन की अच्छी समझ के लिए, आपको मूल अंग्रेजी भाषा के दस्तावेज़ का अध्ययन करने की आवश्यकता है, जिसके बाद या तो अतिरिक्त स्पष्टीकरण या RewriteLog के साथ प्रयोग के घंटे।

लेख ऑपरेशन के mod_rewrite तंत्र का वर्णन करता है। इसके संचालन के सिद्धांतों को समझना हमें प्रत्येक निर्देश के प्रभाव को स्पष्ट रूप से समझने की अनुमति देता है और स्पष्ट रूप से कल्पना करता है कि प्रसंस्करण के निर्देशों के दौरान mod_rewrite के अंदर एक समय या दूसरे में क्या होता है।

मुझे लगता है कि पाठक पहले से ही परिचित है कि mod_rewrite क्या है, और मैं इसकी मूल बातें नहीं बताऊंगा, जो कि इंटरनेट पर आसानी से मिल जाती हैं। यह भी ध्यान दिया जाना चाहिए कि लेख .htaccess फ़ाइल में अपने निर्देशों का उपयोग करते समय mod_rewrite के काम पर प्रकाश डालता है। <VirtualHost> के संदर्भ में काम करते समय अंतर लेख के अंत में उल्लिखित हैं।

तो, आपने mod_rewrite का अध्ययन किया, कई RewriteRule संकलित किए और अंतहीन रीडायरेक्ट का सामना करने में कामयाब रहे, इस मामले के साथ जब किसी कारण के लिए नियम आपके अनुरोध को नहीं पकड़ता है, साथ ही नियम समूह के अप्रत्याशित कार्य के साथ, जब अगला नियम अप्रत्याशित रूप से अनुरोध को बदलता है, तो पिछले नियमों द्वारा श्रमसाध्य रूप से तैयार किया गया।

ऐसा क्यों हो रहा है?

क्या काम करता है के साथ RewriteRule

पहला रिवरट्युल वह मार्ग है जहाँ से .htaccess अनुरोधित फ़ाइल में स्थित है। यह लाइन कभी भी "/" से शुरू नहीं होती है। इसके बाद का रिवाइरट्यूल पिछले रूपांतरणों का परिणाम बताता है।

यह समझने के लिए कि एक रीवेराइट कैसे काम करता है, आपको पहले यह निर्धारित करना होगा कि यह किसके साथ काम करता है । इस बात पर विचार करें कि कैसे अपाचे को एक स्ट्रिंग मिलती है जिसे शुरू में।

जब आप पहली बार mod_rewrite के साथ काम करना शुरू करते हैं, तो आप तार्किक रूप से मान लेते हैं कि यह लिंक के साथ काम करता है। हालाँकि, .htaccess में mod_rewrite का उपयोग करने के मामले में, ऐसा नहीं है। वास्तव में, एक लिंक रिवाइटररुएल को पारित नहीं किया जाता है , लेकिन अनुरोधित फ़ाइल का पथ ।

उस समय Apache की आंतरिक वास्तुकला के कारण ।htaccess प्रभावी होने के कारण, mod_rewrite केवल संसाधित किए जाने वाले फ़ाइल के पथ पर काम कर सकता है। यह इस तथ्य के कारण है कि mod_rewrite में स्थानांतरण से पहले अनुरोध को अन्य मॉड्यूल (उदाहरण के लिए, mod_alias) द्वारा बदला जा सकता है, और साइट पर फ़ाइल का अंतिम पथ अब मूल लिंक के साथ मेल नहीं खा सकता है। यदि mod_rewrite ने मूल लिंक के साथ काम किया, तो यह उन मॉड्यूल की कार्रवाई का उल्लंघन करेगा जिन्होंने इसके पहले अनुरोध को बदल दिया था।

इसलिए, संसाधित की जाने वाली फ़ाइल का पूर्ण पथ mod_rewrite को दिया जाता है। इसके अलावा, mod_rewrite .htaccess का मार्ग जानता है, जिसमें RewriteRule नियम शामिल हैं। फ़ाइल पथ को उस लिंक के समान बनाने के लिए, जिसे साइट डेवलपर के साथ काम करने की योजना बना रहा है, mod_rewrite पूर्ण पथ से भाग को .htaccess फ़ाइल में काट देता है।

तो, यह वह रास्ता है जहाँ से .htaccess का रास्ता काट दिया जाता है जो पहले RewriteRule को दिया जाता है। उदाहरण के लिए:

निवेदन: http://example.com/templates/silver/images/logo.gif
DocumentRoot: /var/www/example.com
फ़ाइल का पथ: /var/www/example.com/templates/silver/images/logo.gif
.htaccess यहां स्थित है: /var/www/example.com/templates/.htaccess
पहला रीराइट्रू पारित किया जाएगा: चांदी / चित्र / लोगो.गिफ़
कृपया ध्यान दें: "टेम्पलेट /" भी काट दिया गया था।

स्लैश के साथ .htaccess का रास्ता कट जाता है। इसका एक परिणाम है: प्रसंस्करण के लिए शुरू में एक पंक्ति जिसे रेवेरिट्यूल को पारित किया जाता है वह कभी भी "/" से शुरू नहीं होता है।

यह याद रखना महत्वपूर्ण है कि रिवेरिट्यूले क्या नहीं करता है । यह साइट के नाम को संसाधित नहीं करता है, जो तर्क स्क्रिप्ट में पारित हो जाते हैं, और यह पूरे लिंक को संसाधित नहीं करता है यदि .htaccess साइट की जड़ में स्थित नहीं है। यह सब रिवर्टकॉन्ड द्वारा किया जाता है, जिसे हम थोड़ी देर बाद छूते हैं। तो:

# - / RewriteRule ^/index.php$ /my-index.php # - RewriteRule RewriteRule ^example.com/.* http://www.example.com # - RewriteRule RewriteRule index.php\?newspage=([0-9]+) news.php?page=$1 # .htaccess , templates, # , . , .htaccess templates/.htaccess , # , mod_rewrite .htaccess RewriteRule # "templates/" RewriteRule ^templates/common/yandex-money.gif$ templates/shared/yad.gif

Mod_rewrite का उपयोग करने की शुरुआत में, मैं केवल साइट के मूल में .htaccess में इसके साथ काम करने की सलाह देता हूं। यह कुछ हद तक उसके काम के नियंत्रण को सरल करेगा।

क्या पुनर्लेखन के साथ काम करता है, हम समझ गए। अब देखते हैं कि यह कैसे काम करता है।

कैसे काम करता है

रिवरराइट नियम को स्ट्रिंग को रेग्युलर एक्सप्रेशंस के अनुसार परिवर्तित करता है, और यह है। RewriteRule एक स्ट्रिंग के साथ काम करता है, न कि किसी फ़ाइल के लिंक या पथ के लिए।

जैसा कि हमें ऊपर पता चला है, .htaccess से अनुरोधित फ़ाइल तक का पथ RewriteRule इनपुट को जाता है। सबसे सुविधाजनक तरीका अब रास्तों और लिंक को अनदेखा करना है और विचार करना है कि एक नियमित स्ट्रिंग के रूप में रिवरराइट क्या काम करता है। यदि यह कार्य किसी भी तरह से किया जाता है, तो यह स्ट्रिंग, रेवेरिएट से रेवेरिट के पास जाती है।

सामान्य शब्दों में, यदि हम झंडे का उपयोग करने की कठिनाइयों को दूर करते हैं (जिनमें से कुछ पर हम नीचे चर्चा करेंगे) और नियमित अभिव्यक्तियों को संकलित करने की कठिनाइयों (जो कि हम शायद ही इस लेख में स्पर्श करेंगे), RewriteRule बहुत सरलता से काम करता है।

हमने एक लाइन ली।
पहले तर्क में रेगेक्स के साथ तुलना करें।
यदि कोई मेल है, तो दूसरे तर्क के मान के साथ पूरे स्ट्रिंग को बदलें।
अगले पुनरीक्षण के लिए लाइन को पारित कर दिया।

यह, सामान्य तौर पर, सभी है। यह स्पष्ट रूप से वर्णन करने के लिए कि एक रिवर्रिएट एक स्ट्रिंग के साथ काम करता है, निम्नलिखित शानदार उदाहरण पर विचार करें:

# : http://mysite.com/info.html # RewriteRule "info.html" # . RewriteRule ^info.html$ "I saw a turtle in the hole. And it was dancing rock-n-roll. And it was smiling. All in all, it was a very funny doll." # "info.html" -> "I saw a turtle..." # . RewriteRule turtle https://example.com/information/index.html # "I saw a turtle..." -> "https://example.com/information/index.html" # ! RewriteRule ^(.*)example.com(.*)$ $1example.org$2 # "https://example.com/information/index.html" -> "https://example.org/information/index.html" # ! RewriteRule ^https:(.*)$ ftp:$1 # "https://example.org/information/index.html" -> "ftp://example.org/information/index.html" # . RewriteRule ^(.*)/index.html$ $1/main.php # "ftp://example.org/information/index.html" -> "ftp://example.org/information/main.php"

जैसा कि आप देख सकते हैं, RewriteRule परवाह नहीं करता है कि किसके साथ काम करना है - यह सिर्फ स्ट्रिंग को दिए गए तर्कों के अनुसार परिवर्तित करता है। यदि आप चाहें, तो आप किसी भी डेटा को एक पंक्ति में संग्रहीत कर सकते हैं, यदि आप चाहें, तो नियमित भावों की दृढ़ता और अच्छे ज्ञान के लिए, आप कम से कम RewriteRule पर tic-tac-toe लिख सकते हैं।

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

सभी रूपांतरण पूरा हो जाने के बाद और अंतिम रीराइटराइट पूरा हो चुका है, रिवर्टबेस प्रभावी हो जाता है।

क्या है रेवाइटबेस?

यदि ट्रांसफ़ॉर्मेशन के बाद प्राप्त क्वेरी सापेक्ष है और मूल से भिन्न है, तो रेवेरिटबेस अपने आप को बाईं ओर जोड़ देगा। .Htaccess में RewriteBase निर्दिष्ट करना सुनिश्चित करें। इसका अर्थ साइट के मूल से .htaccess तक का मार्ग है।
RewriteBase को सभी RewriteRule के बाद ही निष्पादित किया जाता है, और उनके बीच नहीं।

हमने पहले ही ऊपर कहा था कि .htaccess में काम करने वाले mod_rewrite को अनुरोधित फ़ाइल का पूर्ण पथ मिलता है। इसे किसी रीवेरिट के पास भेजने के लिए, mod_rewrite ने .htaccess का रास्ता काट दिया। फिर रिवाइटररूल नियम एक-एक करके अनुरोध को बदलते हैं। और अब, अनुरोध को बदल दिए जाने के बाद, अपाचे को फ़ाइल के पूर्ण पथ को पुनर्स्थापित करना चाहिए, जिसे अंततः प्रक्रिया करना चाहिए। RewriteBase वास्तव में एक हैक है जो फ़ाइल के मूल पथ को पुनर्स्थापित करने में मदद करता है।

सभी रूपांतरणों के बाद RewriteBase को निष्पादित किया जाता है। इसका मतलब यह है कि यह रिवाइटराइट के बीच अनुरोध को नहीं बदलेगा, लेकिन केवल तभी प्रभावी होगा जब सभी रिवाइटररेल पूरा हो चुके हों।

सभी परिवर्तनों के बाद, रिवर्टबेस दिखता है, सापेक्ष पथ अंतिम एक या पूर्ण है। अपाचे के संदर्भ में, हमारा मतलब है रिश्तेदार या निरपेक्ष पथ, साइट के मूल से गिनती:

images / logo.gif - रिश्तेदार।
/images/logo.gif - निरपेक्ष (एक स्लैश की शुरुआत में)।
http://example.com/images/logo.gif इन सबसे पूर्ण है।

यदि पथ निरपेक्ष है, तो ReriteBase कुछ नहीं करता है। और अगर रिश्तेदार - RewriteBase खुद को बाईं ओर जोड़ता है। यह आंतरिक और बाहरी दोनों पुनर्निर्देशों के लिए काम करता है:

# .htaccess /images/ # RewriteBase /images/ RewriteBase /images/ # http://example.com/images/logo.gif # RewriteRule "logo.gif" RewriteRule ^logo.gif$ logo-orange.gif # RewriteRule: "logo.gif" -> "logo-orange.gif" # RewriteBase: "logo-orange.gif" -> "/images/logo-orange.gif" # http://example.com/images/header.png # RewriteRule "header.png" RewriteRule ^header.png$ /templates/rebranding/header.png # RewriteRule: "header.png" -> "/templates/rebranding/header.png" # RewriteBase: , "/'. # http://example.com/images/director.tiff # RewriteRule "director.tiff" # RewriteRule ^director.tiff$ staff/manager/director.tiff [R=301] # RewriteRule: "director.tiff" -> "staff/manager/director.tiff" # + mod_rewrite , # RewriteBase: "staff/manager/director.tiff" -> "/images/staff/manager/director.tiff" # mod_rewrite : # "/images/staff/manager/director.tiff" -> http://example.com/images/staff/manager/director.tiff

आमतौर पर mod_rewrite के साथ कुछ परिचित होने के बाद, निम्नलिखित आदत विकसित होती है: 1) प्रत्येक प्रत्येक .htaccess में "RewriteBase" जोड़ें, 2) एक स्लैश से सभी रीडायरेक्ट शुरू करें: "RewriteRule news .php /index.php?act=news"। इससे रेवेरबेस कलाकृतियों से छुटकारा पाने में मदद मिलती है, लेकिन ऐसा करना गलत है। अब जब हम जानते हैं कि रिवर्टबेस क्या करता है, हम निम्नलिखित सही नियम बना सकते हैं:

RewriteBase को साइट रूट से .htaccess तक के पथ से मेल खाना चाहिए।
आपको "/" के साथ रीडायरेक्ट करना शुरू करना चाहिए, जब आपको साइट रूट से फ़ाइल तक पूर्ण पथ निर्दिष्ट करने की आवश्यकता हो।

यदि आप रिवाइटबेस को निर्दिष्ट नहीं करते हैं तो क्या होता है? डिफ़ॉल्ट रूप से, अपाचे इसे फ़ाइल सिस्टम पर .htaccess (उदा। / / / / Www./ample_templates/) के निरपेक्ष पथ के बराबर बनाता है। अपाचे द्वारा इस धारणा की गलतता बाहरी सापेक्ष पुनर्निर्देश में प्रकट होती है:

# http://example.com/index.php # DocumentRoot: /var/www/example.com/ # .htaccess , RewriteBase. # RewriteBase .htaccess: /var/www/example.com/ # RewriteRule - "index.php" RewriteRule ^index.php main.php [R] # : "index.php" -> "main.php" # mod_rewrite , # RewriteRule # mod_rewrite RewriteBase, . # : "main.php" -> "/var/www/example.com/main.php" # mod_rewrite , : # "/var/www/example.com/main.php" -> http://example.com/var/www/example.com/main.php # , .

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

Mod_rewrite कैसे काम करता है झंडा [L]

mod_rewrite अनुरोध को फिर से संसाधित करना शुरू कर देता है, जब तक कि वह बदलना बंद न कर दे। और ध्वज [L] इसे रोक नहीं सकता है।

अधिक या कम जटिल mod_rewrite कॉन्फ़िगरेशन को संकलित करते समय, यह समझना महत्वपूर्ण है कि किसी अनुरोध को बदलने का परिणाम पिछले RewriteRule के साथ समाप्त नहीं होता है । अंतिम रीराइटराइट नियम के बाद काम किया गया है और रीटराइटबेस को जोड़ा गया है, mod_rewrite यह देखने के लिए लगता है कि अनुरोध बदल गया है या नहीं। यदि अनुरोध बदल गया है, तो इसका प्रसंस्करण नए सिरे से शुरू होता है।

अपाचे ऐसा इसलिए करता है, क्योंकि एक अनुरोध को संशोधित करने की प्रक्रिया में, इसे दूसरी निर्देशिका पर पुनर्निर्देशित किया जा सकता है। इसका अपना स्वयं का .htaccess हो सकता है, जो पिछले अनुरोध प्रसंस्करण में शामिल नहीं था। समान नए .htaccess में नियम हो सकते हैं जो अनुरोध के प्रसंस्करण को प्रभावित करते हैं - दोनों mod_rewrite नियम और अन्य मॉड्यूल के नियम। इस स्थिति को सही ढंग से संभालने के लिए, अपाचे को पूरे प्रसंस्करण चक्र को पुनरारंभ करना होगा।

- रुको, लेकिन एक झंडा है [एल] , जो अनुरोध के प्रसंस्करण को रोकता है mod_rewrite'om!

वास्तव में ऐसा नहीं है। [L] ध्वज अनुरोध प्रसंस्करण की वर्तमान पुनरावृत्ति को रोकता है। हालाँकि, यदि अनुरोध को उन रेवेरिट्यूले द्वारा संशोधित किया गया था, जो अभी भी काम करने में कामयाब रहे, तो अपाचे पहले रिवाइटररूल से फिर से अनुरोध प्रसंस्करण चक्र शुरू करेगा।

# : http://example.com/a.html RewriteBase / RewriteRule ^a.html$ b.html [L] RewriteRule ^b.html$ a.html [L]

ऊपर दिया गया उदाहरण अंत में पुनर्निर्देश के अंतहीन लूप और अंत में "आंतरिक सर्वर त्रुटि" की ओर ले जाएगा। इस उदाहरण में, एक अनंत लूप स्पष्ट है, लेकिन अधिक जटिल कॉन्फ़िगरेशन में आपको यह निर्धारित करने के लिए नियमों में तल्लीन करने की आवश्यकता हो सकती है कि कौन से अनुरोध आपस में लूप कर रहे हैं।

ऐसी स्थितियों से बचने के लिए, यदि आवश्यक हो तो केवल [एल] ध्वज का उपयोग करने की सिफारिश की जाती है। आवश्यकता दो प्रकार की हो सकती है:

जब एक बाहरी रीडायरेक्ट का उपयोग किया जाता है - [L, R = 301] या [L, R = 302]। बाहरी पुनर्निर्देशन के मामले में, अनुरोध का आगे प्रसंस्करण अवांछनीय है (नीचे [आर] ध्वज देखें), और इसे रोकना बेहतर है।
जब एक .htaccess में कोई लूप होता है जिसे समाप्त नहीं किया जा सकता है, और mod_rewrite द्वारा अनुरोध के प्रसंस्करण को जबरन रोका जाना चाहिए। इस मामले में, एक विशेष डिजाइन का उपयोग किया जाता है - लेख के अंत में इस विषय पर युक्तियां देखें।

लेकिन नीचे का उदाहरण साइकिल में नहीं जाएगा। यह निर्धारित करने का प्रयास करें कि क्यों, और कौन सी फाइल अंततः अपाचे में वापस आ जाएगी।

# : http://example.com/a.html # .htaccess RewriteBase / RewriteRule ^a.html$ b.html RewriteRule ^b.html$ a.html # .htaccess

अनुमान: सभी रिवाइटररॉल को निष्पादित करने के परिणामस्वरूप, अनुरोध को बदल दिया जाता है ताकि अंतिम परिणाम मूल के बराबर हो । अपाचे इसे देखता है और अनुरोध को पुनरावृत्ति करना शुरू नहीं करता है । A.html फ़ाइल वापस कर दी जाएगी ।

Mod_rewrite कैसे काम करता है झंडा [आर]

[R] ध्वज अनुरोध को संसाधित करना बंद नहीं करता है, एक बाहरी पुनर्निर्देशन को तुरंत वापस करता है। इसके बजाय, यह एक बाह्य पुनर्निर्देशन की आवश्यकता को याद करता है, और अनुरोध प्रक्रिया अगले रिवरराइट के साथ जारी रहती है। यह हमेशा [एल] ध्वज के साथ उपयोग करने की सिफारिश की जाती है।

[R] ध्वज अपाचे को बताता है कि आंतरिक नहीं, बल्कि बाहरी पुनर्निर्देशन करना आवश्यक है। बाहरी पुनर्निर्देश और आंतरिक के बीच क्या अंतर है? आंतरिक रीडायरेक्ट केवल उपयोगकर्ता को दी जाने वाली फ़ाइल के लिए पथ को बदल देता है, जबकि उपयोगकर्ता का मानना है कि वह उस फ़ाइल को प्राप्त करता है जिसे उसने मूल रूप से अनुरोध किया था। बाहरी रीडायरेक्ट के साथ, अपाचे, फ़ाइल की सामग्री के बजाय, उपयोगकर्ता को 301 या 302 की प्रतिक्रिया की स्थिति देता है और एक लिंक की रिपोर्ट करता है जिसे ब्राउज़र को फ़ाइल प्राप्त करने के लिए उपयोग करना होगा।

ऐसा लगता है कि [R] ध्वज को संसाधित करते समय, Apache को तुरंत RewriteRule को संसाधित करना बंद कर देना चाहिए और उपयोगकर्ता को एक बाहरी रीडायरेक्ट लौटा देना चाहिए। हालाँकि, आइए “कैसे फिर से काम करता है” खंड से एक शानदार उदाहरण याद करते हैं। इसमें, हमने पहले [R] ध्वज को इंगित किया, बाहरी पुनर्निर्देशन की आवश्यकता का संकेत दिया, और फिर निम्न रिवर्नाइट नियम के साथ लिंक को बदलना जारी रखा।

यह बिल्कुल वैसा ही है जब बाहरी पुनर्निर्देशन को निर्दिष्ट करते समय अपाचे काम करता है। वह बस अपने आप को "निशान" देता है कि सभी नियमों को निष्पादित करने के बाद, स्थिति 302 (डिफ़ॉल्ट रूप से) को वापस करना आवश्यक है, लेकिन साथ ही साथ सूची में आगे सभी पुनर्लेखन को निष्पादित करना जारी रखता है। हम अनुरोध को बदलना जारी रख सकते हैं जैसे हमें ज़रूरत है, केवल एक चीज जो काम नहीं करती है वह है पुनर्निर्देशन को आंतरिक बनाना।

हालाँकि, यह संभावना नहीं है कि आप बाहरी रीडायरेक्ट देने के बाद इसे किसी भी तरह से बदलना चाहते हैं। इसलिए, यह अनुशंसा की जाती है कि ध्वज [R] का उपयोग [L] के साथ किया जाए:

# BlackJack RewriteRule ^bj/(.*) blackjack/$1 [R=301,L] # RewriteRule ^bj/(.*) http://blackjack.example.com/$1 [L]

[R] ध्वज का उपयोग करने के बजाय, आप केवल एक बाहरी लिंक निर्दिष्ट कर सकते हैं। इस मामले में, अपाचे यह अनुमान लगाएगा कि बाहरी पुनर्निर्देशित करना आवश्यक है। यहां, [R] ध्वज के स्पष्ट संकेत के साथ मामले की तरह, यह [L] ध्वज का उपयोग करने के लिए अनुशंसित है।

यदि कोई बाहरी रीडायरेक्ट एक ही साइट पर जाता है, तो पूर्ण लिंक निर्दिष्ट करने के बिना [R] ध्वज का उपयोग करना बेहतर होता है (दूसरे शब्दों में, एक रिश्तेदार बाहरी रीडायरेक्ट का उपयोग करें)। यह नियम को साइट के नाम से स्वतंत्र कर देगा।
यदि बाहरी रीडायरेक्ट किसी अन्य साइट की ओर जाता है, अन्यथा, पूर्ण बाहरी लिंक को निर्दिष्ट करने के रूप में, यह काम नहीं करेगा।

Mod_rewrite कैसे काम करता है अनुरोध मापदंडों और ध्वज का संकेत [QSA]

रिवाइटराइट में रिक्वेस्ट पैरामीटर्स बदलने से वह लाइन नहीं बदलती है, जिसके साथ रिवाइटररेल काम करता है। हालाँकि, पैरामीटर बदलते समय, चर% {QUERY_STRING} बदल जाता है, जिसके साथ RewriteCond काम कर सकता है।

प्रयुक्त शब्दावली: "पैरामीटर" - क्वेरी पैरामीटर, "तर्क" - पुनर्विचार तर्क।

RewriteRule का उपयोग करके, आप न केवल उस फ़ाइल के पथ को बदल सकते हैं जिसे संसाधित किया जाएगा, बल्कि GET अनुरोध के मापदंडों को भी पारित किया जाएगा। यह अक्सर एक सामान्य स्क्रिप्ट हैंडलर के लिए सीएनसी प्रसंस्करण पास करने के लिए उपयोग किया जाता है, उदाहरण के लिए:

RewriteBase / # : http://example.com/news/2010/07/12/grand-opening.html # : "news/2010/07/12/grand-opening.html" RewriteRule ^news/(.*)$ index.php?act=news&what=$1 # RewriteRule: "news/2010/07/12/grand-opening.html" -> "index.php" # %{QUERY_STRING}: "" -> "act=news&what=2010/07/12/grand-opening.html"

उस समय जब रेवेरिएट नियम दूसरे तर्क में एक प्रश्न चिह्न का सामना करता है, यह समझता है कि अनुरोध में मापदंडों में बदलाव है। परिणामस्वरूप, निम्न होता है:

रीवराईट्युल उस रेखा को बदल देता है जिसके साथ यह प्रश्नवाचक चिह्न से पहले दूसरे तर्क के भाग के साथ काम करता है। कृपया ध्यान दें कि नए क्वेरी पैरामीटर उस स्ट्रिंग में नहीं आते हैं , जिसके साथ बाद के रीटराइट नियम नियम काम करेंगे।
प्रश्न चिह्न के बाद दूसरे तर्क का हिस्सा चर% {QUERY_STRING} में आता है। यदि [QSA] ध्वज निर्दिष्ट किया गया था, तो क्वेरी मापदंडों को% {QUERY_STRING} की शुरुआत में जोड़ा जाएगा। यदि ध्वज निर्दिष्ट नहीं किया गया था, तो% {QUERY_STRING} को पूरी तरह से रीवेरिट रूल से क्वेरी मापदंडों द्वारा प्रतिस्थापित किया जाएगा।

कुछ और उदाहरण:

RewriteBase / # : http://example.com/news/2010/?page=2 # RewriteRule: "news/2010/" RewriteRule ^news/(.*)$ index.php?act=news&what=$1 # : "news/2010/" -> "index.php" # %{QUERY_STRING}: "page=2" -> "act=news&what=2010/"

सबसे अधिक संभावना है, उपरोक्त नियम सही ढंग से काम नहीं करता है, क्योंकि पृष्ठ तर्क खो जाता है। चलो इसे ठीक करते हैं:

RewriteBase / # : http://example.com/news/2010/?page=2 # RewriteRule: "news/2010/" RewriteRule ^news/(.*)$ index.php?act=news&what=$1 [QSA] # : "news/2010/" -> "index.php" # %{QUERY_STRING}: "page=2" -> "act=news&what=2010/&page=2"

हमने केवल [क्यूएसए] ध्वज जोड़ा, और नियम सही तरीके से काम करना शुरू कर दिया।

यह समझना महत्वपूर्ण है कि क्वेरी पैरामीटर बदलने से% {QUERY_STRING} बदल जाता है, जिसे बाद में RewriteCond में उपयोग किया जा सकता है। तर्कों का परीक्षण करने वाले बाद के नियमों का मसौदा तैयार करते समय इसे ध्यान में रखा जाना चाहिए।

- बेशक, यह बदल जाता है, क्योंकि अनुरोध Apache'm को पुन: पेश करने के लिए जाता है!

नहीं,% {QUERY_STRING} तुरंत बदल जाता है । मैंने प्रमाण नहीं दिया - यह पहले से ही मापदंडों के बारे में लिखा गया है जितना कि यह पढ़ने में दिलचस्प है :)

RewriteCond में जांच करने के लिए क्या करना है जो उपयोगकर्ता द्वारा पारित किए गए, और RewriteRules द्वारा संशोधित नहीं किए गए हैं? लेख के अंत में युक्तियाँ देखें।

RewriteCond और प्रदर्शन

सबसे पहले, यह जाँचता है कि अनुरोध रिक्वायरट्यूल से मेल खाता है या नहीं, और उसके बाद ही रिव्रीकॉन्ड के लिए अतिरिक्त शर्तें।

कुछ शब्दों का उल्लेख करने योग्य है, जिसमें mod_rewrite निर्देशों को निष्पादित करता है। चूँकि RewriteCond पहले .htaccess और फिर RewriteRule में जाता है, ऐसा लगता है कि mod_rewrite पहले सभी स्थितियों की जाँच करता है, और फिर RewriteRule को निष्पादित करने के लिए आगे बढ़ता है।

वास्तव में, सब कुछ दूसरे तरीके से होता है। सबसे पहले, mod_rewrite यह जाँचता है कि क्या वर्तमान अनुरोध मूल्य, ReriteRule के नियमित अभिव्यक्ति से मेल खाता है, और उसके बाद ही वह RewriteCond में सूचीबद्ध सभी शर्तों की जाँच करेगा।

इसलिए यदि आपके पास एक दो-पेज की नियमित अभिव्यक्ति है, तो आप रीवेरिट में और प्रदर्शन के बारे में सोचकर, इस नियम के कार्यान्वयन को अतिरिक्त रेवेरिटकॉन्ड तक सीमित करने का निर्णय लेते हैं, जानते हैं कि कुछ भी काम नहीं करेगा। इस मामले में, अधिक जटिल नियम को छोड़ देने के लिए रीवेरिट्यूले [C] या [S] झंडे का उपयोग करना बेहतर होता है यदि सरल जाँच काम नहीं करती।

रेवेरिटकॉन्ड चर और झंडे, अन्य रेव्रीट्रेल झंडे और अधिक

प्रलेखन पढ़ें।

हम रेवेरिएट, रेवेरिटबेस, [एल], [आर] और [क्यूएसए] झंडे के सिद्धांतों से परिचित हो गए, और mod_rewrite के अंदर अनुरोध प्रसंस्करण तंत्र की भी जांच की। अप्रभावित से: अन्य RewriteRule झंडे, RewriteCond और RewriteMap निर्देश हैं।

सौभाग्य से, ये निर्देश और झंडे किसी भी पहेलियों को नहीं छुपाते हैं और अधिकांश पाठ्यपुस्तकों में वर्णित कार्य के समान हैं। उन्हें समझने के लिए, बस आधिकारिक प्रलेखन पढ़ें। सबसे पहले, मैं उन चरों की सूची का अध्ययन करने की सलाह देता हूं, जिन्हें रिवेरिटकॉन्ड -% {QUERY_STING},% {THE_REQUEST},% {REMOTE_ADDR},% {HTTP_HSTST},% {HTTP: हैडर}, आदि) में जाँच की जा सकती है।

.Htaccess के संदर्भ में और VirtualHost के संदर्भ में mod_rewrite के संचालन में अंतर

<VirtualHost> के संदर्भ में, mod_rewrite ठीक इसके विपरीत काम करता है।

जैसा कि मैंने लेख की शुरुआत में कहा था, ऊपर वर्णित सब कुछ। के संदर्भ में mod_rewrite के उपयोग पर लागू होता है। यदि mod_rewrite का उपयोग <VirtualHost> में किया जाता है, तो यह अलग तरीके से काम करेगा:

<VirtualHost> को RewriteRule में पहले स्लेश से शुरू होने वाला संपूर्ण अनुरोध पथ मिलता है, जो GET के मापदंडों की शुरुआत के साथ समाप्त होता है: "http://example.com/some/news/category/post.html?comet_page=3" -> "/ news / news / श्रेणी / पोस्ट। " यह लाइन हमेशा / के साथ शुरू होती है।
RewriteRule के दूसरे तर्क को भी / के साथ शुरू करने की आवश्यकता है, अन्यथा यह "खराब अनुरोध" होगा।
RewriteBase का कोई मतलब नहीं है।
नियम केवल एक बार पास होते हैं। [एल] ध्वज वास्तव में <VirtualHost> में वर्णित सभी नियमों को संसाधित करता है, बिना किसी पुनरावृत्तियों के।

युक्तियाँ और समाधान

यहां कुछ सुझाव दिए गए हैं जो कि लेख के दौरान दिए जा सकते हैं, लेकिन जिन्हें संक्षिप्तता के लिए मुख्य पाठ से बाहर रखा गया था।

नियमित अभिव्यक्ति संकलन

नियमित रूप से अभिव्यक्ति करने की कोशिश करें ताकि वे सबसे सटीक रूप से उन प्रश्नों को परिभाषित करें जिन्हें आप संशोधित करना चाहते हैं - ताकि किसी अन्य क्वेरी के लिए रिवेरिट्यूले नियम गलती से काम न करें। उदाहरण के लिए:

# "^" ( ) # "$" ( ): RewriteRule ^news.php$ index.php # - : RewriteRule ^news/(.*)$ index.php # - . # - , . # , . # "." (). # http://example.com/news/2009/07/28/b-effect.html RewriteRule ^news/20[0-9]{2}/[0-9]{2}/[0-9]{2}/[^/]+\.html index.php

हालांकि, एक प्रसिद्ध साइट पर नियमित अभिव्यक्तियों पर एक पूरा खंड है ।

बाह्य पुनर्निर्देश बदलें

इस तथ्य के बावजूद कि mod_rewrite आपको RewriteRule का उपयोग करते हुए प्रोटोकॉल तक भी बाहरी पुनर्निर्देशन को बदलने की अनुमति देता है, मैं अत्यधिक ऐसा नहीं करने की सलाह देता हूं। लेख में, बाहरी रीडायरेक्ट को बदलने के साथ एक उदाहरण का उपयोग केवल "लिंक" और "फाइल" जैसी अवधारणाओं से छुटकारा पाने के लिए किया जाता है और अधिक स्पष्ट रूप से यह दिखाने के लिए कि रीटराइट एक सरल रेखा के साथ काम करता है।

मुझे नहीं लगता कि mod_rewrite के डेवलपर्स ने यह मान लिया है कि कोई ऐसा करेगा, इसलिए सभी प्रकार की कलाकृतियां संभव हैं। कृपया ऐसा न करें।

एक अंतहीन लूप को कैसे रोकें

कभी-कभी किसी साइट पर रीडायरेक्ट का तर्क ऐसा होता है कि विशेष क्रियाओं के बिना, mod_rewrite उन्हें एक अप्रत्यक्ष लूप के रूप में मानता है। निम्न उदाहरण लीजिए।

साइट पर एक पृष्ठ /info.html था। एसईओ विशेषज्ञ ने फैसला किया कि खोज इंजन इस पृष्ठ को बेहतर ढंग से अनुक्रमित करेंगे यदि इसे /information.html कहा जाता है और info.html से info.html पर बाहरी पुनर्निर्देशन के लिए कहा जाता है। हालाँकि, किसी कारण से, साइट डेवलपर info.html का नाम बदलकर info.html पर नहीं भेज सकता है और पुनर्निर्देशित कर सकता है - उसे डेटा को सीधे info.html फ़ाइल से भेजने की आवश्यकता है। वह निम्नलिखित नियम लिखते हैं:

# RewriteRule ^info.html information.html [R,L] # /information.html info.html RewriteRule ^information.html info.html

... और एक अंतहीन चक्र का सामना करता है। प्रत्येक अनुरोध /information.html /information.html पर फिर से एक बाहरी रीडायरेक्ट प्राप्त करता है।

इस समस्या को हल करने के लिए कम से कम दो तरीके हैं। Habré पर उनमें से एक को पहले ही वर्णित किया गया था - रीडायरेक्ट को रोकने के लिए एक पर्यावरण चर स्थापित करना आवश्यक है और इसके मूल्य के आधार पर। कोड इस तरह दिखेगा:

RewriteCond %{ENV:REDIRECT_FINISH} !^$ RewriteRule ^ - [L] RewriteRule ^info.html$ information.html [R,L] RewriteRule ^information.html$ info.html [E=FINISH:1]

ध्यान दें कि mod_rewrite वैरिएबल नाम में 'REDIRECT_' जोड़ता है।

दूसरा तरीका THE_REQUEST में यह जांचना है कि उपयोगकर्ता द्वारा वास्तव में क्या अनुरोध किया गया था:

# info.html. # info.html - , . RewriteCond %{THE_REQUEST} "^(GET|POST|HEAD) /info.html HTTP/[0-9.]+$" RewriteRule ^info.html$ information.html [R,L] RewriteRule ^information.html$ info.html

उपयोगकर्ता के प्रारंभिक अनुरोध का विश्लेषण - अपाचे लिंक के प्रकटीकरण के खिलाफ लड़ाई

अनुरोध को संसाधित करते समय, Apache मूल अनुरोध से URL-एन्कोड किए गए वर्णों का विस्तार करता है। कुछ मामलों में, यह वांछनीय नहीं हो सकता है - डेवलपर प्रारंभिक, अनमॉडिफाइड उपयोगकर्ता अनुरोध को सत्यापित करना चाहता है। आप यह कर सकते हैं कि% {THE_REQUEST} चर को RewriteCond में जाँच कर:

RewriteCond %{THE_REQUEST} ^GET[\ ]+/tag/([^/]+)/[\ ]+HTTP.*$ RewriteRule ^(.*)$ index.php?tag=%1 [L]

एक हब पर इस तरह के मामलों में से एक की चर्चा है , इसमें से ऊपर का उदाहरण लिया गया था।

अनुशंसित प्रलेखन

आधिकारिक अपाचे प्रलेखन और विशेष रूप से तकनीकी विवरण । हाँ, हाँ।

आपका ध्यान के लिए बहुत बहुत धन्यवाद!

कैसे mod_rewrite वास्तव में काम करता है। जारी रखने के लिए मैनुअल