क्या मैं अपने सभी http: // लिंक को सिर्फ // में बदल सकता हूं?

Question

डेव वार्ड कहते हैं,

यह वास्तव में प्रकाश पढ़ने के लिए नहीं है, लेकिन RFC 3986 की धारा 4.2 पूरी तरह से योग्य URL के लिए प्रदान करती है जो प्रोटोकॉल (HTTP या HTTPS) को पूरी तरह से छोड़ देती है। जब URL का प्रोटोकॉल छोड़ा जाता है, तो ब्राउज़र इसके बजाय अंतर्निहित दस्तावेज़ के प्रोटोकॉल का उपयोग करता है।

सीधे शब्दों में कहें, ये "प्रोटोकॉल-कम" URL एक संदर्भ को इस तरह से अनुमति देते हैं कि आप हर ब्राउज़र में काम करेंगे:

//ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js

यह पहली बार में अजीब लग रहा है, लेकिन यह "प्रोटोकॉल-कम" URL तीसरे पक्ष की सामग्री को संदर्भित करने का सबसे अच्छा तरीका है जो HTTP और HTTPS दोनों के माध्यम से उपलब्ध है।

यह निश्चित रूप से मिश्रित सामग्री की त्रुटियों का एक समूह है, जो हम HTTP पृष्ठों पर देख रहे हैं - यह मानते हुए कि हमारी संपत्ति HTTP और HTTPS दोनों के माध्यम से उपलब्ध है।

क्या यह पूरी तरह से क्रॉस-ब्राउज़र संगत है? क्या कोई अन्य कैवियट हैं?

Comments

मैंने कुछ समय पहले IE ब्लॉग पर इस तकनीक के बारे में पढ़ा था। लेकिन जब मैंने कोशिश की कि यह बहुत अच्छी तरह से काम नहीं करेगा। यदि मेरी साइट HTTPS के साथ दी गई थी, तो ब्राउज़र (क्रोम) अभी भी प्रोटोकॉल-कम URL के लिए HTTP का उपयोग कर रहा था।

— क्रिस्टोफर रामिरेज़

चेतावनी: HTTP 3xx रीडायरेक्ट में उपयोगकर्ता के योजनाबद्ध URIs को याद रखना! HTTP हेडर इस URL प्रारूप के अनुकूल नहीं हैं। यदि आपको योजना के आधार पर पुनर्निर्देशित करने की आवश्यकता है, तो mod_rewrite या समान का उपयोग करें।

— user2596282

@ user2596282 क्रोम और फ़ायरफ़ॉक्स के आधुनिक संस्करणों में प्रयोग आपके साथ असहमत है, जैसा कि HTTP 1.1 में अभी भी (ड्राफ्ट में) संशोधन है। HTTPbis वर्किंग ग्रुप द्वारा परिभाषित युक्ति ( svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/… ) देखें । शायद आप जो कहते हैं, वह कुछ ब्राउज़रों के लिए सही है, हालाँकि; क्या आप विशेष रूप से किसी के बारे में जानते हैं जो स्थान हेडर में प्रोटोकॉल-सापेक्ष URL पर विफल रहता है।

— मार्क अमेरी जूल

कुछ अच्छे उत्तरों के साथ एक ही प्रश्न: वर्तमान पृष्ठ में से एक को संरक्षित करने के लिए प्रोटोकॉल (स्कीम) को छोड़ देने वाले निरपेक्ष यूआरएल

— --lvaro González

उनका उपयोग न करें, वे बदसूरत और बेमानी हैं।

— IllidanS4 मोनिका को

Answer 1

मैंने इसे प्रकाशित करने से पहले अच्छी तरह से परखा। ब्राउजरशॉट्स के खिलाफ परीक्षण करने के लिए उपलब्ध सभी ब्राउज़रों में से , मैं केवल एक ही ऐसा खोज सकता था जो प्रोटोकॉल सापेक्ष URL को सही तरीके से नहीं संभालता था: डिलो नामक एक अस्पष्ट * निक्स ब्राउज़र ।

दो कमियां हैं जिनके बारे में मुझे फीडबैक मिला है:

1. प्रोटोकॉल-कम URL आपके ब्राउज़र में एक स्थानीय फ़ाइल को "खोलने" के रूप में अपेक्षित रूप से काम नहीं कर सकता है, क्योंकि पृष्ठ का आधार प्रोटोकॉल फ़ाइल होगा: ///। खासतौर पर तब जब आप CDN- होस्टेड एसेट जैसे किसी बाहरी संसाधन के लिए प्रोटोकॉल-कम URL का उपयोग कर रहे हों। अपाचे या आईआईएस जैसे स्थानीय वेब सर्वर का उपयोग http: // स्थानीयहोस्ट पते के खिलाफ परीक्षण करने के लिए करता है, हालांकि ठीक काम करता है।
2. जाहिरा तौर पर कम से कम एक iPhone फ़ीड रीडर ऐप है जो प्रोटोकॉल-कम URL को सही तरीके से नहीं संभालता है। मुझे इस बात की जानकारी नहीं है कि किसी को समस्या है या वह कितनी लोकप्रिय है। एक जावास्क्रिप्ट फ़ाइल की मेजबानी के लिए, यह एक बड़ी समस्या नहीं है क्योंकि आरएसएस के पाठक आमतौर पर वैसे भी जावास्क्रिप्ट सामग्री को अनदेखा करते हैं। हालाँकि, यह एक समस्या हो सकती है यदि आप मीडिया के लिए इन यूआरएल का उपयोग सामग्री के अंदर की छवियों की तरह करते हैं जिन्हें आरएसएस के माध्यम से सिंडिकेटेड करने की आवश्यकता होती है (हालांकि, एक एकल मंच पर यह एकल पाठक ऐप शायद पाठकों की बहुत मामूली संख्या के लिए खाता है)।

Comments

जबकि IE7 / 8 प्रोटोकॉल-सापेक्ष URL (उर्फ। स्कीमहीन URI) को अच्छी तरह से संभालता है, ज्यादातर मामलों में, जब स्टाइलशीट को ऐसे URL के साथ निर्दिष्ट किया जाता है, तो यह उन्हें दो बार डाउनलोड करेगा । (तो स्टीव

— सॉडर्स

मुझे लग रहा है कि IE6 URI को एक रिश्तेदार में बदलने का प्रयास करता है (यानी एक प्रमुख स्लैश को हटाकर)। यह एक linkतत्व में है। उदाहरण के लिए, निर्दिष्ट करते समय //fonts.googleapis.com/css?family=Rokkitt:400,700IE6 लोड करने का प्रयास करता है http://mysite.com/fonts.googleapis.com/css/<...>। इतना अच्छा नहीं!

— CBono

मैंने अपने लॉग्स उदाहरणों से पाया है कि क्या प्रतीत होता है कि वेब स्पाइडर रोबोट (स्रोत अज्ञात) प्रोटोकॉल-कम लिंक का उपयोग करने की कोशिश कर रहे हैं और उन्हें सही तरीके से भी नहीं संभाल रहे हैं।

— काजकाई

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

— डेव वार्ड

यह समझना महत्वपूर्ण है कि ये URL प्रोटोकॉल- कम नहीं हैं , बल्कि प्रोटोकॉल- सापेक्ष हैं । वे अपने संदर्भ से अपने प्रोटोकॉल प्राप्त करते हैं, और एक संदर्भ का अभाव है कि वे अधिकांश ब्राउज़रों में फ़ाइल यूआरएल की तरह काम करेंगे, प्रभावी रूप से अर्थ है कि वे इसमें तोड़ते हैं कि वे इच्छित सामग्री को लोड नहीं करेंगे। जब वे http पर वितरित होने पर काम करेंगे, तो आप पाएंगे कि यदि आप पृष्ठ को बचाते हैं और स्थानीय फ़ाइल से ठीक उसी HTML को लोड करते हैं, तो वे नहीं करेंगे, क्योंकि संदर्भ अलग है। आपको इनका उपयोग करने का एकमात्र संदर्भ http बनाम https है।

— सिंक्रो

Answer 2

एक है कि क्या का सवाल हो सकता है उनके सभी लिंक बदल होने के लिए प्रोटोकॉल-संबंधी विवादास्पद हो सकता है, कि क्या एक के सवाल पर विचार करना चाहिए ऐसा करते हैं। पॉल आयरिश के अनुसार :

2014.12.17: अब जब एसएसएल को सभी के लिए प्रोत्साहित किया जाता है और प्रदर्शन की चिंता नहीं होती है, तो यह तकनीक अब एक विरोधी पैटर्न है। यदि आपके पास आवश्यक संपत्ति एसएसएल पर उपलब्ध है, तो हमेशा https: // संपत्ति का उपयोग करें ।

Comments

मैं बिल्कुल वैसा ही सोच रहा था। Http पर बाहरी संपत्ति डाउनलोड करने का क्या मतलब है अगर यह https के साथ-साथ उपलब्ध है - भले ही मुख्य साइट http का उपयोग कर रही हो (जो कि ऐसा नहीं होना चाहिए, लेकिन यह एक अन्य विषय है)।

— joonas.fi

@ joonas.fi केवल एक चीज जिसे मैं सोच सकता हूं वह मिश्रित HTTP / HTTPS चेतावनियों से बचना है जो कुछ ब्राउज़रों द्वारा उत्पन्न की जा सकती हैं

— Ohad Schneider

@Ohad_Schneider चेतावनियों को केवल तभी ट्रिगर किया जाता है जब दस्तावेज़ सुरक्षित (https) पर लोड होता है, लेकिन असुरक्षित (http) से अधिक संपत्ति होती है। जो मैं सुझाव दे रहा था कि आप हमेशा सुरक्षित से अधिक संपत्ति लोड कर सकते हैं, भले ही दस्तावेज़ असुरक्षित पर लोड हो। पूरे "प्रोटोकॉल-सापेक्ष URL" को अनावश्यक रूप से रेंडर करने के लिए कोई चेतावनी और सुरक्षित उपयोग न करने का कोई कारण नहीं है।

— joonas.fi

@Ohad_Schneider ओह क्षमा करें, मुझे लगता है कि आप जो कह रहे थे, मैंने उसे गलत समझा। Http से अधिक संपत्ति लोड होने पर जब आप दस्तावेज़ खत्म हो जाते हैं तो किसी भी चेतावनी का उत्पादन नहीं करना चाहिए। लेकिन जब आपके डॉक्यूमेंट में https खत्म हो जाता है (और शायद डिफ़ॉल्ट रूप से, क्रोम में कम से कम अवरुद्ध हो) तो http से अधिक संपत्ति लोड करना। क्या आप उस मामले का जिक्र कर रहे हैं, जहां आप अपनी साइट को https पर सेवा देते हैं और बाहरी संपत्तियां केवल http के तहत उपलब्ध हैं? हाँ, यह एक मुद्दा हो सकता है, लेकिन मुझे नहीं लगता कि कोई भी गंभीर 3 पार्टी सेवा है जो अपनी सामग्री को https पर सेवा नहीं देती है, या फिर उन्हें व्यापार से बाहर जाना चाहिए। :)

— joonas.fi

@ joonas.fi Wut? O_o यदि किसी के पास HTTPSed साइट है (तो) प्रोटोकॉल सापेक्ष URL HTTP पर 3 पार्टी संपत्ति प्राप्त करने में मदद करने में मदद नहीं करेगा - कोई रास्ता नहीं। और वैसे भी यह बेहतर है कि आपके HTTPS पेज पर साफ-हरा एसएसएल लोगो नहीं है, क्योंकि यह केवल 3 जी पार्टियों के कारण एचटीटीपीएस का समर्थन नहीं करता है।

— पूजापाठ

Answer 3

यदि आप स्टाइलशीट लोड करने के लिए प्रोटोकॉल-कम URL का उपयोग करते हैं, तो IE 7 & 8 उन्हें दो बार डाउनलोड करेगा: http://www.stevesouders.com/blog/2010/02/10/5a-missing-schema-double-download/

इसलिए, यदि आपको अच्छा प्रदर्शन पसंद है तो सीएसएस से बचना चाहिए।

Comments

यह सच है, लेकिन यह IE7 और 8 के सिकुड़ने के बाजार में हिस्सेदारी के रूप में योजनाबद्ध URL का उपयोग करने से बचने के लिए कम और एक कारण बन जाता है।

— सिमोन लिशके ने

Answer 4

हां, नेटवर्क-पथ संदर्भ आरएफसी 1808 में पहले से ही निर्दिष्ट थे और सभी ब्राउज़रों के साथ काम करना चाहिए।

Comments

यह एचटीएमएल 5 बॉयलरप्लेट कोड में भी अनुशंसित और उपयोग किया जाता है: html5boilerplate.com

— फेलिप लीमा

सफेद हां, आप इसका जवाब नहीं देते "हां क्या कोई अन्य चेतावनी है?" ? ;)

— कैस्पर क्लीजने

@ कैस्पर क्लिजने: मैंने बाकी वाक्य के साथ हां समझाया।

— गुमबो

कैस्पर, गुम्बो वास्तव में पूछे गए दो सवालों का जवाब दे रहा था: "क्या यह पूरी तरह से क्रॉस-ब्राउज़र संगत है? क्या कोई अन्य चेतावनी है?" हां पहले सवाल का जवाब है।

— डैरेन ग्रिफिथ

Answer 5

क्या यह पूरी तरह से क्रॉस-ब्राउज़र संगत है? क्या कोई अन्य कैवियट हैं?

बस इस मिश्रण में फेंकने के लिए, यदि आप एक स्थानीय सर्वर पर विकसित कर रहे हैं, तो यह काम नहीं कर सकता है। आपको एक योजना निर्दिष्ट करने की आवश्यकता है, अन्यथा ब्राउज़र ऐसा मान सकता src="//cdn.example.com/js_file.js"है src="file://cdn.example.com/js_file.js", जो स्थानीय स्तर पर इस संसाधन की मेजबानी नहीं करने के बाद से टूट जाएगा।

Microsoft इंटरनेट एक्सप्लोरर इसके लिए विशेष रूप से संवेदनशील प्रतीत होता है, इस प्रश्न को देखें: स्थानीय एक्सप्लोरर (WAMP) पर Internet Explorer में jQuery लोड करने में सक्षम नहीं

आप शायद हमेशा एक समाधान खोजने की कोशिश करेंगे जो कम से कम संशोधनों के साथ आपके सभी वातावरणों पर काम करे।

HTML5Boilerplate द्वारा उपयोग किए जाने वाले समाधान में संसाधन के सही तरीके से लोड न होने पर कमबैक होता है, लेकिन यह तभी काम करता है जब आप एक चेक को शामिल करते हैं:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>
<!-- If jQuery is not defined, something went wrong and we'll load the local file -->
<script>window.jQuery || document.write('<script src="js/vendor/jquery-1.10.2.min.js"><\/script>')</script>

मैंने यह उत्तर यहां भी पोस्ट किया है ।

अद्यतन करें: HTML5Boilerplate अब <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js">प्रोटोकॉल सापेक्ष URL को हटाने का निर्णय लेने के बाद उपयोग करता है , यहां देखें ।

Answer 6

उपयोग करते समय मेरे पास ये मुद्दे नहीं थे: //domain.com - लेकिन आपको शुरुआत में कोलन जोड़ने की जरूरत है। योआस्ट ने कुछ समय पहले इस बारे में अच्छा लिखा था। लेकिन यह ब्लॉग पोस्ट के ढेर में खो गया है।

Comments

जहां अतिरिक्त: उपयोगी नहीं है के लिए डाउन वोट। हर जगह मैंने गलती से ":" लिंक को तोड़ दिया

— लूट

Answer 7

यदि आप सुनिश्चित करना चाहते हैं कि सभी अनुरोध सुरक्षित प्रोटोकॉल में अपग्रेड किए गए हैं, तो सामग्री सुरक्षा नीति शीर्ष लेख नवीनीकरण-असुरक्षित - अनुरोधों का उपयोग करने का एक सरल विकल्प है

Content-Security-Policy: upgrade-insecure-requests;

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests