यूआरएल एकाधिक फॉरवर्ड स्लैश के साथ, क्या यह कुछ तोड़ देता है?

Question

http://example.com/something/somewhere//somehow/script.js 

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

Answer 1

HTTP RFC 2396 पथ विभाजक को एकल स्लैश होने के लिए परिभाषित करता है।

हालांकि, जब तक कि आप किसी प्रकार की यूआरएल रीराइटिंग का उपयोग नहीं कर रहे हैं (जिस स्थिति में पुनर्लेखन नियम स्लेश की संख्या से प्रभावित हो सकते हैं), यूरी मानचित्र डिस्क पर पथ पर, लेकिन (अधिकांश?) आधुनिक ऑपरेटिंग में सिस्टम (लिनक्स/यूनिक्स, विंडोज), पंक्ति में एकाधिक पथ विभाजक का कोई विशेष अर्थ नहीं है, इसलिए/path/to/foo और/path // to //// foo अंततः उसी फ़ाइल पर मैप किया जाएगा।

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

Answer 2

यूआरएल को फाइल सिस्टम पथों पर नक्शा लगाने की ज़रूरत नहीं है। तो यदि // फाइल सिस्टम पथ में // के बराबर है, तो आप गारंटी नहीं दे सकते कि यह सभी यूआरएल के लिए भी सही है।

Answer 3

"RFC3986: Uniform Resource Identifier (URI): Generic Syntax" में प्रासंगिक path-absolutenon-terminal की घोषणा पर विचार करें (निर्दिष्ट, के रूप में विशिष्ट है, ABNF वाक्य रचना में):

path-absolute = "/" [ segment-nz *("/" segment) ] 

फिर segment घोषणा कुछ लाइनें और नीचे एक ही दस्तावेज़ में विचार करें:

segment  = *pchar 

यदि आप एबीएनएफ पढ़ सकते हैं, तो तारांकन (*) निर्दिष्ट करता है कि निम्न तत्व pchar दोहराया जा सकता है बनाने के लिए कई बार, शून्य समय सहित। इस और सीखना फिर से पढ़ने ऊपर path-absolute घोषणा, आप देख सकते हैं कि एक संभावित खाली segment imples कि दूसरी "/" दोहरा सकते हैं अनिश्चित काल के लिए, इसलिए ////// (कम से कम एक / के मनमाने ढंग से लंबाई) की तरह मान्य संयोजनों की इजाजत दी path-absolute के हिस्से के रूप (जिसका उपयोग यूआरआई का वर्णन करने वाले नियम को निर्दिष्ट करने में किया जाता है)।

चूंकि सभी यूआरएल यूआरआई हैं, हम निष्कर्ष निकाल सकते हैं कि हां, यूआरएल को प्रति उद्धृत आरएफसी के लगातार कई फॉरवर्ड स्लैश की अनुमति है।

लेकिन ऐसा नहीं है कि हर कोई यूआरआई पार्सर्स प्रति विनिर्देशों का पालन करता है या लागू करता है, इसलिए मुझे पूरा यकीन है कि गैर-अनुपालन वाले यूआरआई/यूआरएल पार्सर्स और ऐसे सभी प्रकार के सॉफ़्टवेयर हैं जो इन शीर्ष पर ढेर करते हैं जहां ऐसे कोने के मामले बड़े सिस्टम को तोड़ते हैं।

Answer 4

एक बात जो आप विचार करना चाहें वह यह है कि एक खोज इंजन में आपके पृष्ठ अनुक्रमण को प्रभावित कर सकता है।this वेब पेज के अनुसार,

एक ही पथ के साथ एक यूआरएल दोहराया 3 बार गूगल

उदाहरण वे उपयोग में अनुक्रमित नहीं किया जाएगा है:

example.com/path/path/path/ 

मुझे नहीं है इस बात की पुष्टि इस भी सच हो सकता है अगर आप example.com/// करते थे, लेकिन मैं निश्चित रूप से पता लगाने के लिए अगर एसईओ अनुकूलन अपनी वेबसाइट के लिए महत्वपूर्ण था चाहते हैं।

वे उल्लेख है कि "इसका कारण यह है गूगल सोचता है कि यह एक यूआरएल जाल मारा गया है।" अगर कोई और निश्चित रूप से उत्तर जानता है, तो कृपया इस उत्तर में एक टिप्पणी जोड़ें; अन्यथा, मैंने सोचा कि इस मामले को विचार के लिए शामिल करना प्रासंगिक है।

Answer 5

इस प्रश्न का सही उत्तर है यह सर्वर के कार्यान्वयन पर निर्भर करता है!

डबल-स्लैश आरएफसी 2396 के अनुसार वाक्य रचनात्मक रूप से मान्य है, जो यूआरएल पथ वाक्यविन्यास को परिभाषित करता है, और amn समझाया गया एक खाली यूआरआई सेगमेंट का तात्पर्य है। ध्यान दें कि आरएफसी 23 9 6 केवल खाली पथ खंडों सहित पथों के अर्थशास्त्र नहीं, सिंटैक्स को परिभाषित करता है, इसलिए यह आपके सर्वर पर निर्णय लेने के लिए है।

आप सर्वर सॉफ्टवेयर ढेर आप उपयोग कर रहे उल्लेख नहीं था, शायद आप भी अपने खुद के चल रहे हैं?

किसी भी तरह से, मैं कुछ व्यावहारिक कारणों मतलब जो आप डबल स्लैश भले ही वे वाक्य रचना मान्य हैं से बचने के लिए चाहते हो सकता है बाहर बात करने के लिए करना चाहते हैं:

1. खाली मान्य किया जा रहा है के बाद से हर किसी के द्वारा की उम्मीद नहीं है, यह बग का कारण बनता है। और भले ही आज के अपने सर्वर प्रौद्योगिकी इसके साथ संगत हो सकता है, लेकिन अगले सर्वर प्रौद्योगिकी, या अपने वर्तमान सर्वर प्रौद्योगिकी की भी अगले संस्करण इसे समर्थन नहीं करने का फैसला हो सकता है (उदाहरण के लिए ASP.NET MVC वेब एपीआई पुस्तकालय जब आप की कोशिश में एक त्रुटि फेंकता डबल स्लैश के साथ एक रूट टेम्पलेट निर्दिष्ट करने के लिए)।

2. कुछ सर्वर भी रूट पथ की ओर लौटने के संकेत के रूप // में स्वीकार करे। यह या तो पर प्रयोजन, या एक बग हो सकता है ...

3. क्योंकि यह कभी कभी एक बग है, कुछ सर्वर के ढेर और फायरवॉल इसलिए मान // (पर एक प्रयास बग का शोषण है कि क्या यह वास्तव में एक था बग या नहीं), एक निर्देशिका ट्रावर्सल हमले यानी, और आप 403 Forbidden अग्रिम देना भी यूआरआई पथ की व्याख्या से पहले।

Answer 6

आपका प्रश्न "क्या यह कुछ तोड़ता है"। यूआरएल विनिर्देश के संदर्भ में, यह काम नहीं करता है। आरएफसी न पढ़ें, यहाँ एक त्वरित प्रयोग है तुम कोशिश कर सकते हैं:

cat > tmp.php <<'EOF' 
<?php 
echo $_SERVER['REQUEST_URI']; 
EOF 
php -S localhost:4000 tmp.php 

अब http://localhost:4000/hello//world

Answer 7

करने के लिए अपने ब्राउज़र को खोलने आपके एप्लिकेशन में संसाधनों के लिए लिंक के निर्माण के उदाहरण के लिए आप हैरान हो सकता है।

<script src="mysite.com/resources/jquery//../angular/script.js"></script> 

mysite.com/resources/angular/script.jsकरने का समाधान नहीं होगा लेकिनmysite.com/resources/jquery/angular/script.jsक्या आप शायद नहीं करना चाहता था

डबल स्लैश बुराई कर रहे हैं, उनसे बचने का प्रयास करें।