ทุกคำขอของเว็บส่งคุกกี้เบราว์เซอร์หรือไม่

199

คำขอเว็บทุกครั้งส่งคุกกี้ของเบราว์เซอร์หรือไม่

ฉันไม่ได้พูดถึงการดูหน้าเว็บ แต่ขอรูปภาพ.jsไฟล์ ฯลฯ

อัปเดต หากหน้าเว็บมีองค์ประกอบ 50 รายการนั่นคือคำขอ 50 รายการ เหตุใดจึงส่งคุกกี้ SAME สำหรับแต่ละคำขอไม่ใช่แคชหรือรู้ว่ามีอยู่แล้ว

cookies

— mrblah
แหล่งที่มา

8

ฉันไม่คิดว่าการแคชเป็นไปได้ในสถานการณ์นี้ - เรากำลังพูดถึงเบราว์เซอร์ที่ส่งข้อมูลไปยังเซิร์ฟเวอร์ไม่ใช่วิธีอื่น คุณไม่สามารถบอกได้อย่างแน่นอนว่าเซิร์ฟเวอร์ "มีอยู่แล้ว" หลังจากผู้ใช้ส่งคำขอหนึ่งครั้งด้วยเหตุผลหลายประการ อาจมีเซิร์ฟเวอร์จำนวนมากที่ไม่พูดคุยกัน เซิร์ฟเวอร์อาจไม่ต้องการ (หรือมีที่ว่าง) ที่จะจดจำทุกสิ่งเกี่ยวกับคำขอก่อนหน้า - HTTP ควรจะเป็นแบบไร้รัฐ ทุกคำขอควรเป็นอิสระจากส่วนที่เหลือ ด้วยเหตุนี้จึงต้องส่งคุกกี้เช่นข้อมูลรับรองการตรวจสอบสิทธิ์ทุกคำขอ

— Ian Clelland

ฉันกล่าวถึงสาเหตุที่แคชไม่สมเหตุสมผลสำหรับคุกกี้ในการอัปเดตคำตอบของฉัน: stackoverflow.com/a/1336178/102960

— igorsantos07

199

ใช่ตราบใดที่ URL ที่ร้องขอนั้นอยู่ในโดเมนเดียวกันและเส้นทางที่กำหนดไว้ในคุกกี้ (และข้อ จำกัด อื่น ๆ ทั้งหมด - ปลอดภัย, แบบ httponly, ไม่หมดอายุและอื่น ๆ ) จะเก็บคุกกี้นั้นไว้สำหรับทุกคำขอ

— Ian Clelland
แหล่งที่มา

103

นี่คือเหตุผลว่าทำไมเครื่องมือของหน้าความเร็วเช่น Google Page Speed หรือ YSlow ของ Yahoo แนะนำให้แสดงเนื้อหาแบบคงที่จากโดเมนที่แยกต่างหากและไม่มีคุกกี้

— ceejayoz

ฉันพูดถึงเกี่ยวกับการให้บริการเนื้อหาจากโดเมนแยกต่างหากในคำตอบที่อัปเดตของฉัน: stackoverflow.com/a/1336178/102960

— igorsantos07

เป็นจริงหรือไม่ที่เบราว์เซอร์ส่งคุกกี้ Site2 เมื่อมีการเปลี่ยนเส้นทาง HTTP จาก Site1 ไปยัง Site2

— Zeigeist

92

ดังที่คนอื่น ๆ กล่าวไว้ว่าหากเป็นไปตามข้อ จำกัด ของโฮสต์เส้นทางและอื่น ๆ คุกกี้จะถูกส่งไป 50 ครั้ง

แต่คุณยังถามด้วยว่าทำไม: เพราะคุกกี้เป็นคุณสมบัติ HTTP และ HTTP นั้นไร้สัญชาติ HTTP ถูกออกแบบมาให้ทำงานโดยไม่มีเซิร์ฟเวอร์ที่จัดเก็บสถานะใด ๆ ระหว่างคำขอ

ในความเป็นจริงเซิร์ฟเวอร์ไม่มีวิธีที่ชัดเจนในการรับรู้ว่าผู้ใช้รายใดที่ส่งคำขอที่กำหนด อาจมีผู้ใช้หนึ่งพันคนที่อยู่เบื้องหลังเว็บพรอกซีเดียว (และที่อยู่ IP) หากไม่ได้ส่งคุกกี้ทุกคำขอเซิร์ฟเวอร์จะไม่มีทางรู้ว่าผู้ใช้รายใดร้องขอทรัพยากรใด

ในที่สุดเบราว์เซอร์ไม่มีเงื่อนงำหากเซิร์ฟเวอร์ต้องการคุกกี้หรือไม่มันเพิ่งรู้ว่าเซิร์ฟเวอร์สั่งให้ส่งคุกกี้สำหรับคำขอใด ๆ ไปยัง foo.com ดังนั้นจึงเป็นเช่นนั้น บางครั้งภาพต้องการพวกเขา (เช่นสร้างต่อผู้ใช้แบบไดนามิก) บางครั้งไม่ แต่เบราว์เซอร์ไม่สามารถบอกได้

— derobert
แหล่งที่มา

1

สิ่งนี้เป็นจริงกับ HTTP 1.1 ซึ่งเป็นรูปแบบมัลติเพล็กซ์หรือไม่? นั่นคือการร้องขอจะรวมอยู่ในการเชื่อมต่อ TCP เดียว แน่นอนว่าทุกคำขอจะได้รับพร้อมแนบสำเนาคุกกี้ แต่หากข้อกังวลคือการทำซ้ำการส่งข้อมูลจำนวนมาก HTTP 1.1 จะอยู่ในตำแหน่งที่เหมาะสมที่สุด แต่ผมไม่ทราบว่ามันไม่จริง ...

— คริส Noe

1

จากนั้นปัญหาจะกลายเป็น "เบราว์เซอร์ใดที่ต้องการแนบคุกกี้ไปหรือไม่" เซิร์ฟเวอร์กำหนดนโยบายด้วยคุกกี้เพื่อตัดสินใจว่าโดเมนใดและเส้นทาง URL ใดควรส่งคุกกี้กลับไปที่ แต่จะลืมมันไป คุณต้องการวิธีระบุว่าคำขอบางอย่างในการเชื่อมต่อนั้นมีคุกกี้และอื่น ๆ ไม่ได้ทำ แน่นอนว่าไม่มีอยู่ใน HTTP / 1.1 ยกเว้นรวมไว้อย่างชัดเจนในทุกคำขอ สุจริตโซลูชั่นที่ดีกว่า (เข้ากันได้กับมาตรฐาน) สำหรับการลดแบนด์วิดธ์จะเป็นการเข้ารหัสเนื้อหา gzip ฝั่งไคลเอ็นต์ แต่ยังไม่มีใครสนับสนุนเลย

— Ian Clelland

1

@Ian Clelland: ไคลเอ็นต์ต้องส่งข้อความแรกดังนั้นจึงไม่ทราบว่าเซิร์ฟเวอร์จะส่งอะไรให้ยอมรับการเข้ารหัส (เป็นเซิร์ฟเวอร์ที่จะส่งฟิลด์นั้น HTTP / 1.1 §14.3ระบุว่าเป็นส่วนหัวของคำขอ) และปัญหาก็คือมันอาจแตกต่างกันไปตาม URL แม้กระทั่งบนเซิร์ฟเวอร์เดียวกันและสามารถเปลี่ยนแปลงได้ตลอดเวลาดังนั้นการทำให้มันใช้งานได้ไม่ยุ่งยาก

— Derobert

1

@Chris: ไม่ keepalive เพียงบันทึกการตั้งค่าการเชื่อมต่อ TCP / ค่าใช้จ่ายการฉีกขาดนั่นคือทั้งหมดที่ ส่วนหัวแบบเต็มยังคงถูกส่งสำหรับทุกคำขอ อย่างไรก็ตามการส่งไปป์ไลน์ (การส่งหลายคำขอโดยไม่มีการรอการตอบกลับ) สามารถช่วยได้อย่างมาก 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 บล็อกโพสต์

— igorsantos07
แหล่งที่มา

10

ไม่ทุกคำขอส่งคุกกี้ ขึ้นอยู่กับการกำหนดค่าคุกกี้และการเชื่อมต่อไคลเอนต์ - เซิร์ฟเวอร์

ตัวอย่างเช่นหากsecureตั้งค่าตัวเลือกคุกกี้ของคุณtrueจะต้องส่งผ่านการเชื่อมต่อ HTTPS ที่ปลอดภัย หมายถึงเมื่อคุณเห็นเว็บไซต์ที่มีโปรโตคอล HTTP แล้วคุกกี้เหล่านี้จะไม่ถูกส่งโดยเบราว์เซอร์เนื่องจากการตั้งค่าความปลอดภัยเป็นจริง

— Iman Sedighi
แหล่งที่มา

7

คุกกี้มีคุณสมบัติ "เส้นทาง" หาก "path = /" คำตอบคือใช่

— neoedmund
แหล่งที่มา

ใช่คุณสามารถสร้างโครงสร้างเว็บไซต์ / แอปของคุณเพื่อให้ URL ทั้งหมดที่ต้องการคุกกี้นั้นอยู่ในสถานะที่ไม่เหมือนใคร/app/- มันจะรักษาความสะดวกในการพกพาโดยไม่ต้องใช้โดเมนย่อยแยกต่างหากเพื่อกำจัดค่าใช้จ่ายซ้ำซ้อน หรือคุณอาจเลือกใช้ Google Analytics ที่ไร้ประโยชน์ในตอนนี้สำหรับการเริ่มต้น ฉันเห็นหัวคุกกี้นานมากแล้วฉันสงสัยว่าย่าของฉันถักไหมพรม

— Jake

7

3 ปีที่ผ่านมา

มีอีกสาเหตุที่เบราว์เซอร์ไม่ส่งคุกกี้ คุณสามารถเพิ่มcrossOriginแอตทริบิวต์ที่คุณแท็กและความคุ้มค่าในการ<script> "anonymous"วิธีนี้จะป้องกันไม่ให้มีการส่งคุกกี้ไปยังเซิร์ฟเวอร์ปลายทาง 99.9% ของเวลา javascripts ของคุณเป็นไฟล์คงที่และคุณไม่ได้สร้างรหัส js นั้นตามคุกกี้ของคำขอ หากคุณมีคุกกี้ 1KB และคุณมีทรัพยากร 200 รายการบนหน้าเว็บของคุณผู้ใช้ของคุณกำลังอัปโหลด 200KB และอาจต้องใช้เวลาสักครู่บน 3G และไม่มีผลกระทบใด ๆ กับหน้าผลลัพธ์ ไปที่แอตทริบิวต์ HTML: crossoriginเพื่อการอ้างอิง

— gilm
แหล่งที่มา

กรุณาอธิบาย.

— Jake

4

@Jake คุณสามารถเพิ่มแอตทริบิวต์ crossOrigin ลงในแท็ก <script> ของคุณและค่าเป็น "ไม่ระบุชื่อ" วิธีนี้จะป้องกันไม่ให้มีการส่งคุกกี้ไปยังเซิร์ฟเวอร์ปลายทาง 99.9% ของเวลา javascripts ของคุณเป็นไฟล์คงที่และคุณไม่ได้สร้างรหัส js นั้นตามคุกกี้ของคำขอ หากคุณมีคุกกี้ 1KB และคุณมีทรัพยากร 200 รายการบนหน้าเว็บของคุณผู้ใช้ของคุณกำลังอัปโหลด 200KB และอาจต้องใช้เวลาสักครู่บน 3G และไม่มีผลกระทบใด ๆ กับหน้าผลลัพธ์ เยี่ยมชมdeveloper.mozilla.org/en-US/docs/Web/HTML/…สำหรับการอ้างอิง

— gilm

4

ฉันรู้ว่านี่เป็นด้ายเก่า แต่ฉันเพิ่งสังเกตเห็นว่าเบราว์เซอร์ส่วนใหญ่จะไม่ส่งคุกกี้สำหรับโดเมนหากคุณเพิ่มจุดต่อท้าย ยกตัวอย่างเช่นจะไม่ได้รับการตั้งค่าสำหรับคุกกี้http://example.com. .example.comApache ในทางกลับกันถือว่าเป็นโฮสต์เดียวกัน ฉันพบว่ามีประโยชน์ในการทำให้การติดตามข้ามโดเมนยากขึ้นสำหรับทรัพยากรภายนอกที่ฉันมี แต่คุณสามารถใช้เพื่อเหตุผลด้านประสิทธิภาพได้ หมายเหตุเบรคนี้การตรวจสอบhttpsใบรับรอง ฉันทำการทดสอบสองสามครั้งโดยใช้เบราว์เซอร์ภาพและอุปกรณ์ของฉันเอง แฮ็คทำงานได้กับเบราว์เซอร์เกือบทั้งหมดยกเว้นสำหรับ Safari (อุปกรณ์เคลื่อนที่และเดสก์ท็อป) ซึ่งจะรวมคุกกี้ไว้ในคำขอ

— Gellweiler
แหล่งที่มา

"ทำให้การติดตามข้ามโดเมนยากขึ้นสำหรับทรัพยากรภายนอกที่ฉันรวมไว้" ได้อย่างไร คุณกำลังพูดถึง Farcebook Like และวิดเจ็ตดังกล่าวซึ่งเรารู้จักติดตามการเรียกดูผู้ใช้ที่ยังไม่ได้เข้าสู่ระบบหรือไม่

— Jake

ใช่. มันจะทำให้มันยากขึ้นเพราะเบราว์เซอร์ส่วนใหญ่จะไม่ส่งคุกกี้ไปด้วย ดังนั้นหากคุณรวมบางสิ่งบางอย่างจาก google.com และคุณลงชื่อเข้าใช้ google google จะไม่สามารถลิงก์คำขอทั้งสองได้ สิ่งนี้ไม่รับประกันว่าจะยากเบราว์เซอร์บางตัวส่งคุกกี้ต่อไปและมีวิธีการที่เชื่อถือได้น้อยกว่าและใช้น้อยกว่าเพื่อระบุผู้ใช้ (เช่นที่อยู่ IP) ที่ยังใช้งานได้ ข้อเสียเปรียบที่ยิ่งใหญ่ที่สุดคือคุณไม่สามารถใช้ HTTPS ซึ่งทำให้มันไร้ประโยชน์ในวันนี้

— Gellweiler

0

คำตอบสั้น ๆ คือใช่ บรรทัดด้านล่างมาจากเอกสาร JS

คุกกี้ถูกใช้ครั้งเดียวสำหรับการจัดเก็บข้อมูลฝั่งไคลเอ็นต์ทั่วไป ขณะนี้ถูกต้องตามกฎหมายเมื่อพวกเขาเป็นวิธีเดียวในการจัดเก็บข้อมูลบนไคลเอนต์ตอนนี้ก็ขอแนะนำให้ใช้ API การจัดเก็บข้อมูลที่ทันสมัย คุกกี้จะถูกส่งไปพร้อมกับคำขอทุกครั้งเพื่อให้ประสิทธิภาพแย่ลง (โดยเฉพาะสำหรับการเชื่อมต่อข้อมูลมือถือ)

— Yashwin Munsadwala
แหล่งที่มา