क्या यह एक स्क्रिप्ट src = "http: //…"> में http: // को // के साथ बदलने के लिए वैध है?

Question

मेरे पास निम्नलिखित तत्व हैं:

<script type="text/javascript" src="https://cdn.example.com/js_file.js"></script>

इस मामले में साइट HTTPS है, लेकिन साइट सिर्फ HTTP भी हो सकती है। (जेएस फाइल दूसरे डोमेन पर है।) मैं सोच रहा हूं कि यह सुविधा के लिए निम्नलिखित करने के लिए वैध है या नहीं:

<script type="text/javascript" src="//cdn.example.com/js_file.js"></script>

मैं सोच रहा हूँ अगर इसे हटाने के लिए वैध है http:या https:?

ऐसा लगता है कि मैंने हर जगह परीक्षण किया है, लेकिन क्या ऐसे कोई मामले हैं जहां यह काम नहीं करता है?

Comments

क्या "यह हर जगह काम करता है" छवियों, iframes, लिंक-रिले आदि आदि के लिए सामान्यीकृत किया जा सकता है? यह दिलचस्प सामान है, यदि हां।

— १२३४५

हाँ, यह किसी भी जगह पर काम करना चाहिए जो यूआरआई के लिए कॉल करता है: चित्र, लिंक, आदि। यह इस उपयोग में देखने के लिए दुर्लभ हो सकता है, लेकिन यह पूरी तरह से वैध है।

— जेफ

Whats कि सभी त्वरित upvoting लोग? ऐसा नहीं है कि सवाल बुरा है या कुछ भी है, मैं बस उत्सुक हूं। लेकिन मैं शर्त लगाता हूं कि क्रिस की आंतरिक प्रतिष्ठा का प्रभाव है।

— फ्रेडरिक वर्डेंस्कॉल्ड

@ फ़्रेडरिक: क्योंकि यह एक आकर्षक और उपयोगी चाल है जिससे अधिकांश लोग स्पष्ट रूप से अनभिज्ञ हैं।

— SLss

@ फ़्रेडरिक: क्या?

— SLACs

Answer 1

स्कीम के बिना एक रिश्तेदार URL (http: या https :) मान्य है, प्रति RFC 3986: "यूनिफ़ॉर्म रिसोर्स आइडेंटिफ़ायर (URI): जेनेरिक सिंटैक्स", धारा 4.2 । यदि कोई ग्राहक इस पर विचार करता है, तो यह ग्राहक की गलती है क्योंकि वे RFC में निर्दिष्ट URI सिंटैक्स का अनुपालन नहीं कर रहे हैं।

आपका उदाहरण वैध है और काम करना चाहिए। मैंने उस ट्रैफ़िक URL को भारी ट्रैफ़िक साइटों पर स्वयं उपयोग किया है और शून्य शिकायतें की हैं। इसके अलावा, हम फ़ायरफ़ॉक्स, सफारी, IE6, IE7 और ओपेरा में हमारी साइटों का परीक्षण करते हैं। ये ब्राउज़र सभी उस URL प्रारूप को समझते हैं।

Comments

"यदि कोई ग्राहक इस पर चुटकी लेता है, तो यह ग्राहक की गलती है क्योंकि वे RFC में निर्दिष्ट URI सिंटैक्स का अनुपालन नहीं कर रहे हैं।" - मुझे लगता है कि यह एक दिलचस्प सवाल है - लेकिन क्या एक ग्राहक "युक्ति" का अनुसरण करता है, यह शायद ही एक अच्छा मानक है कि क्या यह एक वेब ऐप में करना बुद्धिमान है।

— मैट हॉवेल

हालांकि यह तकनीक बहुत कम ज्ञात है, यह सभी वेब ब्राउज़रों में समर्थित है। यह बहुत अच्छा काम करता है।

— नेड बाचेल्डर

मुझे आश्चर्य है कि Google विश्लेषिकी के लिए इसका उपयोग क्यों नहीं करता है। वे डॉक्यूमेंट का उपयोग करते हैं। Location.protocol विधि।

— डैरिल हेन

@Darryl Hein मेरा मानना ​​है कि Google document.location.protocol विधि का उपयोग करता है क्योंकि यह केवल योजना को ही नहीं, url को भी संशोधित करता है। वे जाते हैंयदि दस्तावेज़ https स्कीम का उपयोग कर रहा है तो SSL.google-analytics.com पर ।

— निक मेल्ड्रम

Google इसका उपयोग नहीं करता है क्योंकि Windows XP नेटवर्क स्टैक SNI का समर्थन नहीं करता है। यहाँ देखें: blogs.msdn.com/b/ieinternals/archive/2009/12/07/... । इसलिए IE6 पर https के माध्यम से Google विश्लेषिकी स्क्रिप्ट को लोड करने की अनुमति देने से प्रमाणपत्र त्रुटि का परिणाम होगा।

— इलिस्ट्राई

Answer 2

यह किसी भी मुख्यधारा के ब्राउज़र में काम करने की गारंटी है (मैं 0.05% से कम शेयर बाजार वाले ब्राउज़र को ध्यान में नहीं रख रहा हूं)। हेक, यह इंटरनेट एक्सप्लोरर 3.0 में काम करता है।

RFC 3986 एक URI को परिभाषित करता है जो निम्नलिखित भागों से बना होता है:

     foo://example.com:8042/over/there?name=ferret#nose
     \_/   \______________/\_________/ \_________/ \__/
      |           |            |            |        |
   scheme     authority       path        query   fragment

सापेक्ष यूआरआई ( धारा 5.2 ) को परिभाषित करते समय , आप उन सभी वर्गों में से किसी को भी छोड़ सकते हैं, जो हमेशा बाईं ओर से शुरू होती है। छद्म कोड में, यह इस तरह दिखता है:

 result = ""

  if defined(scheme) then
     append scheme to result;
     append ":" to result;
  endif;

  if defined(authority) then
     append "//" to result;
     append authority to result;
  endif;

  append path to result;

  if defined(query) then
     append "?" to result;
     append query to result;
  endif;

  if defined(fragment) then
     append "#" to result;
     append fragment to result;
  endif;

  return result;

आप जिस URI का वर्णन कर रहे हैं, वह एक स्कीम-कम सापेक्ष URI है।

Comments

हाँ, मुझे लगता है कि मैंने सोचा था कि योजना और प्राधिकरण हमेशा परस्पर निर्भर थे। यह समझ में आता है कि यह नहीं है, लेकिन यह कुछ ऐसा नहीं है जिसका मैंने हाल ही में सामना किया है।

— क्रिस

यह किसी भी ब्राउज़र में काम करने की गारंटी नहीं है। यह केवल उन ब्राउज़रों में काम करने की गारंटी है जो RFC का अनुसरण करते हैं।

@Roger Pate: मुझे अभी तक एक ऐसे ब्राउज़र को देखना है जो URI के लिए RFC का पालन नहीं करता है। यह विशेष रूप से मानक इतने लंबे समय तक रहा है ... मैंने इसे IE3.0 में परीक्षण किया है और यह इसे पूरी तरह से ठीक समझता है। यदि आप एक ऐसे ब्राउज़र पर आते हैं जो उन लिंक को नहीं समझता है, तो संभावना है कि यह ऐसा सीमांत ब्राउज़र है, जो मायने नहीं रखेगा।

— एंड्रयू मूर

@ भारत: शायद आप मुझसे अलग हैं, लेकिन जब मैं प्रोग्रामिंग के संदर्भ में "गारंटी" कहता हूं, तो मेरा वास्तव में मतलब है "ऐसा कोई तरीका नहीं है जो संभवतः, कभी भी विफल हो सकता है," न सिर्फ "यह केवल लोकप्रिय कार्यान्वयन में काम करता है कि मैं ' वी ने परीक्षण किया। " मैं इसका एक बड़ा सौदा करने का मतलब नहीं था, लेकिन यह उल्लेख करने के लिए पर्याप्त महत्वपूर्ण था।

@ रेंजर: हां, लेकिन वेब विकास के संदर्भ में, सीमांत ब्राउज़रों (<0.01% बाजार हिस्सेदारी) पर ध्यान नहीं दिया जाता है। यह कहने जैसा है कि एक एपीआई विंडोज के सभी संस्करणों में मौजूद है और फिर कोई व्यक्ति यह कहने के लिए आता है कि यह शराब में समर्थित नहीं हो सकता है ...

— एंड्रयू मूर

Answer 3

क्या ऐसे कोई मामले हैं जहां यह काम नहीं करता है?

यदि मूल पृष्ठ से लोड किया गया था file://, तो यह संभवतः काम नहीं करता है (यह प्राप्त करने की कोशिश करेगा file://cdn.example.com/js_file.js, जो निश्चित रूप से आप स्थानीय रूप से भी प्रदान कर सकते हैं)।

Comments

स्थानीय मशीन पर HTML का परीक्षण करने वाले लोगों के लिए पता होना चाहिए!

— फिलिप ०० Phil

argh ... कोई आश्चर्य नहीं कि मेरा script src="//..."काम नहीं कर रहा था! मैं स्थानीय रूप से html फ़ाइल खोल रहा था!

— बुद्धिमानबुद्धि

किसी को इस के आसपास एक रास्ता पता है?

— किमी

@ ओग-निक: आप एक स्थानीय वेब सर्वर चला सकते हैं। इन दिनों बहुत सारे विकल्प, शून्य कॉन्फ़िगरेशन के साथ। आप चाहते हैं कि वैसे भी, कई अन्य चीजें (जैसे एक्सएचआर या वेब कर्मचारी भी फाइल के लिए काम नहीं करते हैं: डोमेन)

— थिलो

@ थिलो जो मेरे लिए अस्थायी रूप से काम कर रहा है लेकिन मैं गितुब के इलेक्ट्रॉन के साथ एक ऐप बना रहा हूं और यह थोड़ा अधिक जटिल हो जाता है।

— किमी

Answer 4

बहुत से लोग इसे प्रोटोकॉल सापेक्ष URL कहते हैं।

यह IE 7 और 8 में सीएसएस फाइलों के दोहरे डाउनलोड का कारण बनता है ।

Comments

@AndrewMoore "चीज़" को बाहर किए जाने के रूप में वेब प्रोटोकॉल इंगित करता है, इसे "प्रोटोकॉल रिश्तेदार" कहना अधिक समझ में आता है। मैंने कभी भी ftp या http को "स्कीम" नहीं कहा है ...

— Cerin

Answer 5

यहाँ मैं HTML की छुपी हुई विशेषताओं में उत्तर की नकल करता हूं :

प्रोटोकॉल-स्वतंत्र निरपेक्ष पथ का उपयोग करना:

<img src="//domain.com/img/logo.png"/>

यदि ब्राउज़र HTTPS के माध्यम से एसएसएल में एक पेज देख रहा है, तो वह https प्रोटोकॉल के साथ उस संपत्ति का अनुरोध करेगा, अन्यथा वह इसे HTTP के साथ अनुरोध करेगा।

यह उस भयानक को रोकता है, "यह पृष्ठ IE में सुरक्षित और गैर-सुरक्षित आइटम दोनों" त्रुटि संदेश रखता है, आपके सभी संपत्ति अनुरोधों को एक ही प्रोटोकॉल के भीतर रखता है।

<link>कैविएट : जब एक स्टाइलशीट के लिए या @import पर उपयोग किया जाता है , IE7 और IE8 फाइल को दो बार डाउनलोड करते हैं । हालांकि, अन्य सभी उपयोग ठीक हैं।

Answer 6

यह प्रोटोकॉल को छोड़ने के लिए पूरी तरह से वैध है। URL युक्ति वर्षों से इस बारे में स्पष्ट है, और मुझे अभी तक ऐसा ब्राउज़र नहीं मिला है जो इसे नहीं समझता हो। मुझे नहीं पता कि यह तकनीक बेहतर क्यों नहीं है; यह HTTP / HTTPS सीमाओं को पार करने की कांटेदार समस्या का सही समाधान है। यहाँ और अधिक: Http-https संक्रमण और रिश्तेदार URLs

Answer 7

क्या ऐसे कोई मामले हैं जहां यह काम नहीं करता है?

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

Microsoft Internet Explorer विशेष रूप से इसके प्रति संवेदनशील प्रतीत होता है, इस प्रश्न को देखें: स्थानीय एक्सप्लोरर (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 को हटाने का निर्णय लेने के बाद उपयोग करता है , देखें [यहां] [3]।

Answer 8

Gnud के संदर्भ के बाद, RFC 3986 खंड 5.2 कहता है:

यदि योजना घटक को परिभाषित किया गया है, यह दर्शाता है कि संदर्भ एक योजना के नाम से शुरू होता है, तो संदर्भ को एक पूर्ण यूआरआई के रूप में समझा जाता है और हमें किया जाता है। अन्यथा, संदर्भ URI की योजना को आधार URI की योजना घटक से विरासत में मिला है ।

तो //सही है :-)

Answer 9

हाँ, यह RFC 3986 , खंड 5.2 में प्रलेखित है :

(संपादित करें: उफ़, मेरा RFC संदर्भ पुराना था)।

Answer 10

यह वास्तव में सही है, जैसा कि अन्य उत्तरों में कहा गया है। हालाँकि, आपको ध्यान देना चाहिए कि कुछ वेब क्रॉलर आपके सर्वर पर उन्हें अनुरोध करके 404s सेट करेंगे जैसे कि एक स्थानीय URL। (वे दोहरे स्लैश की अवहेलना करते हैं और इसे एकल स्लैश मानते हैं)।

आप इन्हें पकड़ने और इन्हें पुनर्निर्देशित करने के लिए अपने वेबसर्वर पर एक नियम स्थापित करना चाह सकते हैं।

उदाहरण के लिए, Nginx के साथ, आप कुछ ऐसा जोड़ेंगे:

location ~* /(?<redirect_domain>((([a-z]|[0-9]|\-)+)\.)+([a-z])+)/(?<redirect_path>.*) {
  return 301 $scheme:/$redirect_domain/$redirect_path;
}

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

इसके अलावा, यह प्रत्येक क्वेरी के लिए चलने वाला एक बहुत बड़ा रेगीक्स है - मेरी राय में, यह बहु-संगत ब्राउज़रों के बहुमत पर (मामूली) प्रदर्शन हिट पर 404s के साथ गैर-अनुरूप ब्राउज़रों को दंडित करने के लायक है।

Answer 11

JS फाइलों के संदर्भ में //somedomain.com का उपयोग करते समय हम 404 त्रुटियों को देख रहे हैं।

404 का संदर्भ देने वाले संदर्भ इस तरह दिखते हैं: रेफ:

<script src="//somedomain.com/somescript.js" />

404 अनुरोध:

http://mydomain.com//somedomain.com/somescript.js

हमारे वेब सर्वर लॉग में नियमित रूप से दिखाई देने के साथ, यह कहना सुरक्षित है कि: सभी ब्राउज़र और बॉट आरएफसी 3986 सेक्शन 4.2 का सम्मान नहीं करते हैं । जब भी संभव हो प्रोटोकॉल को शामिल करना सबसे सुरक्षित शर्त है।

Comments

हाँ, मैंने इसे बंद कर दिया है, लेकिन 404 के कारण नहीं (मैंने कभी कोई 404 नहीं देखा है ... अगर कोई बॉट इसे सम्मानित नहीं करता है, तो मैं कम देखभाल कर सकता हूं) - क्योंकि मैं अब संसाधनों को लोड नहीं करता हूं अन्य CDN इसलिए मुझे ऐसा करने की आवश्यकता नहीं है (इसके बजाय मैं 1 या 2 फ़ाइलों में जितना संभव हो उतना छोटा करता हूं)।

— डैरिल हेन

कृपया प्रोटोकॉल शामिल करें। मेरे कॉर्डोवा ऐप में प्रोटोकॉल-कम Refs ब्रेक।

— pgorsira

Answer 12

1. सारांश

2019 के लिए उत्तर: आप अभी भी प्रोटोकॉल-सापेक्ष URL का उपयोग कर सकते हैं, लेकिन यह तकनीक एक एंटी-पैटर्न है ।

इसके अलावा:

1. आपको विकसित करने में समस्या हो सकती है।
2. कुछ तृतीय-पक्ष उपकरण उनका समर्थन नहीं कर सकते हैं।

प्रोटोकॉल-सापेक्ष URL से माइग्रेट https://करना अच्छा होगा।

---

2. प्रासंगिकता

यह उत्तर जनवरी 2019 के लिए प्रासंगिक है। भविष्य में, इस उत्तर का डेटा अप्रचलित हो सकता है।

---

3. विरोधी पैटर्न

3.1। तर्क

पॉल आयरिश - फ्रंट-एंड इंजीनियर और Google Chrome के लिए एक डेवलपर वकील - 2014, दिसंबर में लिखें :

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

HTTP पर अनुरोध करने के लिए स्निपेट की अनुमति देने से हाल ही में GitHub Man-on-the-side हमले जैसे हमलों के लिए द्वार खुल जाता है । यदि आपकी साइट HTTP पर है, तो भी HTTPS परिसंपत्तियों का अनुरोध करना हमेशा सुरक्षित होता है, हालांकि रिवर्स सच नहीं है ।

3.2। एक और कड़ी

• प्रोटोकॉल रिश्तेदार यूआरआई का उपयोग करते हुए पृष्ठ पृष्ठ संसाधन
• प्रोटोकॉल-सापेक्ष URL का उपयोग करना बंद करें

3.3। उदाहरण

• 2017 में स्टैक ओवरफ्लो प्रोटोकॉल-सापेक्ष URL से स्विच किया गया https
• 2018 में क्रोम सभी बिना लाइसेंस वाली वेबसाइटों को "सुरक्षित नहीं" के रूप में चिह्नित करेगा

---

4. विकास की प्रक्रिया

उदाहरण के लिए, मैं क्लीन-कंसोल का उपयोग करने की कोशिश करता हूं ।

• उदाहरण फ़ाइल KiraCleanConsole__cdn_links_demo.html:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>clean-console without protocol demonstration</title>
    <!-- Really dead link -->
    <script src="https://unpkg.com/bowser@latest/bowser.min.js"></script>
    <!-- Package exists; link without “https:” -->
    <script src="//cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.js"></script>
    <!-- Package exists: link with “https:” -->
    <script src="https://cdn.jsdelivr.net/npm/gemini-scrollbar/index.js"></script>
</head>
<body>
    Kira Goddess!
</body>
</html>

• उत्पादन:

D:\SashaDebugging>clean-console -i KiraCleanConsole__cdn_links_demo.html
checking KiraCleanConsole__cdn_links_demo.html
phantomjs: opening page KiraCleanConsole__cdn_links_demo.html

phantomjs: Unable to load resource (#3URL:file://cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.js)


phantomjs:   phantomjs://code/runner.js:30 in onResourceError
Error code: 203. Description: Error opening //cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.js: The network path was not found.

  phantomjs://code/runner.js:31 in onResourceError

phantomjs: Unable to load resource (#5URL:https://unpkg.com/bowser@2.1.0/bowser.min.js)


phantomjs:   phantomjs://code/runner.js:30 in onResourceError
Error code: 203. Description: Error downloading https://unpkg.com/bowser@2.1.0/bowser.min.js - server replied: Not Found

  phantomjs://code/runner.js:31 in onResourceError

phantomjs: Checking errors after sleeping for 1000ms
2 error(s) on KiraCleanConsole__cdn_links_demo.html

phantomjs process exited with code 2

लिंक //cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.jsमान्य है, लेकिन मुझे एक त्रुटि मिल रही है।

वेतन ध्यान में file://cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.jsहै और पढ़ने थिलो और bg17aw के बारे में उत्तर file://।

मैं इस व्यवहार के बारे में नहीं जानता था और समझ नहीं पाया कि मुझे पेजर्स के लिए इस तरह की समस्या क्यों है ।

---

5. तीसरे पक्ष के उपकरण

मैं क्लिक करने योग्य URL उदात्त पाठ पैकेज का उपयोग करता हूं । इसका उपयोग करें, मैं केवल ब्राउज़र में अपने पाठ संपादक से लिंक खोल सकता हूं।

उदाहरण में दोनों लिंक मान्य हैं। लेकिन पहला लिंक मैं क्लिक करने योग्य URL के ब्राउज़र उपयोग में सफलतापूर्वक खोल सकता हूं, दूसरा लिंक - नहीं। यह बहुत सुविधाजनक नहीं हो सकता है।

---

6। निष्कर्ष

हाँ:

1. यदि आपको Developing processआइटम के रूप में समस्याएं हैं , तो आप अपना विकास वर्कफ़्लो सेट कर सकते हैं।
2. आपके पास Third-party toolsआइटम के रूप में समस्याएं हैं , तो आप उपकरण योगदान कर सकते हैं।

लेकिन आपको इस अतिरिक्त समस्याओं की आवश्यकता नहीं है। Anti-patternआइटम में लिंक द्वारा जानकारी पढ़ें : प्रोटोकॉल-सापेक्ष URL अप्रचलित है।

Answer 13

Html5-boilerplate पर मैंने जो पैटर्न देखा है वह है:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>
<script>window.jQuery || document.write('<script src="js/vendor/jquery-1.10.2.min.js"><\/script>')</script>

यह की तरह अलग अलग योजनाओं पर सुचारू रूप से चलाता है http, https, file।

Comments

यह अब सच नहीं है, देखें stackoverflow.com/a/37609402/2237601 या यहाँ , वे अब https://सब कुछ के लिए उपयोग करते हैं

— bg17aw

@ bg17aw https://हर जगह का उपयोग करने के साथ समस्या यह है कि आपको अपने सभी बाहरी लिंक को यह देखने के लिए रखना होगा कि क्या वे वास्तव में इसका समर्थन करते हैं, और उन्हें बदलने के लिए http://अगर वे नहीं करते हैं (अन्यथा वे काम नहीं करेंगे)। यह बड़ी संख्या में लिंक के साथ परेशानी भरा हो सकता है।

— tomasz86

@ tomasz86 आप इस बिंदु को याद कर रहे हैं, मैं केवल CDNs से सामग्री को जोड़ने के विशेष मामले पर भरोसा कर रहा था। https: // आजकल के लिए अनिवार्य है। जवाब एक विशेष मामले (html5-बॉयलरप्लेट) के बारे में भी बात करता है। जैसा कि आप कहते हैं, "http के लिए जाँच" नहीं है, क्योंकि CDN हमेशा https का उपयोग करते हैं।

— bg17aw

@ bg17aw यह सच है लेकिन यहाँ सामान्य प्रश्न केवल CDN के बारे में नहीं है। बस इस उत्तर / टिप्पणी को पढ़ने से यह सोचना आसान है कि https://सभी लिंक में (या) का उपयोग किया जाना चाहिए जो सही नहीं है।

— tomasz86

@ tomasz86 कई उत्तर होने की सुंदरता यह है कि उनमें से कोई भी सही नहीं है (यदि एक उत्तर सही होगा, तो दूसरों को हटाने की आवश्यकता होगी), उनमें से कुछ को पढ़ने से हमें एक व्यापक दृष्टिकोण मिलता है। इस मामले में, उत्तर कहता है "html5boilerplate पर पैटर्न है ..." और मेरी टिप्पणी इस जवाब का उल्लेख करते हुए अपडेट करती है कि "अब html5-बॉयलरप्लेट पर पैटर्न नहीं है"। बस। इस विशेष उत्तर के अलावा एक आवश्यक। कृपया यह भी ध्यान दें कि मूल प्रश्न CDNs के बारे में है!

— bg17aw

Answer 14

जैसा कि आपका उदाहरण एक बाहरी डोमेन से लिंक कर रहा है, यदि आप HTTPS का उपयोग कर रहे हैं तो आपको सत्यापित करना चाहिए कि बाहरी डोमेन SSL के लिए भी सेटअप है। अन्यथा, आपके उपयोगकर्ता SSL त्रुटियों और / या 404 त्रुटियों को देख सकते हैं (जैसे कि अलग-अलग फ़ोल्डरों में Plesk स्टोर HTTP और HTTPS के पुराने संस्करण)। सीडीएन के लिए, यह एक मुद्दा नहीं होना चाहिए, लेकिन किसी भी अन्य वेबसाइट के लिए यह हो सकता है।

एक साइड नोट पर, एक पुरानी वेबसाइट को अपडेट करते समय परीक्षण किया गया और एक MET REFRESH के url = भाग में भी काम करता है।