Segundo a rfc 2109
Um cookie pode ter no maximo 4k, um navegador pode ter no maximo 300 cookies e cada dominio no maximo 30 cookies.
Abaixo o documento na integra:
Netscape Communications
Fevereiro 1997
HTTP Estado mecanismo de gestão
Status do presente Memo
Este documento especifica um protocolo Internet normas para a pista
Comunidade Internet, e solicita discussão e sugestões para
melhorias. Por favor, referir-se a actual edição do “Internet
Jornal Protocolo Standards “(1 DST) para o estado de normalização
e do estatuto do presente protocolo. A distribuição deste memorando é ilimitado.
1. RESUMO
Este documento especifica uma maneira de criar uma sessão com stateful HTTP
solicitações e respostas. Ela descreve dois novos cabeçalhos, e Cookie
Set-Cookie, que carregam informações entre os participantes estatais
servidores de origem e os agentes do utilizador. O método descrito aqui difere
a partir da Netscape Cookie proposta, mas pode interoperar com
HTTP/1.0 usuários que utilizam agentes da Netscape método. (Veja o histórico
seção.)
2. TERMINOLOGIA
Os termos utilizador agente, cliente, servidor proxy, e têm origem servidor
o mesmo significado que na especificação HTTP/1.0.
- Nome de host totalmente qualificado (FQHN) significa que o pleno-qualificados
domain name (FQDN) de um anfitrião (ou seja, um total domínio especificados
nome que termina em um domínio de topo como o. com ou. Reino Unido), ou o
numéricos IP (Internet Protocol) endereço de um host. O plenamente
qualificada nome do domínio é preferida; uso do endereço IP numérico é
fortemente desencorajado.
As condições de acolhimento e de solicitação de pedido-URI referem-se aos valores do cliente
seria enviado para o servidor como, respectivamente, o hospedeiro (mas não do porto)
abs_path e porções do absoluteURI (http_URL) do HTTP
solicitação linha. Note que o pedido de acolhimento tem de ser um FQHN.
Kristol Standards Track & Montulli [Page 1]
RFC 2109 HTTP Estado mecanismo de gestão fevereiro 1997
Hosts nomes pode ser especificado quer como um endereço IP ou um FQHN
string. Às vezes temos uma comparação com outro nome de host. A anfitriã da
nome de domínio jogos acolhimento B do caso
* Ambos são nomes de host e os seus endereços IP nome do host cordas jogo
exactamente; ou
* Ambos são nomes de host FQDN cordas e as suas cordas correspondem nome de host
exactamente; ou
* Um FQDN é uma string e tem a forma NB, onde N é um nome não-vazio
string, B tem a forma. B ‘, e B’ é um FQDN string. (Então, x.y.com
domain-jogos. y.com mas não y.com.)
Note que o domínio de jogo não é uma operação comutativa: abccom
domain-jogos. c.com, mas não o inverso.
Porque foi usado no Netscape inicial da execução do estado
gestão, vamos usar o termo “cookie” para se referir ao estado
informação que passa entre uma origem servidor e usuário agente, e
que será armazenado pelo agente do utilizador.
3. Estado e sessões
Este documento descreve uma forma de criar stateful com sessões HTTP
solicitações e respostas. Atualmente, HTTP responder a cada
pedido, sem que o cliente relativas ao pedido anterior ou
subsequentes pedidos, a técnica permite que clientes e servidores
Desejo para a troca de informações ao estado local e solicitações HTTP
respostas dentro de um contexto maior, que nos termos de uma “sessão”. Este
contexto poderia ser usado para criar, por exemplo, um “carrinho”, em
utilizador seleções que podem ser agregados antes da compra, ou uma
Revista navegando sistema, em que um usuário da leitura anterior afecta
ofertas que são apresentados.
Existem, naturalmente, muitos contextos diferentes potenciais e, portanto, muitas
diferentes tipos potenciais de sessão. Os designers “paradigma
sessões criadas pela troca de cookies tem esses atributos chave:
1. Cada sessão tem um início e um fim.
2. Cada sessão é relativamente curta.
3. Ou o usuário agente ou de origem pode encerrar um servidor
sessão.
4. A sessão está implícito na troca de informações de estado.
Kristol Standards Track & Montulli [Página 2]
RFC 2109 HTTP Estado mecanismo de gestão fevereiro 1997
4. ESQUEMA
Temos aqui um esboço caminho para uma origem estatal servidor para enviar informações
agente para o usuário, e para o usuário agente de voltar ao estado
a informação do servidor origem. O objetivo é ter um mínimo
impacto sobre o HTTP e os agentes do utilizador. Somente servidores que precisam de origem
manter sessões iria sofrer qualquer impacto significativo, e que
impacto pode ser largamente comum limita a Gateway Interface (CGI)
programas, a menos que o servidor fornece mais sofisticados estado
apoio à gestão. (Veja Implementação considerações, abaixo.)
4,1 Sintaxe: Geral
Os dois cabeçalhos de gestão estatal, e Set-Cookie Cookie, têm comum
sintática propriedades envolvendo pares valor-atributo. A seguir
gramática utiliza a notação, e fichas DIGIT (dígitos decimais) e
token (informalmente, uma seqüência de não-especial, não-brancos espaço
caracteres) a partir da especificação HTTP/1.1 [RFC 2068] para descrever
sua sintaxe.
- av = av pares de par-par *(”;” av)
AV-pair = attr [ "=" valor]; valor opcional
attr = token
= valor palavra
palavra = token | citou-corda
Atributos (nomes) (attr) são caso-insensitivo. White espaço é
permitidas entre fichas. Note que, embora a sintaxe acima
descrição mostra valor como opcional, attrs exigir mais deles.
NOTA: A sintaxe acima permite que entre o branco eo atributo
o sinal =.
4,2 origem servidor papel
4.2.1 Geral
A origem servidor inicia uma sessão, se assim o desejar. (Note que
“sessão” aqui não se refere a uma conexão de rede, mas persistente
para uma sessão lógico criado a partir de solicitações HTTP e respostas. O
presença ou ausência de uma conexão persistente não deverá ter qualquer efeito
sobre o uso de cookies-derivados sessões). Para iniciar uma sessão, o
origem servidor retorna uma resposta cabeçalho extra para o cliente, Set -
Cookie. (Os detalhes seguem mais tarde.)
Um usuário agente retorna um pedido cabeçalho Cookie (veja abaixo) para o
origem servidor se ele optar por continuar a sessão. A origem servidor
maio ignorá-lo ou utilizá-la para determinar o estado actual da
Kristol Standards Track & Montulli [Página 3]
RFC 2109 HTTP Estado mecanismo de gestão fevereiro 1997
sessão. Ela pode enviar de volta para o cliente uma resposta cabeçalho Set-Cookie
com o mesmo ou diferente informação, que pode ou não enviar nenhum Set-Cookie
cabeçalho de todo. A origem servidor efetivamente termina com uma sessão
enviar ao cliente um cabeçalho Set-Cookie com Max-Age = 0.
Servidores pode retornar uma resposta cabeçalhos Set-Cookie com qualquer resposta.
Usuário agentes devem enviar Cookie pedido cabeçalhos, sujeito a outras
regras detalhadas a seguir, a cada pedido.
Uma origem servidor pode incluir vários Set-Cookie cabeçalhos em um
resposta. Note-se que um gateway poderia intervir várias vezes, tais
cabeçalhos em um único cabeçalho.
4.2.2 Sintaxe Set-Cookie
A sintaxe para o cabeçalho Set-Cookie resposta é
set-cookie = “Set-Cookie:” cookies
cookies = 1 # cookie
NOME cookie = “=” VALOR *(”;” cookie-av)
NOME attr =
VALOR = valor
cookie-av = “Comentar” “=” valor
| “Site” “=” valor
| “Max-Age” “=” valor
| “Caminho” “=” valor
| “Secure”
| “Versão” “=” 1 * DIGIT
Informalmente, os Set-Cookie resposta cabeçalho compreende o token Set -
Cookie:, seguido por uma lista separada por vírgulas de um ou mais cookies.
Cada cookie começa com um nome = valor par, seguido de zero ou mais
ponto e vírgula-separados dos pares valor-atributo. A sintaxe para
atributo de valor pares foi mostrado anteriormente. Os atributos específicos e
a semântica do seguinte modo os seus valores. O atributo NAME = VALOR -
valor par deve estar em primeiro lugar em cada um cookie. Os outros, quando presentes,
Pode ocorrer em qualquer ordem. Se um atributo aparece mais de uma vez em um
cookie, o comportamento é indefinida.
NAME = VALUE
Necessário. O nome do Estado informações ( “cookie”) é DENOMINAÇÃO,
eo seu valor é valor. Nomes que começam com US $ estão reservados para
outros usos e não deve ser utilizado por aplicações.
Kristol Standards Track & Montulli [Página 4]
RFC 2109 HTTP Estado mecanismo de gestão fevereiro 1997
O valor é pouco transparente para o usuário e agente pode ser qualquer coisa a
origem servidor escolhe a enviar, possivelmente em um servidor-selecionados
codificação ASCII imprimíveis. “Opaca” implica que o conteúdo é de
interesse e relevância apenas para o servidor origem. O conteúdo
maio, na verdade, ser lido por qualquer um que analisa a Set-Cookie
cabeçalho.
Comentar comentar =
Opcional. Porque os cookies podem conter informações particulares sobre uma
utilizador, o cookie permite que um atributo origem servidor para o seu documento
destinados uso de um cookie. O usuário pode inspecionar as informações para
decidir se deseja iniciar ou prosseguir uma sessão com esse cookie.
Domínio = domínio
Opcional. O Domínio atributo especifica o domínio para o qual o
cookie é válido. Um domínio explicitamente especificado deve sempre começar
com um ponto.
Max-Age = delta-segundo
Opcional. O Max-Age atributo define o tempo de vida dos
cookie, em segundos. Delta-O segundo é um valor não-decimais
inteiro negativo. Após o delta-segundo decorrer segundo, o cliente
deve descartar o cookie. Um valor de zero significa que o cookie
deve ser rejeitada imediatamente.
Path = caminho
Opcional. O Caminho atributo especifica o subconjunto de URLs a
que este cookie se aplica.
Secure
Opcional. O Secure atributo (sem valor) direciona o usuário
Agente de utilizar apenas (não especificada) assegurar meios de contactar a origem
sempre que o servidor envia de volta este cookie.
O agente usuário (possivelmente sob o controle do usuário) podem determinar
qual o nível de segurança que considere adequadas para “garantir”
cookies. O Secure atributo deve ser considerada de segurança
aconselhamento do servidor para o usuário agente, indicando que está em
a sessão do interesse de proteger o cookie conteúdo.
Version = versão
Necessário. A Versão atributo, um decimal inteiro, identifica a
qual a versão do estado gestão especificação do cookie
conforma. Para esta especificação, Version = 1 se aplica.
Kristol Standards Track & Montulli [Página 5]
RFC 2109 HTTP Estado mecanismo de gestão fevereiro 1997
4.2.3 Controladores cashing
Um servidor deve estar cientes origem do efeito de eventuais caching
de ambos os recursos e retornou a Set-Cookie cabeçalho. Caching
“público” documentos é desejável. Por exemplo, se o servidor origem
pretende utilizar um documento público, tais como uma “porta” como uma página
sentinela para indicar o início de uma sessão para a qual um Set -
Cookie resposta cabeçalho devem ser gerados, a página deve ser armazenada
em caches “pré-caducou” origem de modo a que o servidor irá ver mais
solicitações. “Private documentos”, por exemplo, aqueles que contêm
informações estritamente privado a uma sessão, não devem ser colocados em cache no
caches compartilhados.
Se o cookie é para ser usado por um único usuário, o Set-Cookie
cabeçalho não deve ser armazenada em cache. Um Set-Cookie cabeçalho que se destina a
ser partilhado por vários utilizadores podem estar em cache.
A origem servidor deve enviar os seguintes adicionais HTTP/1.1
cabeçalhos resposta, dependendo de circunstâncias:
* Para suprimir caching do cabeçalho Set-Cookie: Cache-controle: não -
cache = “set-cookie”.
e um dos seguintes procedimentos:
* Para suprimir cache de um documento privado em caches partilhada: Cache -
controle: privado.
* Para permitir o cache de um documento, e exigir que ele seja validado
antes de a devolver ao cliente: Cache-controle: deve-revalidar.
* Para permitir o cache de um documento, mas para exigir que os caches proxy
(agente usuário não caches) validar-lo antes de a devolver ao
client: Cache-control: proxy-revalidar.
* Para permitir o cache de um documento e solicitar que ele seja validado
antes de a devolver ao cliente (por “pré-termina-lo”):
Cache-control: max-age = 0. Nem todos os caches vai revalidar o
documento em todos os casos.
HTTP/1.1 servidores devem enviar Expira: old-data (em que data é um velho -
longa data no passado) sobre respostas contendo Set-Cookie resposta
cabeçalhos a menos que eles sabem para determinados (por meio fora da banda) que
não há downsteam HTTP/1.0 proxies. HTTP/1.1 servidores podem enviar
Cache-Control outras directivas que permitam a caching HTTP/1.1
proxies, além da Expira: old-data directiva; o Cache -
Controle directiva irá sobrepor-se ao Expira: old-data para HTTP/1.1
proxies.
Kristol Standards Track & Montulli [Página 6]
RFC 2109 HTTP Estado mecanismo de gestão fevereiro 1997
4,3 User Agent papel
4.3.1 Interpretando Set-Cookie
O usuário faixa distinto agente mantém informações de estado que chega
através Set-Cookie resposta cabeçalhos origem de cada servidor (como
distinguidas por nome ou endereço IP e porto). O agente usuário
aplica estes padrões para atributos opcionais que estão faltando:
VersionDefaults a “velha cookie” comportamento como originalmente especificados por
Netscape. Veja o histórico seção.
Domínio Padrões para o pedido de acolhimento. (Note que não existe um ponto em
o início do pedido de acolhimento.)
Max-AgeThe comportamento padrão é a de descartar o cookie quando o usuário
Agente saídas.
Padrões caminho para o caminho do URL que gerou o pedido
Set-Cookie resposta, até, mas não incluindo, a
a maioria de direita /.
Secure Se ausente, o usuário poderá enviar o agente durante um cookie
inseguro canal.
4.3.2 Rejeitar Cookies
Para prevenir possíveis violações de segurança ou privacidade, um agente usuário
rejeita um cookie (não deve armazenar seus dados) se qualquer das
seguinte é verdadeiro:
* O valor para o Caminho atributo não é um prefixo do pedido -
URI.
* O valor para o Site não contém nenhum atributo ou incorporados pontos
não começar com um ponto.
* O valor para o pedido de acolhimento não correspondam ao domínio-Domínio
atributo.
* A pedido de acolhimento é um FQDN (não endereço IP) e tem a forma HD,
onde D é o valor do atributo de domínio, e H é uma string
que contém um ou mais pontos.
Exemplos:
* Um pedido de Set-Cookie-host yxfoo.com de Domínio =. foo.com
seria rejeitada, porque H é yx e contém um ponto.
Kristol Standards Track & Montulli [Página 7]
RFC 2109 HTTP Estado mecanismo de gestão fevereiro 1997
* Um pedido de Set-Cookie-host x.foo.com de Domínio =. seria foo.com
ser aceite.
* Um Set-Cookie com Domínio =. com.br ou Domain =. com., Será sempre
rejeitadas, porque não há embutido dot.
* Um Set-Cookie com Domain = ajax.com serão rejeitadas, porque a
Valor de Domínio não comece com um ponto.
4.3.3 Gerenciamento de Cookie
Se um agente usuário recebe uma resposta cabeçalho Set-Cookie cujo nome é
o mesmo que um pré-existentes cookie, e cujo domínio e Path
atribuem valores exatamente (corda) correspondem às de uma pré-existentes
cookie, o novo cookie substitui o antigo. No entanto, se o Set -
Cookie tem um valor para Max-Idade do zero, os (antigos e novos) cookie é
descartados. Caso contrário cookies acumular até que expiram (recursos
licenciamento), momento em que eles são descartados.
Porque os agentes do utilizador ter finito espaço no qual os cookies para armazenar, eles
também pode descartar mais velhos cookies para criar espaço para mais novas, utilizando,
por exemplo, um mínimo de recém-algoritmo utilizado, juntamente com constrangimentos
sobre o número máximo de cookies que cada servidor pode definir origem.
Se um cabeçalho Set-Cookie resposta inclui um comentário atributo, o
agente usuário deve guardar essa informação em uma forma legível por humanos
com o cookie e deve exibir o comentário como parte de um texto
cookie inspecção interface de utilizador.
Usuário agentes deverão permitir que o usuário de controlar a destruição cookie. Um
- raramente utilizado cookie maio funcionar como um “dossier preferências” para a
aplicações de rede, e um usuário pode querer mantê-lo mesmo que seja
- recentemente-o menos utilizado cookie. Uma possível implementação seria
uma interface que permite o armazenamento permanente de um cookie através de uma
caixa (ou, inversamente, a sua destruição imediata).
Privacidade considerações ditar que o usuário tem considerável
controlo de gestão cookie. A seção contém mais PRIVACIDADE
informação.
4.3.4 Enviando para os Cookies Origem Server
Quando se envia uma solicitação para um servidor origem, o usuário envia um agente
Cookie pedido cabeçalho à origem servidor se ele tiver que são cookies
aplicável ao pedido, com base em
* O pedido de acolhimento;
Kristol Standards Track & Montulli [Página 8]
RFC 2109 HTTP Estado mecanismo de gestão fevereiro 1997
* O pedido-URI;
* O cookie da idade.
A sintaxe para o cabeçalho é:
cookie = “Cookie:” cookie-versão
1 *((”;” | “,”) cookie-valor)
cookie-valor NAME = “=” o valor [ ";" caminho] [ ";" domínio]
cookie-versão = “$ Version” “=” valor
NOME attr =
VALOR = valor
path = “$ Path” “=” valor
domain = “$ Domínio” “=” valor
O valor do cookie-versão atributo deve ser o valor a partir do
Versão atributo, se for o caso, da correspondente Set-Cookie resposta
cabeçalho. Caso contrário, o valor de cookie-versão é 0. O valor para
atribuem o caminho deve ser o valor da senda atributo, se for o caso,
as correspondentes cabeçalho Set-Cookie resposta. Caso contrário, a
atributo deve ser omitidos na Cookie pedido cabeçalho. O
Valor para o domínio atributo deve ser o valor a partir do Domínio
atributo, se for o caso, as correspondentes cabeçalho Set-Cookie resposta.
Caso contrário, o atributo deve ser omitida a partir da solicitação Cookie
cabeçalho.
Note que não há qualquer comentário atributo no cabeçalho Cookie pedido
o que corresponde a um no cabeçalho Set-Cookie resposta. O usuário
agente não voltar a comentar a informação do servidor origem.
As seguintes regras aplicam-se a escolha aplicável a partir de valores de cookies
entre todos os cookies o usuário tem agente.
Domínio Seleção
A origem do servidor host totalmente qualificado, nome de domínio deve corresponder
Domínio do atributo do cookie.
Caminho Seleção
O Caminho atributo do cookie deve corresponder a um prefixo da
solicitar-URI.
Max-idade seleção
Os cookies que já expirou deveria ter sido descartado e, portanto,
não são enviadas a um servidor origem.
Kristol Standards Track & Montulli [Página 9]
RFC 2109 HTTP Estado mecanismo de gestão fevereiro 1997
Se vários cookies satisfazem os critérios acima referidos, eles são ordenados em
Cookie o cabeçalho de tal ordem que aqueles com mais específicos Caminho atributos
preceder aqueles com menos específico. Ordenação em relação aos outros
atributos (e.g., Domain) é indeterminado.
Nota: para compatibilidade com versões anteriores, o separador no cabeçalho Cookie
É ponto e vírgula (;) em todo o lado. Um servidor também deve aceitar a vírgula (,)
como separador entre cookie-valores para a futura compatibilidade.
4.3.5 Enviando Cookies em verificar Transações
Os utilizadores devem ter controle sobre sessões, a fim de assegurar a privacidade.
(Ver secção PRIVACIDADE abaixo.) Para simplificar a implementação e para
impedir uma camada adicional de complexidade quando as garantias adequadas
Existem, no entanto, este documento faz uma distinção entre transacções que
são verificáveis e os que estão a verificar. A transação é
verificar se o usuário tem a possibilidade de rever o pedido prévio-URI
a sua utilização na operação. A operação é verificar se o
usuário não tiver essa opção. Verificar operações tipicamente
surgem quando um agente usuário automaticamente pedidos inlined ou incorporados
entidades ou quando se resolve reorientação (3XX) respostas de um
origem servidor. Normalmente a origem transacção, a transacção
que o usuário inicie, é verificável, e que a transação maio
directa ou indirectamente induzir o usuário a fazer verificar agente
transacções.
Quando se torna verificar uma transação, um agente deve permitir que um usuário
sessão somente se um cookie em um domínio D atributo foi enviada ou
recebeu a sua origem na operação, de tal forma que o nome do host no
URI-Pedido de verificar a operação de domain-jogos D.
Esta restrição impede um serviço malicioso autor de utilizar
verificar utilizador operações para induzir um agente para iniciar ou continuar
uma sessão com um servidor em um domínio diferente. A partida ou
continuação de tais sessões poderia ser contrária à privacidade
expectativas do usuário, e também poderia ser um problema de segurança.
Usuário agentes podem oferecer opções configuráveis que permitem que o usuário agente,
autónomo ou de qualquer programas que o usuário executa agente, a ignorar
a regra acima, enquanto estas sobrepor opções default para “off”.
Muitos agentes já atual usuário fornecer uma análise opção que teria
render muitas ligações verificáveis. Por exemplo, alguns agentes usuário exibir
o URL que seria referenciado para um determinado link quando o mouse
ponteiro é colocado sobre o link. O usuário pode, por conseguinte, determinar
saber se a visitar o site antes de provocar o browser para o fazer.
(Embora não seja aplicado ao usuário atual agentes, uma técnica semelhante
poderia ser utilizada para um botão usado para enviar um formulário - o usuário agente
Kristol Standards Track & Montulli [Página 10]
RFC 2109 HTTP Estado mecanismo de gestão fevereiro 1997
poderiam apresentar as medidas a tomar caso o usuário que foram para selecionar
botão.) No entanto, mesmo esta não faria todos os links verificáveis, para
exemplo, ligações a carregado automaticamente imagens não é normalmente
sujeitas ao “rato” verificação.
Muitos agentes usuário também prever a possibilidade de um usuário para visualizar o HTML
fonte de um documento, ou para salvar a fonte para um arquivo externo onde
que podem ser vistas por um outro aplicativo. Embora tal opção não
proporcionar um mecanismo de revisão bruto, alguns utilizadores poderão não considerá-lo
aceitável para este fim.
Como um servidor de 4,4 Origem Interpreta o cabeçalho Cookie
Um usuário agente retorna grande parte da informação no cabeçalho Set-Cookie
a origem do servidor quando o Caminho de correspondências que atribuem um novo
solicitar. Sempre que receber um cookie header, o servidor deverá origem
tratar com cookies cujos nomes prefixo é de US $ especialmente, como um atributo
adjacentes para o cookie. O valor para tal, deve ser um nome
interpretado como aplicável aos lexically (da esquerda para a direita) mais recente
cookie cujo nome não têm o prefixo $. Se não houver nenhuma
cookie anterior, o valor aplica-se ao mecanismo de cookie como uma
inteiro. Por exemplo, considere o cookie
Cookie: $ Version = “1″; Cliente = “WILE_E_COYOTE”;
$ Path = “/ acme”
Versão $ aplica-se ao mecanismo de cookie como um todo (e dá a
número de versão para o mecanismo de cookie). $ Path é um atributo
cujo valor (/ acme) define o Caminho atributo que foi utilizado quando o
Cliente foi definida em um cookie Set-Cookie resposta cabeçalho.
4,5 cache proxy papel
Uma razão para separar o estado de informações tanto de uma URL e
documento conteúdo é o de facilitar o escalonamento que permite caching.
Para apoiar os cookies, um cache proxy deve obedecer essas regras já em
o HTTP especificação:
* Honra pedidos a partir do cache, se possível, com base em cache validade
regras.
* Pass, ao longo de um cookie no cabeçalho solicitar a qualquer pedido que o procurador
deve fazer de outro servidor.
* Voltar a resposta para o cliente. Set-Cookie incluir qualquer resposta
cabeçalho.
Kristol Standards Track & Montulli [Página 11]
RFC 2109 HTTP Estado mecanismo de gestão fevereiro 1997
* Cache recebeu a resposta sujeita ao controlo do costume
cabeçalhos, como expirar, Cache-control: no-cache, e Cache -
controle: privado,
* Cache do Set-Cookie sujeito ao controlo do cabeçalho usual,
Cache-control: no-cache = “set-cookie”. (O cabeçalho Set-Cookie
Normalmente não deve ser armazenada em cache.)
Proxies não devem introduzir Set-Cookie (Cookie) cabeçalhos das suas próprias
no proxy respostas (pedidos).
5. EXEMPLOS
5,1 Exemplo 1
A maioria dos detalhes do pedido e resposta cabeçalhos foi omitido. Assumamos
o usuário não tem nenhum agente cookies armazenados.
1. User Agent -> Servidor
POST / acme / login HTTP/1.1
[formulário de dados]
Usuário identifica autodeterminação através de um formulário.
2. Servidor -> User Agent
HTTP/1.1 200 OK
Set-Cookie: Cliente = “WILE_E_COYOTE”; Version = “1″; Path = “/ acme”
Cookie reflete a identidade do usuário.
3. User Agent -> Servidor
POST / acme / pickitem HTTP/1.1
Cookie: $ Version = “1″; Cliente = “WILE_E_COYOTE”; $ Path = “/ acme”
[formulário de dados]
Usuário seleciona um item de “cesto”.
4. Servidor -> User Agent
HTTP/1.1 200 OK
Set-Cookie: Part_Number = “Rocket_Launcher_0001″; Version = “1″;
Path = “/ acme”
Cesto de contém um item.
Kristol Standards Track & Montulli [Página 12]
RFC 2109 HTTP Estado mecanismo de gestão fevereiro 1997
5. User Agent -> Servidor
POST / acme / navegação HTTP/1.1
Cookie: $ Version = “1″;
Cliente = “WILE_E_COYOTE”; $ Path = “/ acme”;
Part_Number = “Rocket_Launcher_0001″; $ Path = “/ acme”
[formulário de dados]
Usuário seleciona navegação método de formulário.
6. Servidor -> User Agent
HTTP/1.1 200 OK
Set-Cookie: Transporte marítimo = “FedEx”; Version = “1″; Path = “/ acme”
Novo método de transporte marítimo reflecte cookie.
7. User Agent -> Servidor
POST / acme / processo HTTP/1.1
Cookie: $ Version = “1″;
Cliente = “WILE_E_COYOTE”; $ Path = “/ acme”;
Part_Number = “Rocket_Launcher_0001″; $ Path = “/ acme”;
Shipping = “FedEx”; $ Path = “/ acme”
[formulário de dados]
Usuário escolhe a processo judicial.
8. Servidor -> User Agent
HTTP/1.1 200 OK
A transação está completo.
O agente usuário faz uma série de pedidos sobre a origem servidor, após
cada um dos quais ela recebe um novo cookie. Todos os cookies têm o
Caminho e mesmo atributo (padrão) domínio. Devido ao facto de a solicitação URLs
todos têm / acme como um prefixo, e que corresponda à senda atributo, cada
pedido contém todos os cookies recebidos até agora.
5,2 Exemplo 2
Este exemplo ilustra o efeito do Caminho atributo. Todos
detalhes do pedido e resposta cabeçalhos foi omitido. Assumir a
agente usuário não tem cookies armazenados.
Imagine o usuário agente tenha recebido, em resposta a pedidos anteriores,
a resposta cabeçalhos
Kristol Standards Track & Montulli [Página 13]
RFC 2109 HTTP Estado mecanismo de gestão fevereiro 1997
Set-Cookie: Part_Number = “Rocket_Launcher_0001″; Version = “1″;
Path = “/ acme”
e
Set-Cookie: Part_Number = “Riding_Rocket_0023″; Version = “1″;
Path = “/ acme / munição”
Um posterior pedido do agente para o usuário (mesmo) servidor para URLs
da forma / acme / munições / … deve incluir o seguinte pedido
cabeçalho:
Cookie: $ Version = “1″;
Part_Number = “Riding_Rocket_0023″; $ Path = “/ acme / munição”;
Part_Number = “Rocket_Launcher_0001″; $ Path = “/ acme”
Note que o nome = valor par para o cookie com o mais específico
Caminho atributo, / acme / munições, antes de chegar a um com o menor
Caminho atributo específico, / acme. Além disso note que o mesmo cookie
nome aparece mais de uma vez.
Um posterior pedido do agente para o usuário (mesmo) para um servidor URL
da forma / acme / peças / pedido deve incluir o seguinte cabeçalho:
Cookie: $ Version = “1″; Part_Number = “Rocket_Launcher_0001″; $ Path = “/ acme”
Aqui, segundo o cookie do Caminho atributo / acme / munição não é um prefixo
URL do pedido, / acme / peças /, de modo que o cookie não obtém
enviadas para o servidor.
6. APLICAÇÃO CONSIDERAÇÕES
Aqui nós especular sobre prováveis ou desejáveis detalhes para um servidor origem
que implementa gestão estatal.
6,1 Set-Cookie Conteúdo
Um servidor de conteúdos da origem provavelmente deverá ser dividida em disjoint
aplicação áreas, algumas das quais requerem o uso de Estado
informação. O pedido áreas podem ser distinguidos pela sua
URLs pedido. O cabeçalho Set-Cookie pode incorporar informações
sobre o pedido através do estabelecimento de áreas do Caminho para cada atributo
um.
A sessão informação pode, evidentemente, ser claro que o texto codificado ou
Descreve estado. No entanto, se ele cresce muito grande, ele pode tornar-se
pesadas. Por conseguinte, que poderão optar por um implementor para a sessão
informação a ser a chave para um servidor do lado dos recursos. Evidentemente, utilizando
Kristol Standards Track & Montulli [Página 14]
RFC 2109 HTTP Estado mecanismo de gestão fevereiro 1997
uma base de dados gera alguns problemas que este estado de gestão
especificação foi concebido para evitar, a saber:
1. mantendo real estado do lado do servidor;
2. como e quando a recolher lixo de entrada do banco de dados, no caso de o
Agente utilizador termine a sessão, por exemplo, por sair.
6,2 Páginas Estado
Caching benefícios a escalabilidade da WWW. Por isso, é importante
para reduzir o número de documentos que tenham estado em lhes embutido
inerentemente. Por exemplo, se um cabaz de compras do estilo de candidatura
sempre exibe um usuário atual da cesta de conteúdos em cada página, os
páginas não pode ser armazenada, porque cada usuário do cabaz do conteúdo teria
ser diferente. Por outro lado, se cada página contém apenas um link
que permite ao usuário “Olhe meu cesto”, a página pode ser
cache.
6,3 Implementação Limites
Prático usuário agente implementações têm limites ao número e
tamanho de cookies que eles podem armazenar. Em geral, os agentes do utilizador ‘cookie
apoio não deve ter limites fixados. Eles deveriam esforçar para armazenar as
- muitos freqüentemente utilizado cookies possível. Além disso, utilizam-geral
os agentes do utilizador devem proporcionar cada uma das seguintes capacidades mínimas
individualmente, embora não necessariamente em simultâneo:
* Pelo menos 300 cookies
* Pelo menos 4096 bytes por cookie (tal como medida pelo tamanho do
caracteres que compõem o cookie não-terminal na sintaxe
descrição do cabeçalho Set-Cookie)
* Pelo menos 20 cookies per único hospedeiro ou nome do domínio
Usuário agências criadas para fins específicos ou para a limitada capacidade de
dispositivos devem proporcionar, pelo menos, 20 bolinhos de 4096 bytes, a fim de assegurar
que o usuário pode interagir com uma sessão à base de origem servidor.
As informações de um cabeçalho Set-Cookie resposta deve ser mantido em
sua totalidade. Se por alguma razão há insuficiência de espaço para armazenar
o cookie, ele deve ser descartado, não truncado.
As candidaturas deverão utilizar as poucas e tão pequenos quanto possível, os cookies, e
graciosamente eles devem lidar com a perda de um cookie.
Kristol Standards Track & Montulli [Página 15]
RFC 2109 HTTP Estado mecanismo de gestão fevereiro 1997
6.3.1 ataques de negação de serviço
Os agentes do utilizador pode optar por fixar um limite superior sobre o número de cookies
para ser armazenada a partir de um determinado host ou nome de domínio ou sobre o tamanho da
cookie informação. Caso contrário um servidor malicioso poderia tentar
inundação um agente usuário com muitos cookies, cookies ou grandes, em sucessivas
respostas, o que força os cookies do utilizador agente tinha recebido
a partir de outros servidores. No entanto, os níveis mínimos especificados acima deverão ainda
ser apoiadas.
7. PRIVACIDADE
7,1 User Agent controle
Um servidor origem poderia criar um cabeçalho Set-Cookie para rastrear o caminho
de um utilizador através do servidor. Os usuários podem opor a esse comportamento como
intrusiva um acúmulo de informações, mesmo que a sua identidade é
Não evidente. (Identidade poderão tornar-se evidente quando um usuário subsequentemente
preenche um formulário que contém dados de identificação.) Este estado
Especificação de gestão, por isso, exige que um agente usuário dê
o usuário controle sobre um tal eventual intromissão, apesar de a
interface através do qual o usuário é dado esse controle é deixado
indeterminado. No entanto, os mecanismos de controlo serão fornecidos, pelo menos,
permitir que o usuário
* Para desativar completamente o envio de cookies e de poupança.
* A fim de determinar se uma sessão stateful está em andamento.
* Para controlar a poupança de um cookie em função do cookie’s
Domínio atributo.
Tal controlo poderá ser fornecida, por exemplo, pelos mecanismos
* A notificar o usuário quando o usuário agente está prestes a enviar um cookie
a origem do servidor, oferecendo a opção de não iniciar uma sessão.
* A exibir uma indicação visual que está em uma sessão stateful
progressos.
* Para permitir que o usuário decidir quais os cookies, se for o caso, devem ser salvos
quando o usuário conclui uma janela ou um agente usuário sessão.
* Para permitir que o usuário examinar o conteúdo de um cookie em qualquer momento.
Um usuário agente geralmente começa com a execução não lembrar estado
informação. It should be possible to configure a user agent never
to send Cookie headers, in which case it can never sustain state with
Kristol & Montulli Standards Track [Page 16]
RFC 2109 HTTP State Management Mechanism February 1997
an origin server. (The user agent would then behave like one that is
unaware of how to handle Set-Cookie response headers.)
When the user agent terminates execution, it should let the user
discard all state information. Alternatively, the user agent may ask
the user whether state information should be retained; the default
should be “no”. If the user chooses to retain state information, it
would be restored the next time the user agent runs.
NOTE: User agents should probably be cautious about using files to
store cookies long-term. If a user runs more than one instance of
the user agent, the cookies could be commingled or otherwise messed
up.
7.2 Protocol Design
The restrictions on the value of the Domain attribute, and the rules
concerning unverifiable transactions, are meant to reduce the ways
that cookies can “leak” to the “wrong” site. The intent is to
restrict cookies to one, or a closely related set of hosts.
Therefore a request-host is limited as to what values it can set for
Domain. We consider it acceptable for hosts host1.foo.com and
host2.foo.com to share cookies, but not a.com and b.com.
Similarly, a server can only set a Path for cookies that are related
to the request-URI.
8. SECURITY CONSIDERATIONS
8.1 Clear Text
The information in the Set-Cookie and Cookie headers is unprotected.
Two consequences are:
1. Any sensitive information that is conveyed in them is exposed
to intruders.
2. A malicious intermediary could alter the headers as they travel
in either direction, with unpredictable results.
These facts imply that information of a personal and/or financial
nature should only be sent over a secure channel. For less sensitive
information, or when the content of the header is a database key, an
origin server should be vigilant to prevent a bad Cookie value from
causing failures.
Kristol & Montulli Standards Track [Page 17]
RFC 2109 HTTP State Management Mechanism February 1997
8.2 Cookie Spoofing
Proper application design can avoid spoofing attacks from related
domains. Consider:
1. User agent makes request to victim.cracker.edu, gets back
cookie session_id=”1234″ and sets the default domain
victim.cracker.edu.
2. User agent makes request to spoof.cracker.edu, gets back
cookie session-id=”1111″, with Domain=”.cracker.edu”.
3. User agent makes request to victim.cracker.edu again, and
passes
Cookie: $Version=”1″;
session_id=”1234″;
session_id=”1111″; $Domain=”.cracker.edu”
The server at victim.cracker.edu should detect that the second
cookie was not one it originated by noticing that the Domain
attribute is not for itself and ignore it.
8.3 Unexpected Cookie Sharing
A user agent should make every attempt to prevent the sharing of
session information between hosts that are in different domains.
Embedded or inlined objects may cause particularly severe privacy
problems if they can be used to share cookies between disparate
hosts. For example, a malicious server could embed cookie
information for host a.com in a URI for a CGI on host b.com. User
agent implementors are strongly encouraged to prevent this sort of
exchange whenever possible.
9. OTHER, SIMILAR, PROPOSALS
Three other proposals have been made to accomplish similar goals.
This specification is an amalgam of Kristol’s State-Info proposal and
Netscape’s Cookie proposal.
Brian Behlendorf proposed a Session-ID header that would be user-
agent-initiated and could be used by an origin server to track
“clicktrails”. It would not carry any origin-server-defined state,
however. Phillip Hallam-Baker has proposed another client-defined
session ID mechanism for similar purposes.
Kristol & Montulli Standards Track [Page 18]
RFC 2109 HTTP State Management Mechanism February 1997
While both session IDs and cookies can provide a way to sustain
stateful sessions, their intended purpose is different, and,
consequently, the privacy requirements for them are different. A
user initiates session IDs to allow servers to track progress through
them, or to distinguish multiple users on a shared machine. Cookies
are server-initiated, so the cookie mechanism described here gives
users control over something that would otherwise take place without
the users’ awareness. Furthermore, cookies convey rich, server-
selected information, whereas session IDs comprise user-selected,
simple information.
10. HISTORICAL
10.1 Compatibility With Netscape’s Implementation
HTTP/1.0 clients and servers may use Set-Cookie and Cookie headers
that reflect Netscape’s original cookie proposal. These notes cover
inter-operation between “old” and “new” cookies.
10.1.1 Extended Cookie Header
This proposal adds attribute-value pairs to the Cookie request header
in a compatible way. An “old” client that receives a “new” cookie
will ignore attributes it does not understand; it returns what it
does understand to the origin server. A “new” client always sends
cookies in the new form.
An “old” server that receives a “new” cookie will see what it thinks
are many cookies with names that begin with a $, and it will ignore
them. (The “old” server expects these cookies to be separated by
semi-colon, not comma.) A “new” server can detect cookies that have
passed through an “old” client, because they lack a $Version
attribute.
10.1.2 Expires and Max-Age
Netscape’s original proposal defined an Expires header that took a
date value in a fixed-length variant format in place of Max-Age:
Wdy, DD-Mon-YY HH:MM:SS GMT
Note that the Expires date format contains embedded spaces, and that
“old” cookies did not have quotes around values. Clients that
implement to this specification should be aware of “old” cookies and
Expires.
Kristol & Montulli Standards Track [Page 19]
RFC 2109 HTTP State Management Mechanism February 1997
10.1.3 Punctuation
In Netscape’s original proposal, the values in attribute-value pairs
did not accept “-quoted strings. Origin servers should be cautious
about sending values that require quotes unless they know the
receiving user agent understands them (i.e., “new” cookies). A
(”new”) user agent should only use quotes around values in Cookie
headers when the cookie’s version(s) is (are) all compliant with this
specification or later.
In Netscape’s original proposal, no whitespace was permitted around
the = that separates attribute-value pairs. Therefore such
whitespace should be used with caution in new implementations.
10.2 Caching and HTTP/1.0
Some caches, such as those conforming to HTTP/1.0, will inevitably
cache the Set-Cookie header, because there was no mechanism to
suppress caching of headers prior to HTTP/1.1. This caching can lead
to security problems. Documents transmitted by an origin server
along with Set-Cookie headers will usually either be uncachable, or
will be “pre-expired”. As long as caches obey instructions not to
cache documents (following Expires: <a date in the past> or Pragma:
no-cache (HTTP/1.0), or Cache-control: no-cache (HTTP/1.1))
uncachable documents present no problem. However, pre-expired
documents may be stored in caches. They require validation (a
conditional GET) on each new request, but some cache operators loosen
the rules for their caches, and sometimes serve expired documents
without first validating them. This combination of factors can lead
to cookies meant for one user later being sent to another user. The
Set-Cookie header is stored in the cache, and, although the document
is stale (expired), the cache returns the document in response to
later requests, including cached headers.
11. ACKNOWLEDGEMENTS
This document really represents the collective efforts of the
following people, in addition to the authors: Roy Fielding, Marc
Hedlund, Ted Hardie, Koen Holtman, Shel Kaphan, Rohit Khare.
Kristol & Montulli Standards Track [Page 20]
RFC 2109 HTTP State Management Mechanism February 1997
12. AUTHORS’ ADDRESSES
David M. Kristol
Bell Laboratories, Lucent Technologies
600 Mountain Ave. Room 2A-227
Murray Hill, NJ 07974
Phone: (908) 582-2250
Fax: (908) 582-5809
EMail: dmk@bell-labs.com
Lou Montulli
Netscape Communications Corp.
501 E. Middlefield Rd.
Mountain View, CA 94043
Phone: (415) 528-2600
EMail: montulli@netscape.com
