Каждый веб-запрос отправляет файлы cookie браузера?

199

Каждый веб-запрос отправляет куки браузера?

Я говорю не о просмотрах страниц, а о запросе изображения, .jsфайла и т. Д.

Обновление Если веб-страница содержит 50 элементов, это 50 запросов. Почему он отправляет одинаковые файлы cookie для каждого запроса, не кэширует или не знает, что он уже есть?

cookies

— mrblah
источник

8

Я не думаю, что кэширование возможно в этой ситуации - мы говорим о том, что браузер отправляет данные на сервер, а не наоборот. Вы не можете точно сказать, что сервер «уже имеет» его после того, как пользователь отправил один запрос, по многим причинам. Может быть большое количество серверов, которые не общаются друг с другом; сервер может не захотеть (или иметь место) вообще что-либо помнить о предыдущих запросах - предполагается, что HTTP не имеет состояния; каждый запрос должен быть независимым от остальных. По этой причине файлы cookie, такие как учетные данные для аутентификации, должны отправляться с каждым запросом.

— Ян Клелланд

Я упомянул, почему кеширование файлов cookie не имеет смысла в обновлении моего ответа: stackoverflow.com/a/1336178/102960

— igorsantos07

199

Да, если запрошенный URL-адрес находится в пределах того же домена и пути, определенных в файле cookie (и все другие ограничения - безопасный, httponly, срок действия не истек и т. Д.), То файл cookie будет отправляться для каждого запроса.

— Ян Клелланд
источник

103

Именно поэтому, кстати, такие инструменты, как Google Page Speed или Yahoo YSlow, рекомендуют обслуживать статический контент из отдельного домена без файлов cookie.

— ceejayoz

Я упомянул об обслуживании контента из отдельного домена в моем обновленном ответе: stackoverflow.com/a/1336178/102960

— igorsantos07

Правда ли, что браузер отправляет файлы cookie Site2 при перенаправлении HTTP с сайта 1 на сайт 2?

— Zeigeist

92

Как уже говорили другие, если ограничения на хост, путь и т. Д. Cookie будут выполнены, он будет отправлен 50 раз.

Но вы также спросили почему: потому что куки - это функция HTTP, а HTTP не имеет состояния. HTTP предназначен для работы без сохранения сервером какого-либо состояния между запросами.

Фактически, у сервера нет надежного способа узнать, какой пользователь отправляет данный запрос; за одним веб-прокси может быть тысяча пользователей (и, следовательно, IP-адрес). Если куки не отправляются на каждый запрос, сервер не сможет узнать, какой пользователь запрашивает какой-либо ресурс.

Наконец, браузер не имеет ни малейшего представления, нужны ли серверу файлы cookie или нет, он просто знает, что сервер поручил ему отправить файл cookie для любого запроса на foo.com, поэтому он делает это. Иногда изображения нуждаются в них (например, динамически генерируемые для каждого пользователя), иногда нет, но браузер не может сказать.

— derobert
источник

1

Верно ли это с HTTP 1.1, который является схемой мультиплексирования? То есть запросы объединяются в одно TCP-соединение. Конечно, каждый запрос получен с приложением копии файла cookie. Но если проблема заключается в большом дублировании передачи, HTTP 1.1 может оптимизировать. Хотя я не знаю, так ли это на самом деле ...

— Крис Ноу

1

Тогда возникает вопрос "к каким запросам браузер намеревался прикрепить файлы cookie?" Сервер устанавливает политику с помощью куки-файла, чтобы решить, в какие домены и какие URL-пути следует отправить куки-файл, но затем он его забывает. Вам нужно было бы указать, что некоторые запросы в соединении содержат cookie, а другие нет. Этого определенно не существует в HTTP / 1.1, за исключением явного включения их в каждый запрос. Честно говоря, лучшим (совместимым со стандартами) решением для уменьшения пропускной способности будет кодирование содержимого на стороне клиента в формате gzip, но пока это никто не поддерживает.

— Ян Клелланд

1

@Ian Clelland: Клиент должен отправить первое сообщение, поэтому он не знает, что сервер отправит для Accept-Encoding (если бы серверы отправляли это поле, HTTP / 1.1 §14.3 говорит, что это заголовок запроса). И проблема в том, что он может варьироваться в зависимости от URL даже на одном и том же сервере и может меняться со временем, поэтому заставить его работать будет нетривиально.

— Дероберт

1

@Chris: Нет, keepalive просто экономит на настройке / разрыве соединения TCP, вот и все. Полные заголовки по-прежнему отправляются для каждого запроса. Однако конвейерная обработка (отправка нескольких запросов без ожидания ответа) может сильно помочь. HTTP / 1.1 §8.1 дает подробности.

— Дероберт

21

Да. Каждый запрос отправляет куки, которые принадлежат одному домену. Они не кэшируются, поскольку HTTP не имеет состояния, что означает, что каждого запроса должно быть достаточно, чтобы сервер выяснил, что с ним делать. Скажем, у вас есть изображения, которые доступны только определенным пользователям; Вы должны отправлять свой cookie-файл авторизации с каждым из этих 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 cookie-файла не будут присутствовать, но, возможно, будут присутствовать те, которые связаны с этими доменами.

Вы можете прочитать больше о файлах cookie и изображениях, запрашивающих, например, в этом блог-посте StackOverflow .

— igorsantos07
источник

10

Нет. Не каждый запрос отправляет куки. Это зависит от конфигурации cookie и соединения клиент-сервер.

Например, если для вашего файла cookie secureзадано значение, trueто оно должно передаваться через защищенное соединение HTTPS. Означает, что когда вы видите этот веб-сайт с протоколом HTTP, эти файлы cookie не будут отправляться браузерами, поскольку флаг безопасности установлен на true.

— Иман Седиги
источник

7

Cookie имеет свойство path. Если «путь = /», ответ - да.

— neoedmund
источник

Да, вы можете настроить структуру своего сайта / приложения таким образом, чтобы все URL-адреса, для которых требуются файлы cookie, были одинаковыми /app/или такими - это сохраняло бы мобильность без необходимости использования отдельных поддоменов для устранения избыточных накладных расходов. Или вы могли бы отказаться от ныне бесполезной Google Analytics для начала. Я видел заголовки печенья так долго, что я удивляюсь, связала ли их моя бабушка.

— Джейк

7

Прошло 3 года

Есть еще одна причина, по которой браузер не отправляет куки. Вы можете добавить crossOriginатрибут к своему <script>тегу и значение для "anonymous". Это предотвратит отправку файлов cookie на сервер назначения. В 99,9% случаев ваши javascript-коды являются статическими файлами, и вы не генерируете этот js-код на основе файлов cookie запроса. Если у вас есть 1 КБ файлов cookie и 200 страниц на вашей странице, то ваш пользователь загружает 200 КБ, и это может занять некоторое время в сети 3G и оказать нулевое влияние на страницу результатов. Посетите HTML-атрибут: crossorigin для справки.

— gilm
источник

Пожалуйста, объясни.

— Джейк

4

@ Джейк, вы можете добавить атрибут crossOrigin в ваш тег <script> и значение «anonymous». Это предотвратит отправку файлов cookie на сервер назначения. В 99,9% случаев ваши javascript-коды являются статическими файлами, и вы не генерируете этот js-код на основе файлов cookie запроса. Если у вас есть 1 КБ файлов cookie и 200 страниц на вашей странице, то ваш пользователь загружает 200 КБ, и это может занять некоторое время в сети 3G и оказать нулевое влияние на страницу результатов. Посетите developer.mozilla.org/en-US/docs/Web/HTML/… для справки.

— gilm

4

Я знаю, что это старая тема. Но я только что заметил, что большинство браузеров не будут отправлять куки для домена, если вы добавите конечную точку. Например http://example.com., не будет получать файлы cookie, установленные для .example.com. Apache, с другой стороны, рассматривает их как один и тот же хост. Я считаю это полезным, чтобы усложнить отслеживание междоменных доменов для внешних ресурсов, которые я включаю, но вы также можете использовать его из соображений производительности. Обратите внимание, что это тормозит проверку httpsсертификатов. Я провел несколько тестов, используя браузерные снимки и мои собственные устройства. Хак работает практически во всех браузерах, кроме сафари (мобильных и настольных), которые будут включать куки в запросе.

— Gellweiler
источник

Как это «усложняет отслеживание доменов для внешних ресурсов, которые я включаю»? Вы говорите о Farcebook Like и таких виджетах, которые, как мы знаем, отслеживают просмотр случайно зарегистрированных пользователей?

— Джейк

Да. Это усложнит задачу, потому что большинство браузеров не будут отправлять куки. Так что, если вы добавляете что-то, например, с google.com, и вы вошли в Google, Google не может связать два запроса. Это не гарантируется, некоторые браузеры в любом случае отправляют файлы cookie, и существуют менее надежные и менее используемые методы идентификации пользователей (например, IP-адреса), которые все еще будут работать. Самый большой недостаток в том, что вы не можете использовать HTTPS, что делает его сегодня бесполезным.

— Геллвайлер

0

Краткий ответ - да. Следующие строки взяты из документации JS

Cookies когда-то использовались для общего хранения на стороне клиента. Хотя это было законно, когда они были единственным способом хранения данных на клиенте, сейчас рекомендуется использовать современные API хранилища. Файлы cookie отправляются при каждом запросе, поэтому они могут ухудшить производительность (особенно для мобильных соединений для передачи данных).

— Яшвин Мансадвала
источник