আমি কি আমার সমস্ত http: // লিঙ্কগুলিকে কেবল // এর সাথে পরিবর্তন করতে পারি?


240

ডেভ ওয়ার্ড বলেছেন,

এটি ঠিক হালকা পড়া নয়, তবে আরএফসি 3986-এর বিভাগ 4.2 সম্পূর্ণরূপে যোগ্যতাসম্পন্ন URL এর জন্য সরবরাহ করে যা প্রোটোকল (HTTP বা HTTPS) পুরোপুরি বাদ দেয় om যখন কোনও URL এর প্রোটোকল বাদ দেওয়া হয়, ব্রাউজারটি পরিবর্তে অন্তর্নিহিত নথির প্রোটোকল ব্যবহার করে।

সহজ কথায় বলতে গেলে, এই "প্রোটোকল-কম" ইউআরএলগুলি প্রতিটি ব্রাউজারে এর মতো একটি রেফারেন্স কাজ করার অনুমতি দেয় আপনি এটি চেষ্টা করে দেখুন:

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

প্রথমে এটি দেখতে অদ্ভুত লাগে তবে এই "প্রোটোকল-কম" URL টি এইচটিটিপি এবং এইচটিটিপিএস উভয়ের মাধ্যমে উপলব্ধ তৃতীয় পক্ষের সামগ্রীর রেফারেন্সের সেরা উপায়।

এটি অবশ্যই HTTP পৃষ্ঠাগুলিতে আমরা দেখতে পাচ্ছি এমন মিশ্র-সামগ্রীর ত্রুটিগুলির সমাধান করবে - ধরে নিই যে আমাদের সম্পদ এইচটিটিপি এবং এইচটিটিপিএস উভয়ের মাধ্যমেই উপলব্ধ।

এটি কি সম্পূর্ণ ক্রস ব্রাউজারের সাথে সামঞ্জস্যপূর্ণ? অন্য কোন সতর্কতা আছে?


আমি কিছুক্ষণ আগে আইই ব্লগে এই কৌশলটি পড়েছিলাম। তবে আমি যখন চেষ্টা করেছি তখন বেশ ভালো কাজ হয় না। যদি আমার সাইটটি এইচটিটিপিএসের সাথে পরিবেশন করা হত তবে ব্রাউজার (ক্রোম) এখনও প্রোটোকল-কম URLগুলির জন্য HTTP ব্যবহার করে TP
ক্রিস্টোফার রামারেজ

10
সতর্কতা: HTTP 3xx পুনর্নির্দেশগুলিতে ব্যবহারকারী স্কিমহীন ইউআরআই কখনও মনে রাখবেন না !! এইচটিটিপি শিরোনাম এই URL ফর্ম্যাটটির সাথে সামঞ্জস্যপূর্ণ নয়। আপনার যদি স্কিমের উপর নির্ভর করে পুনঃনির্দেশ করা দরকার হয় তবে মোড_উইরাইট বা অনুরূপ ব্যবহার করুন।
ব্যবহারকারী 2596282

1
@ ব্যবহারকারী 2596282 ক্রোম এবং ফায়ারফক্সের আধুনিক সংস্করণগুলির পরীক্ষা-নিরীক্ষা আপনার সাথে একমত নয়, যেমন (এখনও খসড়াটিতে) এইচটিটিপি 1.1-র সংশোধন করে। HTTPbis ওয়ার্কিং গ্রুপ দ্বারা সংজ্ঞায়িত বিশ্লেষণ (দেখুন svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/… )। সম্ভবত আপনি যা বলছেন তা কিছু ব্রাউজারের ক্ষেত্রে সত্য; আপনি কি এমন কোনও ব্যক্তিকে জানেন যা অবস্থান শিরোনামে প্রোটোকল-সম্পর্কিত ইউআরএলগুলিতে ব্যর্থ হয়?
মার্ক আমেরিকা


এগুলি ব্যবহার করবেন না, তারা কুরুচিপূর্ণ এবং অপ্রয়োজনীয়।
ইলিডানএস 4 মনিকাকে

উত্তর:


204

আমি প্রকাশের আগে এটি পুরোপুরি পরীক্ষা করেছি। সকল ব্রাউজারে বিরুদ্ধে পরীক্ষা উপলব্ধ Browsershots একটি অস্পষ্ট * স্নো ব্রাউজার নামক: আমি শুধুমাত্র এক যে প্রোটোকল আপেক্ষিক URL টি সঠিকভাবে হ্যান্ডেল করা হয়নি খুঁজে পাইনি Dillo

আমি দুটি প্রতিক্রিয়া পেয়েছি সম্পর্কে প্রতিক্রিয়া পেয়েছি:

  1. প্রোটোকল-কম URL গুলি যখন আপনি আপনার ব্রাউজারে কোনও স্থানীয় ফাইল "খোলেন" তখন প্রত্যাশা অনুযায়ী কাজ করতে পারে না কারণ পৃষ্ঠার বেস প্রোটোকল ফাইল: /// হবে। বিশেষত যখন আপনি কোনও সিডিএন-হোস্ট করা সম্পত্তির মতো বাহ্যিক সংস্থার জন্য প্রোটোকল-কম URL ব্যবহার করছেন। স্থানীয় ওয়েব সার্ভার যেমন অ্যাপাচি বা আইআইএস ব্যবহার করে http: // লোকালহোস্ট অ্যাড্রেসগুলির বিরুদ্ধে পরীক্ষা করা ভাল কাজ করে।
  2. স্পষ্টতই কমপক্ষে একটি আইফোন ফিড রিডার অ্যাপ রয়েছে যা প্রোটোকল-কম URL গুলি সঠিকভাবে পরিচালনা করে না। কার কার সমস্যা বা এটি কতটা জনপ্রিয় তা সম্পর্কে আমি অবগত নই। একটি জাভাস্ক্রিপ্ট ফাইল হোস্টিংয়ের জন্য, এটি কোনও বড় সমস্যা নয় যেহেতু আরএসএস পাঠকরা সাধারণত জাভাস্ক্রিপ্ট সামগ্রীটি উপেক্ষা করে। যাইহোক, আপনি যদি এই ইউআরএলগুলি মিডিয়ায় যেমন কনটেন্টের অভ্যন্তরের চিত্রগুলির জন্য আরএসএসের মাধ্যমে সিন্ডিকেট করা প্রয়োজন (তবে একক প্ল্যাটফর্মের এই একক পাঠক অ্যাপ্লিকেশন সম্ভবত খুব প্রান্তিক সংখ্যক পাঠকের জন্য অ্যাকাউন্ট করেছেন) সমস্যা হতে পারে।

33
যদিও আই 7/8 প্রোটোকল-সম্পর্কিত ইউআরএলগুলি (যেমন। স্কিমহীন ইউআরআই) ভালভাবে পরিচালনা করে, যখন স্টাইলশিটগুলি এই জাতীয় ইউআরএলগুলির সাথে নির্দিষ্ট করা হয়, এটি সেগুলি দুটিবার ডাউনলোড করবে । (সুতরাং স্টিভ
সাউডারস

3
আমি খুঁজে পেয়েছি যে আইআই 6 ইউআরআইকে কোনও আপেক্ষিকের (যেমন শীর্ষস্থানীয় স্ল্যাশগুলির একটি অপসারণ) রূপান্তর করতে চেষ্টা করে। এটি একটি linkউপাদান মধ্যে। উদাহরণস্বরূপ, নির্দিষ্ট করার সময় //fonts.googleapis.com/css?family=Rokkitt:400,700, আই 6 লোড করার চেষ্টা করে http://mysite.com/fonts.googleapis.com/css/<...>। এত ভাল না!
সিবিোনো

2
আমি আমার লগগুলি উদাহরণ থেকে পেয়েছি যা ওয়েব স্পাইডার রোবট বলে মনে হচ্ছে (উত্স অজানা) প্রোটোকল-কম লিঙ্কগুলি ব্যবহার করার চেষ্টা করছে এবং সেগুলি সঠিকভাবে পরিচালনা করছে না।
কেজকাই

3
প্রোটোকল-কম ইউআরএল সম্পর্কিত নয় এমন আমার লগগুলিতে আমি প্রচুর দেখতে পেয়েছি। এই মাকড়সা অনেকগুলি অবিশ্বাস্যভাবে খারাপভাবে লেখা হয়।
ডেভ ওয়ার্ড

11
এটি বোঝা যে এই URL গুলি গুরুত্বপূর্ণ না protocol- কম , কিন্তু protocol- আপেক্ষিক । তারা তাদের প্রসঙ্গ থেকে তাদের প্রোটোকল পান এবং একটি প্রসঙ্গের অভাবে তারা বেশিরভাগ ব্রাউজারে ফাইল ইউআরএলের মতো কাজ করবে, কার্যকরভাবে এর অর্থ তারা ভেঙে গেছে যে তারা উদ্দেশ্যযুক্ত সামগ্রী লোড করবে না। HTTP- র মাধ্যমে বিতরণ করার সময় তারা যখন কাজ করবে তখন আপনি দেখতে পাবেন যে আপনি যদি স্থানীয় পৃষ্ঠা থেকে পৃষ্ঠাটি সংরক্ষণ করেন এবং ঠিক একই HTML টি লোড করেন তবে সেগুলি তা করবে না, কারণ প্রসঙ্গটি ভিন্ন। আপনি কেবলমাত্র এগুলি ব্যবহার করতে হবে তা হল http বনাম https।
সিঙ্ক্রো

37

এক কিনা প্রশ্নে পারে তাদের সমস্ত লিঙ্কের পরিবর্তন হতে প্রোটোকল-আপেক্ষিক তর্ক করা হতে পারে, কিনা এক প্রশ্নে বিবেচনায় উচিত , তাই না। পল আইরিশ অনুসারে :

2014.12.17: এখন যে সকলের জন্য এসএসএল উত্সাহিত হয়েছে এবং এর কার্য সম্পাদনের উদ্বেগ নেই, এই কৌশলটি এখন একটি অ্যান্টি-প্যাটার্ন। যদি আপনার প্রয়োজনীয় সম্পদটি এসএসএলে পাওয়া যায় তবে সর্বদা https: // সম্পদ ব্যবহার করুন ।


আমি ঠিক একই চিন্তা ছিল। HTTP- র পাশাপাশি যদি এটি বাহ্যিক সম্পদটি ডাউনলোড করতে পারে তবে তা https- তেও উপলভ্য - যদিও মূল সাইটটি http ব্যবহার করছে (যা এটি হওয়া উচিত নয়, তবে এটি অন্য একটি বিষয়)।
junas.fi

1
@ জুনাস.এফই কেবলমাত্র আমি যা ভাবতে পারি তা হ'ল মিশ্র এইচটিটিপি / এইচটিটিপিএস সতর্কতা যা কিছু ব্রাউজার দ্বারা উত্পন্ন হতে পারে এড়ানো
ওহাদ স্নাইডার

3
@ ওহাদ_স্নাইডার সতর্কতাগুলি কেবলমাত্র ডকুমেন্টটি সুরক্ষিত (https) দ্বারা লোড করা থাকলে তবে অনিরাপদ (HTTP) এর চেয়ে বেশি সম্পদগুলি ট্রিগার করা হবে। আমি যা পরামর্শ দিচ্ছিলাম তা হ'ল আপনি সর্বদা সুরক্ষার উপর দিয়ে সম্পদগুলি লোড করতে পারেন, এমনকি নথিটি অনিরাপদভাবে লোড করা থাকলেও। সম্পূর্ণ "প্রোটোকল-সম্পর্কিত ইউআরএল" অপ্রয়োজনীয়ভাবে রেন্ডার করে সুরক্ষিত ব্যবহার না করার কোনও সতর্কতা এবং কারণ নেই।
junas.fi

1
@ ওহাদ_স্নাইডার ওহ দুঃখিত, আমি মনে করি আপনি যা বলছিলেন তা আমি ভুল ব্যাখ্যা করেছি। আপনার ডকুমেন্টটি HTTP শেষ হয়ে গেলে https- র মাধ্যমে সম্পদ লোড করা কোনও সতর্কতা তৈরি করে না। আপনার ডকুমেন্টটি https এর উপরে থাকলে HTTP- র মাধ্যমে সম্পদ লোড করা যায় (এবং সম্ভবত ডিফল্টরূপে অবরুদ্ধ থাকে, কমপক্ষে Chrome এ)। আপনি কি https- র মাধ্যমে আপনার সাইটটি পরিবেশন করছেন এবং বাহ্যিক সম্পদ কেবলমাত্র HTTP- র অধীনে উপলব্ধ সে ক্ষেত্রে উল্লেখ করছেন? হ্যাঁ, এটি একটি সমস্যা হতে পারে তবে আমি মনে করি না যে কোনও গুরুতর তৃতীয় পক্ষের পরিষেবা আছে যা https এর মাধ্যমে তাদের বিষয়বস্তু পরিবেশন করে না, অন্যথায় তাদের ব্যবসায়ের বাইরে যাই হোক। :)
জুনাস.ফি

@ জুনাস.ফুট? ও_ও যদি কারও এইচটিটিপিএসড সাইট থাকে (তবে) প্রোটোকল সম্পর্কিত আপেক্ষিক ইউআরএল এইচটিটিপি-র মাধ্যমে তৃতীয় পক্ষের সম্পদগুলি সমাধান করতে সহায়তা করবে না - কোনও উপায় নেই। এবং যাইহোক, এইচটিটিপিএস পৃষ্ঠায় সেই পরিষ্কার-সবুজ এসএসএল লোগোটি না রাখাই ভাল এটি তৃতীয় পক্ষের কারণে এইচটিটিপিএসকে আবার ফিরিয়ে দেওয়ার চেয়ে এইচটিটিপিএস সমর্থন করে না।
পাইজ

30

স্টাইলশিটগুলি লোড করতে আপনি যদি প্রোটোকল-কম URL গুলি ব্যবহার করেন তবে আই 7 এবং 8 এগুলি দুটিবার ডাউনলোড করবে: http://www.stevesouders.com/blog/2010/02/10/5a-missing-schema-double-download/

সুতরাং, আপনার ভাল পারফরম্যান্স পছন্দ হলে এটি CSS এর জন্য এড়ানো হবে to


5
সত্য, তবে এটি স্কিমবিহীন ইউআরএলগুলি IE 7 এবং 8 এর বাজার ভাগ হিসাবে সঙ্কলন করতে এড়াতে একটি কারণ হিসাবে কম এবং কম হয়ে যায়।
সাইমন লিয়েস্কে

15

হ্যাঁ, নেটওয়ার্ক-পাথের রেফারেন্সগুলি ইতিমধ্যে আরএফসি 1808 এ নির্দিষ্ট করা হয়েছিল এবং সমস্ত ব্রাউজারের সাথে কাজ করা উচিত।


11
এটি এমনকি HTML5 বয়লারপ্লেট কোডটিতেও
ফিলিপ লিমা

1
হ্যাঁ হ্যাঁ, আপনি "হ্যাঁ, অন্য কোনও সতর্কীকরণ আছে?" ? ;)
ক্যাস্পার ক্লিজনে

2
@ ক্যাস্পার ক্লেইজনে: বাকী বাক্যটি দিয়ে আমি হ্যাঁ ব্যাখ্যা করেছি।
গম্বো

1
ক্যাস্পার, গম্বো আসলে জিজ্ঞাসিত দুটি প্রশ্নের জবাব দিচ্ছিল: "এটি কি সম্পূর্ণ ক্রস ব্রাউজারের সাথে সামঞ্জস্যপূর্ণ? অন্য কোনও সতর্কীকরণ রয়েছে?" হ্যাঁ প্রথম প্রশ্নের উত্তর।
ড্যারেন গ্রিফিথ

4

এটি কি সম্পূর্ণ ক্রস ব্রাউজারের সাথে সামঞ্জস্যপূর্ণ? অন্য কোন সতর্কতা আছে?

এটি কেবল মিশ্রণে ফেলে দিতে, যদি আপনি একটি স্থানীয় সার্ভারে বিকাশ করে থাকেন তবে এটি কার্যকর নাও হতে পারে। আপনি একটি স্কিম নির্দিষ্ট করার অন্যথায় ব্রাউজার অনুমান হতে পারে যে প্রয়োজন, src="//cdn.example.com/js_file.js"হয়src="file://cdn.example.com/js_file.js" , যা যেহেতু আপনি এই সম্পদ স্থানীয়ভাবে হোস্টিং করছি না ভঙ্গ করবে।

মাইক্রোসফ্ট ইন্টারনেট এক্সপ্লোরার এটি সম্পর্কে বিশেষ সংবেদনশীল বলে মনে হচ্ছে, এই প্রশ্নটি দেখুন: লোকালহোস্টের (ডাব্লুএএমপি) ইন্টারনেট এক্সপ্লোরারে jQuery লোড করতে সক্ষম নয়

আপনি সম্ভবত সর্বদা এমন একটি সমাধান সন্ধান করার চেষ্টা করবেন যা আপনার সমস্ত পরিবেশে কমপক্ষে পরিবর্তনগুলির প্রয়োজনীয়তার সাথে কাজ করে।

এইচটিএমএল 5 বয়লারপ্লেট দ্বারা ব্যবহৃত সমাধানটি যখন রিসোর্সটি সঠিকভাবে লোড করা না হয় তখন একটি ফ্যালব্যাক পাওয়া যায়, তবে আপনি যদি চেক অন্তর্ভুক্ত করেন তবে তা কেবলমাত্র কাজ করে:

<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 গুলি অবমূল্যায়নের সিদ্ধান্ত নেওয়ার পরে ব্যবহার করুন , এখানে দেখুন


1

//Domain.com ব্যবহার করার সময় আমার এই সমস্যাগুলি ছিল না - তবে আপনাকে শুরুতে কোলন যুক্ত করতে হবে। ইয়োস্ট কিছুক্ষণ আগে এই সম্পর্কে একটি ভাল লেখার ছিল। তবে এটি তার ব্লগ পোস্টগুলির স্তূপে হারিয়ে গেছে।


অতিরিক্ত: দরকারী যেখানে উল্লেখ না করার জন্য ডাউন-ভোট। যেখানেই আমি দুর্ঘটনাক্রমে ":" লিঙ্কটি ভেঙে ফেলেছি
ছিনতাই করে

0

আপনি যদি নিশ্চিত করতে চান যে সমস্ত অনুরোধগুলি সুরক্ষিত প্রোটোকলগুলিতে আপগ্রেড হয়েছে তবে কনটেন্ট সুরক্ষা নীতি শিরোনাম আপগ্রেড-অনিরাপদ-অনুরোধগুলি ব্যবহার করার সহজ বিকল্প রয়েছে

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

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

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.