URL में, // किस लिए है? [बन्द है]

Question

आमतौर पर, जब मैं देखता हूं //, यह सामान्य रूप से कुछ प्रोटोकॉल उपसर्ग का अनुसरण करता है जैसे http:या ftp:। मैंने इसे कभी भी कहीं और रखा हुआ नहीं देखा। उदाहरण के लिए,

http://www.google.com/

एक सामान्य URL है।

हालाँकि, मुझे निम्नलिखित दो सिंटैक्स एक ही साइट के विभिन्न संस्करणों की उपज के लिए मिले,

http://www.weather.com/

http://www.weather.com//

मैंने सोचा होगा कि //प्रोटोकॉल विनिर्देश के अलावा कहीं भी अमान्य होगा। मेरे आश्चर्य के लिए, मैं गलत था। यह समाप्त होने के बारे में क्या है //जो एक ही साइट के एक अलग संस्करण का निर्माण करता है?

संपादित करें:

उस साइट पर किसी ने दूसरे की हवा को पकड़ा होगा क्योंकि दोनों लिंक अब एक ही पृष्ठ पर आते हैं।

Comments

अगर मुझे अनुमान लगाना होता है, तो आप जो कर रहे हैं, वह एक ही साइट को दो बार देख रहा है, लेकिन अतिरिक्त के साथ / अंत में सीएसएस को तोड़ रहा है या इन दिनों जो भी बच्चे अपनी वेबसाइटों को प्रारूपित करने के लिए उपयोग करते हैं। :)

— मार्क एलन

webmasters.stackexchange.com इस प्रश्न के लिए बेहतर हो सकता है।

— मेहपर सी। पलुवज़ालर

@ MehperC.Palavuzlar पूर्वव्यापी में, हाँ। लेकिन सवाल के समय, मुझे लगा कि यह दायरा कुछ हद तक व्यापक है।

— चाड हैरिसन

@MarkAllen खैर टिप्पणी करने के लिए अपनी दिलचस्प का उपयोग कर कि ///या ////URL के अंत में के रूप में एक ही साइट हुई /जहां // किया था कुछ अलग में परिणाम।

— चाड हैरिसन

इस बीच डबल बैकस्लैश (\\) आमतौर पर विंडोज के यूनिफॉर्म नामकरण कन्वेंशन में देखा जाता है, उदाहरण के लिए,\\HostName[@Port]\SharedFolder\Resource

— विलियम सी

Answer 1

अग्रणी //URL सिंटैक्स का हिस्सा है। वर्ल्ड वाइड वेब के आविष्कारक ने उस गलती के लिए माफी मांगी है ।

वास्तव में, यदि आप इसके बारे में सोचते हैं, तो इसे डबल-स्लेश की आवश्यकता नहीं है। मैं इसे डबल-स्लैश नहीं होने के लिए डिज़ाइन कर सकता था। - सर टिम बर्नर्स-ली, वर्ल्ड वाइड वेब के आविष्कारक

---

अनुगामी के रूप में //, यह वास्तव में एक डबल स्लैश नहीं है। पहला स्लैश होस्ट नाम को पथ से अलग करता है। पिछले स्लेश है पथ। एक वेब सर्वर, यदि यह चाहता है, तो /एक खाली पथ से अलग पथ का इलाज कर सकता है , और जाहिर तौर पर weather.com करता है। जैसे कि यह दुर्घटना या जानबूझकर है, आपको उनसे इस बारे में पूछना होगा।

Comments

यह तब से पूर्ण हो जाता है, क्योंकि आप वेब सर्वर को केवल वेब रूट के अलावा किसी अन्य सूचकांक को देखने के लिए कॉन्फ़िगर कर सकते हैं ! मेरी टोपी आपको अच्छी लगी सर।

— चाड हैरिसन

क्या आप कह रहे हैं कि इससे http://example.comअलग तरह से व्यवहार किया जा सकता है http://example.com/? मुझे नहीं लगता था कि पहली स्लैश के मामले में ऐसा ही था।

— असंतुष्टगीतगोत्र

@DisgruntledGoat आप कर सकते थे , हाँ, कुछ का उपयोग कर .htaccessनियम। लेकिन आप शायद नहीं करना चाहिए।

— मैथ्यू

आप एक वेब सर्वर http://example.comसे अलग व्यवहार नहीं कर सकते http://example.com/, क्योंकि वे दोनों एक खाली रास्ता है। आप उन्हें एक ब्राउज़र में अलग तरह से व्यवहार कर सकते हैं।

— डेविड श्वार्ट्ज

मेजबान हेडर, शून्य या एक स्लैश को कभी भी एक ही http अनुरोध में नहीं बदलता हैGET / HTTP/1.1 :: tools.ietf.org/html/rfc2616.html#section-3.2.3

— SingleNegationElimation

Answer 2

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

<script src="//www.google.com/js/gweb/analytics/autotrack.js"></script>

इसलिए अब यह स्पष्ट हो गया है कि इस तरह का प्रोटोकॉल-कम URL पूरी तरह से योग्य URL है, न कि कोई सापेक्ष URL (जो एक एकल स्लैब के साथ शुरू होगा)।

Comments

इस शैली को "प्रोटोकॉल सापेक्ष" URL / URI कहा जाता है। एसओ पर भी ऐसे ही सवाल हैं।

— हिप्पिट्रैएल

और कोई सलाह नहीं। Paulirish.com/2010/the-protocol-relative-url

— लोरंड

Answer 3

वास्तव में इस सवाल का जवाब करने के लिए, मूल विनिर्देश प्रोटोकॉल दिया http:(या शायद ftp:, gopher:, mailto:, news:, telnet:, wais:, file:या prospero:) तो एक // संकेत मिलता है कि यूनिफॉर्म रिसोर्स लोकेटर (यूआरएल) वाक्यविन्यास इस्तेमाल किया जा रहा था, तो मेजबान (वैकल्पिक लगी होती user:password@है) तो पता दूसरे के साथ उचित मूल्य उस /। यह RFC 1738 में प्रस्तावित किया गया था ।

जैसा कि इंटरनेट विकसित हुआ, http:प्रमुख प्रोटोकॉल बन गया इसलिए ब्राउज़र अब यह मानते हैं कि http://अगर यह नहीं है तो एक उपसर्ग जोड़ा जाना चाहिए।

Comments

आपके उत्तर से प्रतीत होता है कि URL के अलावा एक बिंदु पर प्रोटोकॉल के साथ कुछ और इस्तेमाल किया जा सकता था, और इसका उपयोग //करने के संकेत के अलावा कुछ और उपयोग किया होगा ... क्या ऐसा है?

— इज़काता

@ इज़्काता 80 और 90 के दशक के अंत में, जब इंटरनेट शुरू हो रहा था, विभिन्न मदों के लिए कई अलग-अलग प्रारूप सुझाए गए थे। URL, URNs का एक उपसमूह थे (देखें RFC 3305) और इनमें अलग-अलग प्रारूप हो सकते हैं, जैसे isbn:1-23-456789-12-3। अभ्यास में, http:परिभाषित करता है कि बाकी एक URL होगा। RFC केवल प्रस्ताव हैं और अक्सर उन एक्सटेंशनों के लिए अनुमति देते हैं जो कभी भी भौतिक नहीं होते हैं। एक बिंदु पर, टिम बर्नर्स-ली ने कहा कि //एक 'सबनेट' (उदाहरण के लिए http:/govnet/whitehouse.gov) के लिए था। इस विचार का उपयोग कभी नहीं किया गया था, लेकिन '//' अब भी उतना ही कोड है जितना कि इसके लिए उम्मीद और जांच करता है।

— StarNamer

@ इज़काता: आप शायद संचार प्रोटोकॉल के साथ उपयोग किया जाने वाला एक गैर-यूआरएल यूआरएन नहीं देखेंगे; // यही है। यह इंगित करता है कि प्रोटोकॉल का उपयोग (संभवतः दूरस्थ) नेटवर्क स्थान तक पहुंचने के लिए किया जा रहा है जहां एक संसाधन पाया जाना है। वहाँ रहे हैं अन्य URN के अन्य डेटा भागों है और उपयोग नहीं करते हैं कि बहुत सारे // (आपके ब्राउज़र शायद पहचानता है "mailto:", उदाहरण के लिए)। देखें: en.wikipedia.org/wiki/URI_scheme

— KutuluMike

@MichaelEdenfield खैर, यही मैं अब सोच रहा हूँ। क्या कभी कोई ऐसा बिंदु था जहां इसे अलग तरीके से उपयोग करने का इरादा था - कुछ अलग जो एक ही प्रोटोकॉल के माध्यम से संवाद कर सकता है। एक क्रूड उदाहरण के रूप में, एक समय में इरादे के लिए http://www.google.com/और http:%/74.125.225.97/दोनों के लिए मान्य हो सकता है, और //एक होस्टनाम का संकेत दे सकता है जबकि कुछ और जैसे %/आईपी ​​पते को इंगित करता है?

— इज़काता

मुझे ऐसा नहीं लगता। कम से कम मैंने कभी कोई मसौदा दस्तावेज / उदाहरण / आदि नहीं देखा है जिसमें URL के लिए वैकल्पिक उत्तराधिकार योजना हो। मेरी धारणा हमेशा से यह रही है कि टीबीएल सिर्फ यह स्पष्ट करना चाहता था कि एक URL ने एक वास्तविक संसाधन (और मनमाना डेटा नहीं) की ओर इशारा किया है , और // बनाई गई चीजों का उपयोग पर्याप्त रूप से फ़ाइल की तरह दिखता है। URN की हर दूसरी शैली जो मैंने कभी देखी है उसमें डेटा भाग में कोई विशेष उपसर्ग नहीं है । कुछ प्रोटोकॉल यह अनुमति देते हैं कि (मुझे लगता है कि टेलनेट और गोफर, उदाहरण के लिए), लेकिन मैंने कभी भी http (s) के लिए ऐसा कुछ नहीं देखा है।

— कुतुलुमाइक 15

Answer 4

मैं डेविड के स्वीकृत उत्तर में जोड़ना चाहूंगा:

वेब के आविष्कारक की माफी के बावजूद मुझे लगता है कि डबल-स्लैश सिंटैक्स ने एक महत्वपूर्ण उद्देश्य दिया: नेत्रहीन बाहर खड़े होने के लिए। हाइपरलिंक के बिना पाठ में डबल-स्लैश ने URL के आसान दृश्य भेद की अनुमति दी। जब आपने डबल स्लैश को देखा, तो आपने तुरंत सोचा कि इसे ब्राउज़र विंडो में दर्ज किया जा सकता है, उसी तरह जैसे आपने टेक्स्ट युक्त सोचा था@एक ईमेल भेजने के लिए इस्तेमाल किया जा सकता है। यह वेब के संक्रमण चरण के दौरान विशेष रूप से महत्वपूर्ण था, जहां उस युग (ftp, telnet, गोफर) के प्रोटोकॉल में सर्वर पते या संसाधन पथ का प्रतिनिधित्व करने के लिए अपनी अजीब धारणा थी, शायद ही कभी दोनों। डबल-स्लैश से जुड़ी अधिकांश समस्याएं अभी भी मौजूद होंगी, क्योंकि डबल स्लैश एक URL का सबसे कम क्रिप्टोकरंसी है, पोर्ट नंबर, प्रतिशत एन्कोडिंग और केस-सेंसिटिविटी के बारे में सोचते हैं। लेकिन http: something.com जैसे URL होने से यहाँ मेरे उदाहरण से आसानी से भ्रमित हो सकते हैं: something.com। दूसरी ओर http: // देखें, यह हीरे की तरह कैसे चमकता है। डबल-स्लैश वेब प्रतीकात्मकता का एक महत्वपूर्ण हिस्सा रहा है और मेरा मानना ​​है कि यह त्वरित दर को अपनाना है, भले ही यह अनजाने में हो।

उन्होंने फ़ाइल नाम और URL के बीच अंतर करने के लिए भी AmigaOS का काम आसान कर दिया होगा क्योंकि AmigaOS ने फ़ाइल पथ सिंटैक्स का उपयोग किया था volume:path/to/destination। :)