প্রতিটি ওয়েব অনুরোধ ব্রাউজার কুকিজ পাঠায়?

Question

প্রতিটি ওয়েব অনুরোধ ব্রাউজারের কুকিজ পাঠায়?

আমি পৃষ্ঠাগুলির দর্শনগুলি বলছি না, তবে একটি চিত্র, .jsফাইল ইত্যাদির জন্য অনুরোধ করছি

আপডেট যদি কোনও ওয়েব পৃষ্ঠায় 50 টি উপাদান থাকে তবে তা 50 টি অনুরোধ। কেন এটি প্রতিটি অনুরোধের জন্য একই কুকি (গুলি) প্রেরণ করবে, এটি ক্যাশে দেয় না বা এটি ইতিমধ্যে এটি জানে না?

Comments

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

— ইয়ান ক্লেল্যান্ড

আমি উল্লেখ কেন ক্যাশে আমার উত্তর একটি আপডেট কুকিজ জন্য অর্থে দেখা যায় না: stackoverflow.com/a/1336178/102960

— igorsantos07

Answer 1

হ্যাঁ, যতক্ষণ না অনুরোধ করা URL টি একই ডোমেনের মধ্যে এবং কুকিতে সংজ্ঞায়িত পথের মধ্যে থাকে (এবং অন্যান্য সমস্ত বিধিনিষেধ - সুরক্ষিত, কেবলমাত্র, মেয়াদোত্তীর্ণ না হওয়া ইত্যাদি) হোল্ড থাকে, ততক্ষণ কুকি প্রতিটি অনুরোধের জন্য প্রেরণ করা হবে।

Comments

ঘটনাক্রমে, গুগল পেজ গতি বা ইয়াহুর ওয়াইস্কোর মতো পৃষ্ঠা গতির সরঞ্জামগুলি পৃথক, কুকিবিহীন ডোমেন থেকে স্ট্যাটিক সামগ্রী সরবরাহ করার পরামর্শ দেয়।

— সেজেজোজ

: আমি বিষয়বস্তু আমার আপডেট উত্তরে একটি পৃথক ডোমেন থেকে সেবা করার বিষয়ে উল্লেখ stackoverflow.com/a/1336178/102960

— igorsantos07

সাইট 1 থেকে সাইট 2 এ কোনও HTTP পুনঃনির্দেশ থাকলে ব্রাউজারটি সাইট 2 কুকিগুলি প্রেরণ করে এটি কি সত্য?

— জিজিভিস্ট

Answer 2

অন্যরা যেমন বলেছে, কুকির হোস্ট, পথ, ইত্যাদি নিষেধাজ্ঞাগুলি মেটানো হয়, এটি 50 বার পাঠানো হবে।

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

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

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

Comments

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

— ক্রিস নো

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

— ইয়ান ক্লেল্যান্ড 21

@ ইয়ান ক্লেল্যান্ড: ক্লায়েন্টকে প্রথম বার্তাটি প্রেরণ করতে হবে, সুতরাং এটি জানে না যে সার্ভারটি গ্রহণ-এনকোডিংয়ের জন্য কী প্রেরণ করবে (এই ক্ষেত্রটি প্রেরণের জন্য সার্ভার ছিল, এইচটিটিপি / ১.১-১৪.৩ এটির অনুরোধ শিরোনাম বলেছে)। এবং সমস্যাটি হ'ল এটি একই সার্ভারেও ইউআরএল অনুসারে পরিবর্তিত হতে পারে এবং সময়ের সাথে সাথে পরিবর্তিত হতে পারে, তাই এটিকে কাজ করা অ-তুচ্ছ হবে।

— ডারউবার্ট

@ ক্রিস: না, রক্ষণশীল কেবলমাত্র টিসিপি সংযোগ সেটআপ / টিয়ারডাউন ওভারহেড সংরক্ষণ করে, এগুলিই। সম্পূর্ণ শিরোনামগুলি এখনও প্রতিটি অনুরোধের জন্য প্রেরণ করা হয়। তবে পাইপলাইনিং (প্রতিক্রিয়াটির জন্য অপেক্ষা করা একাধিক অনুরোধ প্রেরণ) প্রেরণা সাহায্য করতে পারে। HTTP / 1.1 1.8.1 বিশদ দেয়।

— ডার্বোবার্ট

Answer 3

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

এই কথাটি বলার পরে, এইচটিটিপিএস সেটিং, পাথ বা ডোমেনের মতো অন্যান্য প্রতিক্রিয়াগুলিতে উল্লিখিত অন্যান্য বিধিনিষেধের কারণে কুকিজ পাঠানো হবে না। বিশেষত সেখানে, একটি গুরুত্বপূর্ণ বিষয় লক্ষ্য করুন: কুকিগুলি ডোমেনগুলির মধ্যে ভাগ করা হয় না। এটি আপনার উল্লিখিত চিত্র এবং স্ক্রিপ্টগুলির মতো স্থির ফাইলগুলির জন্য এইচটিটিপি কলগুলির আকার হ্রাস করতে সহায়তা করে।
উদাহরণ: আপনার কাছে 4 টি কুকিজ রয়েছে www.stackoverflow.com; আপনি যদি অনুরোধ করেন তবে www.stackoverflow.com/images/logo.pngএই 4 টি কুকি পাঠানো হবে।
তবে, আপনি যদি অনুরোধ করেন stackoverflow.com/images/logo.png(সাবডোমেন পরিবর্তনটি লক্ষ্য করুন) বা images.stackoverflow.com/logo.png, সেই 4 টি কুকিজ উপস্থিত থাকবে না - তবে সম্ভবত এই ডোমেনগুলির সাথে সম্পর্কিত তারা তা করবে।

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

Answer 4

প্রতিটি অনুরোধ কুকি পাঠায় না। এটি কুকি কনফিগারেশন এবং ক্লায়েন্ট-সার্ভার সংযোগের উপর নির্ভর করে।

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

Answer 5

কুকির একটি "পথ" সম্পত্তি রয়েছে। যদি "পথ = /" হয় তবে উত্তরটি হ্যাঁ।

Comments

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

— জেক

Answer 6

Years বছর কেটে গেছে

ব্রাউজার কুকিজ না পাঠানোর আরও একটি কারণ রয়েছে। আপনি crossOriginআপনার <script>ট্যাগে একটি গুণাবলী এবং মানটি যুক্ত করতে পারেন "anonymous"। এটি কুকিগুলি গন্তব্য সার্ভারে প্রেরণে বাধা দেবে। 99.9% সময়, আপনার জাভাস্ক্রিপ্টগুলি স্থির ফাইল এবং আপনি অনুরোধের কুকিগুলির উপর ভিত্তি করে সেই জেএস কোডটি তৈরি করেন না। আপনার যদি 1KB কুকিজ রয়েছে এবং আপনার পৃষ্ঠায় 200 টি সংস্থান রয়েছে, তবে আপনার ব্যবহারকারী 200KB আপলোড করছেন এবং এটি 3G এ কিছুটা সময় নিতে পারে এবং ফলাফলের পৃষ্ঠায় শূন্য প্রভাব ফেলতে পারে। পরিদর্শন এইচটিএমএল অ্যাট্রিবিউট: crossorigin রেফারেন্সের জন্য।

Comments

দয়া করে ব্যাখ্যা করুন.

— জেক

@ জ্যাক আপনি আপনার <স্ক্রিপ্ট> ট্যাগটিতে একটি ক্রসআরগিন বৈশিষ্ট্য এবং "বেনামে" মান যোগ করতে পারেন ake এটি কুকিগুলি গন্তব্য সার্ভারে প্রেরণে বাধা দেবে। 99.9% সময়, আপনার জাভাস্ক্রিপ্টগুলি স্থির ফাইল এবং আপনি অনুরোধের কুকিগুলির উপর ভিত্তি করে সেই জেএস কোডটি তৈরি করেন না। আপনার যদি 1KB কুকিজ রয়েছে এবং আপনার পৃষ্ঠায় 200 টি সংস্থান রয়েছে, তবে আপনার ব্যবহারকারী 200KB আপলোড করছেন এবং এটি 3G এ কিছুটা সময় নিতে পারে এবং ফলাফলের পৃষ্ঠায় শূন্য প্রভাব ফেলতে পারে। রেফারেন্সের জন্য ডেভেলপার.মোজিলা.আর.ইন- মার্কিন / ডকস / ওয়েব / এইচটিএমএল/… দেখুন Visit

— গিলম

Answer 7

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

Comments

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

— জেক

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

— জেলউইয়েল

Answer 8

সংক্ষিপ্ত উত্তর হ্যাঁ। নীচের লাইনগুলি জেএস ডকুমেন্টেশন থেকে

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