ज़ेन फ्रेमवर्क: एन्कोड डीकोडिंग एन्कोडेड यूआरएल पास करने के बजाय एन्कोडेड यूआरएल?

Question

मैं सेलेनियम और PHPUnit का उपयोग कर अपने ज़ेंड फ्रेमवर्क एप्लिकेशन का परीक्षण कर रहा हूं। मेरे पास एक परीक्षण है जिसे एक यूआरएल खोलने की जरूरत है जिसमें एक एन्कोडेड यूआरएल है।

$redirectToLocation = urlencode('/myothercontroller/action'); // %2Fmyothercontroller%2Faction 
$this->openAndWait('/controller/action/thenRedirectTo/' . $redirectToLocation); 

लेकिन जब मैं अपने परीक्षण चलाने के लिए, ब्राउज़र डीकोड यूआरएल को खोलने की कोशिश की:

/controller/action/thenRedirectTo//myothercontroller/action 

क्या मैं सेलेनियम इनकोडिंग URL खोलने के लिए प्राप्त करने के लिए क्या करना चाहिए?

अद्यतन: असल में ... पता चला है सेलेनियम यह काम है क्या कर रहा है, लेकिन यह के रूप में अगर Apache URL डिकोडिंग है इससे पहले कि यह नियंत्रक से हो जाता है लगता है:

The requested URL /controller/action/thenRedirectTo//myothercontroller/action was not found on this server. 

मैं इस समस्या को कैसे ठीक करना चाहिए ?

अद्यतन: मेरे पास एक ही समस्या के बारे में पूरी बातचीत है: http://old.nabble.com/URL-Encoding-td18850769.html। उनका वर्कअराउंड बेस 64 को यूआरएल एन्कोड करना था, लेकिन यह मेरे लिए पर्याप्त नहीं है। मैं इस समाधान का उपयोग अल्प अवधि में कर सकता हूं, लेकिन मैं जानना चाहता हूं कि इस समस्या का असली कारण क्या है, इसलिए मैं इसे खत्म कर सकता हूं।

अद्यतन: मेरे पास एक सहकर्मी है जो सोचता है कि ज़ेंड फ्रेमवर्क अनुरोध को रूट करने के तरीके में कोई समस्या हो सकती है। क्या आपको लगता है कि यह मामला हो सकता है?

Answer 1

दिलचस्प समस्या। मैंने व्यक्तिगत रूप से किसी क्वेरी स्ट्रिंग में किसी अन्य URL को पास करने में कोई समस्या नहीं आई है, यानी/नियंत्रक/क्रिया/फिर रीडायरेक्ट करने के लिए? Q =% 2 फ़ैमिदर कंट्रोलर% 2 फ़ैक्शन, लेकिन मैंने लंबे समय से अपाचे का उपयोग नहीं किया है, और यह बिल्कुल ठीक नहीं है कि आप ' करने की कोशिश कर रहे हैं।

एक संभावित समाधान डबल यूआरएल एन्कोडिंग हो सकता है।

$redirectToLocation = urlencode(urlencode('/myothercontroller/action')); 
$this->openAndWait('/controller/action/thenRedirectTo/' . $redirectToLocation); 

शायद अपाचे केवल एक स्तर को डीकोड करेगा।

Answer 2

मुझे पहले इस व्यवहार का सामना करना पड़ा है और यह mod_rewrite था जो डिकोडिंग कर रहा था। जहां तक ​​मुझे पता है कि इसके आसपास जाने का एकमात्र तरीका urlencode अनुरोध URL का हिस्सा है जिसे विशेष वर्णों को दो बार संरक्षित करने की आवश्यकता होती है।

Answer 3

आप अपाचे में डिबग मोड में अपने mod_rewrite स्थापित करना चाहिए और वह क्या करता है पर नज़र डालें:

RewriteEngine on 
RewriteLog /tmp/rewrite.log 
RewriteLogLevel 9 

और हमें अपने जेडएफ नियमों को फिर से लिखने दिखा। यह निश्चित रूप से% {QUERY_STRING} पर आधारित है जो प्रतिस्पर्धी डीकोडेड यूआरएल है। हम इसे% {THE_REQUEST} के साथ पुन: कार्य करने का प्रयास कर सकते हैं, जो गैर-डीकोडेड यूआरएल है। सबसे अच्छी बात केवल सही नियंत्रक के लिए% {THE_REQUEST} का इलाज करेगी।

एक और समाधान यूआरएल पर बेस 64 एन्कोडिंग का उपयोग कर सकता है, ताकि mod_rewrite और कोई अन्य टूल इसे यूआरएल जानकारी के रूप में कभी नहीं पकड़े।

परीक्षण करने के लिए एक और चीज है [बी] mod_rewrite पर, जैसा कि यहां बताया गया है: How to encode special characters using mod_rewrite & Apache?। लेकिन मुझे आश्चर्य है कि रीराइट नियम को तोड़ना नहीं होगा।

Answer 4

ऐसा लगता है कि यह Zend Framwork issue आपकी समस्या से संबंधित है। ज़ेंड/कंट्रोलर/अनुरोध/Http.php खोलने के लिए सत्यापित करें और urldecode फ़ंक्शन कॉल को हटाएं, लेकिन चर को रखें और अपना कोड रीस्टेट करें।

Answer 5

यह एक अपाचे "सुविधा" है। एन्कोडेड स्लैश स्वचालित रूप से डीकोड किए जाते हैं और एप्लिकेशन (php) को भेजे जाते हैं। इसलिए इसे एक यूरी के बजाय पैरामीटर के रूप में एक एन्कोडेड यूरी के साथ एक लंबी यूरी के रूप में पहचाना जाता है।

फिर भी, यह कॉन्फ़िगरेशन में AllowEncodedSlashes On का उपयोग करके इसे बंद करना संभव है। Apache manual पर अधिक जानकारी। कृपया ध्यान दें कि इस निर्देश का संदर्भ सर्वर कॉन्फ़िगरेशन और वर्चुअल होस्ट है ताकि आप इसे .htaccess फ़ाइल में नहीं रख सकें।