Czy każde żądanie sieciowe wysyła pliki cookie przeglądarki?

197

Nie mówię o odsłonach, ale prośbie o zdjęcie, .jsplik itp.

Aktualizacja Jeśli strona internetowa zawiera 50 elementów, czyli 50 żądań. Dlaczego miałby wysyłać SAME pliki cookie dla każdego żądania, czy nie buforuje lub nie wie, że już je ma?

cookies

— mrblah
źródło

8

Nie sądzę, aby buforowanie było możliwe w tej sytuacji - mówimy o przeglądarce wysyłającej dane do serwera, a nie na odwrót. Nie można stwierdzić z całą pewnością, że serwer „już go ma” po tym, jak użytkownik wysłał jedno żądanie, z wielu powodów. Może istnieć duża liczba serwerów, które nie rozmawiają ze sobą; serwer może nie chcieć (lub nie mieć miejsca) w ogóle niczego pamiętać o poprzednich żądaniach - HTTP powinien być bezstanowy; każde żądanie powinno być niezależne od pozostałych. Z tego powodu pliki cookie, takie jak dane uwierzytelniające, muszą być wysyłane przy każdym żądaniu.

— Ian Clelland

Wspomniałem, dlaczego buforowanie nie ma sensu dla plików cookie w aktualizacji mojej odpowiedzi: stackoverflow.com/a/1336178/102960

— igorsantos07

198

Tak, tak długo, jak żądany adres URL znajduje się w tej samej domenie i ścieżce zdefiniowanej w pliku cookie (i wszystkie inne ograniczenia - bezpieczne, httponly, nie wygasły itp.) Wstrzymują, plik cookie zostanie wysłany dla każdego żądania.

— Ian Clelland
źródło

103

Nawiasem mówiąc, dlatego narzędzia do zarządzania szybkością strony, takie jak Google Page Speed lub YSlow firmy Yahoo, zalecają podawanie treści statycznych z oddzielnej domeny bez plików cookie.

— ceejayoz

Wspomniałem o udostępnianiu treści z oddzielnej domeny w mojej zaktualizowanej odpowiedzi: stackoverflow.com/a/1336178/102960

— igorsantos07

Czy to prawda, że przeglądarka wysyła pliki cookie Site2, gdy następuje przekierowanie HTTP z Site1 do Site2?

— Zeigeist

92

Jak powiedzieli inni, jeśli ograniczenia dotyczące hosta, ścieżki itp. Pliku cookie zostaną spełnione, zostanie ono wysłane 50 razy.

Ale zapytałeś także dlaczego: ponieważ pliki cookie są funkcją HTTP, a HTTP jest bezstanowy. HTTP jest zaprojektowany do pracy bez przechowywania przez serwer stanu między żądaniami.

W rzeczywistości serwer nie ma solidnego sposobu na rozpoznanie, który użytkownik wysyła dane żądanie; za jednym internetowym serwerem proxy może znajdować się tysiąc użytkowników (a tym samym adres IP). Gdyby pliki cookie nie były wysyłane przy każdym żądaniu, serwer nie miałby sposobu, aby dowiedzieć się, który użytkownik żąda dowolnego zasobu.

Wreszcie, przeglądarka nie ma pojęcia, czy serwer potrzebuje plików cookie, czy nie, po prostu wie, że serwer polecił mu wysłać plik cookie w przypadku każdego żądania do foo.com, więc robi to. Czasami obrazy ich potrzebują (np. Generowane dynamicznie na użytkownika), czasem nie, ale przeglądarka nie może tego stwierdzić.

— derobert
źródło

1

Czy to prawda w przypadku HTTP 1.1, który jest schematem multipleksowania? Tzn. Żądania są pakowane w jedno połączenie TCP. Oczywiście do każdego żądania dołączona jest kopia pliku cookie. Ale jeśli problemem jest dużo duplikacji transmisji, HTTP 1.1 jest w stanie zoptymalizować. Chociaż nie wiem, czy to rzeczywiście ...

— Chris Noe

1

Następnie pojawia się pytanie „do jakich żądań przeglądarka zamierza dołączyć pliki cookie?” Serwer ustawia zasady za pomocą pliku cookie, aby zdecydować, które domeny i ścieżki URL, do których plik cookie powinien zostać odesłany, ale potem go zapomina. Potrzebujesz sposobu, aby określić, że niektóre żądania w połączeniu zawierały plik cookie, a inne nie. To zdecydowanie nie istnieje w HTTP / 1.1, z wyjątkiem jawnego włączenia ich do każdego żądania. Szczerze mówiąc, lepszym (zgodnym ze standardami) rozwiązaniem zmniejszającym przepustowość byłoby kodowanie zawartości gzip po stronie klienta, ale nikt tego jeszcze nie obsługuje.

— Ian Clelland

1

@Ian Clelland: Klient musi wysłać pierwszą wiadomość, więc nie wie, co serwer wysłałby w celu przyjęcia kodowania (gdyby serwery wysłały to pole, HTTP / 1.1 §14.3 mówi, że jest nagłówkiem żądania). Problem polega na tym, że może się różnić w zależności od adresu URL nawet na tym samym serwerze i może się zmieniać z czasem, więc sprawienie, by działało, nie byłoby trywialne.

— derobert

1

@Chris: Nie, keepalive po prostu zapisuje koszt konfiguracji połączenia TCP / koszty porzucenia, to wszystko. Nadal wysyłane są pełne nagłówki dla każdego żądania. Jednak potokowanie (wysyłanie wielu żądań bez oczekiwania na odpowiedź) może znacznie pomóc. HTTP / 1.1 §8.1 podaje szczegóły.

— derobert

21

Tak. Każde żądanie wysyła pliki cookie należące do tej samej domeny. Nie są buforowane, ponieważ HTTP jest bezstanowy, co oznacza, że każde żądanie musi wystarczyć, aby serwer mógł zorientować się, co z nim zrobić. Załóżmy, że masz obrazy dostępne tylko dla niektórych użytkowników; Państwo musi wysłać plik cookie uwierzytelniania z każdego z tych 50 wniosków, więc serwer nie wie, że to ty, a nie ktoś inny, albo gościem, spośród puli wniosków to coraz.

Powiedziawszy to, pliki cookie mogą nie zostać wysłane z powodu innych ograniczeń wymienionych w innych odpowiedziach, takich jak ustawienie HTTPS, ścieżka lub domena. Szczególnie tam należy zauważyć: pliki cookie nie są udostępniane między domenami. Pomaga to zmniejszyć rozmiar wywołań HTTP dla plików statycznych, takich jak wspomniane obrazy i skrypty.
Przykład: masz 4 ciasteczka na www.stackoverflow.com; jeśli poprosisz o to www.stackoverflow.com/images/logo.png, wszystkie te 4 pliki cookie zostaną wysłane.
Jednak jeśli poprosisz stackoverflow.com/images/logo.png(zauważ zmianę subdomeny) lub images.stackoverflow.com/logo.pngte 4 pliki cookie nie będą obecne - ale być może te związane z tymi domenami będą.

Możesz przeczytać więcej o żądaniach plików cookie i obrazów, na przykład w tym wpisie na blogu StackOverflow .

— igorsantos07
źródło

10

Nie. Nie każde żądanie wysyła pliki cookie. To zależy od konfiguracji plików cookie i połączenia klient-serwer.

Na przykład, jeśli secureopcja pliku cookie jest ustawiona na, truewówczas musi być przesyłana za pośrednictwem bezpiecznego połączenia HTTPS. Oznacza, że gdy zobaczysz tę witrynę z protokołem HTTP, te pliki cookie nie będą wysyłane przez przeglądarki, ponieważ bezpieczna flaga jest prawdziwa.

— Iman Sedighi
źródło

7

Cookie ma właściwość „ścieżki”. Jeśli „ścieżka = /”, odpowiedź brzmi „tak”.

— neoedmund
źródło

Tak, możesz zorganizować strukturę witryny / aplikacji w taki sposób, aby wszystkie adresy URL wymagające plików cookie były cienkie /app/lub podobne - zachowałoby to przenośność bez potrzeby posiadania oddzielnych poddomen w celu wyeliminowania zbędnego obciążenia. Możesz też na początek porzucić niepotrzebny Google Analytics. Tak długo widziałem nagłówki plików cookie, zastanawiam się, czy moja babcia je robiła na drutach.

— Jake,

7

Minęły 3 lata

Jest jeszcze jeden powód, dla którego przeglądarka nie wysyła plików cookie. Możesz dodać crossOriginatrybut do <script>tagu i wartość do "anonymous". Zapobiegnie to wysyłaniu plików cookie na serwer docelowy. W 99,9% przypadków javascript są plikami statycznymi i nie generujesz kodu js na podstawie plików cookie żądania. Jeśli masz 1 KB plików cookie i masz 200 zasobów na swojej stronie, to użytkownik przesyła 200 KB, co może zająć trochę czasu w 3G i mieć zerowy wpływ na stronę wyników. Odwiedź atrybut HTML: crossorigin w celach informacyjnych.

— gilm
źródło

Proszę wytłumacz.

— Jake,

4

@Jake możesz dodać atrybut crossOrigin do tagu <script> i wartość „anonimowy”. Zapobiegnie to wysyłaniu plików cookie na serwer docelowy. W 99,9% przypadków javascript są plikami statycznymi i nie generujesz kodu js na podstawie plików cookie żądania. Jeśli masz 1 KB plików cookie i masz 200 zasobów na swojej stronie, to użytkownik przesyła 200 KB, co może zająć trochę czasu w 3G i mieć zerowy wpływ na stronę wyników. Odwiedź stronę developer.mozilla.org/en-US/docs/Web/HTML/... w celach informacyjnych.

— gilm,

4

Wiem, że to stary wątek. Ale właśnie zauważyłem, że większość przeglądarek nie wysyła plików cookie dla domeny, jeśli dodasz kropkę końcową. Na przykład http://example.com.nie otrzyma ustawionych plików cookie .example.com. Z drugiej strony Apache traktuje je jako tego samego hosta. Uważam, że jest to przydatne, aby utrudnić śledzenie w wielu domenach dla zasobów zewnętrznych, które dołączam, ale możesz go również użyć ze względu na wydajność. Należy zauważyć, że to sprawdzenie poprawności httpscertyfikatów. Przeprowadziłem kilka testów przy użyciu przeglądarki i własnych urządzeń. Hack działa na prawie wszystkich przeglądarkach z wyjątkiem safari (mobilnego i stacjonarnego), które będą zawierać pliki cookie w żądaniu.

— Gellweiler
źródło

W jaki sposób „utrudnia śledzenie w wielu domenach dołączanych przeze mnie zasobów zewnętrznych”? Czy mówisz o Farcebook Like i takich widżetach - które, jak wiemy, śledzą przeglądanie przypadkowo zalogowanych użytkowników?

— Jake,

Tak. Utrudni to, ponieważ większość przeglądarek nie wyśle plików cookie. Więc jeśli na przykład dołączasz coś z google.com i jesteś zalogowany w google, google nie może połączyć dwóch żądań. Nie jest to gwarantowane trudne, niektóre przeglądarki i tak wysyłają pliki cookie, a istnieją mniej niezawodne i rzadziej stosowane metody identyfikacji użytkowników (takie jak adresy IP), które nadal będą działać. Największą wadą jest to, że nie można używać HTTPS, co sprawia, że jest on dziś bezużyteczny.

— Gellweiler,

0

Krótka odpowiedź brzmi: tak. Poniższe wiersze pochodzą z dokumentacji JS

Pliki cookie były kiedyś używane do ogólnego przechowywania po stronie klienta. Chociaż było to uzasadnione, gdy były jedynym sposobem przechowywania danych na kliencie, obecnie zaleca się stosowanie nowoczesnych interfejsów API pamięci masowej. Pliki cookie są wysyłane przy każdym żądaniu, dzięki czemu mogą pogorszyć wydajność (szczególnie w przypadku mobilnych połączeń danych).

— Yashwin Munsadwala
źródło