Her web isteği tarayıcı çerezlerini gönderiyor mu?


199

Her web isteği tarayıcının çerezlerini gönderiyor mu?

Sayfa görüntülemelerinden bahsetmiyorum, ancak bir resim, .jsdosya vb.

Güncelleme Bir web sayfasında 50 öğe varsa, bu 50 istektir. Neden her istek için AYNI çerez (ler) gönderir, önbelleğe almaz veya zaten sahip olduğunu bilmiyor mu?


8
Bu durumda önbelleğe almanın mümkün olduğunu düşünmüyorum - tarayıcının sunucuya veri göndermesinden bahsediyoruz, tersi değil. Kullanıcı bir istek gönderdikten sonra birçok nedenden dolayı sunucunun "zaten sahip" olduğundan emin olamazsınız. Birbirleriyle konuşmayan çok sayıda sunucu olabilir; sunucu önceki istekler hakkında hiçbir şey hatırlamak istemeyebilir (veya odaya sahip olmayabilir) - HTTP'nin vatansız olması gerekir; her istek diğerlerinden bağımsız olmalıdır. Bu nedenle, kimlik doğrulama bilgileri gibi çerezler her istekle birlikte gönderilmelidir.
Ian Clelland

Cevabımın bir güncellemesinde önbelleğe almanın neden çerezler için anlamlı olmadığını belirttim: stackoverflow.com/a/1336178/102960
igorsantos07

Yanıtlar:


199

Evet, istenen URL, çerezde tanımlanan alan adı ve yol (ve diğer tüm kısıtlamalar - güvenli, httponly, süresi dolmamış vb.) Bekletildiği sürece, çerez her istek için gönderilir.


103
Bu nedenle, Google Page Speed ​​veya Yahoo'nun YSlow gibi sayfa hızı araçlarının ayrı, çerez içermeyen bir alandan statik içerik sunmasını önermesinin nedeni budur.
ceejayoz

Güncellenmiş
cevabımda

Site1'den Site2'ye bir HTTP Yönlendirme olduğunda tarayıcının Site2 Çerezleri gönderdiği doğru mu?
Zeigeist

92

Diğerlerinin söylediği gibi, çerezin ana bilgisayar, yol vb. Kısıtlamaları karşılanırsa, 50 kez gönderilir.

Ancak nedenini de sordunuz: çünkü çerezler bir HTTP özelliğidir ve HTTP durumsuzdur. HTTP, sunucu istekler arasında herhangi bir durum saklamadan çalışmak üzere tasarlanmıştır.

Aslında, sunucunun hangi kullanıcının belirli bir istek gönderdiğini tanımanın sağlam bir yolu yoktur; tek bir web proxy'sinin (ve dolayısıyla IP adresinin) arkasında bin kullanıcı olabilir. Çerezler her istek gönderilmezse, sunucunun hangi kullanıcının hangi kaynağı istediğini bilmesi mümkün olmaz.

Son olarak, tarayıcının sunucunun çerezlere ihtiyacı olup olmadığı konusunda hiçbir fikri yoktur, sadece sunucunun çerezleri foo.com'a herhangi bir istek için göndermesini istediğini bilir, bu yüzden bunu yapar. Bazen görüntüler onlara ihtiyaç duyar (örneğin, kullanıcı başına dinamik olarak oluşturulan), bazen gerekmez, ancak tarayıcı söyleyemez.


1
Bu çoklama şeması olan HTTP 1.1 için geçerli mi? Yani, istekler tek bir TCP bağlantısında toplanmıştır. Elbette her istek, ekli çerezin bir kopyasıyla birlikte alınır. Ancak, endişe çok fazla iletim çoğaltmasıysa, HTTP 1.1 optimize edilecek bir konumdadır. Aslında gerçekten olup olmadığını bilmiyorum ...
Chris Noe

1
Sonra sorun "tarayıcı çerezleri hangi isteklere eklemeyi planladı?" Sunucu, hangi etki alanlarına ve hangi URL yollarına çerezin geri gönderilmesi gerektiğine karar vermek için çerezle ilkeyi belirler, ancak daha sonra unutur. Bağlantıdaki belirli isteklerin çereze sahip olduğunu ve diğerlerinin sahip olmadığını belirtmek için bir yola ihtiyacınız olacaktır. Bu, HTTP / 1.1'de kesinlikle mevcut değildir, ancak her istekte açıkça belirtilmesi dışında. Dürüst olmak gerekirse, bant genişliğini azaltmak için daha iyi (standartlarla uyumlu) bir çözüm, istemci tarafı gzip içerik kodlaması olacaktır, ancak henüz kimse bunu desteklemez.
Ian Clelland

1
@Ian Clelland: İstemcinin ilk iletiyi göndermesi gerekiyor, bu nedenle sunucunun Kabul Et Kodlaması için ne göndereceğini bilmiyor (bu alanı gönderecek sunuculardı, HTTP / 1.1 §14.3 bunun bir istek başlığı olduğunu söylüyor). Ve sorun, aynı sunucuda bile URL'ye göre değişebilmesi ve zaman içinde değişebilmesidir, bu nedenle çalışmasını sağlamak önemsiz olmaz.
derobert

1
@Chris: Hayır, keepalive sadece TCP bağlantı kurulumunu / söküm yükünü kurtarır, hepsi bu. Her istek için tam başlıklar gönderilir. Ancak, boru hattı oluşturma (yanıtı beklemeden birden fazla istek gönderme) çok yardımcı olabilir. HTTP / 1.1 §8.1 ayrıntılar verir.
derobert

21

Evet. Her istek, aynı alana ait çerezleri gönderir. HTTP vatansız olduğu için önbelleğe alınmazlar, bu da sunucunun onunla ne yapacağını anlaması için her isteğin yeterli olması gerektiği anlamına gelir. Yalnızca belirli kullanıcılar tarafından erişilebilen resimleriniz olduğunu varsayalım; Eğer gereken sunucu o gidiyor isteklerin havuz arasında sen değil başkası veya bir misafir, bilir böylece, bu 50 isteklerinin her biriyle yetkilendirme çerez gönderin.

Bunu söyledikten sonra, HTTPS ayarı, yol veya alan adı gibi diğer yanıtlarda belirtilen diğer kısıtlamalar göz önüne alındığında çerezler gönderilemeyebilir. Özellikle orada, dikkat edilmesi gereken önemli bir şey vardır: çerezler alanlar arasında paylaşılmaz. Bu, bahsettiğiniz resimler ve komut dosyaları gibi statik dosyalar için HTTP çağrılarının boyutunu azaltmaya yardımcı olur.
Örnek: 4 çereziniz var www.stackoverflow.com; bir istekte bulunursanız www.stackoverflow.com/images/logo.png, bu 4 çerezin tamamı gönderilir.
Bununla birlikte, talep ederseniz stackoverflow.com/images/logo.png(alt alan değişikliğine dikkat edin) veya images.stackoverflow.com/logo.pngbu 4 çerez mevcut olmaz - ancak bu alanlarla ilgili olanlar olabilir.

Örneğin bu StackOverflow Blog Yayında talep eden çerezler ve resimler hakkında daha fazla bilgi edinebilirsiniz .


10

Hayır. Her istek çerezleri göndermez. Çerez yapılandırmasına ve istemci-sunucu bağlantısına bağlıdır.

Örneğin, çerezinizin secureseçeneği olarak ayarlanmışsa, truegüvenli bir HTTPS bağlantısı üzerinden iletilmesi gerekir. HTTP protokolüne sahip web sitesini gördüğünüzde, bu çerezler güvenli bayrak doğru olduğundan tarayıcılar tarafından gönderilmeyeceği anlamına gelir.


7

Çerezin "path" özelliği vardır. "Path = /" ise cevap Evet'tir.


Evet, sitenizi / uygulama yapınızı, çerez gerektiren tüm URL'lerin wthin /app/veya benzeri olacağı şekilde düzenleyebilirsiniz - gereksiz ek yükü ortadan kaldırmak için ayrı alt alan adlarına ihtiyaç duymadan taşınabilirliği koruyacaktır. Veya artık işe yaramaz Google Analytics'i bir başlangıç ​​için kullanabilirsiniz. Çerez başlıklarını çok uzun zamandır gördüm.
Jake

7

3 yıl geçti

Tarayıcının çerez göndermemesinin başka bir nedeni daha var. Etiketinize bir crossOriginözellik <script>ve değerine ekleyebilirsiniz "anonymous". Bu, hedef sunucuya çerez gönderilmesini önleyecektir. % 99,9 oranında, javascripts statik dosyalardır ve bu js kodunu isteğin çerezlerine göre oluşturmazsınız. 1KB çereziniz varsa ve sayfanızda 200 kaynağınız varsa, kullanıcınız 200 KB yüklüyor ve 3G'de biraz zaman alabilir ve sonuç sayfasında sıfır etkisi olabilir. Referans olarak HTML özelliğini ziyaret edin : crossorigin .


Lütfen açıkla.
Jake

4
@Jake <script> etiketinize crossOrigin niteliğini ve "anonim" değerini ekleyebilirsiniz. Bu, hedef sunucuya çerez gönderilmesini önleyecektir. % 99,9 oranında, javascripts statik dosyalardır ve bu js kodunu isteğin çerezlerine göre oluşturmazsınız. 1KB çereziniz varsa ve sayfanızda 200 kaynağınız varsa, kullanıcınız 200 KB yüklüyor ve 3G'de biraz zaman alabilir ve sonuç sayfasında sıfır etkisi olabilir. Referans için developer.mozilla.org/tr-TR/docs/Web/HTML/… adresini ziyaret edin .
gilm

4

Bunun eski bir konu olduğunu biliyorum. Ancak, bir nokta eklerseniz, çoğu tarayıcının bir alan adı için çerez göndermediğini fark ettim. Örneğin http://example.com., için ayarlanmış çerezler almaz .example.com. Apache ise onlara aynı ev sahibi gibi davranıyor. Bunu, eklediğim harici kaynaklar için web alanları arası izlemeyi daha zor hale getirmek için yararlı buluyorum, ancak performans nedenleriyle de kullanabilirsiniz. Bunun httpssertifikaların doğrulanmasını frenlediğine dikkat edin . Tarayıcı görüntülerini ve kendi aygıtlarımı kullanarak birkaç test yaptım. Saldırı, istekte çerezleri içeren safari (mobil ve masaüstü) hariç hemen hemen tüm tarayıcılarda çalışır.


"Eklediğim harici kaynaklar için web alanları arası izlemeyi nasıl zorlaştırır"? Farcebook Like ve yanlışlıkla giriş yapmış kullanıcıların göz atma işlemini takip ettiğimizi bildiğimiz bu widget'lardan mı bahsediyorsunuz?
Jake

Evet. Daha zor hale getirecektir, çünkü çoğu tarayıcı çerezleri göndermez. Örneğin, google.com'dan bir şey ekliyorsanız ve google'da oturum açtıysanız, google iki isteği birbirine bağlayamaz. Bunun zor olduğu garanti edilmez, bazı tarayıcılar zaten çerezleri gönderir ve hala çalışacak kullanıcıları (IP Adresleri gibi) tanımlamak için daha az güvenilir ve daha az kullanılan yöntemler vardır. En büyük dezavantajı, bugün işe yaramaz hale getiren HTTPS'yi kullanamamanızdır.
Gellweiler

0

Kısa cevap Evet. Aşağıdaki satırlar JS belgelerinden alınmıştır.

Çerezler bir zamanlar müşteri tarafında genel depolama için kullanıldı. İstemcide veri depolamanın tek yolu bu olduğunda meşru olsa da, şimdi modern depolama API'larının kullanılması önerilir. Çerezler her istekle gönderilir, böylece performansı kötüleştirebilirler (özellikle mobil veri bağlantıları için).

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.