ইউআরএল কেন মামলা সংবেদনশীল?

Question

আমার প্রশ্ন: যখন ইউআরএলগুলি প্রথম ডিজাইন করা হয়েছিল তখন কেস-সংবেদনশীলতা কেন একটি বৈশিষ্ট্য তৈরি করা হয়েছিল? আমি এটি জিজ্ঞাসা করেছি কারণ এটি আমার কাছে (যেমন একটি ল্যাপারসন) বলে মনে হচ্ছে অযথা ত্রুটিগুলি রোধ করতে এবং ইতিমধ্যে জটিল পাঠ্যটির সরলকরণের ক্ষেত্রে কেস-সংবেদনশীলতা পছন্দ করা হবে।

এছাড়াও, কেস-সংবেদনশীল ইউআরএল থাকা (মূল পৃষ্ঠার কোনও বিষয় নেই যা একই পৃষ্ঠায় ইঙ্গিত করে যে বিশাল সংখ্যক ইউআরএল বিপরীতে রয়েছে) এর কি কোনও আসল উদ্দেশ্য / সুবিধা রয়েছে?

উদাহরণস্বরূপ, উইকিপিডিয়া হ'ল একটি ওয়েবসাইট যা অক্ষরের ক্ষেত্রে সংবেদনশীল (প্রথম চরিত্র ব্যতীত):

https://en.wikedia.org/wiki/St একটি সিকে_ এক্সচেঞ্জ হ'ল ডিওএ।

Comments

আপনি অবশ্যই উইন্ডোজ আইআইএস চালান না

— জন কনডে

আমি কল্পনা করি যে এটির ক্র্যাপ ডটকম, এক্সপ্রেস এক্সচেঞ্জ এবং হোয়্যারপ্রিপস ডট কম পছন্দ করবে যে আরও বেশি লোক কেস-সংবেদনশীল নাম ব্যবহার করবে। আরও তথ্যের জন্য, বিরক্তিকর পান্ডা / ডাব্লু- ডোমেন- নামগুলি দেখুন ।

— এরিক টাওয়ার

ইউনিক্স ডিজাইন করা হয়েছিল যখন ইউনিক্স সিস্টেমে ডাইনোসররা পৃথিবীতে ঘোরাঘুরি করেছিল এবং ইউনিক্স কেস সংবেদনশীল।

— থরবজর্ন রাভন অ্যান্ডারসন

উইকিপিডিয়া বিষয় শিরোনামের জন্য সঠিক মূলধনটি ব্যবহার করার চেষ্টা করে এবং সাধারণ পার্থক্যের জন্য পুনর্নির্দেশগুলি ব্যবহার করে। যেমন। html, htmএবং Htmlসমস্ত পুনর্নির্দেশ HTML। তবে গুরুত্বপূর্ণ বিষয় হল, বিশাল বিষয়গুলির কারণে, একাধিক পৃষ্ঠা থাকা সম্ভব যেখানে URL কেবলমাত্র কেস অনুসারে পৃথক হয়। উদাহরণস্বরূপ: লেটেক্স এবং ল্যাটেক্স

— মিস্টারউইট

@ edc65 কিন্তু কবি যে অংশের URL টি (বিশেষতঃ এর পাথ ) হয় কেস সংবেদনশীল - তাই, যে URL কেস সংবেদনশীল দেখা যায় না (সামগ্রিকভাবে)?

— মিঃ হোয়েট

Answer 1

ইউআরএল কেন মামলা সংবেদনশীল হবে না?

আমি বুঝতে পারি যে প্ররোচিত (এবং "শয়তানের উকিল") ধরণের বক্তৃতামূলক প্রশ্নের মতো দেখতে পারে তবে আমি মনে করি এটি বিবেচনা করা কার্যকর। এইচটিটিপি এর নকশাটি হ'ল একটি "ক্লায়েন্ট", যাকে আমরা সাধারণত একটি "ওয়েব ব্রাউজার" বলে থাকি, "ওয়েব সার্ভার" কে ডেটা জিজ্ঞাসা করি।

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

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

বিভিন্ন ওয়েব সার্ভারের মধ্যে ভিন্ন আচরণের মূল কারণটি সম্ভবত সরলতার বিষয়টি নিয়ে ফোটে। একটি ওয়েব সার্ভার তৈরির সহজ উপায় হ'ল কম্পিউটার / ডিভাইসের অপারেটিং সিস্টেম ফাইলগুলি কীভাবে চিহ্নিত করে। অনেক সময়, ওয়েব সার্ভার একটি প্রতিক্রিয়া সরবরাহ করার জন্য একটি ফাইল সনাক্ত করে। ইউনিক্স উচ্চতর কম্পিউটারের আশেপাশে তৈরি করা হয়েছিল, এবং তাই ইউনিক্স বড় হাতের অক্ষর এবং ছোট হাতের অক্ষরগুলিকে অনুমতি দেওয়ার আকাঙ্ক্ষিত কার্যকারিতা সরবরাহ করে। ইউনিক্স বড় হাতের এবং ছোট হাতের সাথে আলাদা হিসাবে বিবেচনা করার সিদ্ধান্ত নিয়েছে কারণ, ভাল, তারা আলাদা different এটি করা সহজ সরল, প্রাকৃতিক জিনিস। ইতিমধ্যে তৈরি সফ্টওয়্যার সমর্থন করার ইচ্ছার কারণে উইন্ডোজ কেস-সংবেদনশীল হওয়ার ইতিহাস রয়েছে এবং এই ইতিহাসটি ডস-এ ফিরে যায় যা ছোট হাতের অক্ষরগুলিকে সমর্থন করে না, সম্ভবত কম শক্তিশালী কম্পিউটার যা কম মেমরি ব্যবহার করে এমন জিনিসগুলি সহজ করার প্রয়াসে। যেহেতু এই অপারেটিং সিস্টেমগুলি পৃথক, ফলাফলটি হ'ল কেবল সার্ভার-ডিজাইন করা (প্রাথমিক সংস্করণ) ওয়েব সার্ভারগুলি একই পার্থক্য প্রতিবিম্বিত করে।

এখন, সেই সমস্ত পটভূমি সহ, এখানে নির্দিষ্ট প্রশ্নের কয়েকটি নির্দিষ্ট উত্তর দেওয়া হল:

যখন ইউআরএলগুলি প্রথম ডিজাইন করা হয়েছিল তখন কেস-সংবেদনশীলতা কেন একটি বৈশিষ্ট্য তৈরি করা হয়েছিল?

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

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

ইউআরএলগুলি প্রক্রিয়া করার জন্য মেশিনগুলির জন্য ডিজাইন করা হয়েছিল। যদিও কোনও ব্যক্তি কোনও ঠিকানা বারে একটি সম্পূর্ণ URL টাইপ করতে পারে, এটি উদ্দিষ্ট নকশার একটি প্রধান অংশ ছিল না। উদ্দেশ্যযুক্ত নকশাটি হ'ল লোকে হাইপারলিঙ্কগুলি অনুসরণ করে ("ক্লিক করুন")। যদি গড় লাইপোপোয়েলরা এটি করে থাকে তবে অদৃশ্য ইউআরএলটি সহজ বা জটিল কিনা তা তারা সত্যিই চিন্তা করে না।

এছাড়াও, কেস-সংবেদনশীল ইউআরএল থাকা (মূল পৃষ্ঠার কোনও বিষয় নেই যা একই পৃষ্ঠায় ইঙ্গিত করে যে বিশাল সংখ্যক ইউআরএল বিপরীতে রয়েছে) এর কি কোনও আসল উদ্দেশ্য / সুবিধা রয়েছে?

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

যাইহোক, অনেক ক্ষেত্রে কেস সংবেদনশীলতার জন্য কোনও দুর্দান্ত বাধ্যবাধকতা নেই, যা আইআইএস সাধারণত এটি নিয়ে বিরক্ত করে না তা প্রমাণিত।

সংক্ষেপে, সবচেয়ে জোরালো কারণ সম্ভবত তাদের জন্য সহজ সরলতা যা ওয়েব সার্ভার সফ্টওয়্যারটি ডিজাইন করেছে, বিশেষত ইউনিক্সের মতো কেস-সংবেদনশীল প্ল্যাটফর্মে। (এইচটিটিপি এমন কিছু নয় যা ইউনিক্সের মূল নকশাকে প্রভাবিত করেছিল, যেহেতু ইউনিক্স এইচটিটিপি-র তুলনায় উল্লেখযোগ্যভাবে বয়স্ক)

Comments

"বিভিন্ন ওয়েব ব্রাউজারগুলির মধ্যে ভিন্ন আচরণের মূল কারণটি সম্ভবত সরলতার বিষয়ে ফুটে ওঠে" " - আমি ধরে নিয়েছি যে আপনি এখানে এবং অন্যান্য কয়েকটি জায়গায় "ওয়েব ব্রাউজারগুলি" না দিয়ে "ওয়েব সার্ভার" বলতে চাইছেন?

— মিঃউইট

আপডেট করা হয়েছে। "ব্রাউজারগুলি" এর প্রতিটি ক্ষেত্রে পর্যালোচনা করে একাধিক প্রতিস্থাপন করে। এটি উল্লেখ করার জন্য আপনাকে ধন্যবাদ যাতে কিছু মানের উন্নতি করা যায়।

— তোগাম

Questionতিহাসিক থেকে শুরু করে প্রযুক্তিগত পর্যন্ত আমার প্রশ্নের বেশ কয়েকটি দুর্দান্ত উত্তর পেয়েছি to আমি শস্যের বিরুদ্ধে যেতে এবং নিম্ন-রেটে উত্তর গ্রহণ করতে দ্বিধা বোধ করি, তবে @ টোগামের উত্তরটি আমার পক্ষে সবচেয়ে সহায়ক ছিল। এই উত্তরটি পুরোপুরি এবং বিস্তৃত তবুও এটি ধারণাটিকে একটি জটিল, কথোপকথন ফ্যাশনে ব্যাখ্যা করতে পারে যা আমি বুঝতে পারি। এবং আমি মনে করি যে এই উত্তরটি আরও গভীরতার সাথে ব্যাখ্যাগুলির একটি ভাল ভূমিকা।

— কাইল

Answer 2

ইউআরএলগুলি কেস-সংবেদনশীল নয়, কেবলমাত্র তাদের কিছু অংশ।
উদাহরণস্বরূপ, URL- এ কিছুই সংবেদনশীল নয় https://google.com,

রেফারেন্স দিয়ে জেনেরিক শব্দবিন্যাস: ইউনিফর্ম রিসোর্স আইডেন্টিফাইয়ার (কোনো URI) - জন্য RFC 3986

প্রথমত, উইকিপিডিয়া থেকে , একটি ইউআরএল দেখতে পাওয়া যায়:

 scheme:[//host[:port]][/]path[?query][#fragment]

(আমি user:passwordঅংশটি সরিয়েছি কারণ এটি আকর্ষণীয় এবং খুব কম ব্যবহৃত হয়)

• scheme:

প্রকল্পগুলি সংবেদন-সংবেদনশীল

• host:

হোস্ট সাব-কম্পোনেন্টটি কেস-সংবেদনশীল।

• path:

পাথ উপাদানটিতে ডেটা রয়েছে ...

• query:

ক্যোয়ারী উপাদানটিতে অ-শ্রেণিবদ্ধ তথ্য রয়েছে ...

• fragment:

পৃথক মিডিয়া প্রকারগুলি বিভিন্ন ধরণের উপসেট, দর্শন বা বাহ্যিক রেফারেন্স নির্দিষ্ট করার জন্য খণ্ড সনাক্তকারী সিনট্যাক্সের মধ্যে বা নিজস্ব কাঠামোগুলি বা কাঠামোগুলিতে তাদের নিজস্ব বিধিনিষেধগুলি সংজ্ঞায়িত করতে পারে

সুতরাং, schemeএবং hostকেস সংবেদনশীল হয়।
বাকি URL টি কেস-সংবেদনশীল।

pathমামলা-সংবেদনশীল কেন ?

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

 scheme:[//host[:port]][/]path[?query][#fragment]
 \____________________/\________________________/
        Location                 Data

• অবস্থান - অবস্থানটির একটি প্রচলিত রূপ রয়েছে এবং এটি কেস-সংবেদনশীল। কেন? সম্ভবত তাই আপনি কয়েক হাজার বৈকল্প না কিনে একটি ডোমেন নাম কিনতে পারেন।

• ডেটা - ডেটা লক্ষ্য সার্ভার দ্বারা ব্যবহৃত হয়, এবং অ্যাপ্লিকেশনটি এর অর্থ কী তা চয়ন করতে পারে । ডেটা কেসকে সংবেদনশীল করে তোলার কোনও মানে হবে না। অ্যাপ্লিকেশনটিতে আরও বিকল্প থাকতে হবে এবং নির্দিষ্ট ক্ষেত্রে কেস-সংবেদনশীলতার সংজ্ঞা দেওয়া এই বিকল্পগুলিকে সীমাবদ্ধ করবে।
  এটি এইচটিটিপিএসের জন্যও একটি কার্যকর পার্থক্য: ডেটা এনক্রিপ্ট করা থাকলেও হোস্টটি দৃশ্যমান।

এটা কি দরকারী?

ক্যাচিং এবং ক্যানোনিকাল ইউআরএলগুলির ক্ষেত্রে কেস-সংবেদনশীলতার সমস্যা রয়েছে তবে এটি অবশ্যই কার্যকর useful কিছু উদাহরণ:

• বেস 64 , যা ডেটা ইউআরআইতে ব্যবহৃত হয় ।
• সাইট, URL- এ করুন Base64- তথ্য এনকোড করতে উদাহরণস্বরূপ: http://tryroslyn.azurewebsites.net/#f:r/A4VwRgNglgxgBDCBDAziuBhOBvGB7AOxQBc4SAnKAgczLgF44AiAUQPwBMBTDuKuYgAsucAKoAlADIBCJgG4AvkA
• ইউআরএল সংক্ষিপ্তকারীরা কেস সংবেদনশীলতা ব্যবহার করে: এর /a5Bচেয়ে আলাদা হতে পারে/a5b
• যেমনটি আপনি উল্লেখ করেছেন, উইকিপিডিয়া "এইডস" কে "এইডস" থেকে আলাদা করতে পারে।

Comments

"ইউআরএলগুলি কেস-সংবেদনশীল নয়" " / "বাকী URL টি কেস-সংবেদনশীল" " - এটা কি একটি বৈপরীত্য বলে মনে হবে?

— মিঃ হোয়েট

সত্য সত্যই, স্কিমটি ইউআরএল বাকি অংশে কী প্রত্যাশা করবে তা নির্ধারণ করে। http:এবং সম্পর্কিত স্কিমগুলির অর্থ URL টি একটি ডিএনএস হোস্টনামকে বোঝায়। ডিআরএনএস ইউআরএল আবিষ্কারের অনেক আগে থেকেই ASCII কেস-সংবেদনশীল ছিল। Ietf.org/rfc/rfc883.txt

— ও এর জোনস

সুন্দরভাবে বিস্তারিত! আমি historicalতিহাসিক দৃষ্টিকোণ থেকে যাচ্ছিলাম। এটি ফাইল ফাইলটি কেবলমাত্র যদি আপনি ফাইল সিস্টেমে আঘাত করে তবেই সংবেদনশীল হওয়া দরকার। অন্যথায়, এটি ছিল না। কিন্তু আজ, বিষয়গুলি পরিবর্তিত হয়েছে। উদাহরণস্বরূপ, প্যারামিটার এবং সিজিআই মূলত বিদ্যমান ছিল না। আপনার উত্তরটি একটি বর্তমান দিনের দৃষ্টিকোণ নেয়। আমি আপনার প্রচেষ্টা পুরষ্কার ছিল !! আপনি সত্যিই এই এক খনন! কে জানত এটি এভাবেই ফুঁসে উঠবে ?? চিয়ার্স !!

— ক্লোজটনোক

@ ডাব্লু ৩ ডি কে: এটি পরিভাষাটির খুব আকর্ষণীয় নয়, তবে আপনি "কেস-সংবেদনশীল" এর অর্থ নিতে পারেন, "একটি চরিত্রের কেস পরিবর্তন করা পুরোপুরি পরিবর্তন করতে পারে", বা আপনি এটির অর্থ নিতে পারেন, "পরিবর্তনটি বদলানো একটি চরিত্রের ক্ষেত্রে সর্বদা পুরো পরিবর্তন হয় "। কোবি মনে করেন যে এই বিষয়টি পরবর্তীকালে জোর দিয়েছিল, তিনি পছন্দ করেন যে কেস-সেনসিটিভের অর্থ হওয়া উচিত "ক্ষেত্রে যে কোনও পরিবর্তন উল্লেখযোগ্য", যা ইউআরএলগুলির ক্ষেত্রে সত্য নয় true আপনি আগের পছন্দ। তারা কেস সম্পর্কে কতটা সংবেদনশীল তা কেবল বিষয় ।

— স্টিভ জেসোপ

@ rybo111: একটি ব্যবহারকারী ধরনের তাহলে example.com/fOObaR , বৈশিষ্ট যে www.example.com সার্ভারটির একটি পাথ "/ FOOBAR" হিসাবে দেওয়া গ্রহণ প্রয়োজন; সার্ভারের অবশ্যই "/ foOBaR" থেকে আলাদা কোনও আচরণ করা উচিত কিনা এই প্রশ্নে এটি নীরব।

— সুপারক্যাট

Answer 3

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

[হালনাগাদ]

আমার বক্তব্য অনুসারে ফাইল সিস্টেমের সাথে ইউআরএলগুলির কোনও সম্পর্ক রয়েছে কিনা সে সম্পর্কে মন্তব্যগুলিতে (মুছে ফেলা হওয়ার পরে) কিছু শক্ত যুক্তি রয়েছে। এই যুক্তিগুলি উত্তপ্ত হয়ে উঠেছে। সম্পর্ক নেই বলে বিশ্বাস করা অত্যন্ত স্বল্পদৃষ্টি। একেবারে আছে! আমাকে আরও ব্যাখ্যা করুন।

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

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

মনে রাখবেন যে প্রাথমিক ওয়েব সার্ভারগুলি হয় মূল ফ্রেমে বা মিড-ফ্রেম কম্পিউটারগুলিতে DEC VAX / VMS সার্ভার এবং দিনের ইউনিক্স (বার্কলে এবং উল্ট্রিক্স পাশাপাশি অন্যান্য) হিসাবে দামী কম্পিউটারগুলিতে চলেছিল, তারপরে খুব শীঘ্রই হালকা ওজন কম্পিউটার যেমন পিসি এবং উইন্ডোজ 3.1। যখন আরও আধুনিক সার্চ ইঞ্জিনগুলি প্রদর্শিত হতে শুরু করেছিল, যেমন গুগলের মতো ১৯৯ 1997/৮ সালে, উইন্ডোজ উইন্ডোজ এনটি তে চলে গিয়েছিল এবং নোভেল এবং লিনাক্সের মতো অন্যান্য ওএসও ওয়েব সার্ভার চালানো শুরু করেছিল। আইআইএস এবং ও'রিলির মতো আরও অনেকগুলি ছিল যেগুলি খুব জনপ্রিয় ছিল, তবে অ্যাপাচিই প্রধান ওয়েব সার্ভার ছিল। এগুলির মধ্যে কেউই ওএস পরিষেবা বাইপাস করেনি। সম্ভবত এটি আজও ওয়েব সার্ভারগুলির মধ্যে কেউ করে না।

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

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

কোনও ওয়েব সার্ভারের ক্ষেত্রে, ধরে নেওয়া যে কোনও পাথ / ফাইলের জন্য ইউআরএল অনুরোধ করা হয়েছে, ওয়েব সার্ভারটি ইউআরএল অনুরোধের (ইউআরআই) পথ / ফাইল অংশ নেয় এবং ফাইল সিস্টেমে একটি অনুরোধ করে এবং তা সন্তুষ্ট হয় বা একটি ব্যতিক্রম নিক্ষেপ। ওয়েব সার্ভার তারপরে প্রতিক্রিয়াটি প্রসেস করে। যদি উদাহরণস্বরূপ, অনুরোধ করা পথ এবং ফাইল যদি অনুমোদন উপ-সিস্টেমের দ্বারা অনুমোদিত এবং অ্যাক্সেস পাওয়া যায় তবে ওয়েব সার্ভারটি I / O অনুরোধটিকে স্বাভাবিক হিসাবে প্রক্রিয়াকরণ করে। যদি ফাইল সিস্টেমটি একটি ব্যতিক্রম ছুঁড়ে, তবে ওয়েব সার্ভারটি ফাইল না পাওয়া গেলে একটি 404 ত্রুটি বা কারণ কোডটি অননুমোদিত থাকলে 403 নিষিদ্ধ ফিরিয়ে দেয়।

যেহেতু কিছু ওএস কেস সংবেদনশীল এবং এই ধরণের ফাইল সিস্টেমে যথাযথ ম্যাচগুলির প্রয়োজন, ওয়েব সার্ভারের জন্য অনুরোধ করা পাথ / ফাইলটি হার্ড ড্রাইভে উপস্থিত যা সঠিকভাবে মেলাতে হবে। এটার কারন খুবিই সাধারন. ওয়েব সার্ভারগুলি আপনার অর্থটি অনুমান করে না। কোনও কম্পিউটার প্রোগ্রাম না করে এটি করে না। ওয়েব সার্ভারগুলি অনুরোধগুলি গ্রহণ করার সাথে সাথে কেবল তাদের প্রক্রিয়া করে। ইউআরএল অনুরোধের পাথ / ফাইল অংশটি সরাসরি ফাইল সিস্টেমে প্রেরণ করা যদি হার্ডড্রাইভের সাথে মেলে না, তবে ফাইল সিস্টেম একটি ব্যতিক্রম ছুঁড়ে ফেলে এবং ওয়েব সার্ভার একটি 404 পাওয়া যায়নি ত্রুটি প্রদান করে।

এটা সত্যিই যে সহজ ভাবেন। এটা রকেট বিজ্ঞান নয়। কোনও URL এর ফাইল / ফাইল অংশ এবং ফাইল সিস্টেমের মধ্যে একটি নিখুঁত সম্পর্ক রয়েছে।

Comments

আমি মনে করি আপনার যুক্তি ত্রুটিযুক্ত। যদিও বার্নারস-লি এফটিপি ইউআরএলগুলির কেস সংবেদনশীলতা সম্পর্কে কোনও পছন্দ করেননি। তিনি এইচটিপি ইউআরএল ডিজাইন করতে পেরেছেন। তিনি এগুলি কেবল মার্কিন-এএসসিআইআই এবং কেস সংবেদনশীল হিসাবে চিহ্নিত করতে পারতেন। যদি কখনও এমন কোনও ওয়েব সার্ভার উপস্থিত থাকে যা কেবলমাত্র URL সিস্টেমে ফাইল সিস্টেমে চলে গেছে তবে সেগুলি অনিরাপদ ছিল এবং ইউআরএল এনকোডিংয়ের প্রবর্তনের ফলে তাদের সাথে সামঞ্জস্যতা ভেঙে গেছে। ওএস স্ম্যাশিং কেস হস্তান্তর করার আগে পাথটি প্রক্রিয়াজাত করা হচ্ছে তা কার্যকর করা সহজ হত। অতএব আমি মনে করি আমাদের এটিকে বাস্তবায়নের তাত্পর্য নয় বরং একটি ডিজাইনের সিদ্ধান্ত হিসাবে বিবেচনা করতে হবে।

— উইলিয়াম হেই

@ উইলিয়ামহায় এর বার্নার্স-লি বা ওয়েব ডিজাইনের সাথে কোনও সম্পর্ক নেই। এটি ওএসের সীমাবদ্ধতা এবং প্রয়োজনীয়তা সম্পর্কে। আমি একজন অবসরপ্রাপ্ত সিস্টেম ইন্টার্নাল ইঞ্জিনিয়ার। আমি এই সময়ে এই সিস্টেমে কাজ করেছি। ইউআরএলগুলি কেস সংবেদনশীল কেন আমি আপনাকে বলছি। এটা কোন অনুমান নয়। এটা কোন মতামত নয়। এটি একটি সত্য। আমার উত্তরটি ইচ্ছাকৃতভাবে সরল করা হয়েছিল। অবশ্যই ফাইল চেক এবং অন্যান্য প্রক্রিয়া রয়েছে যা কোনও প্রকাশ্য বিবৃতি দেওয়ার আগে করা যেতে পারে। এবং হ্যাঁ (!) ওয়েব সার্ভারগুলি এখনও এখনও আংশিকভাবে অনিরাপদ।

— ক্লোজটনোক

ইউআরএলগুলি কেস সেনসেটিভ কিনা তা ওয়েবে ডিজাইনের কোনও সম্পর্ক নেই? সত্যি? কর্তৃপক্ষের পক্ষ থেকে যুক্তি তদন্তের পরে যুক্তি অনুসরণ করে ser সেই ওয়েব সার্ভারগুলি কোনও ইউআরএল এর পাথ উপাদানকে কমবেশি সরাসরি একটি মুক্ত কলের কাছে পৌঁছে দেয় এটি URL এর ডিজাইনের ফলাফল যা এর কারণ নয়। সার্ভারগুলি (বা এফটিপির ক্ষেত্রে স্মার্ট ক্লায়েন্ট) ব্যবহারকারীদের থেকে ফাইল সিস্টেমের ক্ষেত্রে সংবেদনশীলতা লুকিয়ে রাখতে পারে। যে তারা না একটি নকশা সিদ্ধান্ত।

— উইলিয়াম হেই

@ উইলিয়ামহায় আপনার গ্রাস হপারকে ধীর করতে হবে এবং আমি যা লিখেছি তা আবার পড়তে হবে। আমি আরপিএ-নেট ইত্যাদির জন্য ওএস উপাদান, প্রোটোকল স্ট্যাক এবং রাউটার কোড লেখার জন্য একটি অবসরপ্রাপ্ত সিস্টেম ইন্টার্নাল ইঞ্জিনিয়ার I আমি আপাচি, ওরিলি, এবং আইআইএস ইন্টার্নালদের সাথে কাজ করেছি। আপনার FTP যুক্তিটি জল ধরে রাখেনি কারণ কমপক্ষে প্রধান এফটিপি সার্ভার একই কারণে কেস সংবেদনশীল থেকে যায়। ইউআরএল / ইউআরআই ডিজাইনের বিষয়ে আমি কখনই কিছু বলিনি। কোনও সময় আমি বলিনি যে ওয়েব সার্ভারগুলি প্রক্রিয়াজাতকরণ ছাড়াই মানগুলি পাস করেছে। আমি বলেছিলাম যে ওএস পরিষেবাগুলি সাধারণত ব্যবহৃত হয় এবং ফাইল সিস্টেমটি সফল হওয়ার জন্য একটি সঠিক মিল প্রয়োজন।

— ক্লোজটনোক

@ উইলিয়ামহায় দয়া করে বুঝতে পারেন যে আপনি এবং আমি আন্তঃ-উদ্দেশ্য নিয়ে চিন্তাভাবনা করছি। আমি আমার উত্তরে যা বলছিলাম তা হ'ল কিছু ওএসের জন্য, ফাইল সিস্টেম কলগুলি ডিজাইনের দ্বারা কেস সংবেদনশীল। সিস্টেম কলগুলি ব্যবহার করে এবং বেশিরভাগ কাজ করে এমন অ্যাপ্লিকেশনগুলি ওএস বিধি প্রয়োগের ক্ষেত্রে সীমাবদ্ধ - এই ক্ষেত্রে ক্ষেত্রে সংবেদনশীলতা রয়েছে। এই নিয়মটিকে বাইপাস করা অসম্ভব নয়। বাস্তবে এটি ব্যবহারিক না হলেও কিছু ক্ষেত্রে কিছুটা তুচ্ছ হতে পারে। আমি নিয়মিতভাবে আমার

— কাজটিতে

Answer 4

1. ইউআরএলগুলি একটি ইউনিফর্ম রিসোর্স লোকেটার হিসাবে দাবী করে এবং সেই সংস্থানগুলিতে ইঙ্গিত করতে পারে যা ওয়েবকে পূর্বনির্ধারিত করে। এর মধ্যে কয়েকটি কেস সংবেদনশীল (উদাঃ অনেকগুলি এফটিপি সার্ভার) এবং ইউআরএলগুলিকে যুক্তিসঙ্গত স্বজ্ঞাত ফ্যাশনে এই সংস্থানগুলি উপস্থাপন করতে সক্ষম হওয়া প্রয়োজন।

2. কোনও মিল খুঁজে পাওয়ার ক্ষেত্রে কেস সংবেদনশীলতার জন্য আরও কাজ করা প্রয়োজন (হয় ওএসে বা তারও বেশি)।

3. সংবেদনশীল স্বতন্ত্র সার্ভারগুলি ইউআরএলকে কেস সংবেদনশীল হিসাবে সংজ্ঞায়িত করে যদি তারা চান তবে এগুলি সংবেদনশীল হিসাবে প্রয়োগ করতে পারে। বিপরীত সত্য নয়।

4. কেস সংবেদনশীলতা আন্তর্জাতিক প্রেক্ষাপটে অপ্রয়োজনীয় হতে পারে: https://en.wikedia.org/wiki/dotted_and_dotless_I । এছাড়াও আরএফসি 1738 এএসসিআইআই ব্যাপ্তির বাইরে অক্ষর ব্যবহারের অনুমতি দিয়েছে শর্ত রয়েছে যে তারা এনকোডযুক্ত থাকলেও একটি চরসেট নির্দিষ্ট না করে। নিজেকে ওয়ার্ল্ড ওয়াইড ওয়েব বলার জন্য এটি মোটামুটি গুরুত্বপূর্ণ। সংবেদনশীল হিসাবে ইউআরএল সংজ্ঞায়িত করা বাগের জন্য অনেক সুযোগ উন্মুক্ত করবে।

5. আপনি যদি কোনও ইউআরআইতে (যেমন একটি ডেটা ইউআরআই ) প্রচুর ডেটা প্যাক করার চেষ্টা করছেন তবে আপনি যদি উচ্চ এবং নিম্নতর ক্ষেত্রে পৃথক হন তবে আপনাকে আরও প্যাক করতে পারেন।

Comments

আমি নিশ্চিত যে ইউআরএলগুলি historতিহাসিকভাবে ASCII এর মধ্যে সীমাবদ্ধ ছিল। সুতরাং আন্তর্জাতিকীকরণের মূল কারণ হওয়ার সম্ভাবনা কম। ইউনিক্সের মামলাটি সংবেদনশীল হওয়ার ইতিহাস, ওটিওএইচ, সম্ভবত একটি বিশাল ভূমিকা পালন করেছে।

— ডারোবার্ট

যদিও কেবলমাত্র ASCII এর একটি উপসেট একটি ইউআরএল থেকে আনঙ্কডবিহীন ব্যবহার করা যেতে পারে আরএফসি 1738 সুনির্দিষ্টভাবে ASCII পরিসরের বাইরের অক্ষরগুলি এনকোডযুক্ত হতে পারে। একটি চরসেট নির্দিষ্ট না করে এটি জানা সম্ভব নয় কোনটি অষ্টেটগুলি ক্ষেত্রে বাদে একই চরিত্রকে উপস্থাপন করে। আপডেট করা হয়েছে।

— উইলিয়াম হেই

পুনরায় # 4: এটি আসলে এর চেয়ে খারাপ। বিন্দুযুক্ত এবং বিন্দুবিহীন আমি আরও সাধারণ নীতির একটি প্রদর্শনী যে, সবকিছু যদি ইউটিএফ -8 (বা অন্য কোনও ইউটিএফ) হয়, আপনি পাঠের অন্তর্গত লোকালটি না জেনে সঠিকভাবে বড় করে বা ছোট হাতের অক্ষর রাখতে পারবেন না। ডিফল্ট লোকালে, একটি মূল লাতিন অক্ষর I একটি ছোট হাতের লাতিন অক্ষরে i ছোট করে তোলে যা তুর্কি ভাষায় ভুল কারণ এটি একটি বিন্দু যুক্ত করে (কোনও "তুর্কি রাজধানী ডটলেস আই" কোড পয়েন্ট নেই; আপনি ASCII কোডটি ব্যবহার করতে চাইছেন পয়েন্ট)। এনকোডিং পার্থক্যগুলিতে ফেলে দিন এবং এটি "সত্যই কঠিন" থেকে "সম্পূর্ণ অবজ্ঞাযোগ্য" তে চলে যায়।

— কেভিন

Answer 5

আমি ব্লগ থেকে একটি ওল্ড নিউ থিং ফর্মের প্রশ্নগুলির কাছে যাওয়ার অভ্যাসটি চুরি করেছি "কেন এমন কিছু ঘটছে?" পাল্টা প্রশ্ন দিয়ে "পৃথিবী কেমন হত, যদি তা না হত?"

বলুন যে আমি কোনও ফোল্ডার থেকে আমার ডকুমেন্ট ফাইলগুলি সেবার জন্য একটি ওয়েব সার্ভার সেট আপ করেছি যাতে আমি যখন অফিসের বাইরে ছিলাম তখন ফোনে সেগুলি পড়তে পারি। এখন আমার নথি ফোল্ডারে, আমার তিনটি ফাইল, আছে todo.txt, ToDo.txtএবং TODO.TXT(আমি জানি, কিন্তু এটা আমার ধারণা করেছিলাম, য়েদিন আমি ফাইল তৈরি)।

এই ফাইলগুলি অ্যাক্সেস করতে আমি কোন ইউআরএল ব্যবহার করতে সক্ষম হতে চাই? আমি তাদের ব্যবহার করে স্বজ্ঞাত উপায়ে অ্যাক্সেস করতে চাই http://www.example.com/docs/filename।

বলুন আমার কাছে একটি স্ক্রিপ্ট রয়েছে যা আমাকে আমার ঠিকানা পুস্তকে একটি পরিচিতি যুক্ত করতে দেয় যা আমি ওয়েবেও করতে পারি। কীভাবে এর পরামিতিগুলি নেওয়া উচিত? আচ্ছা, আমি এটা পছন্দ ব্যবহার করতে চান সেটি: http://www.example.com/addcontact.php?name=Tom McHenry von der O'Reilly। তবে যদি কেস অনুসারে আমার নাম উল্লেখ করার কোনও উপায় না থাকে তবে আমি কীভাবে এটি করব?

ক্যাট এবং ক্যাট, টেক্সট এবং টেক্সট, ক্ষীর এবং ল্যাটেক্সের উইকি পৃষ্ঠাগুলি আমি কীভাবে আলাদা করব? পৃষ্ঠাগুলি ডিসেমবিগ করুন, তবে আমার ধারণা, তবে আমি যা চেয়েছি কেবল তা পেতে পছন্দ করি।

তবে এগুলি যেহেতু ভুল প্রশ্নের উত্তর দিচ্ছে বলে মনে হচ্ছে।

যে প্রশ্নটি আমি আপনাকে সত্যিই জিজ্ঞাসা করেছিলাম তা হ'ল "ওয়েব সার্ভারগুলি কেন 404 কেবলমাত্র একটি কেস পার্থক্যের জন্য, যখন তারা কম্পিউটার হয়, জীবনকে সহজতর করার জন্য ডিজাইন করা হয় এবং তারা কমপক্ষে সর্বাধিক সুস্পষ্ট কেস-প্রকরণের সন্ধান করতে সক্ষম হয় আমি যে ইউআরএল টাইপ করেছি তা কি কাজ করবে? "

যার উত্তর হ'ল কিছু সাইট এটি করেছে (এবং আরও ভাল, তারা অন্যান্য টাইপগুলিও পরীক্ষা করে দেখায়), কেউ এটির জন্য কোনও ওয়েবসাইভারের ডিফল্ট 404 ত্রুটি পৃষ্ঠা পরিবর্তন করা উপযুক্ত বলে মনে করেন নি ... তবে সম্ভবত তাদের উচিত?

Comments

কিছু সাইট কোনও কোয়েরিকে সমস্ত ছোট হাতের বা সামঞ্জস্যপূর্ণ কিছুতে রূপান্তর করতে একধরনের প্রক্রিয়া ব্যবহার করে। একরকম, এটি স্মার্ট।

— ক্লোজটোক

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

— স্যারনিকিটি

@ সিরনিকিটি কেউ কোনও স্তরে অপরিবর্তনীয়তার প্রস্তাব দিচ্ছিল না এবং ওয়েবসারভার ত্রুটি পৃষ্ঠাগুলি আমি কখনও ব্যবহার করেছি এমন প্রতিটি ওয়েবসভারে কনফিগারযোগ্য; কেউ 304 কোড দিয়ে 404 প্রতিস্থাপনের পরামর্শ দিচ্ছিল না, বরং ত্রুটি পৃষ্ঠায় মানব-ক্লিকযোগ্য পরামর্শের লিঙ্কগুলির একটি তালিকা যুক্ত করুন; ডোমেন নামগুলি একটি খুব আলাদা বিষয় এবং বিষয়টি কেস-সংবেদনশীল এবং ভিন্ন সুরক্ষার প্রসঙ্গে; এবং আইআইএস ইতিমধ্যে ইউআরআইয়ের পথ বা ফাইলের নাম অংশে কেস-পার্থক্যটিকে স্বয়ংক্রিয়ভাবে "ঠিক করে" দেয়।

— দেবী মরগান

1996 সাল থেকে, অ্যাপাচি আপনাকে মোড_স্পেলিং দিয়ে এটি করতে দিয়েছে । এটি করা খুব জনপ্রিয় জিনিস বলে মনে হয় না। ইউনিক্স / লিনাক্সের লোকেরা কেস সংবেদনশীলতাটিকে নিয়ম হিসাবে দেখেন, কেস সংবেদনশীলতাটিকে ব্যতিক্রম হিসাবে দেখেন।

— রিইনারপোস্ট

Answer 6

যদিও উপরের উত্তরটি সঠিক এবং ভাল। আমি আরও কিছু পয়েন্ট যুক্ত করতে চাই।

আরও ভালভাবে বুঝতে, ইউনিক্স (লিনাক্স) বনাম উইন্ডোজ সার্ভারের মধ্যে মূল পার্থক্যটি বুঝতে হবে। ইউনিক্স কেস সংবেদনশীল এবং উইন্ডোজ হ'ল নন-কেস সংবেদনশীল ওএস।

এইচটিটিপি প্রোটোকলটি 1990 সালের দিকে বিবর্তিত হয়েছিল বা বাস্তবায়িত হতে শুরু করেছিল। এইচটিটিপি প্রোটোকলটি সিইআরএন ইনস্টিটিউটে কর্মরত প্রকৌশলী দ্বারা ডিজাইন করেছিলেন, বেশিরভাগ দিন বিজ্ঞানী উইন্ডোজ নয় ইউনিক্স মেশিন ব্যবহার করেছিলেন।

বেশিরভাগ বিজ্ঞানীই ইউনিক্সের সাথে পরিচিত ছিলেন, তাই তারা ইউনিক্স স্টাইল ফাইল সিস্টেমের দ্বারা প্রভাবিত হতে পারেন।

উইন্ডোজ সার্ভারটি 2000 এর পরে প্রকাশিত হয়েছিল windows

এটি কারণ হতে পারে।

Comments

"উইন্ডোজ সার্ভার 2000 এর পরে প্রকাশিত হয়েছিল।" উইন্ডোজ এনটি 3.1 দল 1995 সালে 1993 NT তে 3.51 আপনার সাথে সহমত যেত সম্ভবত ছিল যখন NT তে হয়ে শুরু পরিপক্ক এবং যথেষ্ট ব্যবসা-জটিল সার্ভার অ্যাপ্লিকেশনের সমর্থন করার জন্য সুপ্রতিষ্ঠিত।

— একটি সিভিএন

এনটি 3.51 এর উইন 3.1 ইন্টারফেস ছিল। উইন্ডোজ উইন্ডোজ 95 অবধি সত্যই বন্ধ করেনি এবং একই ইন্টারফেসটি পেতে এনটি 4.0 লাগবে।

— থরবজর্ন রাভন অ্যান্ডারসন

মাইকেল Kjörling, একমত। আমাকে এটি পরিবর্তন করতে দিন।

— মণি

@ থরবজরনআরভানএন্ডারসেন সার্ভারের বাজারে এনটি 3.51 যথাযথভাবে সফল হয়েছিল। কনজিউমার / প্রোসুমার মার্কেটে, এনটি লাইনটি গুরুতর ক্র্যাকশন পেতে শুরু করার আগে উইন্ডোজ 2000 (এনটি 5.0) পর্যন্ত লেগেছে।

— একটি সিভিএন

প্রকৃতপক্ষে, কপওউবটি প্রাথমিকভাবে ইউনিক্স-ভিত্তিক সিস্টেমে তৈরি হয়েছিল, যার ক্ষেত্রে কেস-সংবেদনশীল ফাইল সিস্টেম রয়েছে এবং বেশিরভাগ ইউআরএল সরাসরি ফাইল সিস্টেমের ফাইলগুলিতে ম্যাপ করে।

— রিইনারপোস্ট

Answer 7

কীভাবে একজনকে "কেন এটি এইভাবে ডিজাইন করা হয়েছিল?" পড়তে হবে? প্রশ্ন? আপনি কি সিদ্ধান্ত গ্রহণের প্রক্রিয়াটির historতিহাসিকভাবে-সঠিক অ্যাকাউন্টের জন্য জিজ্ঞাসা করছেন, বা আপনি জিজ্ঞাসা করছেন "কেন কেউ এইভাবে ডিজাইন করবেন?"

Historতিহাসিকভাবে সঠিক অ্যাকাউন্ট পাওয়া খুব কমই সম্ভব। কখনও কখনও যখন স্ট্যান্ডার্ড কমিটিগুলিতে সিদ্ধান্ত নেওয়া হয় তখন বিতর্কটি কীভাবে পরিচালিত হয়েছিল তার একটি ডকুমেন্টারি ট্রেইল পাওয়া যায়, তবে ওয়েবের শুরুর দিনগুলিতে কয়েকটি ব্যক্তি তাড়াতাড়ি সিদ্ধান্ত নিয়েছিলেন - এই ক্ষেত্রে সম্ভবত টিমবিএল নিজেই ছিলেন - এবং যুক্তিটি অসম্ভব লিখে রাখা হয়েছে। তবে টিমবিএল স্বীকার করেছে যে তিনি ইউআরএলগুলির নকশায় ভুল করেছেন - দেখুন http://www.dailymail.co.uk/s ज्ञानtech/article 1220286/Sir-Tim-Berners-Lee-admits-forward-slashes-web-adress -mistake.html

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

Comments

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

— রিইনারপোস্ট

Answer 8

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

এটি আসলে কোনও সমস্যা নয় এবং এটি * নিক্স হোস্টগুলিতে মোটামুটি সাধারণ। আপনার পৃষ্ঠাগুলিতে লিখিত সমস্ত লিঙ্ক সঠিক এবং আপনার কোনও সমস্যা হবে না তা নিশ্চিত করুন। এটিকে আরও সহজ করার জন্য, আমি সবসময় আপনার পৃষ্ঠাগুলিকে সমস্ত ছোট ক্ষেত্রে নামকরণের পরামর্শ দিই তবে কোনও লিঙ্ক লেখার সময় আপনার কখনই নামটি ডাবল চেক করার দরকার নেই।

Answer 9

ক্লোসটনোক ওএস সম্পর্কে ঠিক। কিছু ফাইল সিস্টেম একই নামের সাথে বিভিন্ন ফাইল হিসাবে পৃথক কেসিং ব্যবহার করে।

এছাড়াও, কেস-সংবেদনশীল ইউআরএল থাকা (মূল পৃষ্ঠার কোনও বিষয় নেই যা একই পৃষ্ঠায় ইঙ্গিত করে যে বিশাল সংখ্যক ইউআরএল বিপরীতে রয়েছে) এর কি কোনও আসল উদ্দেশ্য / সুবিধা রয়েছে?

হ্যাঁ. অনুলিপি বিষয়বস্তু সমস্যা এড়ানোর জন্য।

আপনার যদি নিম্নলিখিত URL গুলি উদাহরণস্বরূপ থাকে:

http://example.com/page-1
http://example.com/Page-1
http://example.com/paGe-1
http://example.com/PAGE-1
http://example.com/pAGE-1

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

আপনি যদি সেই পরিস্থিতিতে থাকেন তবে আমি যা করার পরামর্শ দিচ্ছি তা হ'ল সমস্ত নিম্ন-কেস URL টি ব্যবহার করা, তারপরে URL এর কমপক্ষে একটি মূলধনযুক্ত অক্ষর সহ ইউআরএলগুলি লোয়ার কেস সংস্করণে পুনর্নির্দেশ করুন। সুতরাং উপরের ইউআরএলগুলির তালিকায়, সমস্ত ইউআরএলকে প্রথম URL এ পুনঃনির্দেশ করুন।

Comments

"হ্যাঁ। অনুলিপি বিষয়বস্তু সমস্যা এড়ানোর জন্য।" - তবে মনে হবে এর বিপরীতটি কি সত্য? ইউআরএলগুলি কেস-সংবেদনশীল হতে পারে (এবং এটিই সার্চ ইঞ্জিনগুলি তাদের সাথে আচরণ করে) আপনার উল্লিখিত সদৃশ সামগ্রীগুলির কারণ ঘটায় । যদি ইউআরএলগুলি সর্বজনীনভাবে কেস-সংবেদনশীল হয় তবে ভিন্ন ভিন্ন ক্ষেত্রে কোনও সদৃশ সামগ্রী থাকতে হবে না। হিসাবে একইpage-1 হবে । PAGE-1

— মিঃ হোয়াইট

আমি মনে করি একটি দুর্বল সার্ভার কনফিগারেশন হ'ল এটি যখন কেসিংয়ের বিষয়টি আসে তখন নকল সামগ্রী তৈরি করতে পারে। উদাহরণস্বরূপ, RewriteRule ^request-uri$ /targetscript.php [NC].htaccess এ সঞ্চিত বিবৃতিটি মিলবে http://example.com/request-uriএবং http://example.com/ReQuEsT-Uriকারণ এটি [NC]নির্দেশ করে যে সেই নিয়মিত অভিব্যক্তিটি মূল্যায়ন করার সময় কেসিংয়ের কোনও বিষয় নেই।

— মাইক

Answer 10

কেস সংবেদনশীলতার মান আছে।

যদি 26 টি অক্ষর থাকে তবে তাদের প্রত্যেকেরই মূলধনের ক্ষমতা সহ, এটি 52 টি অক্ষর।

৪ টি বর্ণের *৩ * 52২ * ৫২ * ৫২ টি সমন্বয়, 11৩১66১ equal সংমিশ্রণের সমতুল্য has

আপনি যদি অক্ষরগুলি মূলধন করতে না পারেন তবে সংমিশ্রণের পরিমাণ 26 * 26 * 26 * 26 = 456976

26 টির চেয়ে 52 টি চরিত্রের জন্য এটি 14 গুণ বেশি সংমিশ্রণে রয়েছে So সুতরাং তথ্য সংরক্ষণের জন্য, ইউআরএলগুলি সংক্ষিপ্ত হতে পারে এবং কম ডেটা স্থানান্তরিত নেটওয়ার্কগুলিতে আরও তথ্য পাস করা যেতে পারে।

এই জন্য আপনি ইউটিউব https://www.youtube.com/watch?v=xXxxXxxX এর মতো ইউআরএল ব্যবহার করে দেখতে পান