क्या हर वेब अनुरोध ब्राउज़र कुकीज़ भेजता है?

198

क्या प्रत्येक वेब अनुरोध ब्राउज़र की कुकी भेजता है?

मैं पृष्ठ दृश्य नहीं बोल रहा हूं, लेकिन एक छवि, .jsफ़ाइल, आदि के लिए एक अनुरोध

अद्यतन यदि किसी वेब पेज में 50 तत्व हैं, तो वह 50 अनुरोध हैं। यह प्रत्येक अनुरोध के लिए एक ही कुकी क्यों भेजेगा, यह कैश नहीं करता है या यह पहले से ही जानता है?

cookies

— mrblah
स्रोत

8

मुझे नहीं लगता कि इस स्थिति में कैशिंग संभव है - हम ब्राउज़र को सर्वर को डेटा भेजने के बारे में बात कर रहे हैं, न कि दूसरे तरीके से। आप यह सुनिश्चित करने के लिए नहीं कह सकते हैं कि उपयोगकर्ता ने बहुत सारे कारणों से एक अनुरोध भेजने के बाद सर्वर "पहले से ही है"। बड़ी संख्या में सर्वर हो सकते हैं जो एक दूसरे से बात नहीं करते हैं; सर्वर पिछले अनुरोधों के बारे में कुछ भी याद रखने के लिए (या कमरा हो सकता है) नहीं चाहता - HTTP को स्टेटलेस माना जाता है; हर अनुरोध बाकी के लिए स्वतंत्र होना चाहिए। इस कारण से, प्रमाणीकरण क्रेडेंशियल्स की तरह कुकीज़ को हर अनुरोध के साथ भेजा जाना चाहिए।

— इयान क्लेलैंड

मैंने उल्लेख किया कि कैशिंग मेरे जवाब के अपडेट में कुकीज़ के लिए कोई मतलब नहीं है: stackoverflow.com/a/1336178/102960

— igorsantos07

199

हां, जब तक अनुरोध किया गया URL कुकी में परिभाषित एक ही डोमेन और पथ के भीतर है (और अन्य सभी प्रतिबंध - सुरक्षित, httponly, समाप्त नहीं हुआ, आदि), तब कुकी को प्रत्येक अनुरोध के लिए भेजा जाएगा।

— इयान क्लीलैंड
स्रोत

103

यह, संयोग से, यही कारण है कि Google पृष्ठ गति या याहू के YSlow जैसे पृष्ठ गति उपकरण एक अलग, कुकी-मुक्त डोमेन से स्थिर सामग्री परोसने की सलाह देते हैं।

— ceejayoz 17

मैंने अपने अद्यतन उत्तर में एक अलग डोमेन से सामग्री परोसने के बारे में उल्लेख किया: stackoverflow.com/a/1336178/102960

— igorsantos07

क्या यह सच है कि साइट 1 से साइट 2 पर HTTP पुनर्निर्देशन होने पर ब्राउज़र साइट 2 कुकी भेजता है?

— जैजिस्ट ऑक्ट

92

जैसा कि दूसरों ने कहा है, अगर कुकी की मेजबानी, पथ, आदि प्रतिबंधों को पूरा किया जाता है, तो इसे 50 बार भेजा जाएगा।

लेकिन आपने यह भी पूछा कि क्यों: क्योंकि कुकीज़ एक HTTP सुविधा है, और HTTP स्टेटलेस है। HTTP को अनुरोध के बीच किसी भी राज्य को संग्रहीत करने वाले सर्वर के बिना काम करने के लिए डिज़ाइन किया गया है।

वास्तव में, सर्वर के पास यह पहचानने का ठोस तरीका नहीं है कि कौन सा उपयोगकर्ता किसी दिए गए अनुरोध को भेज रहा है; एक वेब प्रॉक्सी (और इस तरह आईपी एड्रेस) के पीछे एक हजार उपयोगकर्ता हो सकते हैं। यदि कुकीज़ को हर अनुरोध नहीं भेजा जाता है, तो सर्वर के पास यह जानने का कोई तरीका नहीं होगा कि कौन सा उपयोगकर्ता जो भी संसाधन का अनुरोध कर रहा है।

अंत में, ब्राउज़र को कोई सुराग नहीं है कि सर्वर को कुकीज़ की आवश्यकता है या नहीं, यह सिर्फ जानता है कि सर्वर ने foo.com को किसी भी अनुरोध के लिए कुकी भेजने का निर्देश दिया है, इसलिए ऐसा करता है। कभी-कभी छवियों को उनकी आवश्यकता होती है (उदाहरण के लिए, डायनामिक रूप से उत्पन्न प्रति उपयोगकर्ता), कभी-कभी नहीं, लेकिन ब्राउज़र बता नहीं सकता।

— derobert
स्रोत

1

क्या यह HTTP 1.1 के साथ सच है, जो एक बहुसंकेतन योजना है? यानी, अनुरोधों को एक एकल टीसीपी कनेक्शन में बांधा गया है। बेशक, हर अनुरोध संलग्न कुकी की एक प्रति के साथ प्राप्त होता है। लेकिन अगर चिंता बहुत हद तक ट्रांसमिशन डुप्लिकेट है, तो HTTP 1.1 अनुकूलन की स्थिति में है। हालांकि मुझे नहीं पता कि यह वास्तव में है ...

— क्रिस नू

1

फिर मुद्दा यह हो जाता है कि "ब्राउज़र ने कुकीज़ को संलग्न करने का अनुरोध किया था?" सर्वर कुकी के साथ नीति निर्धारित करता है, यह तय करने के लिए कि कौन से डोमेन और कौन से URL पथ हैं, कुकी को वापस भेजा जाना चाहिए, लेकिन फिर वह इसे भूल जाता है। आपको यह निर्दिष्ट करने के लिए एक तरीके की आवश्यकता होगी कि कनेक्शन में कुछ अनुरोधों में कुकी थी, और अन्य नहीं थी। यह निश्चित रूप से HTTP / 1.1 में मौजूद नहीं है, सिवाय उनके प्रत्येक अनुरोध में स्पष्ट रूप से शामिल करने से। ईमानदारी से, बैंडविड्थ को कम करने के लिए एक बेहतर (मानकों के अनुकूल) समाधान क्लाइंट-साइड गज़िप सामग्री-एन्कोडिंग होगा, लेकिन कोई भी अभी तक समर्थन नहीं करता है।

— इयान क्लेलैंड

1

@ इयान क्लेलैंड: क्लाइंट को पहला संदेश भेजना होता है, इसलिए यह नहीं पता होता है कि सर्वर एक्सेप्ट-एन्कोडिंग के लिए क्या भेजेगा (उस क्षेत्र को भेजने के लिए सर्वर, HTTP / 1.1 §14.3 इसका अनुरोध हैडर कहता है)। और समस्या यह है कि यह एक ही सर्वर पर भी URL से भिन्न हो सकता है, और समय के साथ बदल सकता है, इसलिए यह काम करना गैर-तुच्छ होगा।

— derobert

1

@ क्रिस: नहीं, कीपैलिव सिर्फ टीसीपी कनेक्शन सेटअप / टेडडाउन ओवरहेड बचाता है, बस। हर अनुरोध के लिए पूर्ण हेडर अभी भी भेजे जाते हैं। हालाँकि, पाइपलाइनिंग (प्रतिक्रिया के लिए कई अनुरोध w / o भेजना) बहुत मदद कर सकता है। HTTP / 1.1 §8.1 विवरण देता है।

— derobert

21

हाँ। प्रत्येक अनुरोध कुकीज़ को भेजता है जो एक ही डोमेन से संबंधित हैं। वे HTTP के रूप में कैश नहीं किए जाते हैं, इसका अर्थ यह है कि सर्वर के लिए हर अनुरोध पर्याप्त होना चाहिए कि वह क्या कर सकता है। मान लें कि आपके पास ऐसी छवियां हैं जो केवल कुछ उपयोगकर्ताओं द्वारा ही सुलभ हैं; आपको उन 50 अनुरोधों में से हर एक के साथ अपनी ऑर्टिकल कुकी भेजनी होगी , ताकि सर्वर को पता चले कि यह आपके और किसी और का नहीं है, या मेहमान, जो इसे मिल रहा है।

यह कहते हुए कि, कुकीज़ को अन्य प्रतिक्रियाओं में उल्लिखित अन्य प्रतिबंधों जैसे HTTPS सेटिंग, पथ या डोमेन पर नहीं भेजा जा सकता है। विशेष रूप से वहाँ, नोटिस करने के लिए एक महत्वपूर्ण बात: कुकीज़ डोमेन के बीच साझा नहीं की जाती हैं। यह स्थिर फ़ाइलों के लिए HTTP कॉल के आकार को कम करने में मदद करता है, जैसे कि आपके द्वारा उल्लिखित चित्र और स्क्रिप्ट।
उदाहरण: आपके पास 4 कुकीज़ हैं www.stackoverflow.com; यदि आप एक अनुरोध करते हैं www.stackoverflow.com/images/logo.png, तो उन सभी 4 कुकीज़ को भेजा जाएगा।
हालाँकि, यदि आप अनुरोध करते हैं stackoverflow.com/images/logo.png(उपडोमेन परिवर्तन पर ध्यान दें) या images.stackoverflow.com/logo.png, वे 4 कुकीज़ मौजूद नहीं होंगी - लेकिन शायद इन डोमेन से संबंधित हैं।

उदाहरण के लिए, इस StackOverflow Blog Post पर आप कुकीज़ और अनुरोधों के बारे में अधिक पढ़ सकते हैं ।

— igorsantos07
स्रोत

10

नहीं, हर अनुरोध कुकीज़ नहीं भेजता है। यह कुकी कॉन्फ़िगरेशन और क्लाइंट-सर्वर कनेक्शन पर निर्भर करता है।

उदाहरण के लिए, यदि आपके कुकी का secureविकल्प सेट है, trueतो इसे सुरक्षित HTTPS कनेक्शन पर प्रेषित किया जाना चाहिए। इसका मतलब है कि जब आप उस वेबसाइट को HTTP प्रोटोकॉल के साथ देखते हैं, तो ये कुकीज़ ब्राउज़रों द्वारा नहीं भेजी जाएंगी क्योंकि सुरक्षित ध्वज सत्य है।

— इमान सेदिघी
स्रोत

7

कुकी के पास एक "पथ" संपत्ति है। यदि "पथ = /", उत्तर हां है।

— neoedmund
स्रोत

हां, आप अपनी साइट / ऐप की संरचना को इस तरह से व्यवस्थित कर सकते हैं कि कुकीज़ की आवश्यकता वाले सभी URL wthin /app/या इस तरह के हैं - यह निरर्थक ओवरहेड को खत्म करने के लिए अलग-अलग उप-डोमेन की आवश्यकता के बिना पोर्टेबिलिटी बनाए रखेगा। या आप एक शुरुआत के लिए अब बेकार गूगल विश्लेषिकी खाई कर सकते हैं। मैंने कुकी हेडर को इतने लंबे समय तक देखा है मुझे आश्चर्य है कि क्या मेरी दादी उन्हें बुनाई कर रही थी।

— जेक

7

3 साल हो गए

एक और कारण है कि एक ब्राउज़र कुकीज़ क्यों नहीं भेजेगा। आप crossOriginअपने <script>टैग में एक विशेषता और मूल्य जोड़ सकते हैं "anonymous"। इससे कुकीज़ को गंतव्य सर्वर पर भेजा जा सकेगा। 99.9% समय, आपके javascripts स्थिर फाइलें हैं, और आप अनुरोध के कुकीज़ के आधार पर उस js कोड को उत्पन्न नहीं करते हैं। यदि आपके पास कुकीज़ का 1KB है, और आपके पेज पर 200 संसाधन हैं, तो आपका उपयोगकर्ता 200KB अपलोड कर रहा है, और हो सकता है कि 3G पर कुछ समय लगे और परिणाम पृष्ठ पर शून्य प्रभाव हो। HTML विशेषता पर जाएं : संदर्भ के लिए क्रॉसोरिगिन ।

— gilm
स्रोत

कृपया समझाएँ।

— जेक

4

@ जेक आप अपने <script> टैग, और "अनाम" के लिए एक क्रॉसऑर्गिन विशेषता जोड़ सकते हैं। इससे कुकीज़ को गंतव्य सर्वर पर भेजा जा सकेगा। 99.9% समय, आपके javascripts स्थिर फाइलें हैं, और आप अनुरोध के कुकीज़ के आधार पर उस js कोड को उत्पन्न नहीं करते हैं। यदि आपके पास कुकीज़ का 1KB है, और आपके पेज पर 200 संसाधन हैं, तो आपका उपयोगकर्ता 200KB अपलोड कर रहा है, और हो सकता है कि 3G पर कुछ समय लगे और परिणाम पृष्ठ पर शून्य प्रभाव हो। यात्रा developer.mozilla.org/en-US/docs/Web/HTML/... संदर्भ के लिए।

— गिल्म

4

मुझे पता है कि यह एक पुराना धागा है। लेकिन मैंने अभी देखा है कि यदि आप एक अनुगामी बिंदु जोड़ते हैं तो अधिकांश ब्राउज़र एक डोमेन के लिए कुकीज़ नहीं भेजेंगे। उदाहरण के लिए http://example.com.कुकीज़ के लिए सेट प्राप्त नहीं होगा .example.com। दूसरी ओर अपाचे उन्हें एक ही मेजबान के रूप में मानते हैं। मुझे यह उपयोगी लगता है कि क्रॉस डोमेन ट्रैकिंग को मैं शामिल बाहरी संसाधनों के लिए अधिक कठिन बना सकता हूं, लेकिन आप इसे प्रदर्शन कारणों से भी उपयोग कर सकते हैं। इस ब्रेक को httpsप्रमाणपत्रों की मान्यता पर ध्यान दें । मैंने ब्राउज़रों और अपने उपकरणों का उपयोग करके कुछ परीक्षण चलाए हैं। हैक सफारी (मोबाइल और डेस्कटॉप) को छोड़कर लगभग सभी ब्राउज़रों पर काम करता है, जिसमें अनुरोध में कुकीज़ शामिल होंगे।

— Gellweiler
स्रोत

यह "मेरे द्वारा शामिल किए गए बाहरी संसाधनों के लिए क्रॉस डोमेन ट्रैकिंग को अधिक कठिन कैसे बनाता है"? क्या आप फ़र्सबुक लाइक और ऐसे विजेट्स के बारे में बात कर रहे हैं - जो हम जानते हैं कि गलती से स्टिल-लॉग-इन यूजर्स का ट्रैक ब्राउज़िंग?

— जेक

हाँ। यह अधिक कठिन बना देगा, क्योंकि अधिकांश ब्राउज़र कुकीज़ को साथ नहीं भेजेंगे। इसलिए यदि आप उदाहरण के लिए google.com से कुछ शामिल कर रहे हैं और आप Google में लॉग इन हैं, तो Google दोनों अनुरोधों को लिंक नहीं कर सकता है। यह कठिन गारंटी नहीं है, कुछ ब्राउज़रों ने कुकीज़ को वैसे भी भेजा था और उपयोगकर्ताओं की पहचान करने के लिए कम विश्वसनीय और कम उपयोग किए जाने वाले तरीके हैं (जैसे आईपी-पते) जो अभी भी काम करेंगे। सबसे बड़ी कमी यह है कि आप HTTPS का उपयोग नहीं कर सकते हैं, जो आज इसे बेकार बनाता है।

— गेल्वेइलर

0

संक्षिप्त उत्तर हां है। नीचे की पंक्तियाँ JS प्रलेखन से हैं

एक बार सामान्य क्लाइंट-साइड स्टोरेज के लिए कुकीज़ का उपयोग किया गया था। जबकि यह वैध था जब वे ग्राहक पर डेटा संग्रहीत करने का एकमात्र तरीका थे, अब आधुनिक भंडारण एपीआई का उपयोग करने की सिफारिश की गई है। कुकीज़ हर अनुरोध के साथ भेजे जाते हैं, इसलिए वे प्रदर्शन को खराब कर सकते हैं (विशेषकर मोबाइल डेटा कनेक्शन के लिए)।

— यशविन मुंसदवाला
स्रोत