লেখক: স্যার টিম বার্নার্স-লি, URI, URL, HTTP, HTML এবং ওয়ার্ল্ড ওয়াইড ওয়েবের উদ্ভাবক এবং W3C-এর বর্তমান প্রধান। নিবন্ধটি 1998 সালে লেখা

কোন URI কে "ঠান্ডা" বলে মনে করা হয়?
একটি যে পরিবর্তন না.
কিভাবে URI পরিবর্তন করা হয়?
ইউআরআই পরিবর্তন হয় না: লোকেরা তাদের পরিবর্তন করে।

তাত্ত্বিকভাবে, লোকেদের ইউআরআই পরিবর্তন করার (বা সমর্থনকারী নথি বন্ধ করার) কোন কারণ নেই, তবে বাস্তবে তাদের লক্ষ লক্ষ রয়েছে।

তত্ত্বগতভাবে, একটি ডোমেন নেমস্পেসের নামমাত্র মালিক প্রকৃতপক্ষে ডোমেন নামস্থানের মালিক এবং তাই এর মধ্যে থাকা সমস্ত ইউআরআই। দেউলিয়া হওয়া ছাড়াও, কোনও ডোমেইন নামের মালিককে নাম রাখতে বাধা দেয় না। এবং তাত্ত্বিকভাবে, আপনার ডোমেন নামের অধীনে URI স্থান সম্পূর্ণরূপে আপনার নিয়ন্ত্রণে, তাই আপনি এটিকে আপনার পছন্দ মতো স্থিতিশীল করতে পারেন। ইন্টারনেট থেকে একটি নথি অদৃশ্য হওয়ার একমাত্র ভাল কারণ হল যে ডোমেন নামের মালিক কোম্পানিটি ব্যবসার বাইরে চলে গেছে বা সার্ভারটি চালু রাখার সামর্থ্য নেই। তাহলে পৃথিবীতে এত মিসিং লিংক কেন? এর কিছু কেবলমাত্র পূর্বচিন্তার অভাব। এখানে কিছু কারণ আপনি শুনতে পারেন:

আমরা শুধু সাইটটিকে আরও ভালো করার জন্য পুনর্গঠিত করেছি।

আপনি কি সত্যিই মনে করেন পুরানো ইউআরআই আর কাজ করতে পারে না? যদি তাই হয়, তাহলে আপনি তাদের খুব খারাপভাবে বেছে নিয়েছেন। পরবর্তী পুনঃডিজাইন করার জন্য নতুন রাখা বিবেচনা করুন.

আমাদের কাছে এত বেশি জিনিস রয়েছে যে আমরা কী পুরানো, কী গোপনীয় এবং এখনও কী প্রাসঙ্গিক সেগুলির ট্র্যাক রাখতে পারি না, তাই আমরা সবগুলি বন্ধ করাই ভাল বলে মনে করেছি৷

আমি শুধু সহানুভূতি জানাতে পারি। W3C এমন একটি সময়কালের মধ্য দিয়ে গেছে যেখানে আমাদের গোপনীয়তার জন্য সংরক্ষণাগার সামগ্রীগুলিকে সর্বজনীন করার আগে সাবধানে পরীক্ষা করতে হয়েছিল৷ সিদ্ধান্তটি আগে থেকেই চিন্তা করা উচিত - নিশ্চিত করুন যে প্রতিটি নথির সাথে আপনি গ্রহণযোগ্য পাঠক সংখ্যা, তৈরির তারিখ এবং আদর্শভাবে মেয়াদ শেষ হওয়ার তারিখ রেকর্ড করেছেন। এই মেটাডেটা সংরক্ষণ করুন.

ঠিক আছে, আমরা আবিষ্কার করেছি যে আমাদের ফাইলগুলি সরাতে হবে...

এটি সবচেয়ে করুণ অজুহাত এক. অনেক লোক জানেন না যে ওয়েব সার্ভারগুলি আপনাকে একটি বস্তুর URI এবং ফাইল সিস্টেমে এর প্রকৃত অবস্থানের মধ্যে সম্পর্ক নিয়ন্ত্রণ করতে দেয়। URI স্থানটিকে একটি বিমূর্ত স্থান হিসাবে ভাবুন, পুরোপুরি সংগঠিত। তারপরে আপনি বাস্তবে এটি উপলব্ধি করার জন্য যে বাস্তবতা ব্যবহার করেন তার একটি ম্যাপিং তৈরি করুন। তারপর ওয়েব সার্ভারে এটি রিপোর্ট করুন। এমনকি আপনি এটি সঠিক পেতে আপনার নিজের সার্ভার স্নিপেট লিখতে পারেন।

জন আর এই ফাইলটি বজায় রাখে না, জেন এখন করে।

ইউআরআই-তে কি জনের নাম ছিল? না, ফাইলটি কি তার ডিরেক্টরিতে ছিল? আচ্ছা ঠিক আছে.

আগে আমরা এর জন্য একটি CGI স্ক্রিপ্ট ব্যবহার করতাম, কিন্তু এখন আমরা একটি বাইনারি প্রোগ্রাম ব্যবহার করি।

একটি পাগল ধারণা আছে যে স্ক্রিপ্ট দ্বারা তৈরি পৃষ্ঠাগুলি "cgibin" বা "cgi" এলাকায় অবস্থিত হওয়া উচিত। এটি আপনি কীভাবে আপনার ওয়েব সার্ভার চালান তার মেকানিক্স প্রকাশ করে। আপনি প্রক্রিয়া পরিবর্তন করেন (এমনকি বিষয়বস্তু সংরক্ষণ করার সময়ও), এবং ওহো - আপনার সমস্ত ইউআরআই পরিবর্তন হয়।

উদাহরণস্বরূপ জাতীয় বিজ্ঞান ফাউন্ডেশন (NSF) নিন:

NSF অনলাইন নথি

http://www.nsf.gov/cgi-bin/pubsys/browser/odbrowse.pl

নথি দেখা শুরু করার প্রথম পৃষ্ঠাটি স্পষ্টতই কয়েক বছরের মধ্যে একই থাকবে না। cgi-bin, oldbrowse и pl - এই সব তথ্যের বিট আউট দেয় কিভাবে-আমরা-এটা-এখন. আপনি যদি একটি নথি অনুসন্ধান করার জন্য পৃষ্ঠাটি ব্যবহার করেন, তাহলে আপনি যে প্রথম ফলাফলটি পান তা সমানভাবে খারাপ:

ক্রিপ্টোলজি এবং কোডিং তত্ত্বের উপর ওয়ার্কিং গ্রুপের রিপোর্ট

http://www.nsf.gov/cgi-bin/getpub?nsf9814

ডকুমেন্ট ইনডেক্স পৃষ্ঠার জন্য, যদিও এইচটিএমএল ডকুমেন্ট নিজেই অনেক ভালো দেখায়:

http://www.nsf.gov/pubs/1998/nsf9814/nsf9814.htm

এখানে pubs/1998 শিরোনামটি ভবিষ্যতের যেকোনো আর্কাইভাল পরিষেবাকে একটি ভাল সূত্র দেবে যে পুরানো 1998 নথি শ্রেণীবিভাগ স্কিম কার্যকর। যদিও ডকুমেন্ট নম্বরগুলি 2098 সালে ভিন্ন দেখাতে পারে, আমি কল্পনা করব যে এই URI এখনও বৈধ হবে এবং NSF বা অন্য কোনও সংস্থার সাথে হস্তক্ষেপ করবে না যা সংরক্ষণাগার বজায় রাখবে।

আমি মনে করিনি ইউআরএলগুলিকে অবিচল থাকতে হবে - সেখানে ইউআরএন ছিল।

এটি সম্ভবত ইউআরএন বিতর্কের সবচেয়ে খারাপ পার্শ্ব প্রতিক্রিয়াগুলির মধ্যে একটি। কিছু লোক মনে করে যে আরও স্থায়ী নামস্থানে গবেষণার কারণে, তারা ঝুলন্ত লিঙ্কগুলির বিষয়ে উদাসীন হতে পারে কারণ "ইউআরএনগুলি সব ঠিক করবে।" আপনি যদি এই ব্যক্তিদের একজন হন, তাহলে আমাকে আপনাকে হতাশ করতে দিন।

আমি দেখেছি বেশিরভাগ URN স্কিমগুলি একটি অথরিটি আইডেন্টিফায়ারের মতো দেখায় যার পরে হয় একটি তারিখ এবং একটি স্ট্রিং যা আপনি নির্বাচন করেন, অথবা শুধুমাত্র একটি স্ট্রিং আপনি নির্বাচন করেন৷ এটি একটি HTTP URI-এর মতোই। অন্য কথায়, আপনি যদি মনে করেন যে আপনার সংস্থা দীর্ঘস্থায়ী URN তৈরি করতে সক্ষম হবে, তাহলে আপনার HTTP URI-এর জন্য সেগুলি ব্যবহার করে এখনই প্রমাণ করুন। এইচটিটিপিতে এমন কিছুই নেই যা আপনার ইউআরআইকে অস্থির করে তোলে। শুধুমাত্র আপনার প্রতিষ্ঠান। একটি ডাটাবেস তৈরি করুন যা নথি URN কে বর্তমান ফাইলের নামের সাথে ম্যাপ করে এবং ওয়েব সার্ভারকে ফাইলগুলি পুনরুদ্ধার করতে এটি ব্যবহার করতে দিন।

আপনি যদি এই পর্যায়ে পৌঁছে থাকেন, যদি কিছু সফ্টওয়্যার বিকাশ করার জন্য আপনার কাছে সময়, অর্থ এবং সংযোগ না থাকে, তাহলে আপনি নিম্নলিখিত অজুহাতটি বলতে পারেন:

আমরা চেয়েছিলাম, কিন্তু আমাদের কাছে সঠিক সরঞ্জাম নেই।

তবে আপনি এটির সাথে সহানুভূতি প্রকাশ করতে পারেন। আমি পুরোপুরি একমত. আপনাকে যা করতে হবে তা হল ওয়েব সার্ভারকে অবিলম্বে অবিরত ইউআরআই পার্স করতে এবং ফাইলটি আপনার বর্তমান উন্মাদ ফাইল সিস্টেমে যেখানেই সংরক্ষণ করা হয় সেখানে ফিরিয়ে দিতে বাধ্য করুন৷ আপনি চেক হিসাবে একটি ফাইলে সমস্ত URI সঞ্চয় করতে চান এবং ডাটাবেসকে সর্বদা আপ টু ডেট রাখতে চান। আপনি একই নথির বিভিন্ন সংস্করণ এবং অনুবাদের মধ্যে সম্পর্ক রক্ষা করতে চান, এবং ফাইলটি দুর্ঘটনাজনিত ত্রুটি দ্বারা দূষিত না হয় তা নিশ্চিত করার জন্য একটি স্বাধীন চেকসাম রেকর্ডও বজায় রাখতে চান। এবং ওয়েব সার্ভারগুলি এই বৈশিষ্ট্যগুলির সাথে বাক্সের বাইরে আসে না। আপনি যখন একটি নতুন নথি তৈরি করতে চান, তখন আপনার সম্পাদক আপনাকে একটি URI উল্লেখ করতে বলেন।

URI পরিবর্তন না করেই আপনাকে URI স্পেসে মালিকানা, নথির অ্যাক্সেস, সংরক্ষণাগার স্তরের নিরাপত্তা ইত্যাদি পরিবর্তন করতে সক্ষম হতে হবে।

এটা সব খুব খারাপ. তবে আমরা পরিস্থিতি সংশোধন করব। W3C এ, আমরা জিগেডিট (জিগস এডিটিং সার্ভার) কার্যকারিতা ব্যবহার করি যা সংস্করণগুলিকে ট্র্যাক করে এবং আমরা নথি তৈরির স্ক্রিপ্টগুলির সাথে পরীক্ষা করি। আপনি যদি সরঞ্জাম, সার্ভার এবং ক্লায়েন্ট বিকাশ করেন তবে এই সমস্যাটিতে মনোযোগ দিন!

এই অজুহাতটি অনেকগুলি W3C পৃষ্ঠার ক্ষেত্রেও প্রযোজ্য, এটি সহ: তাই আমি যেমন বলি, তেমনটি না করে।

আমি কেন যত্ন করব?

আপনি যখন আপনার সার্ভারে ইউআরআই পরিবর্তন করেন, তখন আপনি কখনই পুরোপুরি বলতে পারবেন না কার কাছে পুরানো ইউআরআই-এর লিঙ্ক থাকবে। এগুলো নিয়মিত ওয়েব পেজ থেকে লিঙ্ক হতে পারে। আপনার পৃষ্ঠা বুকমার্ক করুন. ইউআরআই হয়ত বন্ধুর কাছে লেখা চিঠির মার্জিনে স্ক্রল করা হয়েছে।

যখন কেউ একটি লিঙ্ক অনুসরণ করে এবং এটি ভেঙে যায়, তখন তারা সাধারণত সার্ভার মালিকের উপর আস্থা হারিয়ে ফেলে। তিনি তার লক্ষ্য অর্জন করতে না পেরে মানসিক এবং শারীরিকভাবেও হতাশ।

অনেক মানুষ সব সময় ভাঙা লিঙ্ক সম্পর্কে অভিযোগ, এবং আমি ক্ষতি সুস্পষ্ট আশা করি. আমি আশা করি যে সার্ভারের রক্ষণাবেক্ষণকারীর সুনামগত ক্ষতি যেখানে নথিটি অদৃশ্য হয়ে গেছে তাও সুস্পষ্ট।

তাহলে আমার কি করা উচিৎ? ইউআরআই ডিজাইন

2 বছরে, 20 বছরে, 200 বছরে ব্যবহার করা যেতে পারে এমন URIগুলি বরাদ্দ করা ওয়েবমাস্টারের দায়িত্ব৷ এর জন্য প্রয়োজন চিন্তাশীলতা, সংগঠন এবং সংকল্প।

তাদের মধ্যে কোনো তথ্য পরিবর্তন হলে URI পরিবর্তন হয়। আপনি কিভাবে তাদের ডিজাইন খুব গুরুত্বপূর্ণ. (কি, ইউআরআই ডিজাইন? আমাকে কি ইউআরআই ডিজাইন করতে হবে? হ্যাঁ, আপনার এটি সম্পর্কে চিন্তা করা উচিত)। ডিজাইন মূলত ইউআরআই-তে যেকোন তথ্য বাদ দেওয়া।

নথিটি যে তারিখে তৈরি করা হয়েছিল - যে তারিখে URI জারি করা হয়েছিল - এমন কিছু যা কখনই পরিবর্তন হবে না৷ পুরানো সিস্টেম ব্যবহার করে নতুন সিস্টেম ব্যবহার করে এমন প্রশ্নগুলিকে আলাদা করার জন্য এটি খুবই কার্যকর। এটি একটি URI দিয়ে শুরু করার জন্য একটি ভাল জায়গা। যদি একটি নথি তারিখযুক্ত হয়, এমনকি যদি নথিটি ভবিষ্যতে প্রাসঙ্গিক হবে, তবে এটি একটি ভাল শুরু৷

একমাত্র ব্যতিক্রম হল একটি পৃষ্ঠা যা ইচ্ছাকৃতভাবে "সর্বশেষ" সংস্করণ, উদাহরণস্বরূপ সমগ্র সংস্থা বা এটির বড় অংশের জন্য।

http://www.pathfinder.com/money/moneydaily/latest/

এটি মানি ম্যাগাজিনের সর্বশেষ মানি ডেইলি কলাম। এই URI-তে কোনো তারিখের প্রয়োজন না থাকার প্রধান কারণ হল URI সংরক্ষণ করার কোনো কারণ নেই যা লগের বাইরে থাকবে। টাকা অদৃশ্য হয়ে গেলে মানি ডেইলির ধারণাটি অদৃশ্য হয়ে যাবে। আপনি যদি বিষয়বস্তুর সাথে লিঙ্ক করতে চান তবে আপনার সংরক্ষণাগারে আলাদাভাবে লিঙ্ক করা উচিত:

http://www.pathfinder.com/money/moneydaily/1998/981212.moneyonline.html

(সুন্দর দেখাচ্ছে। ধরে নিচ্ছেন যে pathfinder.com-এর সারাজীবনে "টাকা" মানে একই জিনিস থাকবে। একটি ডুপ্লিকেট "98" এবং একটি অপ্রয়োজনীয় ".html" আছে, কিন্তু অন্যথায় এটি একটি শক্তিশালী URI-এর মতো দেখায়।

কি একপাশে ছেড়ে

সমস্ত ! তৈরির তারিখ ছাড়াও, URI তে যেকোন তথ্য রাখলে তা এক না কোনভাবে সমস্যা সৃষ্টি করে।

• লেখকের নাম. নতুন সংস্করণ উপলব্ধ হওয়ার সাথে সাথে লেখকত্ব পরিবর্তিত হতে পারে। লোকেরা সংস্থাগুলি ছেড়ে যায় এবং জিনিসগুলি অন্যদের কাছে দেয়।
• বিষয়. এটা খুবই কঠিন. এটি সর্বদা প্রথমে ভাল দেখায়, তবে আশ্চর্যজনকভাবে দ্রুত পরিবর্তন হয়। আমি নীচে এই সম্পর্কে আরও কথা বলতে হবে.
• অবস্থা. "পুরাতন", "খসড়া" ইত্যাদির মতো ডিরেক্টরি, "সর্বশেষ" এবং "কুল" উল্লেখ না করার মতো, সমস্ত ফাইল সিস্টেমে উপস্থিত হয়। নথিগুলি স্থিতি পরিবর্তন করে - অন্যথায় খসড়া তৈরি করার কোনও অর্থ থাকবে না। একটি নথির সর্বশেষ সংস্করণের একটি স্থায়ী শনাক্তকারীর প্রয়োজন, তার স্থিতি নির্বিশেষে। নামের বাইরে স্ট্যাটাস রাখুন।
• প্রবেশ. W3C-তে, আমরা কর্মচারী, সদস্য এবং জনসাধারণের জন্য সাইটটিকে ভাগে ভাগ করেছি। এটি ভাল শোনাচ্ছে, তবে অবশ্যই, নথিগুলি কর্মীদের কাছ থেকে দলের ধারণা হিসাবে শুরু হয়, সদস্যদের সাথে আলোচনা করা হয় এবং তারপরে সর্বজনীন জ্ঞানে পরিণত হয়। এটি সত্যিই একটি লজ্জাজনক হবে যদি প্রতিবার বিস্তৃত আলোচনার জন্য একটি নথি খোলা হয়, এর সমস্ত পুরানো লিঙ্কগুলি ভেঙে যায়! এখন আমরা একটি সাধারণ তারিখ কোডে চলে যাই।
• ফাইল এক্সটেনশন. একটি খুব সাধারণ ঘটনা. "cgi", এমনকি ".html" ভবিষ্যতে পরিবর্তন হবে। আপনি 20 বছরের মধ্যে এই পৃষ্ঠার জন্য HTML ব্যবহার নাও করতে পারেন, তবে এটির আজকের লিঙ্কগুলি এখনও কাজ করবে৷ W3C সাইটে ক্যানোনিকাল লিঙ্কগুলি এক্সটেনশন ব্যবহার করে না (এটা কিভাবে হল).
• সফটওয়্যার মেকানিজম. URI-তে, "cgi", "exec" এবং অন্যান্য পদগুলি দেখুন যা চিৎকার করে "আমরা কোন সফ্টওয়্যার ব্যবহার করছি তা দেখুন।" কেউ কি পার্ল সিজিআই স্ক্রিপ্ট লিখতে তাদের সমগ্র জীবন ব্যয় করতে চান? না? তারপর .pl এক্সটেনশনটি সরিয়ে ফেলুন। কিভাবে এটি করতে হবে সার্ভার ম্যানুয়াল পড়ুন.
• ডিস্কের নাম। চলে আসো! কিন্তু আমি এটা দেখেছি।

তাই আমাদের সাইট থেকে সেরা উদাহরণ সহজভাবে

http://www.w3.org/1998/12/01/chairs

... W3C চেয়ারস সভার কার্যবিবরণী রিপোর্ট.

বিষয় এবং বিষয় অনুসারে শ্রেণীবিভাগ

আমি এই বিপদ সম্পর্কে আরও বিশদে যাব, কারণ এটি এমন একটি জিনিস যা এড়ানো সবচেয়ে কঠিন। সাধারণত, বিষয়গুলি URI-তে শেষ হয় যখন আপনি আপনার নথিগুলিকে তাদের কাজের দ্বারা শ্রেণিবদ্ধ করেন। কিন্তু সময়ের সাথে সাথে এই ভাঙ্গন বদলে যাবে। এলাকার নাম বদলে যাবে। W3C-তে আমরা মার্কআপকে মার্কআপে পরিবর্তন করতে চেয়েছিলাম এবং তারপরে বিভাগটির প্রকৃত বিষয়বস্তু প্রতিফলিত করতে HTML-এ পরিবর্তন করতে চেয়েছিলাম। উপরন্তু, প্রায়ই একটি সমতল নামস্থান আছে. 100 বছরে, আপনি কি নিশ্চিত যে আপনি কিছু পুনরায় ব্যবহার করতে চান না? আমাদের সংক্ষিপ্ত জীবনে আমরা ইতিমধ্যে "ইতিহাস" এবং "স্টাইল শীট" উদাহরণস্বরূপ পুনরায় ব্যবহার করতে চেয়েছি।

এটি একটি ওয়েবসাইট সংগঠিত করার একটি লোভনীয় উপায়—এবং সমগ্র ওয়েব সহ যেকোনো কিছু সংগঠিত করার একটি সত্যিকারের লোভনীয় উপায়৷ এটি একটি দুর্দান্ত মধ্যমেয়াদী সমাধান তবে দীর্ঘমেয়াদে গুরুতর ত্রুটি রয়েছে।

কারণের একটি অংশ অর্থের দর্শনে নিহিত। একটি ভাষার প্রতিটি শব্দ ক্লাস্টারিংয়ের জন্য একটি সম্ভাব্য লক্ষ্য এবং প্রতিটি ব্যক্তির এর অর্থ কী তা সম্পর্কে আলাদা ধারণা থাকতে পারে। যেহেতু সত্তাগুলির মধ্যে সম্পর্কগুলি একটি গাছের চেয়ে একটি ওয়েবের মতো, এমনকি যারা ওয়েবের সাথে একমত তারা গাছের একটি ভিন্ন উপস্থাপনা বেছে নিতে পারে৷ এটি একটি সাধারণ সমাধান হিসাবে শ্রেণিবিন্যাসের বিপদ সম্পর্কে আমার (প্রায়ই বারবার) সাধারণ পর্যবেক্ষণ।

প্রকৃতপক্ষে, আপনি যখন একটি URI-তে একটি বিষয়ের নাম ব্যবহার করেন, তখন আপনি নিজেকে এক ধরনের শ্রেণীবিভাগের জন্য প্রতিশ্রুতিবদ্ধ করছেন। সম্ভবত ভবিষ্যতে আপনি একটি ভিন্ন বিকল্প পছন্দ করবেন। URI তখন লঙ্ঘনের জন্য সংবেদনশীল হবে।

একটি URI-এর অংশ হিসাবে একটি বিষয় এলাকা ব্যবহার করার কারণ হল যে URI স্থানের সাবসেকশনগুলির জন্য দায়িত্ব সাধারণত অর্পণ করা হয়, এবং তারপরে আপনাকে সাংগঠনিক সংস্থার নাম প্রয়োজন - বিভাগ, গোষ্ঠী, বা যাই হোক না কেন - যেটি সেই সাবস্পেসের জন্য দায়ী৷ এটি একটি সাংগঠনিক কাঠামোর সাথে একটি URI বাধ্যতামূলক৷ এটি সাধারণত নিরাপদ যদি পরবর্তী (বাম) URI একটি তারিখ দ্বারা সুরক্ষিত থাকে: 1998/pics আপনার সার্ভারের কাছে "আমরা 1998 সালে আমরা যাকে এখন ছবি বলি" এর পরিবর্তে "আমরা 1998 সালে ছবি সহ যা বোঝাতে চেয়েছিলাম" এর অর্থ হতে পারে৷

ডোমেইন নাম ভুলবেন না

মনে রাখবেন যে এটি শুধুমাত্র URI-এর পাথের ক্ষেত্রেই নয়, সার্ভারের নামের ক্ষেত্রেও প্রযোজ্য। আপনার যদি বিভিন্ন জিনিসের জন্য আলাদা সার্ভার থাকে তবে মনে রাখবেন যে অনেকগুলি, অনেকগুলি লিঙ্ক ধ্বংস না করে এই বিভাগটি পরিবর্তন করা অসম্ভব। কিছু ক্লাসিক "আমরা আজ যে সফ্টওয়্যারটি ব্যবহার করি তা দেখুন" ভুলগুলি হল ডোমেন নাম "cgi.pathfinder.com", "secure", "lists.w3.org"। এগুলি সার্ভার প্রশাসনকে সহজ করার জন্য ডিজাইন করা হয়েছে। একটি ডোমেন আপনার কোম্পানির একটি বিভাগ, একটি নথির স্থিতি, একটি অ্যাক্সেস স্তর, বা একটি নিরাপত্তা স্তরের প্রতিনিধিত্ব করে কিনা তা নির্বিশেষে, একাধিক নথির প্রকারের জন্য একাধিক ডোমেন নাম ব্যবহার করার আগে খুব সতর্ক থাকুন৷ মনে রাখবেন আপনি পুনঃনির্দেশ এবং প্রক্সি ব্যবহার করে একটি একক দৃশ্যমান ওয়েব সার্ভারের মধ্যে একাধিক ওয়েব সার্ভার লুকিয়ে রাখতে পারেন৷

ওহ, এবং আপনার ডোমেন নাম সম্পর্কে চিন্তা করুন. আপনি পণ্য লাইন পরিবর্তন করার পরে এবং সাবান তৈরি করা বন্ধ করার পরে আপনি soap.com হিসাবে উল্লেখ করতে চান না (এই মুহূর্তে soap.com এর মালিকের জন্য দুঃখিত)।

উপসংহার

2, 20, 200, এমনকি 2000 বছরের জন্য একটি URI সংরক্ষণ করা স্পষ্টতই যতটা সহজ মনে হয় ততটা সহজ নয়। যাইহোক, সমস্ত ইন্টারনেট জুড়ে, ওয়েবমাস্টাররা এমন সিদ্ধান্ত নিচ্ছেন যা এই কাজটিকে ভবিষ্যতে তাদের জন্য সত্যিই কঠিন করে তুলছে। প্রায়শই এটি হয় কারণ তারা এমন সরঞ্জামগুলি ব্যবহার করে যার কাজ শুধুমাত্র এই মুহুর্তে সেরা সাইটটি উপস্থাপন করা - এবং সবকিছু পরিবর্তন হলে লিঙ্কগুলির কী হবে তা কেউ মূল্যায়ন করেনি। যাইহোক, এখানে বিন্দু হল যে অনেক, অনেক কিছু পরিবর্তন হতে পারে, এবং আপনার ইউআরআই একই থাকতে পারে এবং থাকা উচিত। এটি তখনই সম্ভব যখন আপনি কীভাবে এগুলি তৈরি করেন সে সম্পর্কে চিন্তা করেন।

আরও দেখুন:

• একই বিষয়ে জ্যাকব নিলসনের টিরাড

সম্পূরকসমূহ

কিভাবে ফাইল এক্সটেনশন অপসারণ...

...বর্তমান ফাইল-ভিত্তিক ওয়েব সার্ভারে একটি URI থেকে?

আপনি যদি Apache ব্যবহার করেন, উদাহরণস্বরূপ, আপনি বিষয়বস্তু নিয়ে আলোচনা করতে এটি কনফিগার করতে পারেন। ফাইল এক্সটেনশন (যেমন .png) একটি ফাইলে সংরক্ষণ করুন (যেমন mydog.png), কিন্তু আপনি এটি ছাড়াই একটি ওয়েব রিসোর্সে লিঙ্ক করতে পারেন। Apache তারপর সেই নাম এবং যেকোনো এক্সটেনশন সহ সমস্ত ফাইলের জন্য ডিরেক্টরি পরীক্ষা করে এবং সেট থেকে সেরাটি বেছে নিতে পারে (উদাহরণস্বরূপ, GIF এবং PNG)। এবং বিভিন্ন ডিরেক্টরিতে বিভিন্ন ধরণের ফাইল রাখার দরকার নেই, আসলে বিষয়বস্তু ম্যাচিং কাজ করবে না যদি আপনি এটি করেন।

• বিষয়বস্তু আলোচনার জন্য আপনার সার্ভার সেট আপ করুন
• সর্বদা এক্সটেনশন ছাড়াই URI-তে লিঙ্ক করুন

এক্সটেনশন সহ লিঙ্কগুলি এখনও কাজ করবে, কিন্তু আপনার সার্ভারকে বর্তমানে এবং ভবিষ্যতে উপলব্ধ সেরা বিন্যাস চয়ন করতে বাধা দেবে৷

(আসলে, mydog, mydog.png и mydog.gif - বৈধ ওয়েব সম্পদ, mydog একটি সার্বজনীন বিষয়বস্তু ধরনের সম্পদ, এবং mydog.png и mydog.gif — একটি নির্দিষ্ট বিষয়বস্তুর প্রকারের সংস্থান)।

অবশ্যই, যদি আপনি আপনার নিজের ওয়েব সার্ভার লিখছেন, তবে অবিরাম শনাক্তকারীকে তাদের বর্তমান ফর্মের সাথে আবদ্ধ করতে একটি ডাটাবেস ব্যবহার করা একটি ভাল ধারণা, যদিও সীমাহীন ডাটাবেস বৃদ্ধি থেকে সতর্ক থাকুন।

দ্য বোর্ড অফ শেম - গল্প 1: চ্যানেল 7

1999-এর সময়, আমি পৃষ্ঠায় তুষারপাতের কারণে স্কুল বন্ধ হওয়ার ট্র্যাক করেছি http://www.whdh.com/stormforce/closings.shtml. তথ্য টিভি পর্দার নীচে প্রদর্শিত হওয়ার জন্য অপেক্ষা করবেন না! আমি আমার হোম পেজ থেকে এটি লিঙ্ক. 2000 সালের প্রথম বড় তুষার ঝড় আসে এবং আমি পৃষ্ঠাটি পরীক্ষা করি। সেখানে লেখা আছে,

- হিসাবে.
বর্তমানে কিছুই বন্ধ নেই। আবহাওয়া সতর্কতা ক্ষেত্রে ফিরে আসুন.

এটা এত শক্তিশালী ঝড় হতে পারে না. এটা মজার যে তারিখ অনুপস্থিত. তবে আপনি যদি সাইটের মূল পৃষ্ঠায় যান, সেখানে একটি বড় বোতাম থাকবে "বন্ধ স্কুলগুলি", যা পৃষ্ঠায় নিয়ে যায় http://www.whdh.com/stormforce/ বন্ধ স্কুলের একটি দীর্ঘ তালিকা সহ।

হয়তো তারা তালিকা পাওয়ার জন্য সিস্টেম পরিবর্তন করেছে - কিন্তু তাদের URI পরিবর্তন করার দরকার নেই।

বোর্ড অফ শেম - গল্প 2: মাইক্রোসফ্ট নেটমিটিং

ইন্টারনেটের উপর ক্রমবর্ধমান নির্ভরতার সাথে, একটি চতুর ধারণা এসেছিল যে নির্মাতার ওয়েবসাইটের লিঙ্কগুলি অ্যাপ্লিকেশনগুলিতে এম্বেড করা যেতে পারে। এটি অনেক ব্যবহার করা হয়েছে এবং অপব্যবহার করা হয়েছে, কিন্তু আপনি URL পরিবর্তন করতে পারবেন না। ঠিক অন্য দিন আমি ওয়েব/ফ্রি স্টাফ মেনুতে হেল্প/মাইক্রোসফ্ট-এ Microsoft Netmeeting 2/something ক্লায়েন্ট থেকে একটি লিঙ্ক চেষ্টা করেছিলাম এবং একটি 404 ত্রুটি পেয়েছি - সার্ভার থেকে কোনও প্রতিক্রিয়া পাওয়া যায়নি। হয়তো এটা ইতিমধ্যেই ঠিক হয়ে গেছে...

© 1998 টিম বিএল

ঐতিহাসিক দ্রষ্টব্য: 20 শতকের শেষের দিকে, যখন এটি লেখা হয়েছিল, "কুল" ছিল অনুমোদনের একটি উপাধি, বিশেষ করে তরুণদের মধ্যে, যা ফ্যাশনেবলতা, গুণমান বা উপযুক্ততা নির্দেশ করে। তাড়াহুড়ো করে, ইউআরআই পথটি প্রায়শই উপযোগিতা বা স্থায়িত্বের পরিবর্তে "শীতলতার" জন্য বেছে নেওয়া হয়েছিল। এই পোস্টটি শীতল অনুসন্ধানের পিছনে শক্তি পুনঃনির্দেশ করার একটি প্রচেষ্টা।

উত্স: www.habr.com