Todas as solicitações da Web enviam cookies do navegador?

198

Toda solicitação da Web envia os cookies do navegador?

Não estou falando de visualizações de página, mas de uma solicitação de imagem, .jsarquivo etc.

Atualizar Se uma página da web tiver 50 elementos, ou seja, 50 solicitações. Por que enviar os mesmos cookies para cada solicitação, ele não armazena em cache ou sabe que já o possui?

cookies mrblah
fonte
8
Eu não acho que o cache seja possível nessa situação - estamos falando do navegador enviando dados para o servidor, e não o contrário. Você não pode ter certeza de que o servidor "já o possui" depois que o usuário enviou uma solicitação, por vários motivos. Pode haver um grande número de servidores que não se comunicam; o servidor pode não querer (ou ter espaço) se lembrar de nada sobre solicitações anteriores - o HTTP deve ser sem estado; todo pedido deve ser independente do resto. Por esse motivo, cookies, como credenciais de autenticação, devem ser enviados a cada solicitação.
22610 Ian Clelland
Eu mencionei porque o cache não faz sentido para os cookies em uma atualização para a minha resposta: stackoverflow.com/a/1336178/102960
igorsantos07

Respostas:

198

Sim, desde que a URL solicitada esteja dentro do mesmo domínio e caminho definido no cookie (e todas as outras restrições - seguras, normais, não expiradas, etc.) permaneçam, o cookie será enviado para todas as solicitações.

Ian Clelland
fonte
103
Aliás, é por isso que ferramentas de velocidade de página como o Google Page Speed ​​ou o YSlow do Yahoo recomendam a veiculação de conteúdo estático de um domínio separado, sem cookies.
ceejayoz
Eu mencionei a respeito de servir o conteúdo de um domínio separado na minha atualizados resposta: stackoverflow.com/a/1336178/102960
igorsantos07
É verdade que o navegador envia Cookies do Site2 quando há um redirecionamento HTTP do Site1 para o Site2?
Zeigeist
92

Como já foi dito, se as restrições de host, caminho etc. do cookie forem atendidas, ele será enviado 50 vezes.

Mas você também perguntou o porquê: porque os cookies são um recurso HTTP e o HTTP é sem estado. O HTTP foi projetado para funcionar sem que o servidor armazene qualquer estado entre solicitações.

De fato, o servidor não possui uma maneira sólida de reconhecer qual usuário está enviando uma determinada solicitação; pode haver mil usuários atrás de um único proxy da web (e, portanto, endereço IP). Se os cookies não fossem enviados a cada solicitação, o servidor não teria como saber qual usuário está solicitando qualquer recurso.

Por fim, o navegador não tem idéia se o servidor precisa ou não dos cookies, apenas sabe que o servidor o instruiu a enviar o cookie para qualquer solicitação ao foo.com, e assim o faz. Às vezes, as imagens precisam delas (por exemplo, geradas dinamicamente por usuário), às vezes não, mas o navegador não sabe.

derobert
fonte
1
Isso é verdade com o HTTP 1.1, que é um esquema de multiplexação? Ou seja, os pedidos são agrupados em uma única conexão TCP. Obviamente, cada solicitação é recebida com uma cópia do cookie anexada. Mas se a preocupação for muita duplicação de transmissão, o HTTP 1.1 poderá otimizar. Embora eu não sei se ele realmente faz ...
Chris Noe
1
Em seguida, o problema se torna "a quais solicitações o navegador pretendia anexar os cookies?" O servidor define a política com o cookie, para decidir quais domínios e quais caminhos de URL, o cookie deve ser enviado de volta, mas depois o esquece. Você precisaria de uma maneira de especificar que determinadas solicitações na conexão continham o cookie e outras não. Definitivamente, isso não existe no HTTP / 1.1, exceto pela inclusão explícita em todas as solicitações. Honestamente, uma solução melhor (compatível com os padrões) para reduzir a largura de banda seria a codificação de conteúdo gzip do lado do cliente, mas ninguém ainda suporta isso.
22610 Ian Clelland
1
@Ian Clelland: O cliente precisa enviar a primeira mensagem, para que não saiba o que o servidor enviaria para Accept-Encoding (se os servidores enviarem esse campo, o HTTP / 1.1 §14.3 diz que é um cabeçalho de solicitação). E o problema é que ele pode variar por URL, mesmo no mesmo servidor, e pode mudar com o tempo, portanto, fazê-lo funcionar não seria trivial.
derobert
1
@ Chris: Não, o keepalive apenas salva a sobrecarga de configuração / desmontagem da conexão TCP, só isso. Cabeçalhos completos ainda são enviados para cada solicitação. No entanto, o pipelining (enviando várias solicitações sem esperar pela resposta) pode ajudar bastante. HTTP / 1.1 §8.1 fornece detalhes.
Derobert 27/08/2009
21

Sim. Toda solicitação envia os cookies que pertencem ao mesmo domínio. Eles não são armazenados em cache porque o HTTP é sem estado, o que significa que toda solicitação deve ser suficiente para o servidor descobrir o que fazer com ela. Digamos que você tenha imagens acessíveis apenas por determinados usuários; você deve enviar seu cookie de autenticação com cada uma dessas 50 solicitações, para que o servidor saiba que é você e não outra pessoa ou um convidado entre o conjunto de solicitações que está recebendo.

Dito isto, os cookies podem não ser enviados, dadas outras restrições mencionadas nas outras respostas, como configuração HTTPS, caminho ou domínio. Especialmente lá, uma coisa importante a ser observada: os cookies não são compartilhados entre domínios. Isso ajuda a reduzir o tamanho das chamadas HTTP para arquivos estáticos, como as imagens e scripts mencionados.
Exemplo: você tem 4 cookies em www.stackoverflow.com; se você solicitar www.stackoverflow.com/images/logo.png, todos esses 4 cookies serão enviados.
No entanto, se você solicitar stackoverflow.com/images/logo.png(observe a alteração do subdomínio) ou images.stackoverflow.com/logo.png, esses 4 cookies não estarão presentes - mas talvez aqueles relacionados a esses domínios estejam.

Você pode ler mais sobre cookies e imagens solicitando, por exemplo, nesta postagem no blog do StackOverflow .

igorsantos07
fonte
10

Não. Nem toda solicitação envia os cookies. Depende da configuração do cookie e da conexão cliente-servidor.

Por exemplo, se a secureopção do seu cookie estiver definida como true, ele deverá ser transmitido por uma conexão HTTPS segura. Significa que quando você vê o site com protocolo HTTP, esses cookies não serão enviados pelos navegadores, pois o sinalizador seguro é verdadeiro.

Iman Sedighi
fonte
7

O cookie possui uma propriedade "path". Se "caminho = /", a resposta for Sim.

neoedmund
fonte
Sim, você pode organizar sua estrutura de site / aplicativo de forma que todos os URLs que exigem cookies sejam iguais /app/ou semelhantes - ele manteria a portabilidade sem a necessidade de subdomínios separados para eliminar a sobrecarga redundante. Ou você pode abandonar o agora inútil Google Analytics para começar. Eu tenho visto cabeçalhos de biscoito há tanto tempo que me pergunto se minha avó os estava tricotando.
Jake
7

3 anos se passaram

Há outra razão pela qual um navegador não envia cookies. Você pode adicionar um crossOriginatributo à sua <script>tag e o valor para "anonymous". Isso impedirá que os cookies sejam enviados ao servidor de destino. Em 99,9% do tempo, seus javascripts são arquivos estáticos e você não gera esse código js com base nos cookies da solicitação. Se você possui 1 KB de cookies e possui 200 recursos em sua página, seu usuário está enviando 200 KB e isso pode levar algum tempo no 3G e ter efeito nulo na página de resultados. Visite o atributo HTML: crossorigin para referência.

gilm
fonte
Por favor explique.
Jake
4
@ Jake, você pode adicionar um atributo crossOrigin à sua tag <script> e o valor para "anônimo". Isso impedirá que os cookies sejam enviados ao servidor de destino. Em 99,9% do tempo, seus javascripts são arquivos estáticos e você não gera esse código js com base nos cookies da solicitação. Se você possui 1 KB de cookies e possui 200 recursos em sua página, seu usuário está enviando 200 KB e isso pode levar algum tempo no 3G e ter efeito nulo na página de resultados. Visite developer.mozilla.org/en-US/docs/Web/HTML/… para referência.
gilm
4

Eu sei que este é um tópico antigo. Mas acabei de notar que a maioria dos navegadores não envia cookies para um domínio se você adicionar um ponto à direita. Por exemplo http://example.com., não receberá cookies definidos para .example.com. O Apache, por outro lado, os trata como o mesmo host. Acho isso útil para tornar o rastreamento entre domínios mais difícil para os recursos externos que incluí, mas você também pode usá-lo por motivos de desempenho. Observe que isso freia a validação de httpscertificados. Fiz alguns testes usando os navegadores e meus próprios dispositivos. O hack funciona em quase todos os navegadores, exceto no safari (móvel e desktop), que incluirá cookies na solicitação.

Gellweiler
fonte
Como "torna o rastreamento entre domínios mais difícil para recursos externos que eu incluo"? Você está falando sobre o Farcebook Like e esses widgets - que sabemos acompanhar a navegação de usuários acidentalmente ainda conectados?
Jake
Sim. Isso tornará mais difícil, porque a maioria dos navegadores não envia os cookies. Portanto, se você incluir algo do google.com, por exemplo, e estiver conectado ao google, o Google não poderá vincular as duas solicitações. Isso não é garantido, alguns navegadores enviaram os cookies de qualquer maneira e existem métodos menos confiáveis ​​e menos usados ​​para identificar usuários (como endereços IP) que ainda funcionarão. A maior desvantagem é que você não pode usar HTTPS, o que meio que o torna inútil hoje.
Gellweiler # 11/17
0

Resposta curta é Sim. As linhas abaixo são da documentação JS

Os cookies já foram usados ​​para armazenamento geral do lado do cliente. Embora isso fosse legítimo quando eram a única maneira de armazenar dados no cliente, agora é recomendável usar APIs de armazenamento modernas. Os cookies são enviados a cada solicitação, para piorar o desempenho (especialmente para conexões de dados móveis).

Yashwin Munsadwala
fonte