Чи надсилає кожен веб-запит браузера?

198

Чи надсилає кожен веб-запит cookie браузера?

Я не говорю про перегляди сторінок, а про запит на зображення, .jsфайл тощо.

Оновлення Якщо веб-сторінка містить 50 елементів, тобто 50 запитів. Чому він надсилає однакові файли cookie для кожного запиту, не кешуючи вони чи знаючи, що вони вже є?

cookies

— мрбла
джерело

8

Я не думаю, що кешування можливе в цій ситуації - ми говоримо про те, що браузер надсилає дані на сервер, а не навпаки. Ви не можете точно сказати, що сервер "вже має" після того, як користувач надіслав один запит, з безлічі причин. Може бути велика кількість серверів, які не розмовляють між собою; сервер може не хотіти (або мати приміщення) взагалі нічого запам’ятовувати про попередні запити - HTTP повинен бути без громадянства; кожен запит повинен бути незалежним від решти. З цієї причини файли cookie, як ідентифікаційні дані для автентифікації, повинні надсилатися з кожним запитом.

— Ian Clelland

Я згадав , чому кешування не має сенсу для печива в оновленні на мою відповідь: stackoverflow.com/a/1336178/102960

— igorsantos07

199

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

— Ян Клленд
джерело

103

Це, до речі, саме тому інструменти для швидкості сторінки, такі як Google Page Speed або Yhoolow Yahoo, рекомендують подавати статичний вміст в окремий домен, не містить файлів cookie.

— ceejayoz

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

— igorsantos07

Чи правда, що браузер надсилає файли cookie Site2, коли є перенаправлення HTTP з Site1 на Site2?

— Зейгеїст

92

Як уже говорили інші, якщо буде дотримано обмеження на хост cookie, шлях тощо, воно буде надіслане 50 разів.

Але ви також запитали, чому: оскільки файли cookie є функцією HTTP, а HTTP - без стану. HTTP призначений для роботи без того, щоб сервер зберігав будь-який стан між запитами.

Насправді сервер не має надійного способу визначити, хто користувач надсилає даний запит; за одним веб-проксі може бути тисяча користувачів (і, отже, IP-адреса). Якби файли cookie надсилалися не кожен запит, сервер не міг би знати, який користувач запитує який-небудь ресурс.

Нарешті, у браузері немає поняття, потрібен сервер файлів cookie чи ні, він просто знає, що сервер проінструктував його відправити файл cookie для будь-якого запиту на foo.com, і він це робить. Іноді потрібні зображення (наприклад, динамічно генеровані на користувача), іноді - ні, але браузер не може розпізнати.

— дероберт
джерело

1

Це правда з HTTP 1.1, що є схемою мультиплексування? Тобто, запити поєднуються в єдине TCP-з'єднання. Звичайно, кожен запит отримується з доданою копією файлу cookie. Але якщо проблема викликає багато дублювання передач, HTTP 1.1 може оптимізувати. Хоча я не знаю, чи це насправді так ...

— Кріс Ной,

1

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

— Ian Clelland

1

@Ian Clelland: Клієнт повинен надіслати перше повідомлення, тому він не знає, який сервер надішле для Accept-Encoding (були сервери для надсилання цього поля, HTTP / 1.1 §14.3 говорить про його заголовок запиту). Проблема полягає в тому, що вона може змінюватись за URL-адресою навіть на одному сервері і може змінюватися з часом, тому змусити її працювати було б нетривіально.

— дероберт

1

@Chris: Ні, збереження просто зберігає налаштування TCP-з'єднання / відстежує накладні витрати, ось і все. Повні заголовки все ще надсилаються для кожного запиту. Однак конвеєрне планування (надсилання декількох запитів без очікування відповіді) може сильно допомогти. HTTP / 1.1 § 8.1 дає детальну інформацію.

— дероберт

21

Так. Кожен запит надсилає файли cookie, що належать одному домену. Вони не кешовані, оскільки HTTP без стану, що означає, що кожного запиту повинно бути достатньо, щоб сервер міг зрозуміти, що з ним робити. Скажімо, у вас є зображення, доступні лише певним користувачам; ви повинні надіслати свій авторський cookie з кожним із цих 50 запитів, щоб сервер знав, що ви, а не хтось інший чи гість, серед пулу запитів, які він отримує.

Сказавши це, куки-файли можуть не надсилатись з урахуванням інших обмежень, згаданих в інших відповідях, таких як налаштування HTTPS, шлях або домен. Тим більше, що важливо помітити: файли cookie не поділяються між доменами. Це допомагає зменшити розмір викликів HTTP для статичних файлів, таких як зображення та сценарії, які ви згадали.
Приклад: у вас є 4 файли cookie www.stackoverflow.com; якщо ви зробите запит www.stackoverflow.com/images/logo.png, всі ці 4 файли cookie будуть надіслані.
Однак, якщо ви запитаєте stackoverflow.com/images/logo.png(зауважте про зміну субдомену) або images.stackoverflow.com/logo.pngці 4 файли cookie не будуть присутніми - але, можливо, такі, які стосуються цих доменів, будуть.

Докладніше про файли cookie та зображення, які запитують, ви можете прочитати, наприклад, у цій публікації блогу StackOverflow .

— igorsantos07
джерело

10

Ні. Не кожен запит надсилає файли cookie. Це залежить від конфігурації файлів cookie та підключення клієнт-сервер.

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

— Іман Седігі
джерело

7

Cookie має властивість "шлях". Якщо "шлях = /", відповідь - Так.

— неоедмунд
джерело

Так, ви можете організувати структуру свого веб-сайту / програми таким чином, що всі URL-адреси, які потребують файлів cookie, є такими /app/або подібними - це збереже портативність, не потребуючи окремих субдоменів, щоб усунути зайві накладні витрати. Або ви могли б запустити поки що марну Google Analytics. Я так довго бачив заголовки печива, що цікавлюсь, чи в'язала їх бабуся.

— Джейк

7

Минуло 3 роки

Є ще одна причина, чому браузер не надсилає файли cookie. Ви можете додати crossOriginатрибут до свого <script>тегу, а значення - до "anonymous". Це запобіжить надсилання файлів cookie на сервер призначення. У 99,9% часу ваші javascripts є статичними файлами, і ви не генеруєте цей js-код на основі файлів cookie запиту. Якщо у вас є 1 Кб файлів cookie, а у вас є 200 ресурсів на вашій сторінці, ваш користувач завантажує 200 КБ, і це може зайняти деякий час на 3G і мати нульовий ефект на сторінці результатів. Відвідайте атрибут HTML: crossorigin для довідки.

— гілм
джерело

Будь ласка, поясніть.

— Джейк

4

@Jake ви можете додати атрибут crossOrigin до свого тегу <script>, а значення "анонімний". Це запобіжить надсилання файлів cookie на сервер призначення. У 99,9% часу ваші javascripts є статичними файлами, і ви не генеруєте цей js-код на основі файлів cookie запиту. Якщо у вас є 1 Кб файлів cookie, а у вас є 200 ресурсів на вашій сторінці, ваш користувач завантажує 200 КБ, і це може зайняти деякий час на 3G і мати нульовий ефект на сторінці результатів. Завітайте на сторінку developer.mozilla.org/en-US/docs/Web/HTML/… для довідок.

— gilm

4

Я знаю, що це стара нитка. Але я щойно помітив, що більшість браузерів не надсилає файли cookie для домену, якщо ви додаєте крапку. Наприклад http://example.com., не буде отримано файли cookie, встановлені для .example.com. Апач з іншого боку ставиться до них як до одного господаря. Я вважаю це корисним для того, щоб ускладнити відстеження між доменом для зовнішніх ресурсів, які я включаю, але ви можете також використовувати його з міркувань продуктивності. Зверніть увагу на це гальмування перевірки httpsсертифікатів. Я провів кілька тестів за допомогою браузерних знімків та власних пристроїв. Злом працює майже у всіх браузерах, за винятком safari (для мобільних пристроїв та настільних ПК), який включатиме файли cookie у запиті.

— Геллвайлер
джерело

Як це "ускладнює відстеження між доменом для зовнішніх ресурсів, які я включаю"? Ви говорите про Farcebook Like та подібні віджети - які ми знаємо, відстежуючи перегляд випадково все ще зареєстрованих користувачів?

— Джейк

Так. Це ускладнить це, оскільки більшість браузерів не надсилає файли cookie разом. Отже, якщо ви включаєте щось із google.com, наприклад, і ви ввійшли в Google, Google не може зв’язати два запити. Це не гарантується жорстко, деякі браузери все одно надіслали файли cookie, і є менш надійні та менш використовувані методи для ідентифікації користувачів (наприклад, IP-адреси), які все ще працюватимуть. Найбільшим недоліком є те, що ви не можете використовувати HTTPS, що робить його сьогодні марним.

— Gellweiler

0

Коротка відповідь - так. Нижче наведені рядки з документації на JS

Колись файли cookie використовувались для загального зберігання на стороні клієнта. Хоча це було законно, коли вони були єдиним способом зберігання даних на клієнті, тепер рекомендується використовувати сучасні API зберігання. Файли cookie надсилаються з кожним запитом, тому вони можуть погіршити продуктивність (особливо для мобільних даних).

— Яшвін Мунсвавала
джерело