Hypertext Transfer Protocol – HTTP/1.1
Este documento especifica um protocolo Internet normas para a faixa Internet comunidade, e solicita discussão e sugestões para melhorias. Por favor, consulte a edição atual da Internet Jornal Protocolo Standards “(1 DST) para o estado de normalização e status do presente protocolo. A distribuição deste memorando é ilimitado.
Direitos Autorais
Copyright (C) A Internet Society (1999). Todos os direitos reservados.
O Hypertext Transfer Protocol (HTTP) é um aplicativo de nível protocolo para a distribuição, colaboração, informações hipermídia sistemas. É um genérico, protocolo stateless, que pode ser usado para muitas tarefas para além de seu uso de hipertexto, tais como servidores de nome e sistemas de gerenciamento de objetos distribuídos, através do alargamento do seu métodos de solicitação, os códigos de erro e cabeçalhos [47]. Uma característica do HTTP é a digitação ea negociação de representação de dados, permitindo que os sistemas a ser construída independentemente dos dados serem transferidos.
HTTP está em uso pelas informações World Wide Web global iniciativa desde 1990. Esta especificação define o protocolo referido como “HTTP/1.1”, e é uma atualização para RFC 2068 [33].
Índice
- Introdução
- Finalidade e Requisitos
- Terminologia
- operação global
- Duas convenções notacionais e gramática genérica
- Augmented BNF
- Regras básicas
- Parâmetros Protocolo
- HTTP versão
- Uniform Resource Identificadores
- Sintaxe Geral
- http URL
- Comparação URI
- Data / Hora formatos
- Data Full
- Seconds Delta
- Conjuntos de caracteres
- Charset Missing
- Codificações de conteúdo
- Codificações
- Transfer
- Transferência Chunked Codificação
- Tipos de Mídia
- Canonização e Padrões Texto
- Tipos Multipart
- Tokens
- Produto
- Valores Qualidade
- Tags Linguagem
- Tags Entidade
- Unidades de gama
- Mensagem HTTP
- Tipos de mensagens
- Cabeçalhos de mensagens
- Corpo da mensagem
- Message Length
- Geral Campos de cabeçalho
- Pedido
- Request-Line
- Método
- Pedido-URI
- O recurso identificado por um pedido
- Pedido de campos de cabeçalho
- Resposta
- Status-Line
- Frase Código de status e Razão
- Response Header Campos
- Entidade
- Entidade Campos de cabeçalho
- Corpo Entidade
- Tipo
- Duração Entidade
- ligações
- conexões persistentes
- Finalidade
- Operação geral
- Servidores Proxy
- Considerações práticas
- requisitos de transmissão de mensagens
- Conexões persistentes e Controle de Fluxo
- Monitorando Conexões para mensagens de erro Status
- Utilização do 100 (Continua) Status
- Comportamento Client Server prematuramente se fecha conexão
- Definições Método
- Métodos de segurança e idempotentes
- Métodos de segurança
- Métodos idempotent
- OPÇÕES
- GET
- HEAD
- POST
- PUT
- DELETE
- TRACE
- CONNECT
- Status Definições Código
- 1xx informativos
- Continue
- 101 Mudando Protocolos
- 2xx Sucesso
- 200 OK
- 201 Criado
- 202 Aceito
- 203 Informação não-autorizada
- 204 Nenhum conteúdo
- 205 Reset Content
- 206 Conteúdo parcial
- redirecionamento 3xx
- 300 Múltipla Escolha
- 301 Moved Permanently
- 302 encontrados
- 303 Ver Outros
- 304 Not Modified
- 305 Use Proxy
- 306 (não utilizado)
- 307 Redirecionamento temporário
- erro 4xx Cliente
- 400 Bad Request
- 401 Unauthorized
- 402 Pagamento necessário
- 403 Forbidden
- 404 Not Found
- 405 Método Não Permitido
- 406 Não Aceitável
- 407 Autenticação de proxy necessária
- 408 Request Timeout
- 409 Conflito
- 410
- 411 Comprimento necessário
- 412 Requisito Falha
- 413 Entidade de solicitação muito grande
- 414 Pedido-URI Too Long
- 415 Tipo de mídia incompatível
- 416 Intervalo solicitado não satisfatório
- 417 Falha na expectativa
- Server Error 5xx
- 500 Internal Server Error
- 501 Não implementado
- 502 Bad Gateway
- 503 Service Unavailable
- 10.5.5 504 Gateway Timeout
- 10.5.6 505 Versão HTTP não suportada
- Autenticação de acesso
- Negociação de conteúdo
- Negociação Server-driven
- Negociação Agent-driven
- negociação transparente
- Cache em HTTP
- Exatidão Cache
- Avisos
- Cache Mecanismos de controle
- Avisos User Agent Explicit
- Exceções, Regras e Avisos
- Comportamento do cliente controlada
- Modelo de Termo
- Termo servidor especificado
- Termo Heurística
- Cálculos Idade
- Cálculos Termo
- disambiguating Valores Termo
- disambiguating respostas múltiplas
- modelo de validação
- Datas Last-Modified
- Entidade Tag Validators Cache
- validadores fracos e fortes
- Regras para quando usar Tags Entidade e Last-Modified Dates
- Não validar Condicionais
- Cacheabilidade resposta
- Respostas Construindo dos esconderijos
- Fim-de-final e cabeçalhos Hop-by-hop
- Cabeçalhos não modificáveis
- Headers Combinando
- Combinando Escalas Byte
- Caching Respostas negociada
- Caches compartilhados e não compartilhados
- Erros ou comportamento Cache incompleta resposta
- Efeitos colaterais de GET e HEAD
- Invalidação após as atualizações ou exclusões
- write-through obrigatórios
- Substituição Cache
- Lista História
- Definições de campo de cabeçalho
- Aceitar
- accept-charset
- Accept-Encoding
- Accept-Language
- Accept-Ranges
- Idade
- Permitir
- Autorização
- Cache Control
- O que é Cacheable
- O que pode ser armazenado por Caches
- Modificações do Mecanismo de Vencimento Básico
- Revalidação Cache e Controles Atualizar
- No-Transform Directiva
- Extensões para Controle de Cache
- conexão
- Content-Encoding
- Content Language
- Content-Length
- Content-Location
- Content-MD5
- Content-Range
- Content-Type
- Data
- Operação Server Clockless Origem
- ETag
- Espere
- Expira
- De
- Host
- If-Match
- If-Modified-Since
- If-None-Match
- Se Range
- Se-Unmodified-Desde
- Last-Modified
- Localização
- Max-Forwards
- Pragma
- Proxy-Authenticate
- Proxy-Autorização
- Faixa
- intervalos de bytes
- Faixa de solicitações de recuperação
- Referer
- Retry-After
- Server
- TE
- Trailer
- Transfer-Encoding
- Upgrade
- User-Agent
- Vary
- Via
- Atenção
- WWW-Authenticate
- Considerações de Segurança
- informações pessoais
- Abuso de Information Server Log
- A transferência de informações confidenciais
- Informações Encoding Sensitive em URI
- Problemas de privacidade Connected Aceitar Cabeçalhos
- ataques baseados em nomes de arquivo e caminho
- DNS Spoofing
- Headers Localização e falsificação
- Content-Disposition Problemas15,6 credenciais de autenticação e clientes Idle
- Proxies e cache
- Ataques de negação de serviço em Proxies
- Agradecimentos
- Referências
- Endereços de 18 autores
- Apêndices
- Mensagem Internet Media Tipo http / e aplicação http /
- Internet Media Tipo multipart / byteranges19,3 aplicações tolerantes
- Diferenças entre as entidades HTTP e RFC 2045 Entidades …. 167
- MIME-Version 167
- Conversão para a forma canônica
- Conversão de formatos de data
- Introdução de conteúdos-Encoding
- No Content-Transfer-Encoding
- Introdução Transfer-Encoding
- MHTML e limitações de comprimento Line
- Características Adicionais
- Content-Disposition
- Compatibilidade com versões anteriores
- Mudanças de HTTP/1.0
- Compatibilidade com HTTP/1.0 conexões persistentes
- Mudanças de RFC 2068
- Index
- Full Copyright Declaração
1 Introdução
1.1 Finalidade
O Hypertext Transfer Protocol (HTTP) é um aplicativo de nível protocolo para a distribuição, colaboração, informações hipermídia sistemas. HTTP está em uso pelo World Wide Web global iniciativa de informação desde 1990. A primeira versão de HTTP, referido como HTTP/0.9, era um protocolo simples para transferência de dados em bruto em toda a Internet. HTTP/1.0, como definido pela RFC 1945 [6], a melhoria das o protocolo, permitindo que as mensagens sejam no formato MIME, como mensagens metainformation, contendo cerca de transferência e modificadores sobre o pedido semântica / resposta. No entanto, não HTTP/1.0 não suficientemente em conta os efeitos da hierarquia proxies, cache, a necessidade de conexões persistentes, ou virtual hosts. Além disso, a proliferação de incompleta implementadas aplicações que se autodenominam “HTTP/1.0” exigiu um mudança na versão de protocolo para que dois aplicativos de comunicação para determinar um do outro verdadeiras capacidades.
Esta especificação define o protocolo referido como “HTTP/1.1”.
Este protocolo inclui requisitos mais rigorosos do que em HTTP/1.0
para garantir a execução confiável de suas características.
sistemas de informação práticos requerem maior funcionalidade do que simples recuperação, incluindo pesquisa, atualização de front-end e anotação. HTTP permite um conjunto aberto e cabeçalhos de métodos que indicam o efeitos de um pedido [47]. Baseia-se na disciplina de referência fornecidas pelo Uniform Resource Identifier (URI) [3], como um local (URL) [4] ou nome (URN) [20], para indicar o recurso para que um método deve ser aplicado. As mensagens são passadas em um formato semelhante ao que é utilizado por correio Internet [9], conforme definido pelo Multiusos Internet Mail Extensions (MIME) [7].
HTTP também é usado como um protocolo genérico para comunicação entre os agentes do utilizador e proxies / gateways para os sistemas da Internet, incluindo as apoiadas pelo [SMTP 16], NNTP [13], FTP [18], Gopher [2], e WAIS [10] protocolos. Desta forma, HTTP permite hipermídia básico acesso aos recursos disponíveis a partir de diversas aplicações.
1.2 Requisitos
As palavras-chave “deve”, “não deve”, “necessário”, “deverá”, “não deve, “Deveria”, “não deve”, “recomendado”, “MAIO”, e “opcionais” na presente documento devem ser interpretados como descrito no RFC 2119 [34].
Uma implementação não é compatível se ele deixa de satisfazer um ou mais do mosto ou exigidos os requisitos de nível de protocolos que implementa. Uma implementação que satisfaça todos os DEVE ou exigido nível e todos os requisitos deve nivelar por seus protocolos é dito ser “incondicionalmente compliant”; uma que satisfaça todos os DEVE os requisitos de nível, mas não deve nivelar todos os requisitos para a sua protocolos é dito ser “condicionalmente compliant”.
1,3 Terminologia
Esta especificação utiliza uma série de termos para se referir aos papéisdesempenhado pelos participantes, e objetos de, a comunicação HTTP.
conexão
A camada de transporte de circuito virtual estabelecida entre dois programas para fins de comunicação.
mensagem
A unidade básica de comunicação HTTP, consistindo de um questionário estruturado seqüência de octetos correspondência a sintaxe definida no ponto 4 e transmitidos através da conexão.
pedido
Uma mensagem de pedido HTTP, tal como definido no ponto 5.
resposta
Uma mensagem de resposta HTTP, tal como definido no ponto 6.
recurso
Uma rede de dados objeto ou serviço que pode ser identificado por uma URI, tal como definido no ponto 3.2. Os recursos podem estar disponíveis em vários representações (por exemplo, múltiplas linguagens, formatos de dados, tamanho e resoluções) ou variar de outras formas.
entidade
As informações transferidas, como a carga de um pedido ou a resposta. Uma entidade consiste de meta information sob a forma de cabeçalho da entidade, os campos e conteúdos sob a forma de uma entidade do corpo, como descritos na seção 7.
representação
Uma entidade que acompanha uma resposta que está sujeito ao conteúdo negociação, conforme descrito na secção 12. Podem existir múltiplas representações associadas a um estado de resposta particular.
negociação de conteúdo
O mecanismo de seleção da representação adequada quando atendendo a uma solicitação, conforme descrito na secção 12. O representação de entidades de qualquer resposta pode ser negociado
(Incluindo respostas de erro).
variante
Um recurso pode ter um ou mais do que uma representação (s) associado a um dado instante. Cada uma dessas representações é chamado de varriant `’. O uso do termo «variante»não implica necessariamente que o recurso está sujeito ao conteúdo negociação.
cliente
Um programa que estabelece ligações com a finalidade de enviar pedidos.
agente do usuário
O cliente que inicia um pedido. Estes são muitas vezes os navegadores, editores, aranhas (web-percorrendo robôs), ou ferramentas de outro usuário final.
servidor
Um programa aplicativo que aceita conexões a fim de solicitações de serviço através do envio de volta as respostas. Qualquer programa dado pode ser capaz de ser um cliente e um servidor, o uso desses termos se refere apenas ao papel a ser realizada pelo programa de conexão particular, ao invés de recursos do programa em geral. Da mesma forma, qualquer servidor pode atuar como um servidor de origem, proxy, gateway ou túnel, mudando o comportamento baseado na natureza de cada pedido.
servidor de origem
O servidor no qual um dado recurso reside ou está a ser criado.
procuração
Um programa intermediário que atua como um servidor e um cliente com o propósito de fazer pedidos em nome de outros clientes. Os pedidos são atendidos internamente ou por passá-los, com tradução possível, para outros servidores. A procuração deve implementar o cliente eo servidor requisitos desta especificação. A “Proxy transparente” é um proxy que não modificar o pedido ou resposta além do que é necessário para autenticação e proxy identificação. Um proxy “não transparente” é um proxy que modifica pedido ou resposta, a fim de fornecer algum serviço adicionado o agente do usuário, como serviços de grupo de anotação, tipo de mídia transformação redução protocolo, ou anonimato filtragem. Exceto onde tanto o comportamento transparente ou não transparente é explicitamente indicado, as exigências proxy HTTP se aplicam a ambos os tipos de proxies.
portal
Um servidor que atua como um intermediário para algum outro servidor. Ao contrário de um proxy, um gateway recebe pedidos, como se fosse o servidor de origem para o recurso solicitado, o cliente solicitante pode não estar ciente de que ele está se comunicando com um gateway.
túnel
Um programa intermediário que atua como um relé cego entre duas conexões. Uma vez ativo, um túnel não é considerado um partido a comunicação HTTP, embora o túnel pode ter sido iniciadas por uma solicitação HTTP. O túnel deixa de existir quando ambos extremidades das conexões retransmitida está fechado.
esconderijo
A loja local do programa de mensagens de resposta eo subsistema que controla a sua mensagem de armazenamento, recuperação e eliminação. A cache armazena as respostas cacheable, a fim de reduzir a resposta tempo e consumo de banda de rede no futuro, o que equivale pedidos. Qualquer cliente ou servidor pode incluir uma cache, apesar de uma cache não pode ser usado por um servidor que está atuando como um túnel.
cacheable
A resposta é cacheable se um cache pode armazenar uma cópia do a mensagem de resposta para uso em responder as solicitações subseqüentes. O regras de determinação do cacheability de respostas HTTP são definido no ponto 13. Mesmo que um recurso está em cache, que pode a restrições adicionais sobre se um cache pode usar o cache cópia para um determinado pedido.
em primeira mão
A resposta é, em primeira mão se ela vem diretamente e sem atrasos desnecessários do servidor de origem, talvez por um ou mais proxies. A resposta também é em primeira mão, se a sua validade acaba foram verificados diretamente com o servidor de origem.
tempo de expiração explicitamente
O momento em que o servidor de origem tem a intenção de que uma entidade deve deixarão de ser devolvido por um cache sem validação.
tempo de validade heurística
Um tempo de expiração atribuído por um cache quando nenhum termo explícito tempo disponível.
idade
A idade de uma resposta é o tempo desde que foi enviado por, ou validado com sucesso com o servidor de origem.
vida frescura
O período de tempo entre a geração de uma resposta e sua tempo de expiração.
fresco
A resposta é fresco, se a sua idade ainda não tenha excedido a sua frescura da vida.
velho
A resposta é velho, se a sua idade passou sua vida frescura.
semanticamente transparente
A cache se comporta de uma “forma semanticamente transparente”, com relação a uma resposta particular, quando seu uso não afeta a pedido do cliente nem o servidor de origem, exceto para melhorar desempenho. Quando uma cache é semanticamente transparente, o cliente recebe exatamente a resposta do mesmo (exceto para os cabeçalhos hop-by-hop) que teria recebido o seu pedido tinha sido tratado directamente pelo servidor de origem.
validador
Um elemento de protocolo (por exemplo, uma marca de entidade ou uma hora da última modificação) que é usado para descobrir se uma entrada de cache é um equivalente cópia de uma entidade.
montante / jusante
A montante ea jusante descrever o fluxo de uma mensagem: todos mensagens fluxo de montante para jusante.
inbound / outbound
Inbound e outbound referem-se ao pedido e caminhos de resposta para mensagens: “inbound” significa “viajar para o servidor de origem”, e “outbound” significa “viajar para o agente de usuário”
1,4 operação global
O protocolo HTTP é um pedido / resposta protocolo. Um cliente envia uma pedido para o servidor na forma de um método de solicitação, URI e versão do protocolo, seguido por uma mensagem MIME-like com pedido modificadores, as informações do cliente, eo conteúdo possível do corpo ao longo de um conexão com o servidor. O servidor responde com uma linha de status, incluindo a versão da mensagem do protocolo e um sucesso ou um código de erro, seguido por uma mensagem MIME-como contendo as informações do servidor, entidade metainformation, e conteúdo corporal entidade possíveis. A relação entre HTTP e MIME é descrita em 19,4 apêndice.
A maioria comunicação HTTP é iniciada por um agente de usuário e consiste em um pedido para ser aplicado a um recurso em algum servidor de origem. No caso mais simples, isto pode ser conseguido através de uma única conexão (v) entre o agente usuário (UA) eo servidor de origem (O).
————————> Cadeia pedido
UA v ——————- ——————- O
<———————– Cadeia resposta
A situação mais complicada ocorre quando um ou mais intermediários estão presentes no pedido / resposta da cadeia. Há três comum formas de intermediário: proxy, gateway, e do túnel. Um proxy é um despachante, recebendo pedidos para um URI, na sua forma absoluta, reescrever a totalidade ou parte da mensagem, e encaminhar a reformatado pedido para o servidor identificado pela URI. Um gateway é um receber o agente, agindo como uma camada acima de outro servidor (s) e, se necessário, traduzindo as solicitações ao servidor de base de protocolo. Um túnel funciona como um ponto de ligação entre duas ligações sem alterar as mensagens, os túneis são usados quando o comunicação precisa passar por um intermediário (como um firewall) mesmo quando o intermediário não pode compreender o conteúdo das mensagens.
–————————————-> Cadeia pedido
UA v —– —– —– A v B —– —– —– C v —– —– O v
<————————————- Cadeia resposta
A figura acima mostra três intermediários (A, B e C) entre as agente e servidor de origem. Um pedido de resposta ou mensagem que percorre toda a cadeia irá passar por quatro conexões separadas. Esta distinção é importante porque algumas opções de comunicação HTTP só podem ser aplicadas a conexão com o próximo, o túnel não vizinho, só para o final de pontos da cadeia, ou a todas as conexões ao longo da cadeia. Embora o diagrama é linear, cada participante pode estar envolvido em múltiplas comunicações simultâneas. Por exemplo, B podem estar recebendo pedidos de muitos clientes que não A, e / ou encaminhar os pedidos de outros servidores de C, ao mesmo tempo que A manipulação é o pedido.
Qualquer parte da comunicação que não está agindo como um túnel pode utilizar um cache interno para o tratamento dos pedidos. O efeito de uma cache é que o pedido da cadeia / resposta é encurtado quando um dos participantes ao longo da cadeia tem uma resposta em cache aplicável a esse pedido. O seguinte ilustra a cadeia resultante se B tem um cópia em cache de uma resposta anterior do Ó (via C) por um pedido que não tenha sido armazenado em cache pelo AI ou A.
———-> Cadeia pedido
UA v —– —– —– A v B —– – – – – – – C – – – – – – O
<——— Cadeia resposta
Nem todas as respostas são úteis em cache, e alguns pedidos podem conter modificadores que colocam requisitos especiais sobre o comportamento do cache. requisitos para o comportamento de cache HTTP e respostas são cacheable definido no ponto 13.
Na verdade, há uma grande variedade de arquiteturas e configurações de caches e proxies actualmente em experiência ou implantado através da World Wide Web. Esses sistemas incluem hierarquias nacionais de proxy cache para economizar banda transoceânica, os sistemas que broadcast ou multicast entradas de cache, as organizações que distribuem subconjuntos de dados em cache através de CD-ROM, e assim por diante. sistemas de HTTP são usados em intranets corporativas através de ligações de banda larga, e para acesso via PDAs com links de rádio de baixa potência, e conectividade intermitente. O HTTP/1.1 objetivo é apoiar a diversidade de formações já implantados, introduzindo protocolo construções que satisfaçam as necessidades daqueles que constroem aplicações web que requerem alta confiabilidade e, na falta deste, pelo menos, indícios de confiança fracasso.
Comunicação HTTP geralmente ocorre através de conexões TCP / IP. O porta padrão é TCP 80 [19], mas as outras portas podem ser usadas. Isto não não exclui HTTP de ser implementado em cima de qualquer outro protocolo na Internet, ou em outras redes. HTTP somente pressupõe uma confiança transporte; qualquer protocolo que fornece tais garantias pode ser utilizada; o mapeamento do pedido HTTP/1.1 e estruturas de resposta para o unidades de transporte de dados do protocolo em questão está fora do escopo desta especificação.
No HTTP/1.0, a maioria das implementações utilizou uma nova conexão para cada pedido de troca / resposta. No HTTP/1.1, uma conexão pode ser utilizado para um ou mais pedido / resposta intercâmbios, embora as conexões podem ser fechado para uma variedade de razões (ver secção 8.1).
Duas convenções notacionais e Generic Gramática
2,1 Augmented BNF
Todos os mecanismos previstos no presente documento são descritos em prosa e uma Backus-Naur aumentado (FBN), semelhante ao que utilizado pelo RFC 822 [9]. Os implementadores deverão estar familiarizados com os notação, a fim de compreender esta especificação. A BNF aumentada inclui as seguintes construções:
definição do nome = O nome de uma regra é simplesmente o nome próprio (sem qualquer delimitador “<” e “>”) e é separado de sua definição pelo “= Igual” personagem. O espaço em branco só é significativo na medida em que recuo das linhas de continuação é usado para indicar uma regra definição que a linha abrange mais de um. Algumas regras básicas são em letras maiúsculas, como SP, LWS, HT, CRLF, DIGIT, ALPHA, etc Angle parênteses são utilizados dentro de definições sempre que sua presença será facilitar o uso do dom de discernir os nomes regra.
“Literal”
As aspas surround texto literal. Salvo disposição em contrário, o texto é diferencia maiúsculas de minúsculas.
rule1 | rule2
Elementos separados por uma barra (“|”) são alternativas, por exemplo, “yes | não “aceitará sim ou não.
(Rule1 rule2)
Elementos entre parênteses são tratadas como um único elemento. Assim, “(elem (foo | bar) elem)” permite que as seqüências de token “elem elem elem foo bar “e” elem “.
*Estado
O caractere “*” indica que precede um elemento de repetição. O formulário completo é “<n> elemento * <m>”, indicando pelo menos <n> e no máximo <m> ocorrências do elemento. Os valores padrão são 0 e infinito, que “o elemento (*)” permite que qualquer número, incluindo zero; elemento “* 1” requer pelo menos um, e “uma 2element *” permite que um ou dois.
[] Estado
Os colchetes encerram elementos opcionais, “[bar] foo” é equivalente a “* 1 (foo bar)”.
Estado N
repetição específico: “<n> (elemento)” é equivalente a “<n> * <n> (Elemento)”, isto é, exatamente <n> ocorrências (elemento). Assim 2DIGIT é um número de dois dígitos, e 3ALPHA é uma seqüência de três caracteres alfabéticos.
regra #
A construção de “#” é definido, semelhante ao “*”, para a definição de listas de elementos. O formulário completo é “<n> # <m> elemento”, indicando pelo menos <n> e no máximo <m> elementos, separados por um ou mais vírgulas (“,”) E facultativo espaço linear branco (LWS). Isso faz com que o usual forma de listas muito fácil, uma regra como(* LWS elemento (“* LWS,” elemento * LWS)) pode ser mostrado como 1 elemento # Sempre que esta construção é utilizado, os elementos nulos são permitidos, mas não não contribuem para a contagem dos elementos presentes. Isto é, “(Elemento), (elemento)” é permitido, mas conta como apenas dois elementos. Portanto, onde pelo menos um elemento é necessário, em pelo menos um elemento não-nulo deve estar presente. Os valores padrão são 0 e infinito, para que “elemento #” permite que qualquer número, incluindo zero; “Um elemento #” necessita de pelo menos um, e “1 2element #” permite que um ou dois.
; Comentário
Um ponto e vírgula, desencadeou uma certa distância à direita do texto regra, inicia um comentário que continua até o fim da linha. Este é um forma simples de incluir notas úteis em paralelo com o especificações.
implícita LWS *
A gramática descrito por esta especificação é baseada em palavras. Exceto onde denotado, os espaços em branco linear (LWS) pode ser incluído entre quaisquer duas palavras adjacentes (token ou citou-corda), e entre palavras adjacentes e separadores, sem alterar a interpretação de um campo. Pelo menos um delimitador (LWS e / ou separadores) deve existir entre quaisquer dois tokens (para a definição de “token” abaixo), pois de outra forma seria interpretado como um único token.
2.2 Regras básicas
As regras a seguir são utilizados ao longo deste caderno de especificações descrever a análise de construções básicas. O US-ASCII conjunto de caracteres codificados é definido pelo ANSI X3.4-1986 [21].
Octeto = <qualquer 8-bit seqüência de Data>
Char = personagem US-ASCII <qualquer (octets 0-127)>
UPALPHA = letra maiúscula “A”..”Z”> <qualquer US-ASCII
LOALPHA = letra minúscula “a”..”z”> <qualquer US-ASCII
ALPHA = LOALPHA | UPALPHA
DIGIT = <qualquer “0”..”9″> US-ASCII dígitos
CTL = <carácter de controlo US-ASCII
(Octetos 0-31) e DEL (127)>
CR = <US-ASCII CR, (13)> retorno de carro
LF = <US-ASCII LF, linefeed (10)>
SP = <US-ASCII espaço SP, (32)>
HT = <US-ASCII horizontal-tab HT, (9)>
<“> = <US-ASCII (34)> Marca double-quote
HTTP/1.1 define a seqüência CR LF como o marcador de fim-de-linha para todos
elementos do protocolo, exceto a entidade corpo (veja o apêndice para 19,3
aplicações tolerantes). O marcador de fim-de-linha dentro de uma entidade do corpo
é definido pelo seu tipo de mídia associada, como descrito na seção 3.7.
CRLF = CR LF
HTTP/1.1 valores de campo de cabeçalho pode ser dobrada em várias linhas, se o linha de continuação começa com um espaço ou tabulação horizontal. Todos linear spaço em branco, incluindo a dobrar, tem a mesma semântica como SP. O Receptor pode substituir qualquer espaço linear branco com um único antes SP interpretar o valor do campo ou encaminhar a mensagem a jusante.
LWS CRLF = [1] (* SP | HT)
A regra TEXT é utilizado apenas para o conteúdo do campo descritivo e os valores que não se destinem a ser interpretado pelo analisador mensagem. Palavras * do texto pode conter caracteres de outros conjuntos de caracteres de ISO-8859-1 [22] apenas quando codificados de acordo com as regras da RFC 2047 [14].
TEXT = <octeto qualquer excepção CTLs,
mas incluindo LWS>
A CRLF é permitido na definição de texto apenas como parte de um cabeçalho
continuação de campo. Espera-se que a LWS dobrar será
substituídos por um único SP antes da interpretação do valor de texto.
caracteres numéricos hexadecimais são usados em elementos de vários protocolos.
HEX = “A” | “B” | “C” | “D” | “E” | “F”
| “A” | “b” | “c” | “d” | “e” | “f” | DIGIT
Fielding, et al. Standards Track [Página 16]
?
HTTP/1.1 RFC 2616 junho 1999
Muitos valores do campo de cabeçalho HTTP/1.1 composto por palavras separadas por LWS
ou caracteres especiais. Estes caracteres especiais devem ser citados em um
string para ser usado dentro de um valor do parâmetro (conforme definido na seção
3.6).
token = 1 CHAR <qualquer * exceto CTLs ou separators>
separadores = “(” | “)” | “<” | “>” | “@”
| “,” | “,” | “:” | \ “|” <>
| “/” | “[” | “] |”? ” | “=”
| “(” | “)” | SP | HT
Comentários podem ser incluídos em alguns campos do cabeçalho HTTP, envolvendo
o texto de comentário entre parênteses. Os comentários são permitidas apenas em
campos que contêm “comentário” como parte de sua definição de valor de campo.
Em todos os outros campos, entre parênteses são consideradas parte do campo
valor.
comment = “(” * (ctext comentário | | cotado par) “)”
TEXTO <qualquer ctext = excluindo “(” e “)”>
Uma seqüência de caracteres de texto é analisado como uma única palavra, se é citado com
marcas de aspas duplas.
citou-corda = (<* “> (qdtext | cotado par)” <>)
qdtext = <qualquer texto exceto “<>
O caractere de barra invertida (“\”) pode ser usado como um caractere único
citando apenas no mecanismo citou-corda e comentar construções.
citado par = “\” CHAR
Parâmetros 3 do protocolo
HTTP versão 3.1
HTTP usa um “<major>. <minor>” Esquema de numeração para indicar as versões
do protocolo. O protocolo política versão destina-se a permitir
do remetente para indicar o formato de uma mensagem e sua capacidade de
compreender a comunicação HTTP mais, ao invés de os recursos
obtidos através dessa comunicação. Nenhuma mudança é feita para a versão
número da adição de componentes de mensagem que não afectem
comunicação ou comportamento que só vem acrescentar valores de campo extensível.
O número <minor> é incrementado quando as alterações feitas à
protocolo de adicionar características que não mudam a mensagem geral de análise
algoritmo, mas que pode aumentar a semântica da mensagem e implica
recursos adicionais do remetente. O número é <major>
incrementado quando o formato de uma mensagem dentro do protocolo é
alterado. Consulte RFC 2145 [36] para uma explicação mais pormenorizada.
Fielding, et al. Standards Track [Página 17]
?
HTTP/1.1 RFC 2616 junho 1999
A versão de uma mensagem HTTP é indicado por um campo HTTP-Version
na primeira linha da mensagem.
HTTP Version = HTTP “” / “1” * DIGIT “. 1 * DIGIT
Note que os números maiores e menores devem ser tratados de forma distinta
inteiros e que cada um pode ser incrementado superior a um dígito.
Assim, o HTTP/2.4 é uma versão menor que HTTP/2.13, que por sua vez é
inferior HTTP/12.3. zeros à esquerda devem ser ignorados pelos destinatários e
NÃO DEVE ser enviado.
Um aplicativo que envia uma solicitação ou mensagem de resposta, que inclui
HTTP-Version de “HTTP/1.1” deve ser pelo menos condicionalmente conforme
com esta especificação. Os aplicativos que são pelo menos condicionalmente
compatível com esta especificação deve usar um HTTP-Version de
“HTTP/1.1” em suas mensagens, e devem fazê-lo para qualquer mensagem que é
não é compatível com HTTP/1.0. Para mais detalhes sobre quando enviar
valores específicos HTTP-Version, consulte RFC 2145 [36].
A versão do HTTP de um aplicativo é a maior versão do HTTP para
que o aplicativo é compatível com pelo menos condicionalmente.
Proxy e aplicações de gateway precisa ser cuidadoso ao encaminhamento
mensagens em versões de protocolos diferentes do da aplicação.
Desde a versão do protocolo indica a capacidade de protocolo do
remetente, um proxy / gateway não deve enviar uma mensagem com uma versão
indicador, que é maior do que sua versão real. Se uma maior
solicitar versão é recebida, o proxy deve gateway / ou downgrade
a versão do pedido, ou de responder com um erro, ou mudar para o túnel
comportamento.
Devido a problemas de interoperabilidade com proxies HTTP/1.0 descoberto
desde a publicação da RFC 2068 [33], o cache deve proxies, gateways
MAY, túneis e NÃO DEVE atualizar o pedido para a versão mais alto
que suportam. A resposta do proxy / gateway ‘s para que o pedido deve ser
a mesma versão que o pedido principal.
Nota: A conversão entre as versões do HTTP pode envolver a modificação
de campos de cabeçalho exigido ou proibido pelas versões envolvidos.
3,2 Uniform Resource Identifiers
URIs foram conhecidos por muitos nomes: Endereços WWW, Universal Document
Identificadores, Universal Resource Identifier [3] e, finalmente, o
combinação de Uniform Resource Locator (URL) [4] e Names (URN)
[20]. No que diz respeito HTTP está em causa, Uniform Resource Identifiers são
simplesmente formatado strings que identificam – através de nome, localização, ou qualquer
outra característica – um recurso.
Fielding, et al. Standards Track [Página 18]
?
HTTP/1.1 RFC 2616 junho 1999
3.2.1 Sintaxe Geral
URIs em HTTP podem ser representados de forma absoluta ou relativa a alguns
conhecido base URI [11], dependendo do contexto da sua utilização. Os dois
formulários são diferenciados pelo fato de que sempre começam URIs absoluto
com um nome de esquema seguido por dois pontos. Para obter informações definitivas sobre
URL sintaxe e semântica, consulte “Uniform Resource Identifier (URI):
Genéricos sintaxe e semântica “, RFC 2396 [42] (que substitui RFCs
1738 [4] e RFC 1808 [11]). Esta especificação adota o
definições de “URI de referência”, absoluteURI “,” relativeURI “,” Porto “,
“Host”, abs_path “,” rel_path “e” autoridade “de que
especificação.
O protocolo HTTP não coloca qualquer limite a priori sobre a duração dos
um URI. Os servidores devem ser capazes de lidar com a URI de um recurso que
servir, e deve ser capaz de lidar com URIs de duração ilimitada, se
fornecer formulários GET-based que podem gerar tais URIs. Um servidor
Deve retornar 414 (Request-URI Too Long status) se um URI é maior
que o servidor pode suportar (ver secção 10.4.15).
Nota: Os servidores devem ser cautelosos sobre dependendo comprimentos URI
acima de 255 bytes, porque alguns clientes mais velhos ou por procuração
implementações não podem apoiar adequadamente estes comprimentos.
3.2.2 URL http
O “http” regime é utilizado para localizar recursos de rede através do HTTP
protocolo. Esta seção define o regime de sintaxe específica e
semântica para URLs http.
http_URL = “http:” “/ / [” host “: porto] [[abs_path”? consulta]]
Se a porta está vazia ou não dado, a porta 80 é assumido. A semântica
são de que o recurso identificado está localizado no servidor escuta
para conexões TCP em que a porta do mesmo host, eo pedido-URI
para o recurso é abs_path (seção 5.1.2). A utilização de endereços IP
em URLs devem ser evitados sempre que possível (ver RFC 1900 [24]). Se
o abs_path não está presente na URL, ele deve ser dado como “/” quando
usado como um Pedido-URI de um recurso (seção 5.1.2). Se um proxy
recebe um nome de host que não é um nome de domínio totalmente qualificado, que
MAIO adicionar seu domínio para o nome do host que recebeu. Se um proxy recebe
um nome de domínio totalmente qualificado, o proxy não deve alterar o host
nome.
Fielding, et al. Normas Track [Página 19]
?
HTTP/1.1 RFC 2616 junho 1999
3.2.3 Comparação URI
Ao comparar duas URIs para decidir se jogo ou não, um cliente
Deve usar uma comparação diferencia maiúsculas de minúsculas octeto por octeto de todo o
URIs, com as seguintes exceções:
– A porta que está vazio ou não dado é equivalente ao padrão
porta para que a referência URI;
– Comparações de nomes de host deve ser maiúsculas e minúsculas;
– Comparações de nomes de esquema deve ser maiúsculas e minúsculas;
– Um abs_path vazio é equivalente a um abs_path de “/”.
Outros personagens do que nos reserva “e” inseguro “conjuntos (ver
RFC 2396 [42]) são equivalentes ao seu “%” HEX HEX “codificação.
Por exemplo, as três seguintes URIs são equivalentes:
http://abc.com:80/ smith ~ / home.html
http://ABC.com/% 7Esmith/home.html
http://ABC.com:/ 7esmith/home.html%
3,3 Data / Hora Formatos
3.3.1 Data completo
pedidos HTTP, historicamente, tem três formatos diferentes
para a representação de data / hora carimbos:
Sun, 06 de novembro de 1994 08:49:37 GMT, RFC 822, atualizada pela RFC 1123
Domingo, 06-Nov-94 08:49:37 GMT; RFC 850, tornado obsoleto pela RFC 1036
Dom 06 de novembro 08:49:37 1994; asctime ANSI C () do formato
O primeiro formato é preferido como um padrão da Internet e representa
um subconjunto de comprimento fixo do que o definido pela RFC 1123 [8] (uma atualização para
RFC 822 [9]). O segundo formato é de uso comum, mas é baseado na
RFC 850 obsoleto formato de data [12] e carece de um ano de quatro dígitos.
HTTP/1.1 clientes e servidores que analisar o valor de data deve aceitar
todos os três formatos (para compatibilidade com HTTP/1.0), embora eles devam
apenas gerar o formato RFC 1123 para representar os valores HTTP data-
em campos de cabeçalho. Ver secção 19.3 para mais informações.
Nota: Os destinatários dos valores de data são encorajadas a ser robusto
aceitar valores de data que pode ter sido enviado por não-HTTP
aplicações, como é o caso quando recuperar ou postagem
mensagens através de proxies / gateways de SMTP ou NNTP.
Fielding, et al. Standards Track [Página 20]
?
HTTP/1.1 RFC 2616 junho 1999
Todos data HTTP / selos de tempo deve ser representado em Greenwich Mean Time
(GMT), sem exceção. Para efeitos do HTTP, é exatamente GMT
igual a UTC (Coordinated Universal Time). Este é indicado no
primeiro dos dois formatos, através da inclusão de “GMT”, como o de três letras
abreviatura de fuso horário, e devem ser assumidas quando da leitura
asctime formato. HTTP-date é sensível a maiúsculas e não deve incluir
LWS adicionais para além das especificamente incluída como no SP
gramática.
HTTP data = | RFC1123 data-data-rfc850 | asctime data-
“Wkday RFC1123 data =” SP SP SP date1 tempo “GMT”
“Weekday rfc850 data =” SP SP SP date2 tempo “GMT”
data asctime = wkday SP SP SP date3 tempo 4DIGIT
data1 = 2DIGIT meses SP SP 4DIGIT
; Dia mês ano (por exemplo, 02 de junho de 1982)
data2 = 2DIGIT “-” Mês “-” 2DIGIT
; Dia-mês-ano (por exemplo, 02-Jun-82)
date3 = mês (SP 2DIGIT | (SP 1digit))
; Dia mês (por exemplo, 02 de junho)
= tempo 2DIGIT: “2DIGIT:” 2DIGIT
; 0:00:00-23:59:59
wkday = “Mon” | “ter” | “Wed”
| Qui “” | | “sex” Sat “|” Sun “
semana = “segunda-feira” | “Tuesday” | “quarta-feira”
| Quinta-feira “|” Friday “|” Sábado “| domingo”
mes = “Jan” | “fevereiro” | “Mar” | “abril”
| “May” | “Jun” | “julho” | “agosto”
| Setembro “|” outubro “| Nov” | “dezembro”
Nota: Os requisitos HTTP para o formato de data / hora carimbo aplicam-se apenas
a sua utilização no fluxo do protocolo. Clientes e servidores são
não devem utilizar esses formatos de apresentação do usuário, o pedido
log, etc
3.3.2 Seconds Delta
Alguns campos do cabeçalho HTTP permite que um valor de tempo a ser especificado como um
número inteiro de segundos, representado em decimal, após o tempo
que a mensagem foi recebida.
delta-segundos = 1 * DIGIT
3,4 Conjuntos de caracteres
HTTP usa a mesma definição do conjunto de caracteres prazo “, como que
descrito para MIME:
Fielding, et al. Standards Track [Página 21]
?
HTTP/1.1 RFC 2616 junho 1999
O conjunto de caracteres do termo é usado neste documento para se referir a um
método utilizado com uma ou mais tabelas para converter uma seqüência de octetos
em uma seqüência de caracteres. Note que a conversão incondicional
outro sentido não é necessária, na medida em que nem todos os personagens podem
estar disponíveis em um determinado conjunto de caracteres e um conjunto de caracteres pode fornecer
mais do que uma seqüência de octetos para representar um caractere especial.
Esta definição destina-se a permitir que vários tipos de personagem
codificação, a partir de simples mapeamentos de tabela única, como US-ASCII
quadro complexo de mudança de métodos, tais como aqueles que usam ISO-2022’s
técnicas. No entanto, a definição associada a um personagem MIME
nome do conjunto devem ser plenamente especificar o mapeamento a ser realizado a partir de octetos
para caracteres. Em particular, o uso de informações de perfis externos
para determinar o mapeamento exato não é permitido.
Nota: Esta utilização do conjunto de caracteres do termo é mais comumente
referida como uma codificação de caracteres “. No entanto, como HTTP e
MIME compartilhar o mesmo registro, é importante que a terminologia
também serão compartilhadas.
conjuntos de caracteres HTTP são identificados por símbolos insensíveis ao caso. O
conjunto completo de fichas é definido pela IANA registro conjunto de caracteres
[19].
charset = token
Apesar de HTTP permite que um sinal arbitrário para ser usado como um charset
valor, qualquer símbolo que tem um valor pré-definido dentro da IANA
Character Set registro [19] deve representar o conjunto de caracteres definidos
por esse registro. As candidaturas devem limitar seu uso de caráter
define as definidas pela IANA registro.
Os implementadores devem estar conscientes do caráter IETF estabelecer requisitos [38]
[41].
3.4.1 Charset ausente
Alguns softwares HTTP/1.0 interpretou um cabeçalho Content-Type sem
parâmetro charset incorretamente como “beneficiário deve adivinhar.”
Remetentes que desejam derrotar esse comportamento pode incluir um conjunto de caracteres
mesmo quando o parâmetro charset é o ISO-8859-1 e deve fazê-lo quando
Sabe-se que ele não vai confundir o destinatário.
Infelizmente, alguns clientes mais velhos HTTP/1.0 não lidar adequadamente com
um parâmetro charset. HTTP/1.1 beneficiários devem respeitar o
charset etiqueta fornecida pelo remetente, e os agentes que têm
uma disposição para “adivinhar” um conjunto de caracteres deve usar o charset do
Fielding, et al. Standards Track [Página 22]
?
HTTP/1.1 RFC 2616 junho 1999
campo do tipo de conteúdo de apoio que se charset, ao invés do
preferência do beneficiário, quando inicialmente exibindo um documento. Ver
seção 3.7.1.
3,5 codificações conteúdo
valores indicam um conteúdo de codificação de codificação de transformação que tem
foram ou podem ser aplicadas a uma entidade. codificações de conteúdo são essencialmente
usado para permitir que um documento a ser comprimido ou não útil
transformar sem perder a identidade do seu tipo de mídia subjacente
e sem perda de informação. Freqüentemente, a entidade é armazenada em
sob forma codificada, transmitida diretamente, e só decodificada pelo destinatário.
conteúdo de codificação = token
Todo o conteúdo de codificação valores são case-insensitive. HTTP/1.1 usa
conteúdo de codificação valores no Accept-Encoding (art. 14.3) e
Content-Encoding (seção 14.11) campos de cabeçalho. Embora o valor
descreve o conteúdo de codificação, o que é mais importante é que
indica qual é o mecanismo de decodificação será necessária para remover o
codificação.
O Internet Assigned Numbers Authority (a IANA) atua como um registro para
conteúdo de codificação fichas de valor. Inicialmente, o registro contém o
tokens a seguir:
Um formato de codificação gzip produzido pelo programa de compressão de arquivos
“Gzip (GNU zip) como descrito no RFC 1952 [25]. Este formato é uma
Lempel-Ziv (LZ77) com um CRC de 32 bits.
comprimir
O formato de codificação produzido pela compressão de arquivos comuns UNIX
programa “comprimir”. Este formato é uma adaptação Lempel-Ziv-Welch
codificação (LZW).
O uso de nomes de programas para a identificação dos formatos de codificação
não é desejável e não é recomendado para codificações futuro. Seus
uso aqui é representativo da prática histórica, não é bom
design. Para compatibilidade com implementações anteriores do HTTP,
As candidaturas devem considerar “x-gzip” e “x-compress” para ser
equivalente a “gzip” e “comprimir”, respectivamente.
esvaziar
O formato “zlib definido na RFC 1950 [31], em combinação com
o “mecanismo de compressão deflate” descrito no RFC 1951 [29].
Fielding, et al. Standards Track [Página 23]
?
HTTP/1.1 RFC 2616 junho 1999
identidade
O padrão (identidade) de codificação, o uso de nenhuma transformação
qualquer. Este conteúdo de codificação é usado apenas no Accept-
Encoding cabeçalho, e não deve ser usado no Content-Encoding
cabeçalho.
tokens valor Novo conteúdo de codificação devem ser registradas, para permitir que
interoperabilidade entre clientes e servidores, as especificações dos
algoritmos de codificação de conteúdos necessários para implementar um novo valor deve ser
publicamente disponíveis e adequados para execução independente, e
em conformidade com a finalidade de conteúdo codificação definida nesta seção.
Codificações 3,6 Transfer
Transferência de codificação valores são usados para indicar uma codificação
transformação que tem sido, podem ser, ou podem precisar de ser aplicado a um
corpo da entidade, a fim de garantir um “transporte seguro” através da rede.
Isso difere de um conteúdo de codificação em que a transferência é uma codificação
propriedade da mensagem, e não da entidade original.
transferência de codificação = “blocos” | extensão de transferência
extensão transferência * = token (“;” parâmetro)
Os parâmetros são na forma de atributo / valor pares.
atributo parameter = “= valor”
= atributo token
valor = | token citou-corda
Todas as transferências de codificação valores são case-insensitive. HTTP/1.1 usa
transferência de codificação valores no campo de cabeçalho TE (art. 14,39) e em
o campo de cabeçalho Transfer-Encoding (art. 14,41).
Sempre que uma transferência de codificação é aplicada a um corpo da mensagem, o conjunto de
transferência de códigos deve incluir “blocos”, a menos que a mensagem é
denunciado por fechar a conexão. Quando os “blocos” de transferência de
codificação é usado, ele deve ser o último a transferência de codificação aplicada ao
corpo da mensagem. Os “blocos” de transferência de codificação não deve ser aplicada mais
de uma vez para uma mensagem do corpo. Estas regras permitem que o destinatário
determinar a transferência de comprimento da mensagem (4.4).
Transfer-codificações são análogas à-Transfer-Encoding conteúdo
valores de MIME [7], que foram projetados para permitir o transporte seguro de
dados binários sobre um serviço de transporte de 7 bits. No entanto transporte, seguro
tem um foco diferente para um protocolo de transferência de 8 bits, limpo. Em HTTP,
a única característica inseguros de mensagem de órgãos é a dificuldade em
determinar o comprimento exato do corpo (seção 7.2.2), ou o desejo de
criptografar os dados através de um transporte comum.
Fielding, et al. Standards Track [Página 24]
?
HTTP/1.1 RFC 2616 junho 1999
O Internet Assigned Numbers Authority (a IANA) atua como um registro para
transferência de codificação fichas de valor. Inicialmente, o registro contém o
seguintes tokens: “blocos” (seção 3.6.1), a “identidade” (secção
3.6.2), gzip “(ponto 3.5),” comprimir “(seção 3.5), e” esvaziar “
(Seção 3.5).
tokens Novo valor de transferência de codificação deve ser registrado da mesma maneira
como novos tokens valor do conteúdo de codificação (seção 3.5).
Um servidor que recebe uma entidade de corpo com uma transferência de codificação que faz
não entendo deve retornar 501 (Unimplemented), e fechar o
conexão. Um servidor não deve enviar de transferência de códigos para um HTTP/1.0
cliente.
3.6.1 Transferência Chunked Codificação
A codificação fragmentada modifica o corpo de uma mensagem, a fim de
transferi-la como uma série de blocos, cada um com seu indicador próprio tamanho,
seguido por um trailer que contém campos de cabeçalho OPCIONAIS entidade. Este
permite dinamicamente o conteúdo produzido para ser transferido juntamente com o
informações necessárias para o destinatário para verificar se ele tem
recebeu a mensagem completa.
Chunked-Body = pedaço *
pedaço da última
trailer
CRLF
chunk size = pedaço [pedaço extensão de] CRLF
CRLF dados chunk-
chunk-size = 1 * HEX
pedaço de última = 1 * (“0”) [pedaço de extensão-] CRLF
extensão pedaço = (* “,” [bloco-ext-name “=]” chunk-ext-val)
chunk-ext-name = token
chunk-ext-val = | token citou-corda
pedaço de dados de tamanho de bloco = (octeto)
* Trailer = (CRLF cabeçalho entidade)
O campo de tamanho de bloco é uma seqüência de dígitos hexadecimais que indica o tamanho da
o pedaço. A codificação fragmentada é encerrado por qualquer pedaço cujo tamanho é
zero, seguido pelo trailer, que é encerrada por uma linha vazia.
O trailer permite que o remetente para incluir cabeçalho HTTP adicional
campos no final da mensagem. O campo de cabeçalho de reboque pode ser
usado para indicar os campos do cabeçalho são incluídas em um reboque (ver
seção 14.40).
Fielding, et al. Standards Track [Página 25]
?
HTTP/1.1 RFC 2616 junho 1999
Um servidor usando blocos de codificação de transferência em uma resposta NÃO DEVE usar o
reboque para os campos de cabeçalho, a menos que uma das seguintes opções é
verdadeiras:
a) O pedido incluía um campo de cabeçalho que indica TE “trailers” é
aceitável na transferência de codificação da resposta, conforme descrito no
seção 14,39, ou,
b) o servidor é o servidor de origem para a resposta, o trailer
campos constituídos inteiramente de metadados opcionais, como o destinatário
pode usar a mensagem (em uma forma aceitável para o servidor de origem)
sem receber esses metadados. Em outras palavras, o servidor de origem
está disposta a aceitar a possibilidade que os campos de reboque pode
ser descartado silenciosamente ao longo do caminho para o cliente.
Esta exigência impede que uma falha de interoperabilidade quando o
mensagem está sendo recebida por um HTTP/1.1 (ou posterior) e proxy
encaminhado para um destinatário HTTP/1.0. Isso evita uma situação em que
conformidade com o protocolo exigiria uma possível
buffer infinito no proxy.
Um processo de exemplo para decodificar uma Chunked-Corpo é apresentado no
apêndice 19.4.6.
Todos os HTTP/1.1 aplicações devem ser capazes de receber e decodificar as
“Blocos” de transferência de codificação, e deve ignorar as extensões extensão chunk-
eles não entendem.
3,7 Tipos de Mídia
HTTP usa Internet Media Types [17] na seção Content-Type (
14,17) e Aceitar (art. 14.1) campos de cabeçalho, a fim de fornecer
dados aberta e extensível de digitação e tipo de negociação.
tipo de mídia-type = “/ * subtipo (“; “parâmetro)
type = token
subtipo = token
Parâmetros podem seguir o tipo / subtipo sob a forma de atributo / valor
pares (como definido na secção 3.6).
O tipo, subtipo e nomes de atributos de parâmetros são case-
insensível. Os valores dos parâmetros podem ou não ser maiúsculas de minúsculas,
dependendo da semântica do nome do parâmetro. Linear espaço em branco
(LWS) não deve ser utilizado entre o tipo e subtipo, nem entre o
atributo e seu valor. A presença ou ausência de um parâmetro pode
ser significativo para a transformação de um tipo de mídia, em função da sua
definição no âmbito do registo tipo de mídia.
Fielding, et al. Standards Track [Página 26]
?
HTTP/1.1 RFC 2616 junho 1999
Note que algumas aplicações mais antigas HTTP não reconhecem o tipo de mídia
parâmetros. Quando o envio de dados para aplicações de HTTP mais velhos,
implementações só deve usar parâmetros de tipo de mídia quando são
exigidas por esse tipo de definição de subtipo /.
Media valores do tipo são registrados com a Internet Assigned Number
Authority (IANA [19]). O processo de registo do tipo de mídia é
descrito na RFC 1590 [17]. Utilização de tipos de mídia não é registrado
desencorajado.
3.7.1 Padrões de canonização e texto
os tipos de mídia de Internet são registrados com uma forma canônica. Um
corpo da entidade transferidos através de mensagens HTTP devem ser representados na
forma canônica adequado antes de sua transmissão, exceto para
“Texto” tipos, conforme definido no parágrafo seguinte.
Quando na forma canônica, a mídia subtipos do texto “CRLF uso tipo
a quebra de linha de texto. HTTP relaxa esta exigência e permite a
transporte de suportes de texto simples ou com CR LF sozinho representando uma linha
quebrar quando é feito de forma consistente para toda uma entidade do corpo. HTTP
aplicações deve aceitar CRLF, CR nua, nua e LF como sendo
representante de uma quebra de linha na mídia texto recebido via HTTP. Em
Além disso, se o texto é representado em um conjunto de caracteres que não
octetos usar 13 e 10 para CR e LF, respectivamente, como é o caso de
alguns conjuntos de caracteres multi-byte, HTTP permite o uso de qualquer octeto
seqüências são definidas por esse conjunto de caracteres para representar a
equivalente a CR e LF para quebras de linha. Esta flexibilidade em relação
quebras de linha só se aplica aos meios de comunicação de texto no corpo da entidade, um CR nua
LF ou NÃO DEVE ser substituído por CRLF em qualquer uma das HTTP controle
estruturas (tais como campos de cabeçalho e os limites multipart).
Se uma entidade corpo é codificado com um teor de codificação, os activos subjacentes
Os dados devem ser na forma definida acima antes de serem codificados.
O parâmetro “charset é usada com alguns tipos de mídia para definir o
conjunto de caracteres (seção 3.4) dos dados. Quando não charset
parâmetro é fornecido pelo remetente, a mídia subtipos do texto “
tipo são definidos para ter um valor padrão de charset “ISO-8859-1”, quando
recebido via HTTP. Dados em conjuntos de caracteres diferentes de “ISO-8859-1” ou
seus subconjuntos devem ser rotulados com um charset valor adequado. Ver
seção 3.4.1 para compatibilidade problemas.
3.7.2 Tipos de Multipart
MIME prevê uma série de “multipart” tipos – de encapsulations
uma ou mais entidades dentro de um único corpo da mensagem. Todos os multipart
tipos compartilham uma sintaxe comum, tal como definido no ponto 5.1.1 do RFC 2046
Fielding, et al. Standards Track [Página 27]
?
HTTP/1.1 RFC 2616 junho 1999
[40], e deve incluir um parâmetro de limite, como parte do tipo de mídia
valor. O corpo da mensagem é ela própria um elemento de protocolo e deve
portanto, use apenas CRLF para representar as quebras de linha entre as partes do corpo.
Ao contrário do RFC 2046, o epílogo de uma mensagem concatenada deve ser
vazio, aplicações HTTP não pode transmitir o epílogo (mesmo se o
original multipart contém um epílogo). Essas restrições existem na
fim de preservar a natureza auto-delimitação de uma mensagem concatenada-
do corpo, onde o “fim” do corpo da mensagem é indicado pelo
terminando limite multipart.
Em geral, trata de um HTTP multipart corpo da mensagem, não de forma diferente
qualquer outro tipo de mídia: estritamente como carga. A única exceção é o
“Multipart / byteranges” apêndice (tipo 19.2) quando ele aparece na 206
(Partial Content) resposta, que será interpretado por alguns HTTP
mecanismos de cache, como descrito nas seções 13.5.4 e 14.16. Em todos os
outros casos, o agente do usuário HTTP deve seguir o mesmo ou similar
comportamento como um agente de usuário MIME que após a recepção de um tipo multipart.
O MIME cabeçalho campos dentro de cada parte do corpo de uma mensagem concatenada-
organismo não tem qualquer significado para além do HTTP que está definida na
sua semântica MIME.
Em geral, um agente do usuário HTTP deve seguir o mesmo ou similar
comportamento como um agente de usuário MIME que após a recepção de um tipo multipart.
Se o aplicativo recebe um subtipo não reconhecido em várias partes, o
aplicação deve tratá-la como sendo equivalente a “multipart / mista.
Nota: O “multipart / form-data tipo” foi especificamente definido
para transportar dados de forma adequada para a transformação através do POST
método de requisição, conforme descrito no RFC 1867 [15].
Tokens 3,8 Produto
fichas de produto são utilizadas para permitir a comunicação de aplicações
se identificar pelo nome e versão do software. A maioria dos campos utilizando
produto tokens permitem também sub-produtos que representam uma parte significativa
do pedido para a lista, separados por espaço em branco. Por
convenção, os produtos são listados por ordem de sua importância
para identificar o aplicativo.
produto = [token “/]”-versão do produto
versão do produto = token
Exemplos:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Servidor: Apache/0.8.4
Fielding, et al. Standards Track [Página 28]
?
HTTP/1.1 RFC 2616 junho 1999
tokens produto deve ser curto e direto ao ponto. Eles não devem ser
usados para publicidade ou informações não essenciais outros. Embora qualquer
token personagem pode aparecer em uma versão do produto, este token DEVE
ser utilizado apenas para um identificador de versão (ou seja, versões sucessivas de
o mesmo produto só deve diferir na porção versão do produto da
o valor do produto).
3,9 Valores Qualidade
HTTP negociação de conteúdo (seção 12) usa “ponto flutuante curto”
números para indicar a importância relativa (“peso”) de várias
parâmetros negociáveis. Um peso é normalizado para um número real
intervalo de 0 a 1, onde 0 é o valor mínimo e um máximo
valor. Se um parâmetro tem um valor de qualidade de 0, em seguida, com conteúdo
este parâmetro é ‘inaceitável’ para o cliente. HTTP/1.1
aplicações não deve gerar mais de três dígitos após a
ponto decimal. Usuário configuração desses valores devem ser
limitado desta forma.
qValue = (“0” [“. 3digit 0 *])
| (“1” [“.” 0 * 3 (“0”)])
“Os valores de Qualidade” é um termo impróprio, uma vez que esses valores representam apenas
degradação relativa da qualidade desejada.
Tags 3,10 Língua
A linguagem tag identifica uma linguagem natural falada, escrita ou
caso contrário transmitida por seres humanos para a comunicação de informações
para outros seres humanos. As linguagens de computador estão expressamente excluídos.
HTTP usa tags linguagem dentro da língua-Accept e Content-
campos de idiomas.
A sintaxe e registro de marcas da linguagem HTTP é o mesmo que
definido pela RFC 1766 [1]. Em resumo, uma marca linguagem é composta de um
ou mais peças: uma etiqueta de idioma primário e uma série possivelmente vazia de
subtags:
tag-language = * tag primário (“-” subtag)
* Tag primária = 1 8ALPHA
subtag = 1 * 8ALPHA
O espaço em branco não é permitido dentro da marca e todas as tags são case-
insensível. O espaço de nomes de marcas da linguagem é administrado pelo
IANA. tags Exemplo incluem:
pt, en-US, en cockney, i-cherokee, x-porco latino-
Fielding, et al. Standards Track [Página 29]
?
HTTP/1.1 RFC 2616 junho 1999
onde qualquer duas letras tag primário é uma abreviação de ISO-639 línguas
e as duas letras iniciais subtag é um código ISO-3166 país. (O
últimos três marcas acima não estão registados tags: todos, mas os últimos são
exemplos de marcas que poderiam ser registrados no futuro.)
Tags 3,11 Entidade
Entidade tags são usados para comparar duas ou mais entidades do mesmo
recurso solicitado. HTTP/1.1 usa tags entidade no ETag (secção
14,19), If-Match (seção 14.24), If-None-Match (art. 14,26), e
Se-Range (seção 14,27) Os campos de cabeçalho. A definição de como elas
são utilizados e comparados como validadores cache está na seção 13.3.3. Um
tag entidade consiste em uma string opaca citado, possivelmente prefixo
um indicador de fraqueza.
tag entidade = [fraco] opaco tag
fraco = “/ W”
tag opaco = citou-corda
A tag “entidade forte” pode ser compartilhada por duas entidades de um recurso
somente se eles são equivalentes em igualdade octeto.
A “tag entidade fraca”, indicada por um “W / prefixo”, podem ser compartilhados por
duas entidades de um único recurso que as entidades são equivalentes e
poderiam ser substituídos uns pelos outros, sem qualquer alteração significativa na
semântica. A tag entidade fraca pode ser usado apenas para comparação fraca.
Uma tag entidade deve ser única em todas as versões de todas as entidades
associadas a um recurso especial. Um valor de tag dada entidade pode
ser usado para entidades obtidos por solicitações de URIs diferentes. O uso
do mesmo valor entidade tag em conjunto com entidades obtidos por
solicitações de URIs diferentes não implica a equivalência dos
entidades.
Faixa de 3,12 unidades
HTTP/1.1 permite que um cliente solicitar que apenas uma parte (uma série) da
entidade de resposta ser incluídos dentro da resposta. HTTP/1.1 usa gama
unidades do Range (seção 14,35) e Content-Range (art. 14,16)
campos de cabeçalho. Uma entidade pode ser discriminado em função subranges
para várias unidades estruturais.
unidade de gama | bytes = unidade de gama outras unidades
bytes unidade = “bytes”
outra gama unidade = token
A unidade de intervalo só é definido pelo HTTP/1.1 “bytes”. HTTP/1.1
implementações podem ignorar intervalos especificados usando outras unidades.
Fielding, et al. Standards Track [Página 30]
?
HTTP/1.1 RFC 2616 junho 1999
HTTP/1.1 foi concebido para permitir implementações de aplicações
que não dependem do conhecimento dos intervalos.
Mensagem 4 HTTP
Tipos de 4,1 Message
mensagens HTTP consiste em pedidos do cliente para o servidor e as respostas
do servidor para o cliente.
HTTP de mensagem = Request | Resposta; mensagens HTTP/1.1
Pedido (art. 5) e Resposta (secção 6) mensagens usar o genérico
formato de mensagem RFC 822 [9] para a transferência de entidades (a carga
da mensagem). Ambos os tipos de mensagem consiste de um começo de linha, zero
ou mais campos de cabeçalho (também conhecido como “headers”), uma linha vazia (ie,
uma linha com nada que precede o CRLF) indicando o fim do
campos de cabeçalho e, possivelmente, uma mensagem do corpo.
mensagem genérica = iniciar-line
* (CRLF cabeçalho da mensagem)
CRLF
[] Do corpo da mensagem-
linha de partida = Request-Line | Status-Line
No interesse da robustez, os servidores devem ignorar qualquer vazio
s (linha) onde recebeu um pedido de linha é o esperado. Em outras palavras, se
o servidor está lendo o fluxo do protocolo no início de um
e recebe uma mensagem de CRLF em primeiro lugar, ele deve ignorar o CRLF.
Algumas implementações cliente HTTP/1.0 buggy gerar CRLF extra de
depois de um pedido POST. Para reafirmar o que é expressamente proibido pela
BNF, um cliente HTTP/1.1 não deve seguir prefácio ou um pedido com um
CRLF extra.
Cabeçalhos 4,2 Message
campos de cabeçalho HTTP, que incluem header-geral (seção 4.5),
cabeçalho de solicitação (seção 5.3), o cabeçalho de resposta (seção 6.2), e
cabeçalho da entidade (seção 7.1), campos, seguem o mesmo formato genérico como
que consta do ponto 3.1 do RFC 822 [9]. Cada campo de cabeçalho consiste
de um nome seguido de dois pontos (“:”) eo valor do campo. Os nomes dos campos
são insensíveis ao caso. O campo de valor pode ser precedida por uma qualquer quantidade
de LWS, embora um único SP é o preferido. campos de cabeçalho pode ser
ampliado com várias linhas que antecede cada linha extra com a
SP ou pelo menos um HT. Os pedidos devem seguir “forma comum”, onde
um é conhecido ou indicado, ao gerar HTTP construções, desde
podem existir algumas implementações que não aceitam nada
Fielding, et al. Standards Track [Página 31]
?
HTTP/1.1 RFC 2616 junho 1999
além das formas comuns.
cabeçalho da mensagem = nome do campo “:”] [valor do campo
nome do campo = token
valor do campo = (* campo de conteúdo | LWS)
conteúdo do campo = <octetos que compõem o campo de valor
e que consiste em Texto ou combinações *
do token, separadores, e citou-string>
O campo de conteúdo não inclui nenhum líder ou à direita LWS:
espaço em branco linear que ocorrem antes do primeiro espaço em branco não
personagem do campo de valor, ou após o último espaço em branco não
personagem do campo de valor. Essa esquerda ou à direita LWS pode estar
removido sem alterar a semântica do valor do campo. Qualquer LWS
que ocorre entre maio de domínio de conteúdos ser substituídos por um único SP
antes de interpretar o valor do campo ou encaminhar a mensagem
jusante.
A ordem na qual os campos de cabeçalho com diferentes nomes de domínio são
recebido não é significativa. Contudo, é “boa prática” para enviar
campos de cabeçalho-geral do primeiro, seguido pelo cabeçalho do pedido ou resposta
campos de cabeçalho, e terminando com os campos de cabeçalho entidade.
Vários campos cabeçalho da mensagem com o mesmo nome do campo pode ser
presentes em uma mensagem, se e somente se todo o campo de valor para que
campo de cabeçalho é definido como um exemplo, separados por vírgulas [lista, # (valores)].
Deve ser possível combinar os campos de cabeçalho múltiplos em um
“O campo nome: valor do campo-par”, sem alterar a semântica do
mensagem, anexando a cada campo de valor subseqüente para o primeiro, cada
separadas por uma vírgula. A ordem na qual os campos de cabeçalho com o mesmo
nome do campo são recebidas é, portanto, significativa para o
interpretação do valor do campo combinado, e, assim, uma proxy NÃO DEVE
alterar a ordem dos valores de campo quando uma mensagem é enviada.
4,3 Corpo da mensagem
O corpo da mensagem (se houver) de uma mensagem HTTP é usado para transportar o
corpo da entidade associada com o pedido ou resposta. A mensagem do corpo
difere da entidade corpo-somente quando a transferência de codificação foi
aplicada, conforme indicado pelo campo de cabeçalho Transfer-Encoding (secção
14,41).
corpo da mensagem = entidade corpo-
| <entity-body Codificado como por Transfer-Encoding>
Transfer-Encoding deve ser usado para indicar qualquer transferência de códigos
aplicado por um aplicativo para garantir a segurança ea boa transferência do
mensagem. Transfer-Encoding é uma propriedade da mensagem, não da
Fielding, et al. Standards Track [Página 32]
?
HTTP/1.1 RFC 2616 junho 1999
entidade e, portanto, podem ser adicionadas ou removidas por qualquer aplicação ao longo do
pedido cadeia / resposta. (No entanto, seção 3,6 restrições locais sobre
quando determinados transferência de códigos podem ser utilizados).
As regras para quando o corpo da mensagem é permitido em uma mensagem diferente para
solicitações e respostas.
A presença de um corpo da mensagem em um pedido é sinalizado pelo
inclusão de um Content-Length ou campo Transfer-Encoding cabeçalho em
o pedido de mensagem-headers. Uma mensagem do corpo não deve ser incluído no
um pedido, se a especificação do método de solicitação (ponto 5.1.1)
não permitir o envio de uma entidade-corpo nas solicitações. Um servidor deve
ler e enviar uma mensagem do corpo sobre o pedido, se o método de solicitação
não inclui a semântica definida por uma entidade-corpo, então o
corpo da mensagem devem ser ignorados durante o manuseamento do pedido.
Para mensagens de resposta, com ou sem um corpo da mensagem é incluída com
uma mensagem depende tanto do método de pedido e da resposta
código de status (seção 6.1.1). Todas as respostas para o método de solicitação HEAD
NÃO DEVE incluir uma mensagem do corpo, embora a presença da entidade,
campos de cabeçalho pode levar a crer que eles fazem. Todos os 1xx
(Informativo), 204 (sem conteúdo), e 304 (não modificado) respostas
NÃO DEVE incluir uma mensagem do corpo. Todas as outras respostas que incluem um
corpo da mensagem, embora possa ser de comprimento zero.
Comprimento 4,4 Message
A transferência de comprimento de uma mensagem é o comprimento do corpo da mensagem, como
que aparece na mensagem, isto é, após a transferência ter-codificações
foi aplicada. Quando um corpo da mensagem é incluída com uma mensagem, o
Prazo de transferência de corpo que é determinada por um dos seguintes
(Em ordem de prioridade):
1.Os mensagem de resposta que “não deve” incluir uma mensagem do corpo (como
como 1xx, 204, e 304 respostas e qualquer resposta a um chefe
pedido) é sempre terminado por a primeira linha vazia após a
campos de cabeçalho, independentemente de os campos de cabeçalho entidade presente em
a mensagem.
2.Se o campo de cabeçalho Transfer-Encoding (secção 14,41) está presente e
tem qualquer valor diferente de “identidade”, em seguida, a transferência de comprimento é
definido pela utilização do “blocos” de transferência de codificação (seção 3.6),
a menos que a mensagem é denunciado por fechar a conexão.
3.Caso um campo de cabeçalho Content-Length (seção 14.13), está presente, a sua
valor decimal em octetos representa tanto a entidade de comprimento e
comprimento de transferência. O campo de cabeçalho Content-Length NÃO DEVE ser enviado
Se estes dois comprimentos diferentes (ou seja, se um Transfer-Encoding
Fielding, et al. Standards Track [Página 33]
?
HTTP/1.1 RFC 2616 junho 1999
campo de cabeçalho está presente). Se uma mensagem é recebida com tanto um
Transfer-Encoding cabeçalho campo e um campo de cabeçalho Content-Length,
o último deve ser ignorado.
4.Caso a mensagem utiliza o tipo de mídia “multipart / byteranges”, e os
ransferência comprimento não é especificado de outra forma, então essa auto-
elimiting tipo de mídia define a transferência de comprimento. Este tipo de mídia
UST ser utilizado se o remetente sabe que o destinatário possa ass
ele, a presença de um pedido de um cabeçalho com ultiple Faixa de byte
especificadores variam de um cliente de 1,1 significa que o lient pode analisar
multipart / byteranges respostas.
Um cabeçalho de intervalo pode ser transmitido por um proxy 1.0 que não
compreender multipart / byteranges, neste caso o servidor deve
delimitar a mensagem usando os métodos definidos nos itens 1,3 e 5 de
nesta seção.
5.By o servidor fechar a conexão. (Encerramento da conexão
não pode ser usado para indicar o fim de um organismo pedido, desde que
deixaria qualquer possibilidade de o servidor para enviar de volta uma resposta.)
Para compatibilidade com aplicações HTTP/1.0, pedidos HTTP/1.1
contendo uma OBRIGAÇÃO corpo da mensagem, incluir um cabeçalho Content-Length válido
campo a menos que o servidor é conhecido por ser o padrão HTTP/1.1. Se um
pedido contém uma mensagem de corpo e um Content-Length não é dado,
o servidor deve responder com 400 pedido (mau) se não puder
determinar o comprimento da mensagem, ou com 411 (comprimento desejado) se
pretende insistir em receber um válido Content-Length.
Todos os pedidos HTTP/1.1 que recebem as entidades devem aceitar o
“Blocos” de transferência de codificação (seção 3.6), permitindo assim que este mecanismo
a ser utilizado para mensagens quando o comprimento da mensagem não pode ser determinado
de antecedência.
Mensagens não deve incluir tanto um campo de cabeçalho Content-comprimento e um
identidade não-transferência-codificação. Se a mensagem não incluir um não-
identidade de transferência de codificação, o Content-Length deve ser ignorado.
Quando um Content-Length é dada em uma mensagem onde um corpo da mensagem é
permitido, o seu valor do campo deve corresponder exatamente ao número de octetos em
o corpo da mensagem. HTTP/1.1 agentes devem notificar o usuário quando um
comprimento inválido é recebido e detectado.
4,5 Geral Campos de cabeçalho
Existem campos de cabeçalho poucos que têm aplicabilidade geral para
tanto mensagens de solicitação e resposta, mas que não se aplicam ao
entidade que está sendo transferido. Estes campos de cabeçalho só se aplica à
Fielding, et al. Standards Track [Página 34]
?
HTTP/1.1 RFC 2616 junho 1999
mensagem a ser transmitida.
header-geral = Cache-Control; Seção 14,9
| Ligação; Secção 14,10
| Data; Secção 14,18
Pragma |; Secção 14,32
Trailer |; Secção 14,40
| Transfer-Encoding; Secção 14,41
| Upgrade; Secção 14,42
| Via; Secção 14,45
| Aviso; Secção 14,46
nomes de domínio geral cabeçalho pode ser estendida de forma confiável apenas em
combinação com uma mudança na versão do protocolo. No entanto, novos ou
campos de cabeçalho experimental pode ser dada a semântica da geral
campos de cabeçalho, se todas as partes envolvidas na comunicação a reconhecer-lhes
ser campos de cabeçalho geral. campos de cabeçalho não reconhecidos são tratados como
campos de cabeçalho entidade.
5 Pedido
A mensagem de solicitação de um cliente para um servidor inclui, no
primeira linha da mensagem, o método a ser aplicado ao recurso,
o identificador do recurso, ea versão do protocolo em uso.
Pedido = Request Line; Seção 5.1
(* (Header-geral; Seção 4.5
| Pedido de cabeçalho; Seção 5.3
| Cabeçalho entidade) CRLF), Seção 7.1
CRLF
] Corpo da mensagem [; Seção 4.3
5,1 Request-Line
A solicitação de linha começa com um método de token, seguido pelo
Request-URI ea versão do protocolo, e termina com CRLF. O
os elementos são separados por caracteres de SP. N CR ou LF é permitido
exceto na seqüência CRLF final.
Request Line = Método SP Request-URI CRLF SP HTTP-Version
Fielding, et al. Standards Track [Página 35]
?
HTTP/1.1 RFC 2616 junho 1999
5.1.1 Method
O token método indica o método a ser realizada no
recurso identificado pelo Request-URI. O método é sensível a maiúsculas.
Method = “Opções”; 9,2
| “GET secção”; 9,3
| “Cabeça”, Seção 9.4
| POST “; Secção 9.5
| “PUT”, Seção 9.6
| “DELETE” secção; 9,7
| “TRACE”, Seção 9.8
| “CONNECT” secção; 9,9
| Método de extensão
método de extensão = token
A lista dos métodos permitidos por um recurso pode ser especificado em uma
Permitir campo de cabeçalho (art. 14.7). O código de retorno da resposta
sempre notifica o cliente se um método é permitido atualmente em um
recurso, uma vez que o conjunto de métodos permitiu pode mudar dinamicamente. Um
servidor de origem deve retornar o código de status 405 (Método não permitido)
se o método é conhecido pelo servidor de origem, mas não permitiu a
recurso solicitado, e 501 (não implementado) se o método é
despercebidas ou não implementadas pelo servidor de origem. Os métodos GET
ea cabeça devem ser suportados por todos os servidores de uso geral. Todos os outros
métodos são opcionais, no entanto, se os métodos acima são implementados,
devem ser implementadas com a mesma semântica que os especificados
na secção 9.
5.1.2 Pedido-URI
O Request-URI é um Uniform Resource Identifier (seção 3.2) e
identifica o recurso sobre o qual se aplica o pedido.
Pedido-URI = “*” | absoluteURI | abs_path | autoridade
As quatro opções para o Request-URI são dependentes da natureza do
pedido. O asterisco “*” significa que o pedido não se aplica a um
recurso especial, mas para o próprio servidor, e só é permitida
quando o método utilizado não se aplica necessariamente a um recurso. Um
exemplo seria
OPÇÕES * HTTP/1.1
A forma absoluteURI é necessária quando o pedido está a ser feita para um
proxy. O proxy é solicitado a encaminhar o pedido ou o serviço
a partir de um cache válido, e retornar a resposta. Observe que o proxy pode
encaminhar a solicitação para outro proxy ou diretamente para o servidor
Fielding, et al. Standards Track [Página 36]
?
HTTP/1.1 RFC 2616 junho 1999
especificada pelo absoluteURI. Para evitar loops, solicitar um
proxy deve ser capaz de reconhecer todos os nomes de seus servidores, incluindo
as alcunhas, as variações locais, bem como o endereço IP numérico. Um exemplo
Pedido de linha seria:
HTTP/1.1 GET http://www.w3.org/pub/WWW/TheProject.html
Para permitir a transição para absoluteURIs em todos os pedidos no futuro
versões de HTTP, todos os servidores HTTP/1.1 deve aceitar o absoluteURI
formulário de pedidos, embora HTTP/1.1 clientes só gerará
los em pedidos de proxies.
O formulário de autoridade é apenas usado pelo método CONNECT (seção 9.9).
A forma mais comum de solicitação-URI é utilizada para identificar uma
recurso em um servidor de origem ou gateway. Neste caso, a absoluta
caminho do URI deve ser transmitida (ver secção 3.2.1, abs_path) como
Pedido-URI, e localização na rede da URI (autoridade) deve
ser transmitidos em um campo de cabeçalho de host. Por exemplo, um cliente que deseje
para recuperar os recursos acima diretamente do servidor de origem seria
criar uma conexão TCP para a porta 80 do host “www.w3.org” e enviar
as linhas:
GET / pub / WWW / TheProject.html HTTP/1.1
Host: www.w3.org
seguido pelo restante do pedido. Note-se que o caminho absoluto
não pode estar vazio, caso não esteja presente na URI original, ele deve ser
dado como “/” (a raiz do servidor).
O Request-URI é transmitido no formato especificado na seção
3.2.1. Se o Request-URI é codificada usando o “% HEX HEX” encoding
[42], o servidor de origem deve decodificar o Pedido-URI, a fim de
interpretar corretamente o pedido. Servidores devem responder às inválido
Pedidos de URIs com um código de status adequado.
Um proxy transparente não deve reescrever a parte “abs_path do
recebeu o pedido-URI quando encaminhá-lo para o próximo servidor de entrada,
exceto como descrito acima para substituir um abs_path nulo com “/”.
Nota: O “não reescrever” regra impede que o proxy de alterar o
significado do pedido quando o servidor de origem está usando impropriamente
um não-reservados caráter URI para uma finalidade reservados. Implementadores
devem estar cientes de que alguns proxies pre-HTTP/1.1 ter sido conhecida a
reescrever o Request-URI.
Fielding, et al. Standards Track [Página 37]
?
HTTP/1.1 RFC 2616 junho 1999
5.2 O recurso identificado por um Pedido
O recurso exatamente identificado por um pedido é determinada pela Internet
analisar tanto o pedido-URI e do campo de cabeçalho de host.
Um servidor de origem que não permite que os recursos que diferem pela
solicitadas host MAIO ignorar o valor do campo de cabeçalho de host quando
determinação do recurso identificado por um pedido de HTTP/1.1. (Mas veja
seção 19.6.1.1 para outros requisitos relativos ao apoio em HTTP/1.1 Host).
Um servidor de origem que faz diferenciar recursos com base no host
solicitada (por vezes referido como hosts virtuais ou vaidade host
nomes) devem usar as seguintes regras para determinar o pedido
recurso sobre um pedido HTTP/1.1:
1. Se o Request-URI é um absoluteURI, o acolhimento é parte da
Request-URI. Qualquer Host valor do campo de cabeçalho no pedido deve ser
ignorados.
2. Se o Request-URI não é uma absoluteURI, e inclui o pedido
um campo de cabeçalho de host, o host é determinado pelo cabeçalho Host
valor do campo.
3. Se o host, conforme determinado pela regra de 1 ou 2, não é um host válido na
o servidor, a resposta deve ser uma mensagem de erro 400 (Bad Request).
Beneficiários de um pedido HTTP/1.0 que não possui um campo de cabeçalho de host MAIO
tentativa de usar heurísticas (exame por exemplo, do caminho para a URI
algo único para um determinado host) para determinar o que
recurso exato está sendo solicitado.
5,3 cabeçalho campos de solicitação
Os campos de cabeçalho de solicitação permitir que o cliente passe mais
informações sobre o pedido, e sobre o próprio cliente, para o
servidor. Esses campos atuam como modificadores de pedido, com a semântica
equivalentes aos parâmetros de um método de linguagem de programação
invocação.
cabeçalho da solicitação = Aceitar; Seção 14.1
| Accept-charset, ponto 14.2
| Accept-Encoding, Seção 14.3
| Accept-Language, Seção 14.4
Autorização |; Seção 14,8
| Esperar; Secção 14,20
| De; Secção 14,22
Host |; Secção 14,23
| Se o jogo; Secção 14,24
Fielding, et al. Standards Track [Página 38]
?
HTTP/1.1 RFC 2616 junho 1999
| If-Modified-Since secção; 14,25
| If-None-Match, Seção 14,26
| Se Range; Secção 14,27
| Se-Unmodified-Desde secção; 14,28
| Max-Forwards, Seção 14,31
| Proxy-Autorização, Seção 14,34
Range |; Secção 14,35
Referer |; Secção 14,36
| TE; Secção 14,39
| User Agent; Secção 14,43
Pedido de nomes de campo de cabeçalho pode ser estendida de forma confiável apenas em
combinação com uma mudança na versão do protocolo. No entanto, novos ou
MAIO cabeçalho campos experimentais ser dada a semântica da solicitação
campos de cabeçalho, se todas as partes envolvidas na comunicação a reconhecer-lhes
ser campos de cabeçalho de solicitação. campos de cabeçalho não reconhecidos são tratados como
campos de cabeçalho entidade.
6 Resposta
Depois de receber e interpretar uma mensagem de solicitação, o servidor responde
com uma mensagem de resposta HTTP.
Resposta = Status-Line, Seção 6.1
(* (Header-geral; Seção 4.5
| Resposta cabeçalho; Seção 6.2
| Cabeçalho entidade) CRLF), Seção 7.1
CRLF
] Corpo da mensagem [; Seção 7.2
6,1 Status-Line
A primeira linha de uma mensagem de resposta é o Status-Line, que consiste
da versão do protocolo seguido por um código numérico e seu status
frase textual associada, com cada elemento separado por SP
caracteres. N CR ou LF é permitida, com exceção na seqüência CRLF final.
Status-Line = HTTP Version-SP-SP Status Code CRLF Frase Reason-
6.1.1 Código de Status e Razão Frase
O elemento Status-Code é um código de resultado de 3 dígitos do número inteiro
tentativa de entender e satisfazer o pedido. Estes códigos são inteiramente
definido na seção 10. The Reason-Phrase destina-se a dar uma pequena
descrição textual do Status-Code. O Status-Code é destinado
para uso por autómatos e da razão, a frase é destinados ao consumo humano
usuário. O cliente não é obrigado a analisar ou mostrar a Razão,
Frase.
Fielding, et al. Standards Track [Página 39]
?
HTTP/1.1 RFC 2616 junho 1999
O primeiro dígito do código de status define a classe da resposta. O
últimos dois dígitos não têm qualquer papel de categorização. Há 5
valores para o primeiro dígito:
– 1xx: Informativa – Pedido recebido processo, continuando
– 2xx: Sucesso – A ação foi recebida com sucesso,
compreendido e aceite
– Redirecionamento: 3xx – Outras acções devem ser tomadas a fim de
completar o pedido
– 4xx: Client Error – O pedido contém sintaxe inválida ou não pode
ser preenchidas
– 5xx: Server Error – O servidor não cumpriu uma aparentemente
pedido válido
Os valores individuais dos códigos de status numérico definido para
HTTP/1.1, e um exemplo de conjunto de correspondentes Reason-Phrase, são
apresentados a seguir. As frases razão listados aqui são apenas
recomendações – que podem ser substituídos por equivalentes local sem
que afectam o protocolo.
Status Code =
“100 Secção”; 10.1.1: Continue
| “101”; secção 10.1.2: Protocolos de comutação
| “200”; secção 10.2.1: OK
| “201”; secção 10.2.2: Criado
| “202”; secção 10.2.3: Aprovado
| “203”; secção 10.2.4: Informação não-autorizada
| “204”; secção 10.2.5: No Content
| “205”; secção 10.2.6: Conteúdo Reset
| “206”; secção 10.2.7: Conteúdo parcial
| “300 Secção”; 10.3.1: Escolhas Múltiplas
| “301”; secção 10.3.2: Movidos Permanentemente
| “302”; secção 10.3.3: Encontrada
| “303”; secção 10.3.4: Ver Outros
| “304”; secção 10.3.5: Not Modified
| “305”; secção 10.3.6: Usar Proxy
| “307”; secção 10.3.8: Temporary Redirect
| “400”; secção 10.4.1: Bad Request
| “401”; secção 10.4.2: não autorizado
| “402”; secção 10.4.3: Pagamento Obrigatório
| “403”; secção 10.4.4: Proibido
| “404”; secção 10.4.5: Not Found
| “405”; secção 10.4.6: Método não permitido
| “406”; secção 10.4.7: Não é aceitável
Fielding, et al. Standards Track [Página 40]
?
HTTP/1.1 RFC 2616 junho 1999
| “407”; secção 10.4.8: Autenticação de proxy necessária
| “408”; secção 10.4.9: Pedido de tempo limite
| “409”, Seção 10.4.10: Conflito
| “410”; Seção 10.4.11: Gone
| “411”, Seção 10.4.12: Comprimento necessário
| “412”, Seção 10.4.13: Requisito Falha
| “413”, Seção 10.4.14: Entidade de solicitação muito grande
| “414”, Seção 10.4.15: Pedido-URI Too Large
| “415”, Seção 10.4.16: Tipo de mídia não suportado
| “416”; Seção 10.4.17: intervalo não solicitadas satisfatível
| “417”, Seção 10.4.18: Falha na expectativa
| “500”; secção 10.5.1: Internal Server Error
| “501”; secção 10.5.2: Não Implementado
| “502”; secção 10.5.3: Bad Gateway
| “503”; secção 10.5.4: Service Unavailable
| “504”; secção 10.5.5: Gateway Time-out
| “505”; secção 10.5.6: Versão HTTP não suportada
| Extensão do código
código de extensão = 3digit
Razão-Frase = * <TEXT, excluindo CR, LF>
códigos de status HTTP são extensíveis. pedidos HTTP não são necessários
compreender o significado de todos os códigos de status social, embora tal
entendimento é obviamente desejável. No entanto, o pedido deve
entender a classe de qualquer código de status, como indicado pelo primeiro
dígitos, e tratar qualquer resposta não reconhecido como sendo equivalente ao
x00 código de status da classe, com a ressalva de que um
resposta não deve ser reconhecido em cache. Por exemplo, se um
código de status reconhecido de 431 é recebida pelo cliente, pode
seguramente assumir que havia algo errado com seu pedido e
tratar a resposta como se tivesse recebido um código de status 400. Em tal
casos, os agentes deveriam apresentar para o usuário, a entidade voltou
com a resposta, uma vez que essa entidade é susceptível de incluir seres humanos
informações legíveis, que vai explicar a situação incomum.
6,2 cabeçalho campos de resposta
Os campos de cabeçalho de resposta permitir que o servidor passe adicional
informações sobre a resposta que não pode ser colocado no Estado-
Line. Estes campos de cabeçalho dar informações sobre o servidor e sobre
um novo acesso ao recurso identificado pelo Request-URI.
cabeçalho de resposta = Accept-Ranges, Seção 14,5
Idade |; Seção 14,6
ETag |; Secção 14,19
Localização |; Secção 14,30
| Proxy-Authenticate; Secção 14,33
Fielding, et al. Standards Track [Página 41]
?
HTTP/1.1 RFC 2616 junho 1999
| Retry-After secção; 14,37
| Server; Secção 14,38
| Vary; Secção 14,44
| WWW-Authenticate; Secção 14,47
nomes de campo de cabeçalho de resposta pode ser estendida de forma confiável apenas em
combinação com uma mudança na versão do protocolo. No entanto, novos ou
MAIO cabeçalho campos experimentais ser dada a semântica de resposta
campos de cabeçalho, se todas as partes envolvidas na comunicação a reconhecer-lhes
ser campos de cabeçalho resposta. campos de cabeçalho não reconhecidos são tratados como
campos de cabeçalho entidade.
7 Entidade
Mensagens de solicitação e resposta pode transferir uma entidade salvo disposição em contrário
restringida pelo método de solicitação ou código de status resposta. Uma entidade
consiste de campos de cabeçalho entidade e uma entidade do corpo, embora alguns
respostas só incluir a entidade-headers.
Nesta seção, o remetente eo destinatário referir-se tanto o cliente
ou o servidor, dependendo de quem envia e quem recebe a entidade.
7,1 Cabeçalho Campos Entidade
campos de cabeçalho Entity-define metainformation sobre a entidade ou órgão,
se nenhum corpo está presente, sobre o recurso identificado pela solicitação.
Algumas dessas metainformation é opcional; alguns podem ser exigidos pela
porções desta especificação.
cabeçalho da entidade = Permitir, Seção 14.7
| Conteúdo Encoding; Secção 14,11
| Conteúdo Linguagem; Seção 14.12
| Teor de comprimento; Secção 14,13
| Conteúdo Local; Secção 14,14
| Conteúdo-MD5, Seção 14,15
| Conteúdo Gama; Secção 14,16
| Tipo de Conteúdo; Secção 14,17
| Validade; Secção 14,21
| Last-Modified; Secção 14,29
| Extensão cabeçalho
cabeçalho de extensão = mensagem de cabeçalho
O mecanismo de cabeçalho de extensão permite que os campos adicionais do cabeçalho de entidade
a ser definida, sem alterar o protocolo, mas esses campos não podem
presumir-se para ser reconhecido pelo receptor. cabeçalho não reconhecido
campos devem ser ignorados pelo destinatário e deverá ser transmitido pelo
proxies transparentes.
Fielding, et al. Standards Track [Página 42]
?
HTTP/1.1 RFC 2616 junho 1999
7,2 corpo da entidade
A entidade corporal (se houver) enviados com uma solicitação HTTP ou a resposta está na
um formato e codificação definida pela entidade campos de cabeçalho.
corpo da entidade = * octeto
Uma entidade de corpo está presente apenas em uma mensagem quando um corpo da mensagem é
Actualmente, como descrito na seção 4.3. A entidade do corpo é obtido
do corpo da mensagem por qualquer decodificação Transfer-Encoding que possam
têm sido aplicados para garantir a correcta e segura transmissão da mensagem.
7.2.1 Tipo
Quando uma entidade corpo é fornecido com uma mensagem, o tipo de dados que
corpo é determinada através dos campos de cabeçalho Content-Type e Content-
Codificação. Estes definir uma camada dupla, ordenou a codificação do modelo:
corpo da entidade: = Content-Encoding (Content-Type (dados))
Content-Type especifica o tipo de mídia de dados subjacentes.
Content-Encoding pode ser usado para indicar qualquer conteúdo adicional
códigos aplicados aos dados, geralmente com o propósito de dados
compressão, que são propriedade do recurso solicitado. Não há
nenhuma codificação padrão.
Qualquer mensagem HTTP/1.1 contendo um corpo entidade deverá incluir uma
campo de cabeçalho Content-Type define o tipo de mídia que o corpo. Se
e somente se o tipo de mídia não é dado por um campo Content-Type, o
tentativa receptor pode adivinhar o tipo de mídia através da inspeção de sua
conteúdo e / ou a extensão de nome (s) da URI utilizado para identificar o
recursos. Se o tipo de mídia ainda é desconhecida, o beneficiário deve
tratá-lo como o tipo “application / octet-stream”.
7.2.2 Duração Entidade
A entidade de comprimento de uma mensagem é o comprimento do corpo da mensagem-
antes de qualquer transferência de códigos foram aplicados. Seção 4.4 define
como a transferência de comprimento de uma mensagem do corpo é determinado.
Fielding, et al. Standards Track [Página 43]
?
HTTP/1.1 RFC 2616 junho 1999
8 ligações
8,1 Conexões Persistentes
8.1.1 Finalidade
Antes de conexões persistentes, uma conexão TCP em separado foi
estabelecida para buscar cada URL, aumentando a carga nos servidores HTTP
e causando congestionamento na internet. O uso de imagens in-line e
outros dados associados muitas vezes requerem um cliente para fazer várias
solicitações do mesmo servidor em um curto espaço de tempo. Análise da
estes problemas de desempenho e os resultados de um protótipo
implementação estão disponíveis [26] [30]. Implementação de experiências e
medições de HTTP/1.1 real (RFC 2068) implementações bom show
resultados [39]. Alternativas têm sido explorados, por exemplo,
[T / TCP 27].
conexões HTTP persistentes têm uma série de vantagens:
– Ao abrir e fechar conexões TCP menos, o tempo de CPU é salvo
em routers e hosts (clientes, servidores, proxies, gateways,
túneis ou esconderijos), e memória utilizados para controle do protocolo TCP
blocos podem ser salvos no arquivo hosts.
– Os pedidos e respostas HTTP pode ser canalizado através de uma ligação.
Pipelining permite que um cliente faz vários pedidos sem
espera para cada resposta, permitindo que uma única conexão TCP para
ser usado com muito mais eficiência, com o tempo decorrido muito menor.
– Congestionamento da rede é reduzido através da redução do número de pacotes
causada por TCP é aberta, e permitindo TCP tempo suficiente para
determinar o estado de congestionamento da rede.
– Latência em solicitações subseqüentes é reduzido uma vez que não há tempo
gasto na abertura de conexão TCP handshake.
– HTTP pode evoluir mais graciosa, uma vez que erros podem ser relatados
sem a pena de fechar a conexão TCP. Clientes que utilizam
futuras versões do HTTP pode otimista tentar um novo recurso,
mas se comunicando com um servidor mais antigo, repetir com o velho
semântica após um erro é relatado.
implementações HTTP deve implementar as conexões persistentes.
Fielding, et al. Standards Track [Página 44]
?
HTTP/1.1 RFC 2616 junho 1999
8.1.2 Operação Geral
Uma diferença significativa entre HTTP/1.1 e versões anteriores do
HTTP é que as conexões persistentes são o comportamento padrão de qualquer
conexão HTTP. Ou seja, salvo indicação em contrário, o cliente
Deve assumir que o servidor irá manter uma conexão persistente,
mesmo após as respostas de erro do servidor.
Conexões persistentes fornecer um mecanismo pelo qual um cliente e um
servidor pode sinalizar o encerramento de uma conexão TCP. Esta sinalização tem
lugar usando o campo de cabeçalho Connection (seção 14.10). Depois de um fim
foi sinalizado, o cliente não deve enviar mais pedidos em que
conexão.
8.1.2.1 Negociação
Um servidor HTTP/1.1 pode presumir que um cliente HTTP/1.1 pretende
manter uma conexão persistente menos um cabeçalho Connection, incluindo
a conexão token “fechar” foi enviado o pedido. Se o servidor
escolhe para fechar a conexão imediatamente após o envio da
resposta, ele deve enviar um cabeçalho Connection, incluindo a
estreita conexão token.
Um HTTP/1.1 cliente pode esperar uma conexão permanecer aberta, mas
decidir mantê-lo aberto com base em saber se a resposta de um servidor
contém um cabeçalho de conexão com a conexão token perto. Em caso
o cliente não quer manter uma ligação mais do que isso
solicitação, ele deve enviar um cabeçalho Connection, incluindo a
estreita conexão token.
Se o cliente ou o servidor envia o próximo token no
cabeçalho Connection, que o pedido se torna o último para o
conexão.
Os clientes e servidores não deve presumir que uma conexão persistente é
mantida para as versões HTTP menos de 1,1 a menos que seja explicitamente
sinalizado. Veja Seção 19.6.2 para obter mais informações sobre para trás
compatibilidade com os clientes HTTP/1.0.
A fim de permanecer persistente, todas as mensagens sobre a conexão deve
tem um comprimento de mensagem auto-definido (isto é, não definido pelo encerramento
da conexão), como descrito na seção 4.4.
Fielding, et al. Standards Track [Página 45]
?
HTTP/1.1 RFC 2616 junho 1999
8.1.2.2 Pipelining
Um cliente que suporta ligações persistentes podem “pipeline” sua
pedidos (ou seja, enviar várias solicitações, sem esperar para cada
de resposta). Um servidor deve enviar as suas respostas a essas solicitações no
mesma ordem em que os pedidos foram recebidos.
Clientes que assumem as conexões persistentes e pipeline imediatamente
após o estabelecimento da conexão deve estar preparado para repetir suas
ligação, se a primeira tentativa falhar conduta. Se um cliente não
como uma nova tentativa, ele NÃO DEVE pipeline antes de conhecer a conexão é
persistentes. Os clientes também devem estar preparados para reenviar os seus pedidos se
o servidor fecha a conexão antes de enviar todos os
respostas correspondentes.
Clientes NÃO DEVE pedidos pipeline usando métodos não-idempotentes, ou
seqüências não-idempotentes de métodos (ver secção 9.1.2). Caso contrário, uma
encerramento prematuro da conexão de transporte pode levar a
resultados indeterminados. Um cliente que pretenda enviar uma organização não-idempotentes
pedido deve esperar para enviar o pedido até que ele tenha recebido o
status de resposta para o pedido anterior.
8.1.3 Servidores Proxy
É especialmente importante que os proxies implementar corretamente a
propriedades do campo de cabeçalho de conexão, tal como especificado na secção
14.10.
O servidor proxy deve sinalizar conexões persistentes separadamente com
seus clientes e os servidores de origem (ou outros servidores proxy) que
conecta. Cada conexão persistente se aplica apenas a um transporte
link.
Um servidor proxy não devem criar uma conexão persistente HTTP/1.1
com o cliente HTTP/1.0 (ver RFC 2068 [33] para obter informações e
discussão dos problemas com o cabeçalho Keep-Alive implementado por
muitos clientes HTTP/1.0).
8.1.4 Considerações práticas
Servidores geralmente têm algum valor de tempo limite além do qual eles
não manter uma conexão inativa. Os servidores proxy pode fazer
esse valor maior, pois é provável que o cliente estará fazendo
mais ligações através do mesmo servidor. O uso de persistente
ligações locais sem requisitos no comprimento (ou existência) de
este time-out para o cliente ou o servidor.
Fielding, et al. Standards Track [Página 46]
?
HTTP/1.1 RFC 2616 junho 1999
Quando um cliente ou servidor deseja time-out que deve emitir um gracioso
sobre a estreita conexão de transporte. Clientes e servidores devem ambos
constantemente a olhar para o outro lado do próximo de transportes, e
responder a ele conforme o caso. Se um cliente ou servidor não detecta
do outro lado fechar rapidamente poderia causar recurso desnecessário
dreno na rede.
Um cliente, servidor ou proxy pode fechar a conexão de transporte, em qualquer
tempo. Por exemplo, um cliente pode ter começado a enviar um novo pedido
ao mesmo tempo que o servidor tenha decidido encerrar a marcha lenta “
conexão. A partir do servidor do ponto de vista, a conexão está sendo
fechado enquanto ele estava inativo, mas a partir do ponto de vista do cliente, uma
pedido está em andamento.
Isto significa que os clientes, servidores e proxies deve ser capaz de recuperar
assíncrono de eventos próximos. software cliente deve reabrir o
conexão de transporte e retransmitir a sequência abortada de pedidos
sem interação do usuário, desde que a seqüência de solicitação é
idempotent (ver secção 9.1.2). Os métodos não-idempotentes ou seqüências
NÃO DEVE ser repetida automaticamente, embora os agentes poderão oferecer um
operador humano a opção de repetir o pedido (s). Confirmação por
agente de usuário de software com a compreensão semântica da aplicação
Pode substituir a confirmação do usuário. A repetição automática NÃO DEVE
ser repetido se a segunda seqüência de solicitações de falhar.
Os servidores devem sempre responder, pelo menos, um pedido por conexão,
se possível. Servidores não devem fechar uma conexão no
meio de transmissão de uma resposta, a menos que uma rede ou falha do cliente
é suspeita.
Os clientes que usam conexões persistentes devem limitar o número de
conexões simultâneas para que eles mantenham um determinado servidor. A
cliente de um único usuário não deve manter mais de duas conexões com
qualquer servidor ou proxy. A procuração deve usar até 2 conexões * N
outro servidor ou proxy, onde N é o número de simultaneamente
usuários ativos. Estas diretrizes são destinadas a melhorar a resposta HTTP
vezes e evitar o congestionamento.
8,2 Transmissão Requisitos Mensagem
8.2.1 Conexões persistentes e Controle de Fluxo
servidores HTTP/1.1 deverá manter conexões persistentes e uso do TCP
mecanismos de controle de fluxo para resolver sobrecargas temporárias, ao invés de
encerra conexões com a expectativa de que os clientes irão repetir.
Esta última técnica pode agravar o congestionamento da rede.
Fielding, et al. Standards Track [Página 47]
?
HTTP/1.1 RFC 2616 junho 1999
8.2.2 Monitorando Conexões para mensagens de status de erro
Um HTTP/1.1 (ou posteriores) cliente enviando uma mensagem de corpo deve acompanhar
a conexão de rede para um estado de erro enquanto ele está transmitindo
o pedido. Se o cliente vê um status de erro, ele deve
suspender imediatamente a transmissão do corpo. Se o corpo está sendo enviado
usando um “encoding” blocos (seção 3.6), um pedaço de comprimento zero e
vazio trailer pode ser usado para marcar o fim prematuro da mensagem.
Se o corpo foi precedida por um cabeçalho Content-Length, o cliente deve
fechar a conexão.
8.2.3 Utilização do 100 (Continua) Status
A propósito dos 100 (Continua) status (ver secção 10.1.1) é
permitir que um cliente que está enviando uma mensagem de solicitação com um corpo de solicitação
para determinar se o servidor de origem está disposta a aceitar o pedido de
(Com base nos cabeçalhos de solicitação), antes de o cliente envia o pedido
corpo. Em alguns casos, pode ser tanto inadequada ou muito
ineficiente para o cliente para enviar o corpo, se o servidor irá rejeitar
a mensagem sem olhar para o corpo.
Requisitos para HTTP/1.1 clientes:
– Se um cliente vai esperar por uma resposta 100 (Continua) antes
enviar o corpo da solicitação, ele deve enviar um cabeçalho de solicitação Esperar-
campo (seção 14,20) com o “100-continue” expectativa.
– Um cliente não deve enviar um cabeçalho de solicitação Esperar-campo (seção
14,20), com o “100 continuam” expectativa se não tenciona
para enviar um corpo de solicitação.
Devido à presença das implementações mais velhos, o protocolo permite
situações ambíguas em que um cliente pode enviar “Expect: 100 –
continuar “, sem receber qualquer um status 417 (Falha na expectativa)
ou de um status 100 (Continua). Portanto, quando um cliente envia esta
campo de cabeçalho para um servidor de origem (possivelmente através de um proxy) de que
nunca vi um 100 (Continua) estado, o cliente não deve esperar
por um período indeterminado, antes de enviar o corpo da solicitação.
Requisitos para servidores HTTP/1.1 origem:
– Ao receber um pedido, que inclui um cabeçalho de solicitação de esperar
campo com o “100 continuam” expectativa, um servidor de origem deve
quer responder com 100 (Continue status) e continuar a ler
do fluxo de entrada, ou responder com um código de status final. O
servidor de origem não deve esperar para o corpo antes de solicitar o envio de
os 100 resposta (Continua). Se ele responde com um status final
código, pode fechar a conexão de transporte ou pode continuar
Fielding, et al. Standards Track [Página 48]
?
HTTP/1.1 RFC 2616 junho 1999
para ler e descartar o resto do pedido. Não se deve
executar o método solicitado se ele retorna um código de status final.
– Um servidor de origem não enviar uma resposta 100 (Continua) se
a mensagem de pedido não inclui um cabeçalho de solicitação de esperar
campo com o “100 continuam” expectativa, e não deve enviar uma
100 (Continua) a resposta, se esse pedido vem de um HTTP/1.0
(Ou anterior) do cliente. Há uma exceção a esta regra: para
compatibilidade com o RFC 2068, um servidor pode enviar uma 100 (Continua)
status em resposta a uma solicitação PUT ou POST HTTP/1.1 que faz
não incluir um cabeçalho de solicitação Esperar-campo com o “100 –
expectativa de continuar “. Esta excepção, cujo objectivo é
para minimizar os atrasos de processamento do cliente associada a um
esperar não declarado por 100 (Continua) status, se aplica somente a
HTTP/1.1 pedidos, e não com quaisquer outros pedidos HTTP
valor da versão.
– Um servidor de origem pode omitir a 100 (Continuação) A resposta se tiver
já recebeu algum ou todo o corpo do pedido de
solicitação correspondente.
– Um servidor de origem, que envia uma resposta 100 deve (Continua)
finalmente enviar um código de estado final, uma vez que o corpo é pedido
recebida e processada, a menos que ele termina o transporte
conexão prematuramente.
– Se um servidor de origem recebe uma solicitação que não inclui um
Espere campo de cabeçalho de solicitação com o “100-continue” expectativa
A solicitação inclui um corpo pedido, o servidor responde
com um código de estado final antes de ler o corpo todo pedido
a partir da conexão de transporte, o servidor não deve fechar
a ligação de transporte até que tenha lido o pedido na totalidade,
ou até que o cliente fecha a conexão. Caso contrário, o cliente
talvez não confiável receber a mensagem resposta. No entanto, esta
exigência não é ser interpretado como um servidor de prevenção
se defender contra ataques de negação de serviço ataques, ou de
mal quebrado implementações do cliente.
Requisitos para HTTP/1.1 proxies:
– Se um proxy recebe uma solicitação que inclui um pedido Esperar-
campo de cabeçalho com o “100 continuam” expectativa eo proxy
nem sabe que o servidor do próximo salto em conformidade com ou HTTP/1.1
superior, ou não sabe a versão do HTTP do next-hop
servidor, ele deve encaminhar o pedido, incluindo o cabeçalho Expect
de campo.
Fielding, et al. Standards Track [Página 49]
?
HTTP/1.1 RFC 2616 junho 1999
– Se o procurador sabe que a versão do servidor do próximo salto é
HTTP/1.0 ou menor, ela não deve transmitir o pedido, e ele deve
responder com um status 417 (Falha na expectativa).
– Proxies deve manter um cache de gravação da versão HTTP
números recebidos dos servidores recém-referenciado next-hop.
– A procuração não deve transmitir a 100 resposta (Continua) se o
mensagem de solicitação foi recebida de um HTTP/1.0 (ou anterior)
cliente e não incluir um cabeçalho de solicitação Esperar-campo com
“100-continue” expectativa. Esta exigência substitui o
regra geral para o encaminhamento de respostas 1xx (ver secção 10.1).
8.2.4 Comportamento Client Server prematuramente se fecha conexão
Se um cliente envia uma solicitação HTTP / 1.1, que inclui um corpo da solicitação,
mas que não inclui um cabeçalho de solicitação Esperar-campo com o
“100 continuam” expectativa e, se o cliente não está directamente
conectado a um servidor de origem HTTP/1.1, e se o cliente vê o
fechar a conexão antes de receber qualquer status do servidor, a
cliente deve repetir o pedido. Se o cliente não repita a
pedido, pode usar o seguinte “backoff exponencial binário”
algoritmo para ter a certeza de obter uma resposta confiável:
1. Iniciar uma nova conexão com o servidor
2. Transmitir o pedido-headers
3. Inicializar uma variável R para o tempo de ida e volta estimado para a
servidor (por exemplo, com base no tempo que levou para estabelecer a
conexão), ou para um valor constante de 5 segundos se o round-
trip time não está disponível.
4. Compute T = R * (2 ** N), onde N é o número do anterior
tentativas do pedido.
5. Esperar tanto por uma resposta de erro do servidor, ou para T
segundos (o que ocorrer primeiro)
6. Se nenhuma resposta de erro é recebida, depois de transmitir o segundo T
corpo do pedido.
7. Se o cliente vê que a ligação é encerrada prematuramente,
repita a etapa 1 até que o pedido for aceite, um erro
resposta é recebida, ou o usuário se torna impaciente e
finaliza o processo de repetição.
Fielding, et al. Standards Track [Página 50]
?
HTTP/1.1 RFC 2616 junho 1999
Se em algum momento um estado de erro é recebida, o cliente
– Não deve continuar e
– Deve fechar a conexão se não tiver completado o envio do
mensagem de solicitação.
Definições 9 Método
O conjunto de métodos comuns para HTTP/1.1 é definido abaixo. Embora
este conjunto pode ser expandido, os métodos complementares não se pode presumir a
compartilhar a mesma semântica para clientes e servidores estendida separadamente.
O Host campo de cabeçalho de solicitação (art. 14,23), deve acompanhar todas as
pedidos HTTP/1.1.
9.1 Métodos de segurança e idempotentes
9.1.1 Métodos de segurança
Os implementadores devem estar conscientes de que o software representa o usuário em
suas interações sobre a Internet, e deve ser cuidadosa para permitir
o usuário estar ciente de quaisquer ações que possam ter que possam ter um
significado inesperado para si ou para outrem.
Em particular, a convenção tenha sido estabelecido que o GET e
HEAD métodos não devem ter o significado de ter uma ação
além de recuperação. Estes métodos devem ser considerados “seguros”.
Isso permite que os agentes do usuário para representar outros métodos, como POST, PUT
DELETE e, de uma maneira especial, para que o usuário tenha conhecimento da
fato de que uma ação possivelmente inseguras está sendo solicitado.
Naturalmente, não é possível garantir que o servidor não
gerar efeitos colaterais como resultado da execução de uma requisição GET, em
fato, alguns recursos dinâmicos que consideram um recurso. O importante
distinção aqui é que o usuário não solicitar a efeitos colaterais,
assim, portanto, não podem ser responsabilizados por eles.
9.1.2 Métodos idempotente
Métodos também podem ter a propriedade de “idempotência” em que (com exceção
de erros ou problemas de validade) os efeitos colaterais de N> 0 idênticos
pedidos é a mesma que para um único pedido. Os métodos GET, HEAD,
PUT e DELETE partes desta propriedade. Além disso, as opções de métodos e
TRACE NÃO DEVE ter efeitos secundários, e assim são inerentemente idempotent.
Fielding, et al. Standards Track [Página 51]
?
HTTP/1.1 RFC 2616 junho 1999
No entanto, é possível que uma sequência de vários pedidos não é
idempotent, mesmo se todos os métodos executados nessa seqüência são
idempotent. (A seqüência é idempotente se uma única execução do
seqüência inteira sempre produz um resultado que não seja alterado por um
reexecution de todos, ou parte, dessa sequência.) Por exemplo, um
seqüência não é idempotente, se o seu resultado depende de um valor que é
posteriormente modificado na mesma seqüência.
Uma seqüência que não tem efeitos colaterais é idempotente, por definição
(Desde que não haja operações simultâneas estão sendo executados no
mesmo conjunto de recursos).
9,2 OPÇÕES
O método OPTIONS representa um pedido de informações sobre o
opções de comunicação disponíveis no pedido / resposta em cadeia
identificado pelo Request-URI. Este método permite que o cliente
determinar as opções e / ou condições associadas a um recurso,
ou os recursos de um servidor, sem que tal implique uma acção de recurso
ou iniciar uma recuperação de recursos.
As respostas a este método não são armazenáveis em cache.
Se o pedido de opções inclui uma entidade de corpo (como indicado pela
presença de Content-Length Encoding ou-Transfer), então o tipo de mídia
Deve ser indicado por um campo Content-Type. Embora esta
especificação não define nenhum uso para esse órgão, o futuro
extensões para HTTP podem usar o corpo opções para tornar mais detalhadas
consultas sobre o servidor. Um servidor que não suporta tal
extensão pode descartar o corpo da solicitação.
Se o Request-URI é um asterisco (“*”), o pedido OPÇÕES
destina a ser aplicada ao servidor, em geral, ao invés de um determinado
recursos. Desde as opções de um servidor de comunicação normalmente dependem
o recurso, o * “pedido” só é útil como um ping “ou” não-op “
tipo de método, mas não faz nada além de permitir que o cliente teste
os recursos do servidor. Por exemplo, isso pode ser usado para testar
um proxy para HTTP/1.1 conformidade (ou falta dela).
Se o Request-URI não é um asterisco, aplica-se o pedido OPÇÕES
apenas as opções que estão disponíveis ao se comunicar com o
recursos.
A resposta 200 deve incluir todos os campos que indicam o cabeçalho
características opcionais implementadas pelo servidor e aplicável a esse
recursos (por exemplo, permitir), possivelmente incluindo as extensões não definido pela
esta especificação. O corpo da resposta, se houver, deve também incluir
informações sobre as opções de comunicação. O formato de uma tal
Fielding, et al. Standards Track [Página 52]
?
HTTP/1.1 RFC 2616 junho 1999
corpo não é definido por esta especificação, mas pode ser definido pela
futuras extensões para HTTP. negociação de conteúdo pode ser utilizado para seleccionar
o formato de resposta adequada. Se não houver resposta do corpo é incluído, o
Resposta deve incluir um campo Content-Length com um campo de valor de
“0”.
O Max-Forwards cabeçalho de solicitação de campo pode ser utilizado para direcionar uma
procuração específica na cadeia de pedido. Quando o proxy recebe uma OPÇÕES
pedido, em absoluteURI pedido para que o encaminhamento é permitido,
A verificação deve ser proxy para um campo Max-Forwards. Se o Max-Forwards
valor do campo é zero (“0”), o proxy não deve transmitir a mensagem;
Em vez disso, o procurador deverá responder com as suas opções de comunicação.
Se o Max-Forwards valor do campo é um número inteiro maior que zero, o
proxy deve diminuir o campo de valor, quando se encaminha o pedido. Se
nenhum campo Max-Forwards está presente no pedido, em seguida, o enviado
pedido não deve incluir um campo Max-Forwards.
9,3 GET
O método GET significa recuperar todas as informações (sob a forma de um
entidade) é identificado pelo Request-URI. Se o Request-URI refere-se
a um processo de produção de dados, que são os dados que serão produzidos
retornado como a entidade na resposta e não a fonte do texto
processo, a menos que o texto passa a ser a saída do processo.
A semântica do método GET mudar para um “GET condicional” se o
mensagem de solicitação inclui um If-Modified-Since, Se-Unmodified-Since,
If-Match, If-None-Match, ou campo de cabeçalho If-Gama. A GET condicional
pedidos método que a entidade seja transferido apenas sob a
circunstâncias descritas pelo campo de cabeçalho condicional (s). O
método GET condicional é destinada a reduzir de rede desnecessário
uso, permitindo que as entidades em cache para ser atualizada sem a necessidade de
várias solicitações ou a transferência de dados já na posse do cliente.
A semântica do método GET para uma mudança parcial “GET”, se o
mensagem de solicitação inclui um campo de cabeçalho Range. A GET parcial dos pedidos
que apenas parte da entidade ser transferido, conforme descrito na secção
14,35. O método GET parcial é destinada a reduzir o uso desnecessário
uso da rede, permitindo que entidades parcialmente recuperado para ser
concluído sem a transferência de dados já na posse do cliente.
A resposta a uma solicitação GET é cacheable se e somente se satisfizer
os requisitos para HTTP caching descrito no ponto 13.
Consulte a seção 15.1.3, por motivos de segurança, quando utilizado para formulários.
Fielding, et al. Standards Track [Página 53]
?
HTTP/1.1 RFC 2616 junho 1999
9,4 HEAD
O método HEAD é idêntico ao GET, exceto que o servidor não deve
retornar uma mensagem do corpo na resposta. O metainformation contido
nos cabeçalhos HTTP, em resposta a um pedido de cabeça deve ser idêntico
com as informações enviadas em resposta a uma solicitação GET. Este método pode
ser utilizado para a obtenção metainformation sobre a entidade decorrente da
pedido, sem transferir a entidade corpo-próprio. Este método é
frequentemente usado para testar links de hipertexto para a validade, a acessibilidade,
e modificação recente.
A resposta a um pedido de cabeça pode ser armazenado em cache no sentido de que o
informações contidas na resposta pode ser usado para atualizar uma
armazenadas em cache anteriormente entidade de recurso. Se o campo de novos valores
indicar que a entidade cache difere da entidade atual (como
seria indicado por uma mudança de Content-Length, Content-MD5, ETag
ou Last-Modified), o cache deve tratar a entrada de cache como
obsoleto.
9,5 POST
O método POST é utilizado para solicitar que o servidor de origem aceitar a
entidade fechada no pedido como um novo subordinado do recurso
identificado pelo Request-URI na Request-Line. POST é projetado
para permitir um método uniforme para cobrir as seguintes funções:
– Anotação dos recursos existentes;
– Afixar uma mensagem a um quadro de avisos, notícias, mailing list,
ou grupo similar de artigos;
– Proporcionar um bloco de dados, como o resultado de apresentar um
forma, para um processo de manipulação de dados;
– Estender uma base de dados através de uma operação de acréscimo.
A função real realizada pelo método POST é determinada pela
servidor, e é geralmente dependente do Pedido-URI. A entidade postada
está subordinada à URI da mesma forma que um arquivo está subordinado
para um diretório que o contém, a notícia está subordinado a um
newsgroup a que é colocada, ou um registro está subordinado a um
banco de dados.
A ação realizada pelo método POST não pode resultar em um
recurso que pode ser identificado por um URI. Neste caso, ou 200
(OK) ou 204 (sem conteúdo) é o status resposta adequada,
dependendo ou não a resposta inclui uma entidade que
descreve o resultado.
Fielding, et al. Standards Track [Página 54]
?
HTTP/1.1 RFC 2616 junho 1999
Se o recurso foi criado no servidor de origem, a resposta
Deve ser 201 (criado) e incluir uma entidade que descreve o
status do pedido e remete para o novo recurso, e uma localização
cabeçalho (ver secção 14,30).
As respostas a este método não são armazenáveis em cache, a menos que a resposta
inclui apropriado Cache-Control ou campos de cabeçalho Expires. No entanto,
a 303 (Ver Outros) resposta pode ser usado para direcionar o usuário para o agente
recuperar um recurso cacheable.
pedidos correio devem obedecer os requisitos de transmissão de mensagens definidos
na seção 8.2.
Consulte a seção 15.1.3, por motivos de segurança.
9,6 PUT
O método PUT pedidos que a entidade fechada ser armazenados sob a
fornecidas Pedido-URI. Se o Request-URI refere-se a uma já
existentes de recursos, a entidade fechada deve ser considerada como um
versão modificada de um residente no servidor de origem. Se o
Request-URI não apontar para um recurso existente, e que é URI
susceptível de ser definido como um novo recurso do usuário solicitante
agente, servidor de origem pode criar o recurso com o URI. Se um
novo recurso é criado, o servidor de origem deve informar o agente
através do 201 (Criado) resposta. Se um recurso existente é modificado,
ou o 200 (OK) ou 204 (sem conteúdo) códigos de resposta deve ser enviada
para indicar a conclusão do pedido. Se o recurso
não poderiam ser criados ou modificados com o Pedido-URI, um adequado
resposta de erro deve ser dado, que reflete a natureza da
problema. O destinatário da entidade não deve ignorar qualquer conteúdo *
(Por exemplo: Content-Range) cabeçalhos que não compreendam ou não implementar
e deve retornar um 501 (não implementado) resposta em tais casos.
Se o pedido passa através de um cache ea solicitação-URI identifica
uma ou mais entidades atualmente em cache, as entradas devem ser
tratado como velho. As respostas a este método não são armazenáveis em cache.
A diferença fundamental entre o POST e PUT é
refletido no significado da Request-URI. O URI em uma
solicitação POST identifica o recurso que irá lidar com o anexo
entidade. Esse recurso pode ser um processo de aceitação de dados, um gateway para
algum outro protocolo, ou uma entidade separada que aceita anotações.
Em contraste, a URI em uma solicitação PUT identifica a entidade fechada
com o pedido – o agente sabe o URI se destinam ea
tentativa do servidor não deve aplicar ao pedido de algum outro recurso.
Se os desejos do servidor que o pedido seja aplicado a um URI diferente,
Fielding, et al. Standards Track [Página 55]
?
HTTP/1.1 RFC 2616 junho 1999
Deve ainda enviar um 301 (Movido permanentemente resposta), o agente poderá
em seguida, fazer a sua própria decisão sobre se ou não para redirecionar o
pedido.
Um único recurso, podem ser identificados por muitos URIs diferentes. Para
exemplo, um artigo pode ter uma URI para identificar “o actual
versão “, que é separada da URI que identifica cada particular
versão. Neste caso, um pedido Coloque em uma URI geral pode resultar em
várias URIs outro ser definida pelo servidor de origem.
HTTP/1.1 não define como um método PUT afeta o estado de um
servidor de origem.
PUT deve obedecer a requisitos de transmissão de mensagem definidos
na seção 8.2.
Salvo disposição em contrário de uma entidade particular cabeçalho, o
entidade-headers no pedido PUT deve ser aplicado ao recurso
criados ou modificados pelo PUT.
9,7 DELETE
Os pedidos DELETE método que exclua o servidor de origem do recurso
identificado pelo Request-URI. Este método pode ser substituído por humanos
intervenção (ou outros meios) no servidor de origem. O cliente não pode
ser garantido que a operação foi realizada, mesmo se o
código de status retornado do servidor de origem indica que a ação
foi concluída com êxito. No entanto, o servidor NÃO DEVE
indicar sucesso, salvo se, no momento a resposta é dada,
pretende excluir o recurso ou movê-lo para um inacessível
Local.
Uma resposta bem sucedida deve ser de 200 (OK) se a resposta inclui um
entidade que descreve o estado, 202 (Aceito), se a ação não tem
ainda não foi promulgada, ou 204 (sem conteúdo) se a ação foi aprovada
mas a resposta não inclui uma entidade.
Se o pedido passa através de um cache ea solicitação-URI identifica
uma ou mais entidades atualmente em cache, as entradas devem ser
tratado como velho. As respostas a este método não são armazenáveis em cache.
9,8 TRACE
O método TRACE é usado para chamar um controle remoto, aplicação de camada de circuito
parte de trás da mensagem de solicitação. O destinatário final do pedido
Deve reflectir a mensagem recebida para o cliente como o
corpo da entidade de um 200 (OK resposta). O beneficiário final seja o
Fielding, et al. Standards Track [Página 56]
?
HTTP/1.1 RFC 2616 junho 1999
servidor de origem ou a primeira proxy ou gateway para receber um Max-Forwards
valor de zero (0) no pedido (ver secção 14,31). A pedido TRACE
Não deve incluir uma entidade.
TRACE permite ao cliente ver o que está sendo recebido na outra
final da cadeia de pedido e utilizar esses dados para os testes de diagnóstico ou
da informação. O valor do campo de cabeçalho Via (seção 14.45) é de
interesse particular, desde que age como um traço da cadeia pedido.
O uso do campo de cabeçalho Max-Forwards permite ao cliente o limite
comprimento da cadeia de pedido, que é útil para testar uma cadeia de
proxies encaminhar mensagens em um loop infinito.
Se a solicitação for válida, a resposta deve conter toda a
mensagem de solicitação da entidade corpo, com um Content-Type de
“Http / mensagem”. As respostas a este método não deve ser armazenado em cache.
9,9 CONNECT
Esta reserva especificação do nome do método CONNECT para uso com um
proxy que pode mudar dinamicamente a ser um túnel (por exemplo, SSL
tunelamento [44]).
10 Código Definições Status
Cada Estado-código é descrito abaixo, incluindo uma descrição de que
Método (s) que pode seguir e qualquer metainformation exigido no
a resposta.
10,1 1xx Informativa
Essa classe de código de status indica uma resposta provisória,
consistindo apenas do Status-Line e cabeçalhos opcionais, e é
denunciado por uma linha vazia. Não existem cabeçalhos necessários para esta
classe de código de status. Desde HTTP/1.0 não define nenhum status 1xx
códigos, os servidores não deve enviar uma resposta 1xx para um cliente HTTP/1.0
exceto sob condições experimentais.
Um cliente deve estar preparado para aceitar uma ou mais respostas 1xx status
antes de uma resposta regular, mesmo se o cliente não espera 100
(Continua) mensagem de status. Inesperado respostas 1xx status pode estar
ignorados por um agente do usuário.
Proxies deve encaminhar as respostas 1xx, a menos que a conexão entre o
proxy eo seu cliente foi fechado, ou se o próprio proxy
solicitada a geração da resposta 1xx. (Por exemplo, se um
Fielding, et al. Standards Track [Página 57]
?
HTTP/1.1 RFC 2616 junho 1999
proxy adiciona um “Expect: 100 continuam campo” quando se encaminha um pedido,
então não precisa enviar o correspondente 100 (Continua)
resposta (s)).
10.1.1 100 Continue
O cliente deverá continuar com seu pedido. Esta resposta é provisório
usado para informar o cliente que a parte inicial do pedido tem
foram recebidos e ainda não foi rejeitado pelo servidor. O cliente
Deve continuar enviando o restante do pedido ou, se o
pedido já foi concluída, ignore esta resposta. O servidor
Deve enviar uma resposta final sobre o pedido tenha sido concluída. Ver
seção 8.2.3 para discussão detalhada sobre o uso e manuseio deste
código de status.
10.1.2 101 protocolos de comutação
O servidor entende e está disposto a cumprir com o cliente
pedido, através do campo de cabeçalho da mensagem de atualização (art. 14,42), para uma
mudança no protocolo de aplicação a ser utilizado nesta conexão. O
servidor irá mudar os protocolos, as definidas pela resposta do
Upgrade campo de cabeçalho imediatamente após a linha em branco que
termina a resposta 101.
O protocolo deve ser ligado apenas quando é vantajoso fazer
isso. Por exemplo, a mudança para uma nova versão do HTTP é vantajoso
em relação às versões mais antigas, e mudar para um tempo real, síncrono
protocolo pode ser vantajoso quando oferecer recursos que usam
tais características.
10,2 2xx sucesso
Essa classe de código de status indica que o pedido do cliente foi
recebidos com sucesso, compreendido e aceite.
10.2.1 200 OK
O pedido foi bem sucedido. As informações retornou com a resposta
é dependente do método utilizado no pedido, por exemplo:
Começar uma entidade correspondente ao recurso solicitado é enviado em
a resposta;
HEAD os campos de cabeçalho entidade correspondente ao pedido
recursos são enviados em resposta sem qualquer corpo da mensagem;
POST descrevendo uma entidade, ou contendo o resultado da ação;
Fielding, et al. Standards Track [Página 58]
?
HTTP/1.1 RFC 2616 junho 1999
Trace uma entidade que contém a mensagem de solicitação de entrada na
end.
10.2.2 201 Criado
O pedido foi cumprida e resultou em um novo recurso a ser
criado. O recurso recém-criado pode ser referenciado pelo URI (s)
devolvido na entidade da resposta, com a URI mais específica
para o recurso dado por um campo de cabeçalho Location. A resposta
Deve incluir uma entidade que contém uma lista de recursos
características e localização (s) a partir do qual o usuário ou usuário agente pode
escolher o mais adequado. O formato é especificado pela entidade
a determinado tipo de mídia no campo de cabeçalho Content-Type. A origem
servidor deve criar o recurso antes de retornar o código de status 201.
Se o recurso não pode ser realizada imediatamente, o servidor deve
responder com 202 resposta (Aprovado) em seu lugar.
A MAIO 201 resposta contém um campo de cabeçalho ETag resposta indicando
o valor atual da marca da entidade para a variante pedida apenas
criado, consulte a seção 14.19.
10.2.3 202 Aceito
O pedido foi aceito para processamento, mas o tratamento tem
não foi concluída. O pedido poderá ou não vir a ser
ação, como poderia ser anulado quando o tratamento realmente tem
lugar. Não existe nenhum mecanismo para re-enviar um código de status de um
operação assíncrona como este.
A resposta 202 é intencionalmente não-comprometedora. Sua finalidade é
permitir que um servidor para aceitar um pedido de algum outro processo (talvez um
processo batch-oriented que só é executado uma vez por dia), sem
exigir que a ligação do agente do usuário para o servidor persistir
até que o processo seja concluído. A entidade voltou com o presente
resposta deve incluir uma indicação do status atual do pedido de
e quer um ponteiro para um monitor de estado ou alguma estimativa de quando o
usuário pode esperar que o pedido seja cumprido.
10.2.4 203 Informação não-autorizada
O metainformation retornou na entidade cabeçalho não é o
conjunto definitivo disponíveis a partir do servidor de origem, mas são recolhidas
a partir de um local ou uma cópia de terceiros. O jogo apresentado pode ser um subconjunto
ou superconjunto da versão original. Por exemplo, incluindo o local
anotação de informações sobre o recurso pode resultar em um superconjunto
do metainformation conhecido pelo servidor de origem. A utilização deste
código de resposta não é obrigatório e só é apropriado quando o
resposta de outra forma seriam 200 (OK).
Fielding, et al. Standards Track [Página 59]
?
HTTP/1.1 RFC 2616 junho 1999
10.2.5 204 Nenhum conteúdo
O servidor cumpriu o pedido, mas não precisa retornar um
corpo da entidade, e talvez queira retornar metainformation atualizado. O
resposta pode incluir metainformation novos ou atualizados na forma de
entidade-headers, que se apresentam devem ser associados com o
solicitadas variante.
Se o cliente é um agente do usuário, não deve alterar a sua visão do documento
daquele que causou o pedido para ser enviado. Esta resposta é
destinados a permitir a entrada de acções a realizar-se sem
causando uma mudança para ver o agente ativo do documento, embora
qualquer novo ou metainformation atualizados devem ser aplicados ao documento
atualmente em vista o agente ativo do usuário.
A resposta 204 não deve incluir um corpo da mensagem, e, portanto, é sempre
rescindido pela primeira linha vazia após os campos de cabeçalho.
10.2.6 205 Reset Content
O servidor cumpriu o pedido e que o agente deverá redefinir
a exibição do documento que causou o pedido para ser enviado. Esta resposta
destina-se principalmente para permitir a entrada de acções a realizar-se via
entrada do usuário, seguido de um esclarecimento da forma em que a entrada é
dado para que o usuário pode facilmente iniciar uma outra ação de entrada. O
resposta não deve incluir a entidade.
10.2.7 206 Conteúdo parcial
O servidor cumpriu a solicitação parcial GET para o recurso.
O pedido deve ter incluído um campo de cabeçalho Range (art. 14,35)
indicando a faixa desejada, e pode ter incluído uma Se-Range
campo de cabeçalho (art. 14,27) para fazer o pedido de condicional.
A resposta deve incluir os campos de cabeçalho que se segue:
– Ou um campo de cabeçalho Content-Range (seção 14,16), indicando
o intervalo incluído com esta resposta, ou um multipart / byteranges
Content-Type incluindo Content-Range campos para cada parte. Se um
Content-Length campo de cabeçalho está presente na resposta, o seu
valor deve corresponder ao número real de octetos transmitidos na
corpo da mensagem.
– Data
– ETag e / ou Content-Location, se o cabeçalho teria sido enviado
em uma resposta 200 para o mesmo pedido
Fielding, et al. Standards Track [Página 60]
?
HTTP/1.1 RFC 2616 junho 1999
– Expira, Cache-Control, e / ou alterar, se o campo de valor pode
diferem dos que enviaram qualquer resposta anterior para o mesmo
variante
Se a resposta 206 é o resultado de uma solicitação de gama que se utilizou um
validador cache forte (ver secção 13.3.3), a resposta NÃO DEVE
incluir outras entidades-headers. Se a resposta é o resultado de um
Se o pedido de gama que usou um validador fraco, a resposta NÃO DEVE
incluir outras entidades e cabeçalhos; isso evita inconsistências entre
cache entidade, órgãos e cabeçalhos atualizados. Caso contrário, a resposta
Deve incluir todos os cabeçalhos de entidade que teriam sido devolvidos
com um 200 (OK resposta) para o mesmo pedido.
A cache não deve combinar uma resposta 206 com outras armazenadas em cache anteriormente
se o conteúdo cabeçalhos ETag ou Last-Modified não correspondem exatamente,
ver 13.5.4.
Uma cache que não suporta o Gama e cabeçalhos Content-Range
NÃO DEVE cache 206 (parcial) respostas.
10,3 redirecionamento 3xx
Essa classe de código de status indica que a ação ainda precisa ser
tomadas pelo agente, a fim de atender a solicitação. A ação
necessárias podem ser realizadas pelo agente do usuário sem a interação
com o usuário se e somente se o método utilizado no segundo pedido é
GET ou HEAD. Um cliente deve detectar loops infinitos de redirecionamento, uma vez que
loops como gerar tráfego de rede para cada redirecionamento.
Nota: as versões anteriores desta especificação recomendada uma
máximo de cinco redirecionamentos. Os criadores de conteúdo devem estar cientes
que pode haver clientes que implementam tais fixo
limitação.
10.3.1 300 Múltipla Escolha
O recurso solicitado corresponde a qualquer um de um conjunto de
representações, cada uma com sua própria localização específica, e agente
informações negociação conduzida (seção 12) está sendo fornecido para que
o usuário (ou User Agent) pode selecionar uma representação preferencial e
redirecionar o seu pedido para esse local.
A não ser que foi uma solicitação HEAD, a resposta deve incluir uma entidade
contendo uma lista de características e localização do recurso (s) de
que o agente do usuário ou usuário pode escolher o mais adequado. O
entidade formato é especificado pelo tipo de mídia no Content-
Tipo de campo de cabeçalho. Dependendo do formato e da capacidade de
Fielding, et al. Standards Track [Página 61]
?
HTTP/1.1 RFC 2616 junho 1999
o agente, a seleção da opção mais adequada pode ser
executadas automaticamente. No entanto, esta especificação não define
qualquer padrão de seleção automática desse tipo.
Se o servidor tem a opção preferencial de representação, ele deve
incluir a URI específicos para que a representação no local
campo, os agentes poderão usar o valor do campo Localização para automático
redirecionamento. Esta resposta é cacheable salvo indicação em contrário.
10.3.2 301 Moved Permanently
O recurso solicitado foi atribuído um novo URI permanente e qualquer
futuras referências ao presente recurso deve usar um dos retornados
URIs. Clientes com capacidades de edição link deveria automaticamente
re-ligação referências à solicitação URI para um ou mais dos novos
referências retornado pelo servidor, sempre que possível. Esta resposta é
cacheable salvo indicação em contrário.
O novo URI permanente deve ser dada pelo campo Local no
a resposta. A menos que o método da requisição HEAD, a entidade do
resposta deve conter uma breve nota de hipertexto com um hiperlink para
Os novos (URI).
Se o código de status 301 é recebido em resposta a uma solicitação de outros
de GET ou HEAD, o agente não deve automaticamente redirecionar o
pedido, salvo se pode ser confirmada pelo usuário, pois isto pode
alterar as condições em que o pedido foi emitido.
Nota: Quando redirecionando automaticamente após uma solicitação POST
receber um código de status 301, alguns agentes HTTP/1.0 existente
vai erroneamente transformá-lo em uma requisição GET.
10.3.3 302 encontrados
O recurso solicitado reside temporariamente em um URI diferente.
Desde o redirecionamento pode ser alterada em algumas ocasiões, o cliente deve
continuar a usar o Request-URI para futuras solicitações. Esta resposta
só é cacheable se indicado por um cache de Controle ou cabeçalho Expires
de campo.
O URI temporária deve ser feita pelo campo Local no
a resposta. A menos que o método da requisição HEAD, a entidade do
resposta deve conter uma breve nota de hipertexto com um hiperlink para
Os novos (URI).
Fielding, et al. Standards Track [Página 62]
?
HTTP/1.1 RFC 2616 junho 1999
Se o código de status 302 é recebido em resposta a uma solicitação de outros
de GET ou HEAD, o agente não deve automaticamente redirecionar o
pedido, salvo se pode ser confirmada pelo usuário, pois isto pode
alterar as condições em que o pedido foi emitido.
Nota: RFC 1945 e RFC 2068 especifica que o cliente não é permitida
Para alterar o método sobre o pedido redirecionado. Entretanto, a maioria
implementações agente usuário existente tratar 302 como se fosse um 303
resposta, realizando um GET no valor do campo Localização, independentemente
do método de solicitação original. Os códigos de status 303 e 307 têm
foi adicionado para os servidores que desejam fazer inequivocamente que
tipo de reação é esperada do cliente.
10.3.4 303 Ver Outros
A resposta à solicitação pode ser encontrado em um URI diferente e
Devem ser recuperados usando um método GET sobre esse recurso. Este método
existe principalmente para permitir a saída de um post script ativado para
redirecionar o agente do usuário a um recurso selecionado. O novo URI não é um
referência substituto para o recurso solicitado inicialmente. Os 303
resposta não deve ser armazenado em cache, mas a resposta para a segunda
(Redirecionado) pedido pode ser armazenado em cache.
O URI diferente deve ser dada pelo campo Local no
a resposta. A menos que o método da requisição HEAD, a entidade do
resposta deve conter uma breve nota de hipertexto com um hiperlink para
Os novos (URI).
Nota: Muitos agentes pre-HTTP/1.1 não entendem a 303
status. Quando a interoperabilidade com os referidos clientes é uma preocupação, a
Código de status 302 pode ser usado em vez disso, uma vez que a maioria dos agentes do usuário reagir
para uma resposta 302, conforme descrito aqui para 303.
10.3.5 Não 304 Modified
Se o cliente tiver realizado um pedido GET condicional eo acesso é
permitido, mas o documento não foi modificado, o servidor deve
responder com este código de status. A resposta 304 não deve conter um
corpo da mensagem, e, portanto, é sempre denunciado pela primeira linha vazia
após o cabeçalho campos.
A resposta deve incluir os campos de cabeçalho que se segue:
– Data, a menos que a sua omissão é exigido pela seção 14.18.1
Fielding, et al. Standards Track [Página 63]
?
HTTP/1.1 RFC 2616 junho 1999
Se um servidor de origem clockless obedece a essas regras, e procurações e
adicionar os seus clientes a própria data qualquer resposta recebida sem um (como
já especificado em [RFC 2068], seção 14.19), caches irá operar
corretamente.
– ETag e / ou Content-Location, se o cabeçalho teria sido enviado
em uma resposta 200 para o mesmo pedido
– Expira, Cache-Control, e / ou alterar, se o campo de valor pode
diferem dos que enviaram qualquer resposta anterior para o mesmo
variante
Se o GET condicional utilizado um validador cache forte (ver secção
13.3.3), a resposta não deve incluir outras entidades-headers.
Caso contrário (ou seja, o GET condicional utilizado um validador fraco), o
Resposta não deve incluir outras entidades-headers, o que impede
incoerências entre as entidades e órgãos em cache e cabeçalhos atualizados.
Se uma resposta 304 indica que uma entidade que não está actualmente em cache, então o
cache deve ignorar a resposta e repetir o pedido sem o
condicional.
Se um cache usa uma recebeu 304 respostas para atualizar uma entrada de cache, o
cache deve atualizar a entrada para refletir qualquer novo campo valores indicados no
a resposta.
10.3.6 305 Use Proxy
O recurso solicitado deve ser acessado através do proxy dada por
o campo Localização. O campo Localização dá a URI do proxy.
O beneficiário deverá repetir este único pedido através do
proxy. 305 respostas só deve ser gerado por servidores de origem.
Nota: RFC 2068 não estava claro que era 305 destina-se a um redirecionamento
único pedido, e para ser gerada por servidores de origem única. Não
observar essas limitações têm consequências significativas de segurança.
10.3.7 306 (não utilizado)
O código de status 306 foi usado em uma versão anterior do
especificação, não é mais usado, eo código é reservado.
Fielding, et al. Standards Track [Página 64]
?
HTTP/1.1 RFC 2616 junho 1999
10.3.8 Redirect 307 temporários
O recurso solicitado reside temporariamente em um URI diferente.
Desde o redirecionamento pode ser alterada em algumas ocasiões, o cliente deve
continuar a usar o Request-URI para futuras solicitações. Esta resposta
só é cacheable se indicado por um cache de Controle ou cabeçalho Expires
de campo.
O URI temporária deve ser feita pelo campo Local no
a resposta. A menos que o método da requisição HEAD, a entidade do
resposta deve conter uma breve nota de hipertexto com um hiperlink para
URI novo (s), uma vez que muitos agentes não pre-HTTP/1.1
compreender o status 307. Portanto, a nota deve conter as
informações necessárias para que o usuário repita o pedido inicial em
URI novo.
Se o código de status 307 é recebido em resposta a uma solicitação de outros
de GET ou HEAD, o agente não deve automaticamente redirecionar o
pedido, salvo se pode ser confirmada pelo usuário, pois isto pode
alterar as condições em que o pedido foi emitido.
10,4 erro 4xx Cliente
A classe 4xx de código de status é destinado para os casos em que o
cliente parece ter cometido um erro. Exceto quando responde a uma solicitação HEAD,
o servidor deve incluir uma entidade que contém uma explicação dos
situação de erro, e se é temporária ou permanente
condição. Esses códigos de status são aplicáveis a qualquer método de solicitação.
Os agentes deverão exibir qualquer entidade incluída para o usuário.
Se o cliente está enviando dados, uma implementação de servidor usando TCP
Deve ser cuidadoso para garantir que o cliente confirma a recepção da
o pacote (s) contendo a resposta, antes que o servidor, fecha o
conexão de entrada. Se o cliente continua a enviar dados para o servidor
após o encerramento, o TCP na pilha do servidor irá enviar um pacote de reset
o cliente, que pode apagar a entrada do cliente não confirmadas buffers
antes que eles possam ser lidos e interpretados pela aplicação HTTP.
10.4.1 400 Bad Request
A solicitação não pôde ser entendida pelo servidor devido a malformações
sintaxe. O cliente não deve repetir o pedido, sem
modificações.
Fielding, et al. Standards Track [Página 65]
?
HTTP/1.1 RFC 2616 junho 1999
10.4.2 401 Unauthorized
O pedido requer autenticação do usuário. A resposta deve incluir um
WWW-Authenticate campo de cabeçalho (art. 14,47) contendo um desafio
aplicável ao recurso solicitado. O cliente pode repetir o
pedido com um campo apropriado do cabeçalho Authorization (seção 14.8). Se
o pedido já está incluído credenciais de autorização, então o 401
resposta indica que a autorização foi recusada para os
credenciais. Se a resposta 401 contém o mesmo desafio que a
resposta anterior, e que o agente já tenha tentado
autenticação pelo menos uma vez, então o usuário deve ser apresentado o
entidade que foi dada em resposta, uma vez que esta entidade pode
incluir informações diagnósticas relevantes. HTTP autenticação de acesso
é explicado em “Autenticação HTTP: Basic e Digest Access
Authentication “[43].
10.4.3 402 Pagamento necessário
Este código é reservado para uso futuro.
10.4.4 403 Forbidden
O servidor entendeu o pedido, mas se recusa a cumpri-la.
Autorização e não vai ajudar o pedido não devem ser repetidos.
Se o método de pedido não era a cabeça eo servidor pretende fazer
pública porque o pedido não tenha sido cumprida, ele deve descrever o
motivo para a recusa da entidade. Se o servidor não deseja
disponibilizar essas informações para o cliente, o código de status 404
(Not Found) pode ser usado em seu lugar.
10.4.5 404 Not Found
O servidor não encontrou nada que correspondam ao Pedido-URI. Não
indicação é dada se a condição é temporária ou
permanente. O 410 (Gone) código de status deve ser usado se o servidor
sabe, através de algum mecanismo interno configurável, que um velho
recurso está permanentemente disponível e não tem nenhum endereço de encaminhamento.
Esse código de status é comumente utilizado quando o servidor não deseja
revelar exatamente porque a solicitação foi recusada, ou quando nenhuma outra
resposta é aplicável.
10.4.6 405 Método Não Permitido
O método especificado no-Request Line não é permitido para o
recurso identificado pelo Request-URI. A resposta deve incluir um
Permitir cabeçalho contendo uma lista de métodos válidos para a requerida
recursos.
Fielding, et al. Standards Track [Página 66]
?
HTTP/1.1 RFC 2616 junho 1999
10.4.7 Não Aceitável 406
O recurso identificado pela solicitação só é capaz de gerar
entidades que têm características de resposta de conteúdo não aceitáveis
de acordo com a aceitar os cabeçalhos enviados na solicitação.
A não ser que foi uma solicitação HEAD, a resposta deve incluir uma entidade
contendo uma lista de características e localização disponíveis entidade (s)
a partir do qual o usuário ou usuário pode escolher o agente mais
adequadas. O formato é especificado pela entidade a determinado tipo de mídia
no campo de cabeçalho Content-Type. Dependendo do formato e das
capacidades do agente do usuário, a seleção do mais adequado
MAIO escolha ser executado automaticamente. No entanto, esta especificação
, não define qualquer tipo de selecção automática desse tipo.
Nota: HTTP/1.1 servidores estão autorizados a retornar respostas, que são
não é aceitável de acordo com a aceitar os cabeçalhos enviados no
pedido. Em alguns casos, pode até ser preferível para o envio de uma
406 resposta. Os agentes são incentivados a examinar os cabeçalhos das
uma resposta de entrada para determinar se ele é aceitável.
Se a resposta poderia ser inaceitável, um agente deverá
interromper temporariamente a recepção de mais dados e consulta ao usuário um
decisão sobre as novas acções.
10.4.8 407 Autenticação de proxy necessária
Este código é semelhante ao 401 (não autorizado), mas indica que o
cliente deve primeiro se autenticar com o proxy. O proxy deve
retornar um campo de cabeçalho Proxy-Authenticate (seção 14.33) contendo uma
desafio aplicável ao proxy para o recurso solicitado. O
cliente pode repetir o pedido com uma adequada Proxy-Authorization
campo de cabeçalho (art. 14,34). HTTP autenticação de acesso é explicada
em “Autenticação HTTP: Basic e Digest Authentication Access”
[43].
10.4.9 408 Request Timeout
O cliente não apresentou um pedido dentro do tempo que o servidor
estava preparado para esperar. O cliente pode repetir o pedido, sem
modificações em qualquer momento posterior.
10.4.10 Conflito 409
O pedido não pôde ser concluída devido a um conflito com o actual
estado do recurso. Este código só é permitida em situações em que
Espera-se que o usuário pode ser capaz de resolver o conflito
e reenvie a solicitação. O corpo resposta deve incluir o suficiente
Fielding, et al. Standards Track [Página 67]
?
HTTP/1.1 RFC 2616 junho 1999
informações para o usuário a reconhecer a origem do conflito.
Idealmente, a entidade teria a resposta incluir informações suficientes para a
agente de usuário ou usuário para resolver o problema, no entanto, que não pode ser
possível e não é necessário.
Os conflitos são mais prováveis de ocorrer em resposta a uma solicitação PUT. Para
exemplo, se versões estavam sendo usados e da entidade a ser posta
incluiu mudanças de um recurso que entrem em conflito com aquelas feitas por um
anterior (de terceiros) pedido, o servidor poderá usar a resposta 409
para indicar que ele não pode completar a solicitação. Neste caso, o
entidade resposta provavelmente contêm uma lista das diferenças
entre as duas versões em um formato definido pela resposta
Tipo de Conteúdo.
10.4.11 410
O recurso solicitado não está mais disponível no servidor e não
endereço de encaminhamento é conhecido. Esta condição deverá ser
considerado permanente. Clientes com capacidades de edição ligação deverá
excluir referências ao Pedido-URI após a aprovação do usuário. Se o
servidor não sabe, ou não tem facilidade para determinar, ou não
a condição é permanente, o código de status 404 (Not Found) deve ser
utilizado. Esta resposta é cacheable salvo indicação em contrário.
A resposta 410 é destinado principalmente para auxiliar a tarefa de web
manutenção, mediante notificação ao beneficiário que o recurso é
indisponível intencionalmente e que o desejo de que os proprietários do servidor
links remoto para que o recurso seja removido. Tal acontecimento é comum para
limitadas no tempo, serviços promocionais e de recursos pertencentes
indivíduos já não trabalha mais no site do servidor. Não é
necessário marcar todos os recursos permanentemente disponível como “desaparecido” ou
para manter a marca durante um período de tempo – que é deixada ao
critério do proprietário do servidor.
10.4.12 411 Comprimento necessário
O servidor se recusa a aceitar o pedido, sem definição de conteúdo
Comprimento. O cliente pode repetir o pedido, se acrescenta um válido
Content-Length campo de cabeçalho que contém o comprimento do corpo da mensagem-
na mensagem de solicitação.
10.4.13 412 Requisito Falha
A condição dada em um ou mais dos campos de solicitação de cabeçalho
avaliada como falsa quando foi testada no servidor. Esta resposta
código permite que o cliente colocar condições prévias sobre o recurso atual
metainformation (dados de campo de cabeçalho) e assim evitar que o requerido
o método seja aplicado a um recurso diferente do pretendido.
Fielding, et al. Standards Track [Página 68]
?
HTTP/1.1 RFC 2616 junho 1999
10.4.14 413 Entidade de solicitação muito grande
O servidor está se recusando a processar um pedido, porque o pedido
entidade é maior do que o servidor está disposto ou capaz de processar. O
servidor pode fechar a conexão para impedir que o cliente continue
o pedido.
Se a condição é temporária, o servidor deve incluir uma repetição,
Depois de campo de cabeçalho para indicar que ela é temporária e, após o que
vez que o cliente pode tentar novamente.
10.4.15 414 Pedido-URI Too Long
O servidor está se recusando a atender a solicitação porque a solicitação-URI
é mais do que o servidor está disposta a interpretar. Esta rara
condição só é provável de ocorrer quando um cliente indevidamente
converteu uma solicitação POST para uma solicitação GET com consulta de longa
informações, quando o cliente tem descido em um buraco URI “negra” de
redirecionamento (por exemplo, um redirecionada prefixo URI que aponta para um sufixo de
próprio), ou quando o servidor está sob ataque por um cliente tentar
explorar falhas de segurança presentes em alguns servidores com comprimento fixo
buffers para leitura ou para manipular a solicitação-URI.
10.4.16 415 Tipo de mídia não suportado
O servidor está se recusando a atender a solicitação porque a entidade de
o pedido está em um formato não suportado pelo recurso solicitado
para o método solicitado.
10.4.17 416 intervalo não solicitadas Satisfatório
Um servidor deve retornar uma resposta com esse código de status se a solicitação
incluiu uma escala de campo de cabeçalho de solicitação (secção 14,35), e nenhum dos
os valores de especificador de escala neste domínio se sobrepõem a dimensão actual
dos recursos selecionados, eo pedido não incluir uma Se-Range
campo de cabeçalho de solicitação. (Para byte-intervalos, isto significa que o primeiro-
byte-pos de todos os valores variam de byte-spec foi maior do que o
comprimento atual do recurso selecionado.)
Quando esse código de status é retornado para um pedido de gama-byte, o
resposta deve incluir um cabeçalho Content-Range campo de cabeçalho de entidade
especificando a extensão do recurso seleccionado (ver secção
14,16). Esta resposta não deve usar o multipart / byteranges conteúdo
tipo.
Fielding, et al. Standards Track [Página 69]
?
HTTP/1.1 RFC 2616 junho 1999
10.4.18 417 Falha na expectativa
A expectativa de um dado esperar-campo de cabeçalho de solicitação (ver secção
14,20) não poderiam ser atingidos por este servidor, ou, se o servidor for um proxy,
o servidor tem prova inequívoca de que o pedido não pôde ser cumprido
pelo servidor do próximo salto.
10,5 erro 5xx Server
códigos de status de resposta começa com o dígito “5”, indicam os casos em
qual o servidor está consciente de que errou ou é incapaz de
executar o pedido. Exceto quando responde a uma solicitação HEAD, o
Server deve incluir uma entidade que contém uma explicação dos
situação de erro, e se é temporária ou permanente
condição. Os agentes deverão exibir qualquer entidade incluída a
usuário. Estes códigos de resposta são aplicáveis a qualquer método de solicitação.
10.5.1 500 Internal Server Error
O servidor encontrou uma condição inesperada que impediu
de cumprir a solicitação.
10.5.2 Não Implementado 501
O servidor não suporta a funcionalidade necessária para cumprir as
pedido. Esta é a resposta adequada quando o servidor não
reconhecer o método de solicitação e não é capaz de apoiá-lo para
qualquer recurso.
10.5.3 502 Bad Gateway
O servidor, enquanto age como um gateway ou proxy, recebeu um inválido
resposta do servidor, a montante, na tentativa de acesso
atender a solicitação.
10.5.4 503 Service Unavailable
O servidor está atualmente incapaz de lidar com o pedido, devido a uma
sobrecarga temporária ou manutenção do servidor. A implicação
é que esta é uma condição temporária que será aliviado após
algum atraso. Se forem conhecidas, a duração do atraso pode ser indicado em
Repetir cabeçalho em seguida. Se não repetir-Depois é dado, o cliente deve
lidar com a resposta de como seria uma resposta 500.
Nota: A existência do código de status 503, não implica que um
servidor deve usá-lo quando se tornar sobrecarregado. Alguns servidores podem desejar
simplesmente recusar a ligação.
Fielding, et al. Standards Track [Página 70]
?
HTTP/1.1 RFC 2616 junho 1999
10.5.5 504 Gateway Timeout
O servidor, enquanto age como um gateway ou proxy, não recebe uma
resposta atempada a partir do servidor upstream especificado pela URI (por exemplo,
HTTP, FTP, LDAP) ou algum outro servidor auxiliar (DNS, por exemplo) é necessário
para acessar, na tentativa de completar o pedido.
Nota: Nota para implementadores: alguns proxies utilizados são conhecidos
retorno de 400 ou 500 quando o tempo de consultas DNS para fora.
10.5.6 505 Versão HTTP não suportada
O servidor não suporta, ou se recusar a apoiar, o protocolo HTTP
versão que foi usada na mensagem de solicitação. O servidor é
indicando que ele é incapaz ou não para completar o pedido
usando a mesma versão que o principal cliente, como descrito na seção
3.1, a não ser com essa mensagem de erro. A resposta deverá conter
uma entidade que descreve porque essa versão não é suportado e que outros
protocolos são suportados por esse servidor.
11 Autenticação de Acesso
HTTP fornece autenticação desafio-resposta OPCIONAL vários
mecanismos que possam ser utilizados por um servidor para um desafio de cliente
pedido e por um cliente para fornecer informações de autenticação. O
quadro geral de autenticação de acesso, ea especificação de
“Básico” e “digerir” autenticação, são especificadas no “HTTP
Autenticação: Basic e Digest Authentication Access “[43]. Esta
especificação adota as definições de “desafio” e “credenciais”
a partir dessa especificação.
12 Negociação de Conteúdo
A maioria das respostas HTTP incluem uma entidade que contém informações para
interpretação por um usuário humano. Naturalmente, é desejável para o fornecimento
do usuário com o melhor “disponível” entidade correspondente à
pedido. Infelizmente para os servidores e caches, nem todos os usuários têm a
mesmas preferências para o que é “melhor”, e nem todos os agentes do utilizador são
igualmente capazes de tornar todos os tipos de entidade. Por essa razão, HTTP
tem as disposições de vários mecanismos de “negociação de conteúdo” –
o processo de seleção a melhor representação de uma resposta dada
quando há múltiplas representações disponíveis.
Nota: Esta não é chamado de “formato de negociação”, pois o
representações alternativas podem ser do mesmo tipo de mídia, mas o uso
diferentes capacidades desse tipo, seja em línguas diferentes,
etc
Fielding, et al. Standards Track [Página 71]
?
HTTP/1.1 RFC 2616 junho 1999
Qualquer resposta que contenha uma entidade do corpo podem ser objecto de negociação,
incluindo as respostas de erro.
Existem dois tipos de negociação de conteúdo, que são possíveis em
HTTP: negociação servidor motor e agente-driven. Estes dois tipos de
negociação são ortogonais e, portanto, podem ser utilizadas separadamente ou em
combinação. Um dos métodos de combinação, referida como transparente
negociação, ocorre quando um cache usa a negociação agente-driven
informações prestadas pelo servidor de origem, a fim de fornecer
negociação servidor orientado para solicitações subseqüentes.
12,1 Negociação Server-driven
Se a seleção da melhor representação de uma resposta é feita por
um algoritmo localizado no servidor, ele é chamado de servidor-driven
negociação. A seleção é baseada nas representações disponíveis de
a resposta (sobre as dimensões que podem variar, por exemplo, linguagem,
conteúdo de codificação, etc) eo conteúdo de campos de cabeçalho especial no
a mensagem de pedido ou outras informações relativas ao pedido
(Como o endereço de rede do cliente).
negociação Server-driven é vantajoso quando o algoritmo para
selecionar, dentre as representações disponíveis é difícil
descrever para o agente, ou quando o servidor deseja enviar o seu
“melhor estimativa” para o cliente juntamente com a primeira resposta (esperando
evitar o atraso de ida e volta de um pedido subsequente, se o melhor “
acho que é bom o suficiente para o utilizador). A fim de melhorar o servidor
acho que, o agente do usuário pode incluir campos de solicitação de cabeçalho (Accept,
Accept-Language, Accept-Encoding, etc), que descrevem sua
preferências para tal resposta.
negociação Server-driven tem desvantagens:
1. É impossível para o servidor para determinar com precisão o que
poderia ser melhor “para qualquer usuário determinado, uma vez que exigiria
conhecimento completo de ambas as capacidades do agente do usuário
e utilização prevista para a resposta (por exemplo, que o usuário deseja
para vê-lo na tela ou imprimi-lo no papel?).
2. Tendo o agente descrever as suas capacidades em todos os
pedido tanto pode ser muito ineficiente (já que apenas uma pequena
percentagem de respostas têm múltiplas representações) e
potencial violação da privacidade do usuário.
3. Isso dificulta a implementação de um servidor de origem eo
algoritmos para a geração de respostas a um pedido.
Fielding, et al. Standards Track [Página 72]
?
HTTP/1.1 RFC 2616 junho 1999
4. Pode limitar a capacidade de um cache público a usar a mesma resposta
para solicitações de usuários múltiplos.
HTTP/1.1 inclui os seguintes campos do cabeçalho da solicitação para permitir
negociação do servidor dirigido através da descrição do agente do usuário
capacidades e preferências do usuário: Accept (seção 14.1), Accept-
Charset (art. 14.2), Accept-Encoding (art. 14.3), Accept-
Language (seção 14.4) e User-Agent (art. 14,43). No entanto, uma
servidor de origem não se limita a estas dimensões e pode variar a
resposta com base em qualquer aspecto do pedido, incluindo informação
fora dos campos de cabeçalho do pedido ou no prazo de campos de cabeçalho de extensão
não definidas por esta especificação.
O campo de cabeçalho Vary podem ser usadas para expressar os parâmetros que o
servidor usa para selecionar uma representação que está sujeita a servidor
negociação conduzida. Consulte a seção 13,6 para a utilização do campo de cabeçalho Vary
por caches e secção 14,44 para a utilização do campo de cabeçalho Vary por
servidores.
12,2 Negociação Agent-driven
Com a negociação do agente-driven, a escolha do melhor representação
para uma resposta é realizada pelo agente após receber uma
A resposta inicial do servidor de origem. A seleção é baseada em uma lista
das representações disponíveis na resposta incluídos no
campos de cabeçalho ou órgão de entidade da resposta inicial, com cada
representação identificada por sua própria URI. Selecção entre a
representações podem ser executadas automaticamente (se o agente é
capaz de fazê-lo) ou manualmente pelo usuário selecionar a partir de um
gerados (possivelmente de hipertexto) menu.
negociação agente-driven é vantajosa quando a resposta poderia variar
dimensões mais comumente usados (tais como o tipo, idioma ou codificação),
quando o servidor de origem é incapaz de determinar um agente de usuário
capacidade de analisar o pedido e, em geral quando do público
caches são usados para distribuir a carga do servidor e reduzir o uso da rede.
Agente de negociação baseada sofre a desvantagem de precisar de um
segundo pedido para obter a melhor representação suplente. Este
segundo pedido só é eficiente quando o cache é usada. Além disso,
Esta especificação não define qualquer mecanismo de apoio
seleção automática, embora também não impede que tais
mecanismo a ser desenvolvido como uma extensão e utilizados no
HTTP/1.1.
Fielding, et al. Standards Track [Página 73]
?
HTTP/1.1 RFC 2616 junho 1999
HTTP/1.1 define o 300 (múltipla escolha) e 406 (Não Aceitável)
códigos de status para ativar a negociação do agente orientado quando o servidor é
ou é incapaz de dar uma resposta variável usando o servidor-driven
negociação.
12,3 negociação transparente
negociação transparente é uma combinação de ambos servidor-driven e
negociação agente-driven. Quando uma cache é fornecido com uma forma de
lista das representações disponível da resposta (como agente-driven
negociação) e as dimensões de variância estão completamente esclarecidos
pelo cache, o cache se torna capaz de executar servidor
negociação conduzida em nome do servidor de origem para posterior
pedidos nesse recurso.
negociação transparente tem a vantagem de distribuir os
trabalho de negociação que seria necessária a origem
servidor e também a remoção do atraso segundo pedido do agente-driven
negociação quando o cache é capaz de adivinhar corretamente o direito
a resposta.
Esta especificação não define nenhum mecanismo de transparência
negociação, embora também não impede que esse mecanismo de
sendo desenvolvido como uma extensão que pode ser usado dentro de HTTP/1.1.
13 Cache em HTTP
HTTP normalmente é usado para sistemas de informação distribuídos, onde
desempenho pode ser melhorado com o uso de caches resposta. O
HTTP/1.1 protocolo inclui uma série de elementos destinados a fazer
trabalho de cache, bem como possível. Porque esses elementos são
inextricável de outros aspectos do protocolo, e porque
interagir uns com os outros, é útil para descrever o cache de base
design de HTTP separadamente a partir das descrições detalhadas dos métodos,
cabeçalhos, os códigos de resposta, etc
Caching seria inútil se não melhorar significativamente
desempenho. O objetivo do cache no HTTP/1.1 é eliminar a necessidade
para enviar pedidos, em muitos casos, e para eliminar a necessidade de enviar
respostas completas em muitos outros casos. O primeiro reduz o número de
rede de round-trips necessário para muitas operações, usamos um
“Validade” mecanismo para este efeito (ver secção 13.2). O
este reduz os requisitos de largura de banda da rede; usamos uma “validação”
mecanismo para o efeito (ver secção 13.3).
Requisitos para o desempenho, disponibilidade e desconectados
operação exige que sejamos capazes de relaxar a meta de semântica
transparência. O protocolo HTTP/1.1 permite que os servidores de origem, caches,
Fielding, et al. Standards Track [Página 74]
?
HTTP/1.1 RFC 2616 junho 1999
e os clientes de forma explícita reduzir a transparência, quando necessário.
No entanto, porque a operação não-transparente, pode confundir não-especialista
usuários, e pode ser incompatível com alguns aplicativos de servidor
(Tais como aqueles para encomendar mercadorias), o protocolo exige que
transparência ser flexibilizada
– Só por um pedido de nível de protocolo explícito quando relaxada pela
cliente / servidor ou origem
– Apenas com um aviso explícito para o utilizador final, quando relaxado por
cache ou cliente
Portanto, o protocolo HTTP/1.1 fornece esses elementos importantes:
1. Protocolo de recursos que proporcionam a transparência semântica completa quando
isso é exigido por todas as partes.
2. Protocolo de recursos que permitem que um servidor de origem ou do agente do usuário para
expressamente pedido e controle de operações não-transparente.
3. Protocolo de recursos que permitem que um cache para anexar advertências
respostas que não preservar a aproximação solicitadas
transparência semântica.
Um princípio básico é que deve ser possível para os clientes
detectar qualquer relaxamento potencial de transparência semântica.
Nota: O servidor, cache ou implementador do cliente pode ser enfrentado com
decisões de projeto não explicitamente discutida nesta especificação.
Se a decisão pode prejudicar a transparência semântica, o implementador
deve tender para o lado de manter a transparência salvo
análise cuidadosa e completa mostra benefícios significativos em
transparência quebrar.
13.1.1 Exatidão Cache
A cache correta deve responder a uma solicitação com o maior up-to-date
resposta na posse do cache que é apropriado para a solicitação (ver
seções 13.2.5, 13.2.6, e 13,12), que satisfaz uma das seguintes
condições:
1. Foi verificada a equivalência com o que o servidor de origem
teria retornado pela revalidação a resposta com o
servidor de origem (art. 13.3);
Fielding, et al. Standards Track [Página 75]
?
HTTP/1.1 RFC 2616 junho 1999
2. Trata-se de “fresco” o suficiente “(ver secção 13.2). No caso padrão,
Isso significa que ele atende ao requisito de frescura menos restritivo
do cliente, servidor de origem, e cache (ver secção 14.9); se
o servidor de origem para que especifica, é a exigência de frescura
do servidor de origem sozinho.
Se a resposta não é armazenado “fresco o bastante” pelos mais
exigência restritiva de frescor tanto o cliente como o
servidor de origem, em circunstâncias cuidadosamente considerado o cache
Ainda pode retornar a resposta adequada com o Aviso
cabeçalho (ver secção 13.1.5 e 14,46), a menos que tal resposta
é proibida (por exemplo, a “directiva” cache no interior da loja, ou por um
“No-cache” cache-request directiva; ver secção 14.9).
3. É um 304 adequada (não modificado), 305 (Proxy Redirect)
ou erro (4xx ou 5xx) mensagem de resposta.
Se o cache não pode se comunicar com o servidor de origem, em seguida, um
cache correta deve responder como acima se a resposta pode ser
corretamente servido a partir do cache, caso contrário ele deve retornar um erro ou
aviso indicando que houve uma falha de comunicação.
Se uma cache recebe uma resposta (ou uma resposta inteira, ou uma 304
(Not Modified resposta)) que, normalmente, em frente ao
pedido do cliente, ea resposta recebida não é mais fresco, o
cache deve enviá-lo para o cliente solicitante, sem a adição de um novo
Aviso (mas sem remover os cabeçalhos existentes Warning). A cache
NÃO DEVE tentar revalidar uma resposta simplesmente porque esse
resposta tornou-se obsoleto em trânsito, o que poderia levar a um infinito
loop. Um agente que recebe uma resposta obsoleto sem aviso
Pode exibir um aviso de indicação para o usuário.
13.1.2 Avisos
Sempre que um cache retorna uma resposta que não seja de primeira mão, nem
“Fresco” o suficiente “(no sentido de condição 2 na seção 13.1.1), ele
Deve anexar um aviso nesse sentido, através de um aviso header-geral.
O cabeçalho de advertência e as advertências definidas atualmente são descritos
na seção 14.46. O aviso permite que os clientes tomem as
acção.
Avisos podem ser utilizados para outros fins, tanto cache-relacionados e
em contrário. O uso de um aviso, ao invés de um código de status de erro,
distinguir essas respostas de verdadeiros fracassos.
Os avisos são atribuídos três dígitos alertar os códigos. O primeiro dígito
indica se o aviso deve ou não deve ser excluído de uma
entrada de cache armazenado após a revalidação de sucesso:
Fielding, et al. Standards Track [Página 76]
?
HTTP/1.1 RFC 2616 junho 1999
Avisos 1xx que descrevem o estado frescor ou revalidação de
a resposta, e assim deve ser excluído depois de uma bem sucedida
revalidação. MAIO 1XX avisar códigos ser gerado por um cache apenas quando
validar uma entrada de cache. Não deve ser gerada pelos clientes.
Avisos 2xx que descrevem alguns aspectos do corpo da entidade ou entidades
cabeçalhos que não é corrigida por uma revalidação (por exemplo, um
órgãos de compressão lossy da entidade) e que não deve ser
suprimido após a revalidação de sucesso.
Consulte a seção 14,46 para as definições dos códigos próprios.
caches HTTP/1.0 cache todos os avisos nas respostas, sem
excluindo os da primeira categoria. Avisos em respostas que
são passados para caches HTTP/1.0 realizar um campo de aviso da data-extra,
que impede que um destinatário futuro HTTP/1.1 de acreditar um
Atenção erroneamente cache.
Advertências também realizar um texto de alerta. O texto pode estar em qualquer
linguagem natural adequado (talvez com base em Aceitar o cliente
headers), e incluir uma indicação facultativa do que conjunto de caracteres é
utilizado.
Vários avisos podem ser associadas a uma resposta (seja pela origem
servidor ou por um cache), incluindo vários avisos com o mesmo código
número. Por exemplo, um servidor pode fornecer a mesma advertência com
textos em Inglês e basco.
Quando vários avisos estão ligados a uma resposta, não pode ser
prática ou razoável para mostrar todos eles para o usuário. Este
versão de HTTP não especificar as regras de prioridade estrita para decidir
quais os avisos para exibir e em qual ordem, mas que sugerem algumas
heurística.
Mecanismos de controle 13.1.3 Cache
Os mecanismos básicos de cache em HTTP/1.1 expiração (servidor especificado
vezes e validadores) são diretrizes implícita caches. Em alguns
casos, um servidor ou cliente pode ser necessário fornecer directivas explícitas
para os caches HTTP. Nós usamos o cabeçalho Cache-Control para esta finalidade.
O cabeçalho Cache-Control permite que um cliente ou servidor para transmitir uma
variedade de directivas ou pedidos ou respostas. Estes
directivas tipicamente substituir o padrão de cache algoritmos. Como um
Regra geral, se houver qualquer conflito aparente entre o cabeçalho
valores, a interpretação mais restritiva é aplicada (ou seja, o
aquele que é mais provável que preservar a transparência semântica). No entanto,
Fielding, et al. Standards Track [Página 77]
?
HTTP/1.1 RFC 2616 junho 1999
em alguns casos, as directivas de controle de cache são explicitamente especificados como
enfraquecendo a aproximação de transparência semântica (por exemplo,
“Max-velho” ou “público”).
As diretrizes de controle de cache, são descritos em pormenor na secção 14.9.
13.1.4 Explicit Avisos User Agent
Muitos agentes do utilizador permitem aos usuários substituir a base
mecanismos de cache. Por exemplo, o agente pode permitir que o usuário
para especificar que as entidades em cache (mesmo aqueles explicitamente obsoleto) são
nunca validado. Ou o agente usuário poderá adicionar habitual “Cache-
Control: max-velho = “3600 para cada solicitação. O agente de usuário não deve
resultados padrão para qualquer comportamento não-transparente, ou comportamento que
em cache anormalmente ineficaz, mas pode ser configurado explicitamente
a fazê-lo por uma ação explícita do usuário.
Se o usuário tiver substituído os mecanismos de caching básico, o usuário
agente deve indicar explicitamente ao utilizador sempre que isso resulta em
a exibição de informações que não puderam atender o servidor do
requisitos de transparência (em particular, se a entidade é exibido
conhecido por ser velho). Como o protocolo normalmente permite que o agente do usuário
para determinar se as respostas são obsoletos ou não, essa indicação só precisa
ser exibida quando isso realmente acontece. A indicação não precisa ser um
caixa de diálogo, que poderia ser um ícone (por exemplo, uma foto de uma podridão
peixes) ou algum outro indicador.
Se o usuário tiver substituído os mecanismos de cache de uma forma que
anormalmente reduzir a eficácia dos caches, o agente deverá
continuamente indicar esse estado para o usuário (por exemplo, por um
exibição de uma imagem da moeda em chamas), para que o usuário não
inadvertidamente consumir recursos em excesso ou sofre de excesso de
latência.
13.1.5 Exceções às Regras e Avisos
Em alguns casos, o operador de uma cache pode optar por configurá-lo para
retornar respostas velho, mesmo quando não solicitados pelos clientes. Este
decisão não deve ser feito de ânimo leve, mas pode ser necessária por razões
de disponibilidade ou desempenho, especialmente quando o cache está mal
ligado ao servidor de origem. Sempre que um cache retorna um velho
respostas, ele deve marcá-lo como tal (utilizando um cabeçalho Warning), que permite
o software de cliente para alertar o usuário que pode haver um potencial
problema.
Fielding, et al. Standards Track [Página 78]
?
HTTP/1.1 RFC 2616 junho 1999
Ele também permite que o agente a tomar medidas para obter uma primeira-mão ou
resposta fresco. Por esta razão, a cache não deve retornar um velho
resposta se o cliente solicitar expressamente em primeira mão ou um doce,
a menos que seja impossível cumprir por razões políticas ou técnicas.
13.1.6 Client Comportamento controlado
Enquanto o servidor de origem (e, em menor medida, caches intermediários,
pela sua contribuição para a idade de uma resposta) são os principais
fonte de informação de validade, em alguns casos, o cliente pode precisar
para controlar uma decisão sobre se a cache para retornar um cache
resposta sem validá-lo. Clientes de fazer isso usando vários
directivas do cabeçalho Cache-Control.
solicitação de um cliente pode especificar a idade máxima que está disposto a
de aceitar uma resposta unvalidated, especificando um valor de zero forças
o cache (s) para revalidar todas as respostas. Um cliente também pode especificar
o mínimo de tempo que resta antes de uma resposta expira. Ambos estes
opções de aumentar as restrições sobre o comportamento dos caches, e assim não pode
mais relax aproximação do cache de transparência semântica.
A cliente também pode especificar que ele irá aceitar respostas obsoleto, até
uma certa quantidade máxima de staleness. Isso afrouxa as restrições sobre a
caches, e por isso poderia violar o servidor de origem é especificado
restrições em matéria de transparência semântica, mas pode ser necessário
operação de apoio desconectado, ou de alta disponibilidade em face da
conectividade pobre.
Modelo de 13,2 Termo
13.2.1 Termo servidor especificado
cache HTTP funciona melhor quando caches pode evitar totalmente tomada
solicitações ao servidor de origem. O principal mecanismo para evitar
pedidos é para um servidor de origem para fornecer um termo explícito
momento no futuro, indicando que uma resposta pode ser usada para satisfazer
solicitações subseqüentes. Em outras palavras, um cache pode retornar um novo
resposta sem antes entrar em contato com o servidor.
Nossa expectativa é que os servidores irão atribuir futuro explícita
tempos de expiração para respostas, na crença de que a entidade não é
susceptível de alterar, de forma semanticamente significativas, antes da
tempo de validade não seja atingido. Isso normalmente preserva semântica
transparência, desde as vezes o servidor de validade são cuidadosamente
escolhido.
Fielding, et al. Standards Track [Página 79]
?
HTTP/1.1 RFC 2616 junho 1999
O mecanismo de vencimento aplica-se apenas às respostas tirada de um cache
e não em primeira mão as respostas enviadas imediatamente ao
cliente solicitante.
Se um servidor de origem pretende forçar uma cache semanticamente transparente
para validar todas as solicitações, pode atribuir uma data de expiração explicitamente
no passado. Isto significa que a resposta é sempre velho, e assim o
cache deve validá-lo antes de usá-lo para solicitações subseqüentes. Ver
seção 14.9.4 para uma forma mais restritiva para forçar revalidação.
Se um servidor de origem quer impor qualquer cache HTTP/1.1, não importa quão
ele está configurado, para validar cada solicitação, ele deverá usar o must “,
revalidar “diretiva de controle cache (ver secção 14.9).
Servidores especificar tempos de expiração explicitamente usando o Expires
cabeçalho, ou a directiva máximo de idade do cabeçalho Cache-Control.
Um tempo de validade não pode ser usado para forçar um agente do usuário para atualizar
sua exibição ou recarregar um recurso, a sua semântica aplicam-se apenas ao cache
mecanismos e esses mecanismos só precisa verificar um recurso
status de validade quando um novo pedido para que o recurso é iniciado.
Consulte a seção 13,13 para uma explicação sobre a diferença entre caches
e mecanismos de história.
13.2.2 Termo Heurística
Desde servidores de origem não são sempre momentos de validade explícito,
caches HTTP normalmente atribuir tempos de expiração heurísticos, empregando
algoritmos que utilizam valores de cabeçalho (tal como o Last-Modified
tempo) para estimar um tempo de expiração plausível. O HTTP/1.1
especificação não fornece algoritmos específicos, mas não impor
restrições pior em seus resultados. Desde validade heurística
vezes pode comprometer a transparência semântica, eles devem utilizar
cautelosamente, e nós incentivamos os servidores de origem para fornecer explícito
tempos de expiração, tanto quanto possível.
13.2.3 Cálculos Idade
Para saber se uma entrada de cache é fresco, um cache precisa saber se
sua idade superior à sua vida frescura. Discutimos a forma de calcular
este último no ponto 13.2.4, esta seção descreve como calcular
a idade de uma resposta ou a entrada de cache.
Nesta discussão, nós usamos o termo “agora” para significar “o valor atual
do relógio na máquina de executar o cálculo. “Hosts que utilizam
HTTP, especialmente máquinas que funcionam os servidores de origem e caches, DEVE
usar NTP [28], ou algum protocolo similar para sincronizar os relógios de
um padrão mundial de tempo exato.
Fielding, et al. Standards Track [Página 80]
?
HTTP/1.1 RFC 2616 junho 1999
HTTP/1.1 requer servidores de origem para enviar um cabeçalho de data, se possível,
com todas as respostas, dando o momento em que a resposta foi
gerados (ver secção 14,18). Nós usamos o date_value termo para designar
o valor do cabeçalho de data, de uma forma adequada para a aritmética
operações.
HTTP/1.1 usa a resposta Idade cabeçalho para transmitir a idade estimada do
a mensagem de resposta quando for proveniente de um cache. O campo Idade valor
é a estimativa do cache da quantidade de tempo decorrido desde a resposta foi
geradas ou revalidada pelo servidor de origem.
Em essência, o valor da idade é a soma do tempo que a resposta
Foi residente em cada uma das caches ao longo do caminho da
servidor de origem, além da quantidade de tempo que se encontre em trânsito ao longo
caminhos de rede.
Nós usamos o age_value termo para denotar o valor do cabeçalho de idade, em
uma forma adequada para operações aritméticas.
A idade de uma resposta pode ser calculada de duas maneiras totalmente independentes:
1. date_value menos agora, se o relógio local é razoavelmente bem
sincronizados com o relógio do servidor de origem é. Se o resultado for
negativo, o resultado passa a zero.
2. age_value, se todos os caches ao longo do caminho resposta
implementar HTTP/1.1.
Dado que temos duas maneiras independentes para calcular a idade de uma
resposta em que é recebido, podemos combinar estes como
corrected_received_age = max (agora – date_value, age_value)
e enquanto temos tanto relógios sincronizados ou quase tudo
HTTP/1.1 caminhos, obtém-se uma confiança (conservador) de resultado.
Devido a atrasos na rede, imposta, algum intervalo significativo pode
passar entre o momento em que o servidor gera uma resposta eo tempo
que é recebido na próxima saída cache ou cliente. Se não forem corrigidas,
esse atraso pode resultar em idades indevidamente baixo.
Porque o pedido que resultou na Idade valor retornado deve ter
sido iniciada antes que a geração de valor Idade, podemos corrigir
para os atrasos impostos pela rede, a gravação do momento em que o
pedido foi iniciada. Então, quando um valor de idade é recebido, ele deve
ser interpretado em relação ao momento do pedido foi iniciado, não
Fielding, et al. Standards Track [Página 81]
?
HTTP/1.1 RFC 2616 junho 1999
o tempo que a resposta foi recebida. Isso resulta em algoritmo
comportamento conservador, não importa o quanto demora é experiente. Então, nós
computar:
corrected_initial_age = corrected_received_age
+ (Agora – request_time)
onde “request_time” é o tempo (de acordo com o relógio local), quando
o pedido para que suscitou esta resposta foi enviada.
Resumo do algoritmo de cálculo de idade, quando um cache recebe uma
resposta:
/ *
* Age_value
* É o valor de Idade: cabeçalho recebido pela cache com
* Esta resposta.
* Date_value
* É o valor de cabeçalho do servidor de origem: Data
* Request_time
* É a hora (local) quando o cache feito o pedido
* Que resultou nessa resposta em cache
* Response_time
* É a hora (local) quando o cache recebeu o
* Resposta
* Agora
* É o atual (local) de tempo
* /
apparent_age = max (0, response_time – date_value);
corrected_received_age apparent_age = max (, age_value);
request_time response_delay = response_time -;
corrected_initial_age corrected_received_age response_delay = +;
resident_time = agora – response_time;
current_age corrected_initial_age resident_time = +;
O current_age de uma entrada de cache é calculado somando o montante
de tempo (em segundos) desde a entrada de cache foi modificada pela última validados pela
servidor de origem para o corrected_initial_age. Quando uma resposta é
gerada a partir de uma entrada de cache, o cache deve incluir uma idade de
campo de cabeçalho na resposta com um valor igual ao da entrada da cache
current_age.
A presença de um campo de cabeçalho de idade em uma resposta implica que uma
resposta não é em primeira mão. No entanto, o inverso não é verdadeiro, pois
a falta de um campo de cabeçalho Idade em uma resposta não implica que o
Fielding, et al. Standards Track [Página 82]
?
HTTP/1.1 RFC 2616 junho 1999
resposta é em primeira mão, a menos que todos os caches ao longo do caminho solicitação são
compatível com HTTP/1.1 (ou seja, caches velhos HTTP não aplicou
o campo de cabeçalho Idade).
Cálculos 13.2.4 Termo
A fim de decidir se uma resposta é fresco ou velho, é preciso
comparar a sua vida frescura à sua idade. A idade é calculada como
descrito na seção 13.2.3, esta seção descreve como calcular
o frescor da vida, e para determinar se uma resposta expirou.
Na discussão abaixo, os valores podem ser representados em qualquer forma
adequados para operações aritméticas.
Nós usamos o expires_value termo para denotar o valor do Vencimento
cabeçalho. Nós usamos o max_age_value termo para designar um adequado
valor do número de segundos realizado pelo “max-idade”, de
o cabeçalho Cache-Control em uma resposta (ver secção 14.9.3).
A directiva máximo de idade tem prioridade sobre expira, então, se a idade max é
presentes em uma resposta, o cálculo é simples:
freshness_lifetime = max_age_value
Caso contrário, se Expira está na resposta, o cálculo é:
freshness_lifetime = expires_value – date_value
Observe que nenhum desses cálculos é vulnerável a bagunça no relógio,
uma vez que todas as informações vem de origem do servidor.
Se nenhum dos Expira, Cache-Control: max-age, ou Cache-Control:-s
maxage (ver secção 14.9.3) aparece na resposta, ea resposta
não inclui quaisquer outras restrições ao cache, o cache pode calcular
uma vida frescura usando uma heurística. O cache deve anexar aviso
113 a qualquer resposta, cuja idade é superior a 24 horas, se tal advertência
não já foi adicionado.
Além disso, se a resposta não tem uma hora da última modificação, a heurística
valor de vencimento não deve ser mais do que uma fração do intervalo
desde aquela época. Um cenário típico desta fração pode ser de 10%.
O cálculo para determinar se uma resposta expirou é bastante
simples:
response_is_fresh = (freshness_lifetime> current_age)
Fielding, et al. Standards Track [Página 83]
?
HTTP/1.1 RFC 2616 junho 1999
13.2.5 disambiguating Valores Termo
Como os valores de vencimento são atribuídos de forma otimista, é possível
por dois caches para conter valores fresco para o mesmo recurso que são
diferentes.
Se um cliente realizar uma recuperação recebe uma resposta não em primeira mão
para um pedido que já estava fresca em seu próprio cache, ea data
cabeçalho de sua entrada em vigor cache é mais recente que a data do novo
resposta, o cliente pode ignorar a resposta. Se assim for, pode
repetir o pedido com um “Cache-Control: max-age = directiva” 0 (ver
seção 14.9), para forçar uma verificação de origem do servidor.
Se um cache tem duas novas respostas para a mesma representação, com
validators diferente, ele deve usar o que tem a data mais recente
cabeçalho. Esta situação pode ocorrer porque o cache é pooling
respostas de outros caches, ou porque um cliente pediu um
recarregar ou a revalidação de uma entrada de cache aparentemente fresco.
13.2.6 disambiguating respostas múltiplas
Como um cliente pode estar recebendo respostas através de vários caminhos, assim
que o fluxo de algumas respostas através de um conjunto de caches e outros
respostas do fluxo através de um conjunto diferente de caches, um cliente pode
receber as respostas em uma ordem diferente daquela em que a origem
servidor enviou. Gostaríamos que o cliente use o mais recente
resposta gerada, mesmo que as respostas mais velhos são ainda, aparentemente,
frescos.
Nem a tag entidade, nem o valor de expiração pode impor uma
ordenação das respostas, pois é possível que uma resposta mais tarde
intencionalmente leva um tempo de expiração anterior. Os valores de data são
condenada a uma granularidade de um segundo.
Quando um cliente tenta revalidar uma entrada de cache, ea resposta é
recebe contém um cabeçalho de data que parece ser mais antiga que a
para a entrada em vigor, o cliente deve repetir o pedido
incondicionalmente, e incluem
Cache Control: max-age = 0
para forçar qualquer cache intermediário para validar suas cópias diretamente
com o servidor de origem, ou
Cache-Control: no-cache
para forçar qualquer cache intermediário para obter uma nova cópia a partir da origem
servidor.
Fielding, et al. Standards Track [Página 84]
?
HTTP/1.1 RFC 2616 junho 1999
Se os valores de data são iguais, então o cliente pode tanto usar a resposta
(Ou pode, se ele está sendo extremamente prudente pedido, uma nova resposta).
Servidores não devem depender de os clientes poderem escolher
determinista entre respostas geradas durante o mesmo segundo,
vezes se sobrepõem a sua expiração.
13,3 modelo de validação
Quando uma cache tem uma entrada velho que gostaria de usar como um
resposta ao pedido de um cliente, ele primeiro tem que verificar com a origem
servidor (ou, eventualmente, uma cache intermediário com uma resposta fresco) para
ver se a sua entrada em cache ainda é utilizável. Chamamos isso de “validação”
a entrada de cache. Desde que nós não queremos ter de pagar a sobrecarga de
retransmitir a resposta completa se a entrada de cache é bom, e nós
não querem pagar as despesas gerais de uma ida e volta extra, caso o cache
entrada é inválido, o protocolo HTTP/1.1 suporta o uso de
métodos condicional.
As características principais do protocolo para apoiar métodos condicionais são
aqueles preocupados com “validadores cache.” Quando um servidor de origem
gera uma resposta completa, que atribui algum tipo de validador para ele,
que é mantida com a entrada de cache. Quando um cliente (agente do usuário ou
proxy cache) faz um pedido condicional de um recurso para que
tem uma entrada de cache, que inclui o validador associado à
pedido.
O servidor então verifica se validador contra o validador atual
para a entidade e, se forem iguais (ver secção 13.3.3), ele responde
com um código especial de status (geralmente, 304 (Not Modified)) e não
corpo da entidade. Caso contrário, ele retorna uma resposta completa (incluindo
corpo da entidade). Assim, evitar a transmissão da resposta completa se o
validador partidas, e evitar uma ida extra se não
partida.
No HTTP/1.1, um pedido condicional parece exatamente o mesmo que um normal
pedido para o mesmo, exceto que ele carrega uma especial
cabeçalho (que inclui o validador) que, implicitamente, transforma o
método (geralmente, GET) em uma condicional.
O protocolo inclui tanto positivos como negativos sentidos da cache
condições de validação. Ou seja, é possível requerer que
um método ser executada se e somente se um validador e jogos ou se
somente se não validadores jogo.
Fielding, et al. Standards Track [Página 85]
?
HTTP/1.1 RFC 2616 junho 1999
Nota: a resposta que carece de um validador ainda pode ser armazenada em cache, e
servido de cache até que expire, a menos que seja explicitamente
proibida por uma diretiva de controle de cache. No entanto, um cache não pode
fazer uma recuperação da condicional se ele não tem um validador para o
entidade, o que significa que não será atualizável após o seu termo.
13.3.1 Datas Last-Modified
The Last-Modified valor do campo de cabeçalho entidade é frequentemente utilizado como um cache
validador. Em termos simples, uma entrada de cache é considerada válida
Se a entidade não foi modificado desde que o valor da última modificação.
13.3.2 Entidade Cache Validators Tag
O ETag valor do campo de cabeçalho de resposta, uma marca entidade, prevê um
“Validador cache opaco”. Isso pode permitir a validação mais confiável
em situações em que é inconveniente para armazenar datas de modificação,
onde a resolução de um segundo valores de data HTTP não é
suficiente ou quando o servidor de origem deseja evitar certos
paradoxos que podem surgir do uso de datas de modificação.
Entity Tags são descritos na seção 3.11. Os cabeçalhos usados com
tags entidade são descritos nas secções 14,19, 14,24, 14,26 e 14,44.
13.3.3 validadores fracos e fortes
Desde os servidores, tanto de origem e caches irá comparar dois validadores para
decidir se elas representam uma mesma entidade ou diferentes, normalmente uma
Seria de esperar que se a entidade (a entidade do corpo ou qualquer outra entidade,
cabeçalhos) muda de forma alguma, então o validador associado seria
mudar também. Se isso for verdade, então nós chamamos este um validador
“Validador forte.”
No entanto, pode haver casos em que um servidor prefere mudar o
validador apenas semanticamente mudanças significativas, e não quando
aspectos significativos da mudança da entidade. A validação que não
sempre mudar quando as alterações de recursos é um validador “fraco”.
Entidade tags são normalmente “validadores forte”, mas o protocolo
fornece um mecanismo para marcar uma tag entidade como “fraco”. Pode-se pensar
um validador forte como aquele que muda sempre que os bits de uma entidade
alterações, ao passo que um valor é alterado sempre que o fraco sentido de uma entidade
alterações. Alternativamente, pode-se pensar de um validador forte como parte
de um identificador para uma entidade específica, enquanto que um validador é fraco
parte de um identificador para um conjunto de entidades semanticamente equivalentes.
Nota: Um exemplo de um validador forte é um número inteiro que é
incrementada no armazenamento estável toda vez que uma entidade é alterada.
Fielding, et al. Standards Track [Página 86]
?
HTTP/1.1 RFC 2616 junho 1999
tempo de uma entidade de modificação, se representado por um segundo
Resolução, poderá ser um validador fraco, pois é possível que
o recurso pode ser modificado duas vezes durante um único segundo.
Suporte para validators fraco é opcional. No entanto, os validadores fracos
permitir uma maior eficiência de cache de objetos equivalentes, para
exemplo, um contador de visitas em um site é bom o suficiente, provavelmente, se for
atualizado a cada poucos dias ou semanas, e qualquer valor durante esse período
é provável “suficientemente bom” para ser equivalente.
A “utilização” de um validador seja, quando um cliente gera um pedido de
e inclui a validação em um campo de cabeçalho de validação, ou quando um
servidor compara dois validadores.
validadores fortes são utilizáveis em qualquer contexto. validadores fracos são apenas
utilizável em contextos que não dependem de igualdade exata de uma entidade.
Por exemplo, qualquer tipo é útil para um GET condicional de uma completa
entidade. No entanto, apenas um validador forte é utilizável para uma sub-escala
recuperação, pois, caso contrário o cliente pode acabar com um internamente
entidade inconsistente.
Clientes simples questão MAIO (subrange não) com requisições GET ou fraco
validadores ou validadores forte. Os clientes não devem usar validadores fracos
em outras formas de solicitação.
A única função que define o protocolo HTTP/1.1 nos validadores é
comparação. Existem duas funções de validação de comparação, em função
se o contexto de comparação permite o uso de validadores fracos
ou não:
– A função de comparação forte: a fim de ser considerados iguais,
ambos os validadores devem ser idênticas em todos os sentidos, e ambos devem
NÃO será fraco.
– A função de comparação mais fraca: a fim de ser considerados iguais,
ambos os validadores devem ser idênticas em todos os sentidos, mas um ou
Ambos eles podem ser etiquetados como “fraco”, sem afetar o
resultado.
Uma marca forte é entidade a menos que seja explicitamente marcado como fraco.
Secção 3.11 apresenta a sintaxe para tags entidade.
A hora da última modificação, quando usado como um validador de um pedido, é
implicitamente fraco a menos que seja possível deduzir que ele é forte,
usando as seguintes regras:
– O validador está sendo comparado por um servidor de origem para o
validador atual para a entidade e,
Fielding, et al. Standards Track [Página 87]
?
HTTP/1.1 RFC 2616 junho 1999
– Esse servidor de origem confiável sabe que a entidade associada que
não muda duas vezes durante a segunda abrangidos pela apresentados
validador.
ou
– O validador está prestes a ser usado por um cliente em uma Se-
Modified-Since, ou If-Unmodified cabeçalho vez, porque o cliente
tem uma entrada de cache para a entidade associada, e
– Essa entrada de cache inclui um valor Date, que dá o tempo
quando o servidor de origem enviou a resposta original, e
– A última vez que apresentou-Modified é pelo menos 60 segundos antes
o valor de data.
ou
– O validador está sendo comparado por um intermediário para o cache
validador armazenados em cache sua entrada para a entidade, e
– Essa entrada de cache inclui um valor Date, que dá o tempo
quando o servidor de origem enviou a resposta original, e
– A última vez que apresentou-Modified é pelo menos 60 segundos antes
o valor de data.
Este método se baseia no fato de que, se duas respostas diferentes foram
enviados pelo servidor de origem durante o mesmo segundo, mas ambos tiveram a
hora da última modificação mesmo, então pelo menos uma dessas respostas que
têm um valor igual a Data de seu tempo da última modificação. Os 60 arbitrárias –
segundo os guardas limite contra a possibilidade de que a data e de última
Modificado valores são gerados a partir clocks diferentes, ou um pouco
momentos diferentes durante a preparação da resposta. Um
aplicação pode usar um valor maior do que 60 segundos, se for
Acredita que 60 segundos é muito curto.
Se um cliente deseja realizar uma recuperação de sub-escala de um valor para
que tenha apenas um tempo Last-Modified e não validador opaco,
Pode fazer isso apenas se a hora da última modificação é forte no sentido de
descrito aqui.
A cache de origem do servidor receber um pedido condicional, que não
uma de corpo inteiro GET, deve utilizar a função de comparação forte
avaliar a condição.
Estas regras permitem caches HTTP/1.1 e clientes para executar com segurança sub-
recuperações gama de valores que foram obtidos a partir de HTTP/1.0
Fielding, et al. Standards Track [Página 88]
?
HTTP/1.1 RFC 2616 junho 1999
servidores.
Regras para 13.3.4 Quando usar Tags Entidade e Last-Modified Datas
Nós adotamos um conjunto de regras e recomendações para os servidores de origem,
clientes, e armazena a respeito de quando vários tipos de validação deve
ser utilizado, e para que fins.
HTTP/1.1 servidores de origem:
– Devem enviar um validador tag entidade, a menos que não é viável
gerar um.
– Pode enviar a tag entidade fraca, em vez de uma marca forte entidade, se
considerações sobre o desempenho suporta o uso de tags entidade fraca,
ou se é inviável para enviar uma tag entidade forte.
– Devem enviar um valor Last-Modified se é possível enviar um,
a menos que o risco de um colapso na transparência semântica que
pode resultar do uso desta data em uma cabeçalho If-Modified-Since
conduziria a graves problemas.
Em outras palavras, o comportamento preferido para um servidor de origem HTTP/1.1
é enviar ambas uma marca forte e uma entidade valor da última modificação.
Para ser legal, a entidade marca forte deve mudar quando o
mudanças entidade valor associado de qualquer maneira. A tag entidade fraca deve
alterações sempre que o associado às mudanças na entidade semanticamente
forma significativa.
Nota: a fim de proporcionar semanticamente cache transparente, uma
servidor de origem deve evitar a reutilização de uma marca forte entidade específica
valor para duas entidades diferentes, ou reutilizar um determinado fraco
valor entidade marca para duas entidades semanticamente diferentes. Esconderijo
entradas podem persistir por longos períodos arbitrariamente, independentemente da
tempos de validade, para que ele possa ser inadequado para esperar que uma
cache nunca mais vai tentar validar uma entrada usando um
validador que obteve, em algum momento no passado.
HTTP/1.1 clientes:
– Se uma entidade tag foi fornecida pelo servidor de origem, devem
usar essa tag entidade em qualquer pedido cache condicional (utilizando-se
Match ou If-None-Match).
– Se apenas um valor Last-Modified foi fornecido pela origem
do servidor, deve usar esse valor em cache subrange não-condicional
pedidos (usando If-Modified-Since).
Fielding, et al. Standards Track [Página 89]
?
HTTP/1.1 RFC 2616 junho 1999
– Se apenas um valor Last-Modified foi fornecida por um HTTP/1.0
servidor de origem, pode usar esse valor em cache subrange condicional
pedidos (usando If-Unmodified-Desde:). O agente deverá
fornecem uma maneira de desativar esta, em caso de dificuldade.
– Se ambas as tag de uma entidade e um valor Last-Modified foram
fornecidos pelo servidor de origem, devem usar tanto em validadores
pedidos cache condicional. Isto permite que ambos HTTP/1.0 e
HTTP/1.1 caches de responder adequadamente.
Um servidor de origem HTTP/1.1, ao receber um pedido de condicional que
inclui tanto uma data Last-Modified (por exemplo, num If-Modified-Since, ou
Se não modificado-desde-campo de cabeçalho) e uma ou mais marcas entidade (por exemplo,
num If-Match, If-None-Match, ou campo de cabeçalho If-Range) como cache
validadores, não deve retornar um status de resposta de 304 (Not Modified)
menos que isso é coerente com todo o cabeçalho condicional
campos do pedido.
Um proxy cache HTTP/1.1, ao receber uma solicitação condicional que
inclui tanto uma data Last-Modified e uma ou mais marcas como entidade
validadores cache, não deve retornar uma resposta em cache local para o
cliente, a menos que a resposta em cache é compatível com todos os
campos de cabeçalho condicional no pedido.
Nota: O princípio geral por trás destas regras é que HTTP/1.1
servidores e os clientes devem transmitir tanto não redundante
informação que está disponível nas suas respostas e solicitações.
HTTP/1.1 sistemas de receber esta informação fará com que o mais
suposições conservadoras sobre os validadores que recebem.
HTTP/1.0 clientes e caches irá ignorar tags entidade. Em geral,
última vez os valores recebidos ou utilizados por estes sistemas
origem cache suporte transparente e eficiente, e assim HTTP/1.1
servidores deverá fornecer os valores da última modificação. Nesses casos raros
onde o uso de um valor Last-Modified como um validador de um
HTTP/1.0 sistema pode resultar em um sério problema, então HTTP/1.1
servidores de origem não deve fornecer um.
13.3.5 não validar Condicionais
O princípio por trás tags entidade é que apenas o autor do serviço
conhece a semântica de um recurso bastante para selecionar um
mecanismo adequado de validação cache, ea especificação de qualquer
comparação validador função mais complexa do que a igualdade de bytes que
abrir uma lata de minhocas. Assim, as comparações de qualquer outros cabeçalhos
(Exceto Last-Modified, para compatibilidade com HTTP/1.0) nunca são
utilizadas para fins de validar uma entrada de cache.
Fielding, et al. Standards Track [Página 90]
?
HTTP/1.1 RFC 2616 junho 1999
13,4 Cacheabilidade Resposta
A menos que especificamente limitado por um cache-control (seção 14.9)
directiva, um sistema de cache pode sempre guardar uma resposta bem sucedida
(Ver secção 13.8) como uma entrada de cache, pode devolvê-lo sem validação
se é fresco, e devolvê-la após uma validação bem sucedida. Se
não há nem um validador cache nem um tempo de expiração explícita
associado com uma resposta, não esperamos que ele seja armazenado em cache, mas
caches certos podem violar essa expectativa (por exemplo, quando pouco
ou nenhuma conectividade de rede está disponível). Um cliente normalmente pode detectar
que essa resposta foi tirado de um cache, comparando a data
cabeçalho para o tempo atual.
Nota: alguns caches HTTP/1.0 são conhecidos por violar essa expectativa
sem dar qualquer aviso.
No entanto, em alguns casos, pode não ser apropriado para uma cache de
manter uma entidade, ou devolvê-lo em resposta a uma posterior
pedido. Isso pode ser porque a transparência absoluta é semântica
considerados necessários pelo autor do serviço, ou por causa de segurança ou
considerações de privacidade. Algumas directivas de controle de cache são
portanto, de modo a que o servidor pode indicar que certos
entidades de recursos, ou parte dela, não devem ser armazenados em cache
independentemente de outras considerações.
Note-se que 14,8 seção normalmente impede que um cache compartilhado de poupança
e devolvendo uma resposta a um pedido anterior, se o pedido
incluído um cabeçalho de autorização.
A resposta recebida com um código de status 200, 203, 206, 300, 301 ou
410 podem ser armazenadas por um cache e usada em resposta a uma posterior
pedido, sujeito ao mecanismo de expiração, a menos que um cache-control
directiva proíbe a colocação em cache. No entanto, uma cache que não suporta
da Gama e Content-Range cabeçalhos cache NÃO DEVE 206 (parcial
Content) respostas.
A resposta recebida com qualquer outro código de status (por exemplo, códigos de status 302
e 307) não deve ser retornado em uma resposta a uma solicitação subseqüente
a menos que haja controle de cache-directivas ou outro cabeçalho (s) que
explicitamente o permitam. Por exemplo, estes incluem o seguinte: um
Expira cabeçalho (art. 14,21); um “máximo de idade,” s-maxage “,” deve-
revalidar “,” proxy-revalidar “,” público “ou” privadas “de controle de cache
directiva (art. 14.9).
Fielding, et al. Standards Track [Página 91]
?
HTTP/1.1 RFC 2616 junho 1999
13,5 Respostas Construindo dos esconderijos
A finalidade de um cache HTTP é armazenar as informações recebidas
resposta às solicitações para o uso em responder às solicitações futuras. Em
muitos casos, um cache simplesmente retorna as partes apropriadas de
resposta ao solicitante. No entanto, se a cache tem uma entrada de cache
com base em uma resposta anterior, que poderia ter de combinar as peças de um novo
resposta com o que é realizado na entrada de cache.
Cabeçalhos 13.5.1 End-to-end e Hop-by-hop
Para efeitos de definição do comportamento dos caches e não-cache
proxies, que divide os cabeçalhos HTTP em duas categorias:
– End-to-end cabeçalhos, que são transmitidos para a final
destinatário de um pedido ou resposta. Fim-de-final em cabeçalhos
respostas devem ser armazenados como parte de uma entrada de cache e deve ser
transmitida em qualquer resposta formado a partir de uma entrada de cache.
– Hop-by-hop cabeçalhos, que são significativos apenas para um único
conexão nível de transporte, e não são armazenados por caches ou
enviado por proxies.
A seguir HTTP/1.1 cabeçalhos são cabeçalhos hop-by-hop:
– Ligação
– Keep-Alive
– Proxy-Authenticate
– Proxy-Autorização
– TE
– Trailers
– Transfer-Encoding
– Upgrade
Todos os outros cabeçalhos definidos pelo HTTP/1.1 são cabeçalhos de ponta a ponta.
Outros cabeçalhos hop-by-hop deve estar listado em um cabeçalho Connection,
(Art. 14,10) para ser introduzido na HTTP/1.1 (ou posteriores).
13.5.2 Cabeçalhos não modificáveis
Algumas características do protocolo HTTP/1.1, como Digest
Autenticação, depende do valor de determinados cabeçalhos de ponta a ponta. A
proxy transparente não deve modificar um cabeçalho de fim-de-final a menos que o
definição de cabeçalho que exige ou permite que especificamente.
Fielding, et al. Standards Track [Página 92]
?
HTTP/1.1 RFC 2616 junho 1999
Um proxy transparente não podem alterar qualquer uma das seguintes áreas de
pedido ou resposta, e não deve adicionar qualquer um destes campos, se não
já está presente:
– Conteúdo Local,
– Content-MD5
– ETag
– Last-Modified
Um proxy transparente não podem alterar qualquer uma das seguintes áreas de
resposta:
– Expira
Mas pode adicionar qualquer um destes campos, se não estiver presente. Se um
cabeçalho Expires é adicionado, deve ser dado um campo de valor idêntico ao
a do cabeçalho Data em que a resposta.
A procuração não podem alterar ou adicionar qualquer um dos seguintes campos em um
mensagem que contém o controle não transformar-cache-directiva, ou
qualquer pedido:
– Content-Encoding
– Content-Range
– Tipo de conteúdo
A não-transparente proxy pode modificar ou adicionar esses campos em uma mensagem
que não inclui nenhuma transformação, mas se ele faz isso, ele deve adicionar um
Aviso 214 (Transformação aplicada) se já não aparecem
na mensagem (ver secção 14,46).
Atenção: modificação desnecessária de cabeçalhos fim-de-final pode
causar falhas de autenticação mais forte, se a autenticação
mecanismos são introduzidos em versões posteriores do HTTP. Tal
mecanismos de autenticação podem invocar os valores dos campos do cabeçalho
não listadas aqui.
O campo Content-Length de um pedido ou resposta é adicionada ou excluída
de acordo com as regras na secção 4.4. A DEVE proxy transparente
preservar a entidade de comprimento (seção 7.2.2) da entidade corpo,
Embora possa alterar o comprimento de transferência (4.4).
Fielding, et al. Standards Track [Página 93]
?
HTTP/1.1 RFC 2616 junho 1999
13.5.3 Headers Combinar
Quando uma cache faz uma solicitação de validação de um servidor, eo servidor
fornece um 304 (não modificado resposta) ou 206 (Partial Content)
resposta, o cache, em seguida, constrói uma resposta a enviar à
cliente solicitante.
Se o código de status é 304 (não modificado), o cache usa a entidade-
corporal armazenada na entrada do cache como a entidade de corpo presente de saída
a resposta. Se o código de status é de 206 (Partial Content) e ETag ou
cabeçalhos Last-Modified exatamente iguais, o cache pode combinar o
conteúdos armazenados no cache com a entrada de novos conteúdos recebidos em
a resposta e usar o resultado como a entidade de corpo presente de saída
resposta (ver 13.5.4).
Os cabeçalhos de fim-de-final armazenado na entrada de cache são usados para o
construído resposta, exceto que
– Os cabeçalhos de aviso armazenado com 1xx avisar código (ver secção
14,46) devem ser excluídos da entrada de cache e transmitido
a resposta.
– Os cabeçalhos de aviso armazenados com 2xx avisar código deve ser mantida
na entrada do cache e da resposta enviada.
– Os cabeçalhos fim-de-final previsto na resposta 304 ou 206 deve
substituir os cabeçalhos correspondentes a partir da entrada de cache.
A menos que o cache decidir remover a entrada de cache, ele deve também
substituir os cabeçalhos de fim-de-final armazenado com a entrada de cache com
cabeçalhos correspondentes recebeu na resposta recebida, exceto para
Atenção cabeçalhos como descrito imediatamente acima. Se um cabeçalho de campo
nome na resposta recebida corresponde a mais de um cabeçalho no
entrada de cache, como todos os cabeçalhos de idade deve ser substituída.
Em outras palavras, o conjunto de ponta a ponta-headers recebidos no
resposta recebida substitui todos os cabeçalhos correspondentes fim-de-final
armazenado com a entrada de cache (exceto para os cabeçalhos de aviso armazenados com
1xx avisar código, que são excluídos mesmo se não for substituído).
Nota: esta regra permite que um servidor de origem para usar um 304 (não
Modificada) ou uma 206 resposta (Partial Content) para atualizar qualquer cabeçalho
associada a uma resposta anterior para a mesma entidade ou sub-
intervalos dos mesmos, embora nem sempre pode ser significativa ou
correcta para o fazer. Esta regra não permite que um servidor de origem para uso
uma 304 (Not Modified) ou 206 resposta (Partial Content) para
inteiramente excluir um cabeçalho que tinha fornecido com uma versão anterior
a resposta.
Fielding, et al. Standards Track [Página 94]
?
HTTP/1.1 RFC 2616 junho 1999
13.5.4 Combinando Escalas Byte
A resposta pode transferir apenas subrange um dos bytes de uma entidade-
corpo, quer porque o pedido incluído um ou mais Faixa de
especificações, ou porque a conexão foi interrompida precocemente. Depois
várias transferências, cache pode ter recebido várias gamas de
a mesma entidade do corpo.
Se o cache tem um conjunto armazenado não-vazio de subranges de uma entidade, e
uma das transferências mais subrange resposta, o cache pode
combinar a subrange novo com o conjunto existente, se ambas as seguintes
condições:
– Tanto a resposta da entrada e da entrada de cache tem um cache
validador.
– Os dois validadores cache jogo usando a comparação forte
função (ver secção 13.3.3).
Se o requisito não for cumprido, o cache deve usar somente a mais
resposta parcial recentes (com base na data valores transmitidos com
cada resposta, e utilizando a resposta recebida, se estes valores são
igual ou falta), e deve descartar outras informações parciais.
13,6 Caching Respostas negociada
Utilização de negociação de conteúdo do servidor-driven (art. 12.1), como indicado
pela presença de um campo de cabeçalho Vary em uma resposta, altera a
condições eo processo pelo qual um pode usar o cache de resposta para
solicitações subseqüentes. Consulte a seção 14,44 para o uso do cabeçalho Vary
campo pelos servidores.
Um servidor deve usar o campo de cabeçalho Vary para informar o cache do que
campos de cabeçalho de solicitação, foram usados para selecionar entre vários
representações de um sujeito cacheable resposta para o servidor-driven
negociação. O conjunto de campos de cabeçalho com o nome do campo Vary valor
é conhecido como o “selecionando” pedir-headers.
Quando o cache de receber um pedido subsequente cujo pedido-URI
especifica uma ou mais entradas de cache, incluindo um campo de cabeçalho Vary,
o cache não deve usar essa entrada de um cache para a construção de uma resposta
o pedido de novo a não ser que todos os cabeçalhos de solicitação de seleção presente
no pedido de nova partida correspondente armazenado solicitação cabeçalhos
o pedido original.
A seleção de solicitação de dois pedidos de cabeçalhos são definidos para corresponder
se e somente se a seleção de solicitação cabeçalhos na primeira solicitação pode
ser transformado para a seleção de solicitação cabeçalhos no segundo pedido
Fielding, et al. Standards Track [Página 95],
?
HTTP/1.1 RFC 2616 junho 1999
adicionando ou removendo espaço em branco linear (LWS) em locais onde esta
é permitido pela BNF correspondente, e / ou combinando múltiplos
cabeçalho da mensagem, os campos com o mesmo nome de campo seguindo as regras
sobre os cabeçalhos das mensagens na secção 4.2.
A Vary cabeçalho campo valor de “*” sempre falha em encontrar e subsequente
pedidos em que o recurso só pode ser devidamente interpretado pelo
servidor de origem.
Se os campos de cabeçalho de pedido seleção para a entrada em cache não
coincidir com a seleção de campos de solicitação de cabeçalho do novo pedido, em seguida,
o cache não deve usar uma entrada de cache para satisfazer o pedido, salvo
em primeiro lugar retransmite a nova solicitação ao servidor de origem em uma condicional
pedido, o servidor responde com 304 (Not Modified), incluindo um
tag entidade ou Content-Location que indica a entidade a ser utilizado.
Se uma entidade tag foi atribuída a uma representação em cache, o
pedido enviado deve estar subordinado a entidade e incluir tags
em um campo If-None-Match cabeçalho de todas as suas entradas para o cache
recursos. Esta transmite ao servidor o conjunto de entidades atualmente
na posse do cache, de modo que se qualquer uma dessas entidades coincide com o
entidade requerida, o servidor pode utilizar o campo de cabeçalho ETag em sua 304
(Not Modified resposta) para dizer que a entrada do cache é apropriado.
Se a entidade marca de resposta de novos jogos que existente
entrada, a nova resposta deve ser usado para atualizar os campos de cabeçalho de
a entrada em vigor, eo resultado deve ser retornado para o cliente.
Se qualquer uma das entradas de cache existentes contém apenas parcial de conteúdo
para a entidade associada, a entidade marca não deveria ser incluído no
o campo de cabeçalho If-None-Match, se o pedido for para uma faixa que
seria plenamente satisfeita com essa entrada.
Se uma cache recebe uma resposta de sucesso, cujo Content-Location
campo de jogos que de uma entrada de cache existentes para o mesmo Pedidos
] URI, cuja marca entidade difere daquele da entrada em vigor, e
cuja data é mais recente do que a entrada em vigor, a
entrada em vigor não deve ser devolvido em resposta a futuras solicitações
e deve ser eliminada a partir do cache.
13,7 caches compartilhados e não compartilhados
Por razões de segurança e privacidade, é necessário fazer uma
distinção entre “comum” e “não comum” caches. A não-compartilhados
cache é aquela que é acessível apenas a um único utilizador. Acessibilidade
neste caso devem ser aplicadas por mecanismos de segurança adequados.
Todos os outros caches são consideradas “comuns”. Outras seções
Fielding, et al. Standards Track [Página 96]
?
HTTP/1.1 RFC 2616 junho 1999
este lugar especificações determinadas restrições sobre o funcionamento do
caches compartilhados, a fim de evitar a perda de privacidade ou o fracasso de
controles de acesso.
13,8 erros ou comportamento de cache de resposta incompleta
A cache que recebe uma resposta incompleta (por exemplo, com menos
bytes de dados do que o especificado no cabeçalho Content-Length) pode armazenar
a resposta. No entanto, o cache deve tratar isso como um parcial
a resposta. respostas parciais podem ser combinados como descrito na secção
13.5.4, o resultado pode ser uma resposta completa ou ainda pode ser
parcial. A cache não deve retornar uma resposta parcial a um cliente
explicitamente sem marcá-lo como tal, usando o 206 (parcial
Content) código de status. A cache não deve retornar uma resposta parcial
usando um código de status 200 (OK).
Se uma cache recebe uma resposta 5xx ao tentar revalidar um
entrada, ela pode transmitir essa resposta para o cliente solicitante,
ou agir como se o servidor não respondeu. Neste último caso, pode
retornar uma resposta anteriormente recebida a menos que a entrada em cache
inclui o “must-revalidar” diretiva de controle cache (ver secção
14.9).
13,9 Efeitos colaterais de GET e HEAD
A menos que o servidor de origem proíbe explicitamente o cache do seu
respostas, a aplicação de métodos GET e HEAD para eventuais recursos
NÃO DEVE ter efeitos colaterais que levam a comportamentos errados se
estas respostas são tomadas a partir de um cache. Podem ainda ter lado
efeitos, mas o cache não é obrigada a considerar tais efeitos secundários em
suas decisões de cache. Caches são sempre esperados para observar um
restrições explícitas servidor de origem na cache.
Notamos uma exceção a essa regra: uma vez que algumas aplicações
tradicionalmente utilizados GETs e Chefes com URLs query (aqueles que contêm um
“? na parte rel_path) para realizar operações com colaterais significativos
efeitos, caches não deve tratar as respostas a tais URIs tão fresca, a menos
o servidor fornece um tempo de expiração explicitamente. Este especificamente
significa que as respostas dos servidores HTTP/1.0 para URIs não deverá
ser tomadas a partir de um cache. Consulte a seção 9.1.1 para informações relacionadas.
Invalidação 13,10 após as atualizações ou exclusões
O efeito de certos métodos realizados em um recurso na origem
servidor pode causar uma ou mais entradas de cache existentes para tornar-se não
transparente inválido. Ou seja, embora possam continuar a ser
“Fresco”, não refletem exatamente o que o servidor de origem seria
troca de um novo pedido no recurso.
Fielding, et al. Standards Track [Página 97]
?
HTTP/1.1 RFC 2616 junho 1999
Não há nenhuma maneira para o protocolo HTTP para garantir que todas essas
entradas de cache são marcados como inválidos. Por exemplo, pedir que
causou a mudança no servidor de origem não poderia ter ido até
o proxy se uma entrada de cache é armazenado. No entanto, várias regras de ajuda
reduzir a probabilidade de um comportamento errôneo.
Nesta seção, a frase “invalidar uma entidade” significa que o
cache remova todas as instâncias da entidade a partir do seu
armazenamento, ou marcará as como “inválido” e na necessidade de um imperativo
revalidação antes que eles podem ser retornados em resposta a uma posterior
pedido.
Alguns métodos HTTP deve causar um cache para invalidar uma entidade. Isto é
ou a entidade referida pelo Request-URI, ou pela localização
ou cabeçalhos Content-Location (se houver). Estes métodos são:
– PUT
– DELETE
– POST
A fim de evitar ataques de negação de serviço, uma nulidade com base
na URI em um local ou de Conteúdo Local cabeçalho só deve ser
executada se a parte de host é o mesmo que no Request-URI.
A cache que passa através de pedidos para os métodos não
entender deveria invalidar quaisquer entidades referidas pelo
Request-URI.
13,11 write-through Obrigatório
Todos os métodos que podem ser esperadas para causar modificações no
recursos do servidor de origem deve ser escrito através da origem
servidor. Isso inclui actualmente todos os métodos, exceto para GET e HEAD.
A cache não deve responder a esse pedido de um cliente antes de ter
transmitir o pedido para o servidor de entrada e de ter recebido uma
correspondente resposta do servidor de entrada. Isso não impede
um proxy cache de enviar uma resposta 100 (Continua) antes da
servidor de entrada enviou sua resposta final.
A alternativa (conhecido como “write-back” ou “copy-back caching”) não é
permitido em HTTP/1.1, devido à dificuldade de fornecer consistente
atualizações e os problemas decorrentes do servidor, cache, ou rede
falha antes de write-back.
Fielding, et al. Standards Track [Página 98]
?
HTTP/1.1 RFC 2616 junho 1999
13,12 substituição Cache
Se um (novo cacheable ver secções 14.9.2, 13.2.5, 13.2.6 e 13.8)
resposta é recebida a partir de um recurso, enquanto todas as respostas existentes para a
o mesmo recurso estão em cache, o cache deve usar a nova resposta
responder à solicitação atual. Ela pode inserir-lo em cache de armazenamento
e pode, se reúne todos os requisitos, usá-lo para responder a qualquer
futuros pedidos que já causaram a resposta à velha
ser devolvido. Se ela insere o nova resposta em cache no armazenamento
regras aplicam-se na secção 13.5.3.
Nota: a nova resposta que tem um valor mais velhos cabeçalho Data de
respostas existentes em cache não é cacheable.
Listas de 13,13 História
Os agentes têm, frequentemente, mecanismos de história, como “Back” e botões
listas de história, que pode ser usado para reexibir uma entidade recuperada
mais cedo em uma sessão.
mecanismos de História e caches são diferentes. Em particular a história
mecanismos não deve tentar mostrar uma visão semanticamente transparente
o estado atual de um recurso. Pelo contrário, a história é um mecanismo destinado
para mostrar exatamente o que o usuário viu no momento em que o recurso foi
recuperados.
Por padrão, um tempo de expiração não se aplica aos mecanismos de história.
Se a entidade ainda está em depósito, um mecanismo de história deve mostrar
ainda se a entidade tiver expirado, a menos que o usuário tenha sido especificamente
configurado que o agente de atualização de documentos vencidos da história.
Isso não deve ser interpretada no sentido de proibir o mecanismo da história
dizendo ao usuário que a visão pode estar obsoleto.
Nota: se os mecanismos de lista do histórico desnecessariamente impedir que os usuários
visualização dos recursos obsoletos, isto tende a forçar os autores serviço
evitar o uso de controles de expiração HTTP e controles cache quando
que de outro modo como fazer. Serviço autores podem considerar
importante que os usuários não sejam apresentadas com mensagens de erro ou
mensagens de aviso quando usar controles de navegação (como o Back)
para visualizar previamente buscado recursos. Mesmo que às vezes essa
recursos não devem em cache, ou deveria expirar rapidamente, o usuário
considerações interface pode forçar os autores de recorrer ao serviço
outros meios de prevenção de cache (por exemplo, “uma vez só” URLs), a fim
para não sofrer os efeitos do mau funcionamento da história
mecanismos.
Fielding, et al. Standards Track [Página 99]
?
HTTP/1.1 RFC 2616 junho 1999
Definições 14 campo de cabeçalho
Esta seção define a sintaxe ea semântica de todos os padrões
HTTP/1.1 campos de cabeçalho. Para os campos de cabeçalho entidade, tanto o remetente e
referem-se destinatário o cliente ou servidor, dependendo de quem
envia e que recebe da entidade.
14,1 Accept
Aceitar o campo de cabeçalho de solicitação pode ser usado para especificar certos meios de comunicação
tipos que são aceitáveis para a resposta. Aceitar os cabeçalhos podem ser
usado para indicar que o pedido é especificamente limitado a uma pequena
conjunto de tipos desejado, como no caso de um pedido de in-line
imagem.
Aceitar = “Aceitar”: “
# (Media gama [] aceitar-params)
meios de comunicação de alcance = (“*/*”
| (Tipo “/” * “)
| (“Tipo / subtipo”)
) * (“;” Parâmetro)
aceitar-params = “”; “q” = * “qValue (aceitar extensão)
aceitar extensão = “[” token “=” (token | citou-corda)]
O asterisco “*” caracteres é usado para tipos de mídia do grupo em intervalos,
“*/*” com indicação de todos os tipos de mídia e “* / tipo”, indicando todos os
subtipos desse tipo. Os meios de comunicação de alcance podem incluir tipo de mídia
parâmetros que são aplicáveis a esse intervalo.
Todos os meios de comunicação de alcance pode ser seguido por um ou mais aceitar-params,
começando com o parâmetro “q para indicar uma qualidade relativa
fator. O primeiro parâmetro “q (se houver separa) os meios de comunicação de alcance
parâmetro (s) a partir do aceitar-params. Fatores de qualidade permitem ao usuário
ou agente do usuário para indicar o grau relativo de preferência para os que
meios de comunicação de alcance, utilizando a escala qValue 0-1 (seção 3.9). O
valor padrão é q = 1.
Nota: O uso do nome do parâmetro “q” de tipo de mídia independente
parâmetros de parâmetros Accept extensão é devido ao histórico
prática. Embora este parâmetro impede qualquer tipo de mídia chamada
“Q” de ser usado com uma variedade de mídia, um evento como esse é acreditado
ser improvável, dada a ausência de qualquer “q” parâmetros da IANA
Registro tipo de mídia eo uso raro de qualquer tipo de mídia
parâmetros em Accept. Futuro tipos de mídia são desencorajados de
registrar qualquer parâmetro chamado “q”.
Fielding, et al. Standards Track [Página 100]
?
HTTP/1.1 RFC 2616 junho 1999
O exemplo
Accept: audio / *; q = 0,2, audio / basic
Deve ser interpretada como “Eu prefiro audio / basic, mas me enviar o áudio
tipo, se é o melhor disponível após uma marca de 80% para baixo em termos de qualidade. “
Se nenhum campo de cabeçalho Accept está presente, então é assumido que a
cliente aceita todos os tipos de mídia. Se um campo de cabeçalho Accept está presente,
e se o servidor não pode enviar uma resposta que seja aceitável
de acordo com o combinado Aceitar valor do campo, então o servidor deverá
enviar uma resposta 406 (não aceitável).
Um exemplo mais elaborado é
Accept: text / plain; q = 0,5, texto / html,
text / x-DVI; q = 0,8, text / x-c
Verbalmente, isso seria interpretado como “text / html e text / xc são
os tipos de mídia preferido, mas se eles não existirem, em seguida, enviar o
text / x-dvi entidade, e se isso não existe, envie o texto / plain
entidade. “
intervalos de mídia pode ser substituído por mais intervalos específicos de mídia ou
tipos específicos de mídia. Se mais de um intervalo de mídia se aplica a um dado
tipo, a referência mais específica tem precedência. Por exemplo,
Accept: text / *, texto / html, text / html; nível = 1, / *
tem a precedência seguinte:
1) text / html; nível = 1
2) text / html
3) text / *
4) * / *
A mídia fator de qualidade tipo associado com um tipo de dado é
determinada por encontrar os meios de comunicação série com a maior precedência
que corresponde a esse tipo. Por exemplo,
Accept: text / *; q = 0,3, text / html; q = 0,7, text / html; nível = 1,
text / html; nível = 2; q = 0,4, / *; q = 0,5
causaria os seguintes valores para ser associado:
text / html; nível = 1 = 1
text / html = 0,7
text / plain = 0,3
Fielding, et al. Standards Track [Página 101]
?
HTTP/1.1 RFC 2616 junho 1999
image / jpeg = 0,5
text / html; nível = 2 = 0,4
text / html; nível 3 = 0,7
Nota: Um agente do usuário pode ser fornecido com um conjunto padrão de qualidade
Os valores para os intervalos determinados meios de comunicação. No entanto, a menos que o agente é
um sistema fechado que não pode interagir com outros agentes de processamento,
este conjunto padrão devem ser configuráveis pelo usuário.
14,2 accept-charset
A Accept-Charset campo de cabeçalho de solicitação pode ser usado para indicar o
conjuntos de caracteres são aceitáveis para a resposta. Este campo permite
clientes capazes de compreensão mais abrangente ou especiais,
efeitos conjuntos de caracteres para sinalizar que a capacidade de um servidor que é
capaz de representar documentos nesses conjuntos de caracteres.
Accept-charset = “Accept-Charset”: “
# 1 ((charset | “*”) [“,” q “=” qValue])
Conjunto de caracteres os valores estão descritos na seção 3.4. Cada charset MAIO
ser atribuído um valor de qualidade de associado que representa o usuário
preferência para o charset. O valor padrão é q = 1. Um exemplo é
Accept-Charset: iso-8859-5, unicode-1-1, q = 0,8
O valor especial “*”, se presentes no campo Accept-Charset,
corresponde a cada conjunto de caracteres (incluindo ISO-8859-1), que não é
mencionados em outras partes do campo Accept-Charset. Se não “*” está presente
em um campo Accept-Charset, então todos os conjuntos de caracteres não explicitamente
mencionadas obter um valor de qualidade de 0, exceto para ISO-8859-1, que recebe
um valor de qualidade de um, se não explicitamente mencionada.
Se nenhum cabeçalho Accept-Charset estiver presente, o padrão é que qualquer
conjunto de caracteres é aceitável. Se um cabeçalho Accept-Charset está presente,
e se o servidor não pode enviar uma resposta que seja aceitável
de acordo com o cabeçalho Accept-Charset, em seguida, o servidor deve enviar
uma resposta de erro com o 406 (não aceitável) o código de estado, embora
o envio de uma resposta inaceitável também é permitida.
14,3 Accept-Encoding
A Accept-Encoding cabeçalho campo pedido é semelhante a aceitar, mas
restringe o conteúdo de códigos (seção 3.5) que são aceitáveis em
a resposta.
Accept-Encoding = “Accept-Encoding”: “
Fielding, et al. Standards Track [Página 102]
?
HTTP/1.1 RFC 2616 junho 1999
# 1 ([códigos “,” “q” = “qValue)]
codificações = (conteúdo de codificação “* |”)
Exemplos de seu uso são:
Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: comprimir; q = 0,5 gzip; q = 1,0
Accept-Encoding: gzip, q = 1.0, identidade, q = 0,5, *; q = 0
Um servidor de testes se o conteúdo de codificação é aceitável, de acordo com
um campo Accept-Encoding, usando as seguintes regras:
1. Se o conteúdo de codificação é uma das codificações de conteúdo listado em
o campo Accept-Encoding, então é aceitável, a menos que seja
acompanhado por um qValue 0. (Tal como definido no ponto 3.9, a
qValue 0 significa “não é aceitável.”)
2. * O “especial” símbolo em um campo Accept-Encoding corresponde a qualquer
codificação de conteúdos disponíveis não listadas no cabeçalho
de campo.
3. Se vários conteúdos códigos são aceitáveis, então o aceitável
conteúdo de codificação com o qValue mais non-zero é o preferido.
4. A “identidade” de conteúdo de codificação é sempre aceitável, a menos
especificamente recusado porque o campo Accept-Encoding inclui
“Identidade; q = 0”, ou porque o campo inclui “*; q = 0” e não
não incluir explicitamente a “identidade” de conteúdo de codificação. Se o
Accept-Encoding campo de valor estiver vazio, apenas a identidade “
codificação é aceitável.
Se um campo Accept-Encoding está presente em um pedido, e se o
servidor não pode enviar uma resposta que seja aceitável de acordo com o
Accept-Encoding cabeçalho, o servidor deve enviar uma resposta de erro
com o código de status 406 (Não Aceitável).
Se nenhum campo Accept-Encoding está presente em um pedido, o servidor pode
supor que o cliente aceitará qualquer conteúdo codificação. Neste caso,
se a “identidade” é um dos conteúdos disponíveis, códigos, então o
servidor deve usar a “identidade” de conteúdo de codificação, a menos que tenha
informações adicionais que um diferente conteúdo de codificação é significativa
para o cliente.
Nota: Se o pedido não inclui um campo Accept-Encoding,
e se a “identidade” de codificação de conteúdo não está disponível, então
conteúdo códigos comumente compreendido pelos clientes HTTP/1.0 (ie,
Fielding, et al. Standards Track [Página 103]
?
HTTP/1.1 RFC 2616 junho 1999
“Gzip” e “compactar”) são os preferidos, alguns clientes mais velhos
indevidamente exibir mensagens enviadas com outras codificações de conteúdo. O
servidor também pode tomar essa decisão com base em informações sobre
o agente especial do usuário ou cliente.
Nota: A maioria dos pedidos HTTP/1.0 não reconhecem ou obedecer qvalues
associado com conteúdo codificações. Isto significa que não qvalues
trabalho e não são permitidos com gzip-x ou x-compress.
14,4 Accept-Language
A Accept-Language campo do cabeçalho da solicitação é semelhante a aceitar, mas
restringe o conjunto das línguas naturais que são preferidos como
resposta ao pedido. Language tags são definidas no ponto 3.10.
Accept-Language = “Aceitar idioma”: “
# 1 ([intervalo de linguagem “;” q “=” qValue])
gama-language = ((1 * 8ALPHA (“-” 1 * 8ALPHA)) | “*”)
Cada linguagem de alcance pode ser dado um valor de qualidade de associados que
representa uma estimativa da preferência do usuário para os idiomas
especificado por esse intervalo. O valor padrão de qualidade com “q = 1”. Para
exemplo,
Accept-Language: da, pt-br, q = 0,8, en; q = 0,7
seria dizer: “Eu prefiro dinamarquês, mas aceita e Inglês Britânico
outros tipos de Inglês. “A linguagem de gama corresponde a uma linguagem de tag-se
exatamente igual ao tag, ou se ele é exatamente igual a um prefixo de
marca de tal forma que o caráter primeira marca a seguir o prefixo é “-“.
A faixa especial “*”, se presentes no campo Accept-Language,
corresponde cada marca não igualada por nenhum outro intervalo presentes no
campo Accept-Language.
Nota: Este uso de uma regra de correspondência de prefixo não implica que
tags linguagem são atribuídos a línguas de tal forma que é
sempre verdade que, se um usuário compreende uma linguagem com um certo
tag, então este usuário também entender todas as línguas com tags
para que esta marca é um prefixo. A regra permite que o prefixo simplesmente
uso de tags prefixo se este for o caso.
O fator de qualidade língua atribuído a uma linguagem de marcas pela
campo Accept-Language é o valor maior a qualidade da linguagem
faixa de domínio que corresponda ao idioma tag. Se nenhum idioma
intervalo no campo coincide com a marca, o fator qualidade língua
atribuído é 0. Se nenhum cabeçalho Accept-Language está presente no
pedido, o servidor
Fielding, et al. Standards Track [Página 104]
?
HTTP/1.1 RFC 2616 junho 1999
Deve assumir que todas as línguas são igualmente aceitáveis. Se um
cabeçalho Accept-Language estiver presente, então todas as línguas que são
atribuído um fator de qualidade maior que 0 são aceitáveis.
Pode ser ao contrário das expectativas de privacidade do usuário para enviar
um cabeçalho Accept-Language com as preferências completo linguística
o usuário em cada solicitação. Para uma discussão sobre este assunto, ver
seção 15.1.4.
Como inteligibilidade é altamente dependente do usuário individual, é
recomendável que os aplicativos cliente fazer a escolha de linguística
preferência à disposição do usuário. Se a escolha não é feita
disponível, então o campo de cabeçalho Accept-Language não deve ser dada em
o pedido.
Nota: Ao fazer a escolha de preferência lingüística à disposição
o usuário, lembramos implementadores do fato de que os usuários não são
familiarizados com os detalhes do idioma correspondente, conforme descrito acima,
e deve fornecer orientação adequada. Como exemplo, os usuários
supor que a selecção “en-gb”, que será servido qualquer
tipo de documento Inglês Britânico Inglês se não estiver disponível. A
agente poderia sugerir em tal caso, para adicionar “en” para obter o
melhor comportamento a condizer.
14,5 Accept-Ranges
A Accept-Ranges campo de cabeçalho de resposta permite que o servidor
indicar a aceitação dos pedidos de intervalo para recurso:
Accept-Ranges = “Accept-Ranges”: “aceitável varia-
aceitável, varia = 1 # | Unidade de gama none “
Origem servidores que aceitam pedidos de gama-byte pode enviar
Accept-Ranges: bytes
mas não são obrigados a fazê-lo. Os clientes podem gerar gama-byte
pedidos sem ter recebido este cabeçalho para o recurso
envolvidas. Faixa de unidades estão definidos no ponto 3.12.
Os servidores que não aceitam qualquer tipo de pedido para um intervalo
recurso pode enviar
Accept-Ranges: none
aconselhar o cliente não para tentar um pedido de intervalo.
Fielding, et al. Standards Track [Página 105]
?
HTTP/1.1 RFC 2616 junho 1999
14,6 Idade
A Idade campo de cabeçalho de resposta transmite estimativa do remetente da
quantidade de tempo desde a resposta (ou a sua revalidação) foi
gerado no servidor de origem. A resposta em cache é “fresco” se
sua idade não exceda o seu tempo de vida de frescura. Idade valores são
calculado como especificado no ponto 13.2.3.
Idade = “Age”: “valor-idade
valor de idade = delta segundos
Idade valores são inteiros não-negativos decimal, que representa o tempo em
segundos.
Se uma cache recebe um valor maior que o maior positivo
inteiros que podem representar, ou se qualquer dos seus cálculos idade
transborda, ele deve transmitir um cabeçalho de idade com um valor de
2147483648 (2 ^ 31). Um servidor HTTP/1.1 que inclui um cache deve
incluir um campo de cabeçalho Idade em cada resposta gerada a partir de sua
próprio cache. Caches deve usar um tipo de aritmética de pelo menos 31
bits do intervalo.
14,7 Permitir
Permitir o campo de cabeçalho entidade, lista o conjunto de métodos suportados
por o recurso identificado pelo Request-URI. O propósito deste
campo é estritamente para informar o destinatário de métodos válidos
associado ao recurso. Permitir um campo de cabeçalho deve ser
presentes em 405 (Método não permitido dar resposta).
Permitir = “Permitir”: “# Method
Exemplo de uso:
Permitir: GET, HEAD, PUT
Este campo não pode impedir um cliente de tentar outros métodos.
No entanto, as indicações dadas pelo que o valor de campo de cabeçalho
Devem ser seguidas. O conjunto real dos métodos permitidos é definido
pelo servidor de origem no momento de cada solicitação.
Permitir o cabeçalho do campo pode ser fornecido com um pedido para PUT
recomendará os métodos a serem apoiadas pelo novo ou modificado
recursos. O servidor não é obrigado a apoiar estes métodos e
Deve incluir uma Permitir cabeçalho na resposta que dá a real
métodos suportados.
Fielding, et al. Standards Track [Página 106]
?
HTTP/1.1 RFC 2616 junho 1999
A procuração não deve modificar o que o campo de cabeçalho mesmo que ele não
compreender todos os métodos especificados, desde que o agente pode
tem outros meios de comunicação com o servidor de origem.
14,8 Autorização
Um agente de usuário que deseja se autenticar com um servidor –
normalmente, mas não necessariamente, depois de receber uma resposta 401 – não
então, incluindo um campo de cabeçalho de pedido de autorização com a
pedido. O valor do campo Authorization consiste de credenciais
contendo as informações de autenticação do agente do usuário para
no reino do recurso que está sendo solicitado.
Autorização = “Autorização”: “credenciais
HTTP de autenticação de acesso é descrito em “Autenticação HTTP:
Access Basic e Digest Authentication “[43]. Se o pedido for
autenticado e um domínio especificado, as credenciais do mesmo deverá
ser válido para todas as outras solicitações, dentro deste reino (supondo que
o esquema de autenticação em si não exigirem o contrário, como
as credenciais que variam de acordo com um valor de desafio ou usando
relógios sincronizados).
Quando um cache compartilhado (ver secção 13.7) recebe uma solicitação
contendo um campo de autorização, não deve retornar a
correspondente resposta como uma resposta a qualquer solicitação, a não ser uma
das seguintes exceções específicas detém:
1. Se a resposta inclui o “s-maxage” cache-control
directiva, o cache de utilização de Maio, que a resposta em resposta a uma
pedido subsequente. Mas (se a idade máxima especificada tem
passado) um proxy cache deve revalidar primeiro com a origem
servidor, usando o pedido de cabeçalhos a partir do novo pedido a fim de permitir
origem do servidor para autenticar o novo pedido. (Esta é a
comportamento definido para maxage s). Se a resposta for “s-
maxage = 0 “, o proxy deve revalidar sempre antes de re-uso
ele.
2. Se a resposta inclui o “must-revalidar” o controle de cache
directiva, o cache de utilização de Maio, que a resposta em resposta a uma
pedido subsequente. Mas se a resposta for velho, todos os caches
Primeiro deve revalidar com o servidor de origem, utilizando o
solicitação de cabeçalhos a partir do novo pedido para permitir que o servidor de origem
para autenticar o novo pedido.
3. Se a resposta inclui o “público” diretiva de controle de cache,
ela pode ser devolvida em resposta a qualquer pedido posterior.
Fielding, et al. Standards Track [Página 107]
?
HTTP/1.1 RFC 2616 junho 1999
14,9 Cache Control-
O Cache-Control campo de cabeçalho geral é usado para especificar as directivas
que devem ser obedecidas por todos os mecanismos de cache ao longo da
pedido cadeia / resposta. As directivas especificam o comportamento destina-se a
evitar caches de interferir negativamente com o pedido ou
a resposta. Estas directivas tipicamente substituir o padrão de cache
algoritmos. directivas Cache são unidirecionais, em que a presença
de uma directiva de um pedido não significa que a mesma directiva é
a ser dada na resposta.
Note-se que caches HTTP/1.0 não pode implementar Cache-Control e
só poderia aplicar Pragma: no-cache (ver secção 14,32).
directivas de cache deve ser passada através de um proxy ou gateway
aplicação, independentemente da sua importância a esse pedido,
vez que as directivas possam ser aplicáveis a todos os destinatários ao longo do
pedido cadeia / resposta. Não é possível especificar um cache
directiva para um cache específico.
Cache-Control = “Cache-Control”: “1 # cache-diretiva
directiva cache = cache-request-diretiva
| Resposta cache-diretiva
cache pedido directiva =
“No-cache”; Seção 14.9.1
| “No-store”, Seção 14.9.2
| “Max-idade” = “delta-segundos; Seção 14.9.3, 14.9.4
| “Max-velho” [= “] delta segundos, Seção 14.9.3
| “Min-fresca” = “delta-segundos; Seção 14.9.3
| “Não transformar”, Seção 14.9.5
| “Only-if-cache”, Seção 14.9.4
| Cache extensão; Seção 14.9.6
cache-resposta directiva =
“Público”, Seção 14.9.1
| “[” Privado “=” “> <1 # <nome do campo”>], Seção 14.9.1
| “No-cache” [“=” “> <1 # <nome do campo”>]; Seção 14.9.1
| “No-store”, Seção 14.9.2
| “Não transformar”, Seção 14.9.5
| “Deve-revalidar”, Seção 14.9.4
| “Proxy-revalidar”, Seção 14.9.4
| “Max-idade” = “delta-segundos; Seção 14.9.3
| “S-maxage” = “delta-segundos; Seção 14.9.3
| Cache extensão; Seção 14.9.6
extensão de cache = [símbolo “=” (token | citou-corda)]
Fielding, et al. Standards Track [Página 108]
?
HTTP/1.1 RFC 2616 junho 1999
Quando uma directiva aparece sem um parâmetro # nome do campo, o
directiva aplica-se o pedido na totalidade ou resposta. Quando um desses
directiva aparece com um nome de um parâmetro de campo #, ele só se aplica aos
o campo com o nome ou campos, e não para o resto do pedido ou
a resposta. Este mecanismo suporta a extensibilidade, implementações de
Versões futuras do protocolo HTTP pode aplicar essas diretrizes
campos de cabeçalho não definidos no HTTP/1.1.
As diretrizes de controle de cache pode ser quebrada nestes geral
categorias:
– Restrições sobre o que está armazenado em cache, estes só podem ser impostas por
origem do servidor.
– Restrições sobre o que pode ser armazenado por um cache, que podem ser
impostas tanto pela origem do servidor ou agente do usuário.
– Alterações do mecanismo de vencimento básico, que poderão ser
impostas tanto pela origem do servidor ou agente do usuário.
– Controla mais de revalidação cache e recarregar; estes só podem ser
imposta por um agente do usuário.
– Controle sobre a transformação de entidades.
– Extensões para o sistema de cache.
14.9.1 O que é Cacheable
Por padrão, a resposta é cacheable se os requisitos da
método de requisição, pedido campos de cabeçalho, eo status da resposta
indicar que ele está armazenado em cache. Seção 13.4 resume esses padrões
para cacheability. As directivas seguinte resposta Cache-Control
permitir que um servidor de origem para substituir o padrão de um cacheability
resposta:
público
Indica que a resposta pode ser armazenado por qualquer cache, mesmo que
normalmente não cacheable ou cacheable somente dentro de um não-
cache compartilhado. (Veja também a autorização, secção 14.8, para
detalhes adicionais.)
privado
Indica que a totalidade ou parte da mensagem de resposta se destina a
um único usuário e não deve ser armazenada por um cache compartilhado. Este
permite que um servidor de origem para indicar que as partes específicas do
Fielding, et al. Standards Track [Página 109]
?
HTTP/1.1 RFC 2616 junho 1999
resposta são destinados a um único usuário e não são válidos
resposta às solicitações de outros usuários. Uma memória cache (não compartilhada) privado
MAIO cache a resposta.
Nota: Este uso da palavra privado controla apenas quando o
resposta pode ser armazenada em cache, e não pode garantir a privacidade do
conteúdo da mensagem.
sem cache
Se a diretiva no-cache não especificar um campo nome, então um
cache não deve usar a resposta para satisfazer um pedido posterior
sem sucesso com a revalidação do servidor de origem. Este
permite que um servidor de origem para evitar o cache, mesmo que por caches
foram configurados para retornar respostas obsoleto às solicitações do cliente.
Se a diretiva no-cache não especificar um ou mais nomes de domínio,
então um cache pode usar a resposta para satisfazer um pedido subsequente,
sujeita a outras restrições de cache. No entanto, o
determinado campo de nome (s) não deve ser enviado em resposta a um
posterior pedido de revalidação, sem sucesso com a origem
servidor. Isso permite que um servidor de origem para evitar a reutilização de
certos campos de cabeçalho de uma resposta, permitindo ainda o cache
do resto da resposta.
Nota: A maioria das caches HTTP/1.0 não reconhecerá ou obedecer a essa
directiva.
14.9.2 O que pode ser armazenado por Caches
no interior da loja
O objectivo da directiva nenhuma loja é para evitar a
liberação involuntária ou a retenção de informações sensíveis (por
exemplo, em fitas de backup). A directiva não se aplica ao armazenamento de
mensagem inteira, e podem ser enviadas em uma resposta ou uma
pedido. Se enviou um pedido, um cache não deve armazenar qualquer parte do
qualquer pedido deste ou de qualquer resposta. Se enviou uma resposta,
um cache NÃO DEVE armazenar qualquer parte de qualquer resposta a este ou
solicitar que ela suscitou. Esta directiva aplica-se tanto não
compartilhado e um cachê. “Loja NÃO DEVE” neste contexto significa
que o cache não deve intencionalmente armazenar as informações em
armazenamento não-volátil, e deve fazer uma tentativa de melhor esforço para
remover as informações de armazenamento volátil com a maior brevidade
possível após a sua transmissão.
Mesmo quando esta directiva está associada com uma resposta, os usuários
pode armazenar explicitamente uma resposta tão fora do cache
sistema (por exemplo, com um “Salvar como” caixa de diálogo). História buffers loja pode
respostas, como parte de sua operação normal.
Fielding, et al. Standards Track [Página 110]
?
HTTP/1.1 RFC 2616 junho 1999
O objectivo desta directiva é o de satisfazer os requisitos previstos
de determinados utilizadores e autores de serviços que estão preocupados com
liberações acidentais de informações através de acessos para imprevistos
estruturas de dados de cache. Embora a utilização da presente directiva pode
melhorar a privacidade em alguns casos, o cuidado que ele não está em nenhum
forma de um mecanismo confiável e suficiente para garantir a privacidade. Em
particular, mal-intencionado ou comprometido caches podem não reconhecer ou
obedecer a esta directiva, e redes de comunicações podem ser
vulneráveis à espionagem.
14.9.3 Modificações do Mecanismo de Vencimento Básico
O tempo de expiração de uma entidade podem ser especificadas pela origem
servidor usando o cabeçalho Expires (ver secção 14,21). Como alternativa,
Pode ser especificado usando a diretiva máximo de idade em uma resposta. Quando
a idade max-diretiva de controle de cache está presente em uma resposta em cache,
a resposta é velho, se a sua idade atual é maior do que a idade
determinado valor (em segundos) na hora de um novo pedido para que
recursos. A directiva máximo de idade em uma resposta implica que o
resposta é cacheable (ie, “público”) a menos que algum outro, mais
directiva cache restritivas também está presente.
Se a resposta inclui um cabeçalho Expires e max idade
, a Directiva máximo de idade substitui o cabeçalho Expires, mesmo
se o cabeçalho Expires é mais restritiva. Essa regra permite que uma origem
servidor para fornecer, de uma resposta dada, um tempo de validade para
HTTP/1.1 um cache (ou superior) do que para um cache HTTP/1.0. Isso pode ser
útil se os caches HTTP/1.0 certos indevidamente calcular idades ou
tempos de expiração, talvez devido ao relógio dessincronizado.
Muitas implementações de cache do HTTP/1.0 tratará um valor que expira
é inferior ou igual ao valor de resposta Data como sendo equivalente
da directiva resposta Cache-Control “no-cache”. Se um HTTP/1.1
cache receber tal resposta, ea resposta não inclui um
Cache-Control campo de cabeçalho, deve considerar a resposta a ser
não cacheable para manter a compatibilidade com servidores HTTP/1.0.
Nota: Um servidor de origem pode querer usar um HTTP relativamente novo
recurso de cache de controle, tais como a directiva “privado, numa
rede, incluindo caches velhos que não entendem que
característica. O servidor de origem, será necessário combinar o novo recurso
com um campo Expires cujo valor seja igual ou inferior ao
Valor Data. Isto irá prevenir de caches velhos indevidamente
cache a resposta.
Fielding, et al. Standards Track [Página 111]
?
HTTP/1.1 RFC 2616 junho 1999
maxage s-
Se a resposta inclui uma directiva maxage s, depois de um comum
cache (mas não para um cache privado), a idade máxima especificada pelo
presente directiva substitui a idade máxima especificada nem pela
directiva max idade ou o cabeçalho Expires. O s maxage-directiva
implica também a semântica da directiva-proxy revalidar (ver
seção 14.9.4), ou seja, que o cache compartilhado não deve usar o
após a entrada torna-se obsoleto para responder a uma solicitação subseqüente
sem primeiro revalidação com o servidor de origem. A s-
maxage directiva é sempre ignorado por um cache privado.
Note que a maioria das caches mais velhos, não compatível com esta especificação,
não aplicar quaisquer directivas controle de cache. Um servidor de origem
pretenda utilizar uma diretiva de controle de cache, que restringe, mas não
evitar, por um cache de cache compatíveis com HTTP/1.1 pode explorar o
exigência de que a directiva máximo de idade substitui o cabeçalho Expires,
eo facto de caches pre-HTTP/1.1-compliant não observar o
directiva max idade.
Outras directivas permitem um agente do usuário para modificar o vencimento básico
mecanismo. Estas directivas podem ser especificados em um pedido:
max idade
Indica que o cliente está disposto a aceitar uma resposta cuja
idade não é maior do que o tempo especificado em segundos. Salvo-max
directiva obsoleto também está incluído, o cliente não está disposto a
aceitar uma resposta obsoleto.
min-doce
Indica que o cliente está disposto a aceitar uma resposta cuja
o frescor da vida é nada menos que sua idade atual mais o
tempo especificado em segundos. Ou seja, o cliente quer uma resposta
que será ainda fresca durante pelo menos o número especificado de
segundos.
max-velho
Indica que o cliente está disposto a aceitar uma resposta que tem
excedeu o seu tempo de validade. Se max-velho é atribuído um valor,
em seguida, o cliente está disposto a aceitar uma resposta que tenha ultrapassado
seu tempo de validade, por mais que o número especificado de
segundos. Se nenhum valor é atribuído a Max-velho, o cliente é
dispostos a aceitar uma resposta obsoleto de qualquer idade.
Se um cache retorna uma resposta obsoleto, por causa de um max-velho
directiva relativa a um pedido, ou porque o cache está configurado para
substituir o tempo de expiração de uma resposta, o cache deve anexar um
Aviso de cabeçalho para a resposta obsoleto, utilizando Aviso 110 (A resposta é
obsoleto).
Fielding, et al. Standards Track [Página 112]
?
HTTP/1.1 RFC 2616 junho 1999
A cache pode ser configurado para retornar respostas obsoletos sem
validação mas apenas se este não entre em conflito com qualquer DEVE “nível
requisitos relativos à validação de cache (por exemplo, um “must-revalidar”
controle de cache-directiva).
Se ambos a pedido do novo e da entrada em cache incluem idade “max”
directivas, o menor dos dois valores é usado para determinar
o frescor da entrada de cache para esse pedido.
14.9.4 Revalidação Cache e Controles Atualizar
Às vezes, um agente do usuário pode querer ou precisar de insistir que um cache
revalidar a sua entrada no cache com o servidor de origem (e não apenas com
o cache próximo ao longo do caminho para o servidor de origem), ou para recarregar as suas
entrada de cache do servidor de origem. revalidação Fim-de-final pode ser
necessário se quer ou o cache do servidor de origem tem superestimado
o tempo de expiração da resposta em cache. Atualizar Fim-de-final pode ser
necessário se a entrada de cache foi corrompido por algum motivo.
revalidação End-to-end podem ser solicitadas ou quando o cliente faz
não ter sua própria cópia local em cache, caso em que nós chamamos
“Revalidação de ponta a ponta não especificado”, ou quando o cliente não tem uma
cópia em cache local, caso em que o chamam de “fim específico-de-final
revalidação “.
O cliente pode especificar esses três tipos de ação usando Cache-
pedido directivas de controlo:
Atualizar Fim-de-final
O pedido inclui um “sem-cache” diretiva de controle de cache, ou, para
compatibilidade com os clientes HTTP/1.0 “Pragma: no-cache”. Campo
nomes não devem ser incluídos com a diretiva no-cache em um
pedido. O servidor não deve usar uma cópia armazenada em cache quando responder a
tal pedido.
revalidação end-to-end específico
O pedido inclui um “max-age = 0” diretiva de controle de cache, que
forças de cada cache ao longo do caminho para o servidor de origem para
revalidar a sua própria entrada, se houver, com o cache próximo ou servidor.
O pedido inicial inclui um cache-validação condicional com
validador atual do cliente.
Unspecified revalidação fim-de-final
O pedido inclui a “idade-max = 0” diretiva de controle de cache, que
forças de cada cache ao longo do caminho para o servidor de origem para
revalidar a sua própria entrada, se houver, com o cache próximo ou servidor.
O pedido inicial não inclui uma cache de validação
Fielding, et al. Standards Track [Página 113]
?
HTTP/1.1 RFC 2616 junho 1999
condicional; a primeira cache ao longo do caminho (se houver) que detém uma
entrada de cache para esse recurso inclui um cache-validação
condicional com seu validador atual.
max idade
Quando um cache intermediário é forçado, por meio de um max-age = 0
directiva, para revalidar a sua própria entrada de cache, eo cliente tem
forneceu o seu próprio validador do pedido, o validador fornecido
pode diferir do validador atualmente armazenados com o cache
entrada. Neste caso, o cache pode usar um validador para fazer
seu pedido, sem afetar a transparência semântica.
No entanto, a escolha do validador pode afetar o desempenho. O
melhor abordagem para o cache intermediário para usar suas próprias
validador quando do seu requerimento. Se o servidor responde com 304
(Not Modified), então o cache pode retornar a sua cópia agora validada
para o cliente com um 200 (OK resposta). Se o servidor responde com
uma nova entidade e validador cache, no entanto, o cache intermediário
Pode comparar o validador retornou com o previsto no
o pedido do cliente, utilizando a função de comparação forte. Se o
validador do cliente é igual ao servidor de origem, então o
cache intermediário simplesmente retorna 304 (Not Modified). Caso contrário,
ele retorna a nova entidade com um 200 (OK resposta).
Se o pedido inclui a diretiva no-cache, não deve
incluir min doce, max-velho, ou máximo de idade.
only-if-cache
Em alguns casos, tais como tempos de rede extremamente pobres
conectividade, um cliente pode querer um cache para retornar somente os
respostas que ele tem armazenado e não precisa recarregar ou
revalidação com o servidor de origem. Para fazer isso, o cliente pode
incluir a directiva só-se-cache em uma solicitação. Se ele recebe
presente directiva, um cache deve ou responder usando uma entrada de cache
que é consistente com as outras restrições do pedido, ou
responder com um status 504 (Gateway Timeout). No entanto, se um grupo
de caches está sendo operado como um sistema unificado com bom interno
conectividade, como um pedido pode ser enviado dentro desse grupo de
caches.
deve-revalidar
Como um cache pode ser configurado para ignorar um servidor especificado
tempo de expiração, e porque uma solicitação do cliente pode incluir um max-
directiva velho (que tem um efeito semelhante), o protocolo também
inclui um mecanismo para o servidor de origem para solicitar a revalidação
de uma entrada de cache sobre qualquer uso subseqüente. Quando deve-revalidar
directiva está presente em uma resposta recebida por um cache, que cache
NÃO DEVE usar a entrada após tornar-se obsoleto para responder a uma
Fielding, et al. Standards Track [Página 114]
?
HTTP/1.1 RFC 2616 junho 1999
pedido subsequente sem primeiro revalidação com a origem
servidor. (Ou seja, o cache deve fazer uma revalidação de ponta a ponta a cada
tempo, se, com base unicamente na Expira o servidor de origem ou máximo de idade
valor, a resposta em cache é obsoleto).
A directiva deve-revalidar é necessário um apoio contínuo
operação de certas características do protocolo. Em todas as circunstâncias um
HTTP/1.1 cache deve obedecer a dever-revalidar directiva, em
particular, se o cache não pode alcançar o servidor de origem para qualquer
motivo, é preciso gerar uma resposta 504 (Gateway Timeout).
Os servidores devem enviar o must-revalidar directiva se e somente se
falta de revalidar um pedido à entidade poderia resultar em
mau funcionamento, como um silêncio unexecuted financeira
transação. Os destinatários não devem tomar qualquer ação automatizada que
viole a presente directiva, e não devem fornecer automaticamente uma
unvalidated cópia da revalidação, a entidade se falhar.
Embora isso não seja recomendado, os agentes que operam sob
restrições de conectividade grave pode violar esta directiva, mas, se
assim, deve explicitamente avisar o usuário que tem uma resposta unvalidated
foram fornecidas. O aviso deve ser fornecido em cada unvalidated
acesso, e deve exigir a confirmação explícita do usuário.
proxy-revalidar
A directiva-proxy revalidar tem o mesmo significado que deve-
revalidar directiva, exceto que ela não se aplica a não-compartilhados
agente caches usuário. Pode ser usado em uma resposta a uma
solicitação autenticado para permitir cache do usuário para armazenar e
depois retornar a resposta sem a necessidade de revalidar-lo (desde
que já foi autenticado por uma vez que o usuário), mas ainda
proxies exigem que muitos usuários do serviço de revalidação de cada vez
(A fim de certificar-se de que cada usuário tenha sido autenticado).
Note-se que tais respostas autenticado também a necessidade de cache público
diretiva de controle, a fim de permitir que sejam armazenadas em cache em tudo.
14.9.5 No-Transform Directiva
não transformar-
Os implementadores de caches intermediários (proxies) acharam útil
para converter o tipo de mídia da entidade determinados organismos. A não-
proxy transparente pode, por exemplo, converter entre a imagem
formatos, a fim de economizar espaço em cache ou para reduzir a quantidade de
tráfego em uma conexão lenta.
Problemas operacionais graves ocorrem, porém, quando estes
transformações são aplicadas a entidade órgãos destinados a certas
tipos de aplicações. Por exemplo, os pedidos de médico
Fielding, et al. Standards Track [Página 115]
?
HTTP/1.1 RFC 2616 junho 1999
de imagem, análise de dados científicos e aqueles que utilizam fim-de-final
autenticação, todos dependem de receber um corpo de entidade que é pouco
bit para idêntico ao original entidade corpo.
Portanto, se uma mensagem inclui a não transformar-directiva, uma
proxy cache intermédia ou não deve alterar os cabeçalhos que estão
enumerados no ponto 13.5.2 como estando sujeitas a não transformar-
directiva. Isto implica que o cache ou proxy não deve alterar
qualquer aspecto da entidade corpo-que é especificada por esses cabeçalhos,
incluindo o valor da entidade corpo-próprio.
14.9.6 Extensões para Controle de Cache
O campo de cabeçalho Cache-Control pode ser alargado através da utilização de um
ou mais tokens extensão cache, cada uma com um valor opcional atribuído.
extensões Informativos (aqueles que não exigem uma mudança na
comportamento cache) podem ser adicionados sem alterar a semântica do outro
directivas. extensões comportamentais são projetados para funcionar, agindo como
modificadores para a base existente de directivas cache. Tanto o novo
ea Directiva padrão são fornecidos, de tal forma que
aplicações que não entendem a nova directiva padrão
para o comportamento especificado pela directiva padrão, e aqueles que
compreender a nova directiva irá reconhecê-lo como modificar o
necessidades relacionadas com a directiva padrão. Desta forma,
extensões para as directivas de controle de cache pode ser feita sem
exigindo alterações no protocolo base.
Este mecanismo de extensão depende de uma cache HTTP obedecendo todas as
directivas de controlo de cache definida para seus nativos HTTP versão, obedecendo
determinadas extensões, e ignorando todas as directivas que não
compreender.
Como exemplo, considere uma directiva resposta hipotética nova chamada
comunidade que atua como um modificador da directiva privado. Nós
definir esta nova directiva no sentido de que, para além de qualquer não-compartilhados
cache, qualquer cache que é compartilhado apenas por membros da comunidade
chamada no seu valor pode cache a resposta. Um servidor de origem
desejando que permitam à comunidade UCI usar um outro modo privado
resposta em seu cache compartilhado (s) poderá fazê-lo, incluindo
Cache-Control: comunidade privada = “UCI”
A cache vendo este campo irá agir corretamente, mesmo se o cache
não compreende a comunidade cache extensão, uma vez que também
ver e compreender a directiva privado e, portanto, padrão para o seguro
comportamento.
Fielding, et al. Standards Track [Página 116]
?
HTTP/1.1 RFC 2616 junho 1999
Unrecognized cache-directivas devem ser ignorados; presume-se que qualquer
directiva-cache susceptível de ser reconhecido por um cache vai HTTP/1.1
ser combinado com as diretrizes padrão (ou padrão de resposta do
cacheability) tal que o comportamento do cache permanecerá minimamente
correctos, mesmo se o cache não compreende a extensão (s).
Conexão 14,10
O campo de cabeçalho Connection-geral permite ao remetente especificar
opções que são desejadas para esse propósito específico e não deve
ser comunicadas por proxies em conexões mais.
O cabeçalho Connection tem a seguinte gramática:
Connection = “Conexão”: “1 # (conexão token)
conexão token token =
HTTP/1.1 procuradores deverão analisar o campo de cabeçalho Connection antes de uma
mensagem é transmitida e, para cada conexão token neste domínio,
eliminar qualquer campo de cabeçalho (s) da mensagem com o mesmo nome que o
conexão token. As opções de conexão são sinalizados pela presença de
uma conexão token no campo de cabeçalho Connection, e não por qualquer
campo de cabeçalho adicional correspondente (s), desde o cabeçalho adicional
campo não pode ser enviado se não há parâmetros associados a esse
opção de conexão.
cabeçalhos de mensagens listadas no cabeçalho Connection não deve incluir
fim-de-final cabeçalhos, como Cache-Control.
HTTP/1.1 define a opção “ligação estreita” para o remetente
sinal de que a conexão será encerrada após a conclusão do
a resposta. Por exemplo,
Connection: close
em qualquer pedido ou a campos de cabeçalho de resposta indica que
a ligação não deve ser considerada «persistente” (seção 8.1)
após a solicitação atual / resposta é completa.
HTTP/1.1 aplicações que não suportam conexões persistentes DEVE
incluir a opção “ligação estreita” em cada mensagem.
Um sistema que recebe um HTTP/1.0 (ou versão anterior) mensagem que
inclui um cabeçalho Connection deve, para cada conexão token neste
campo, remover e ignorar qualquer campo de cabeçalho (s) da mensagem com
o mesmo nome que a conexão token. Isso protege contra enganado
encaminhamento de tais campos do cabeçalho por pre-HTTP/1.1 proxies. Consulte a seção
19.6.2.
Fielding, et al. Standards Track [Página 117]
?
HTTP/1.1 RFC 2616 junho 1999
14,11 Content-Encoding
O Content-Encoding cabeçalho campo entidade é usado como um modificador do
tipo de mídia. Quando presente, o seu valor indica o conteúdo adicional
códigos foram aplicados à entidade corpo e, portanto, que a decodificação
mecanismos devem ser aplicadas a fim de obter o tipo de mídia
referenciado pelo campo de cabeçalho Content-Type. Content-Encoding é
usado principalmente para permitir que um documento para ser compactado sem perder
a identidade do seu tipo de mídia subjacente.
Content-Encoding = “Content-Encoding”: “1 # content-coding
codificações de conteúdo são definidos no ponto 3.5. Um exemplo de sua utilização é
Content-Encoding: gzip
O conteúdo de codificação é uma característica da entidade identificada por
Pedido-URI. Normalmente, a entidade do corpo é armazenada com este
codificação e só é decodificada antes do processamento ou utilização análoga.
No entanto, um proxy transparente não pode modificar o conteúdo de codificação, se o
nova codificação é conhecida por ser aceite pelo beneficiário, excepto se o
“Não transformar a” diretiva de controle de cache está presente na mensagem.
Se o conteúdo de codificação de uma entidade não é “identidade”, o
Resposta deve incluir um Content-Encoding cabeçalho da entidade (secção
14,11), que lista os não-identidade de conteúdo de código (s) utilizado.
Se o conteúdo de codificação de uma entidade em uma mensagem de pedido não é
aceitáveis para o servidor de origem, o servidor deve responder com um
código de status 415 (Unsupported Media Type).
Se codificações múltiplas foram aplicadas a uma entidade, o conteúdo
códigos devem ser listados na ordem em que foram aplicadas.
Informações adicionais sobre a codificação parâmetros podem ser fornecidos
por outros campos do cabeçalho entidade não definidas por esta especificação.
14,12 Content Language-
O Content-Language campo de cabeçalho entidade descreve o natural
língua (s) da audiência destinada à entidade fechada. Nota
que isto não poderia ser equivalente a todas as línguas utilizadas no
a entidade do corpo.
Content-Language = “Content-Language”: “uma linguagem tag #
Fielding, et al. Standards Track [Página 118]
?
HTTP/1.1 RFC 2616 junho 1999
Language tags são definidas no ponto 3.10. O objetivo principal do
Content-Language é permitir ao usuário identificar e diferenciar
entidades de acordo com o próprio idioma preferido do usuário. Assim, se o
corpo de conteúdos é destinado apenas para uma audiência dinamarquesa-alfabetizados, o
campo apropriado é
Content-Language: da
Se não Content-Language for especificado, o padrão é que o conteúdo
destina-se a todos os públicos língua. Isso pode significar que o
remetente não considera que seja específica para qualquer língua natural,
ou que o remetente não sabe para qual a linguagem que se destina.
Vários idiomas podem ser listados para o conteúdo que se destina a
várias audiências. Por exemplo, uma versão do “Tratado de
Waitangi “, apresentado simultaneamente no original Maori e Inglês
versões, exigiria
Content-Language: mi, en
Entretanto, apenas porque vários idiomas estão presentes dentro de uma entidade
não significa que se destina a vários públicos linguística.
Um exemplo seria o primer de um novato linguagem, como “A Primeira
Lição em latim, “o que é claramente destinado a ser utilizado por um
audiência Inglês-alfabetizados. Neste caso, o Content-Language seria
devidamente incluir apenas “en”.
Content-Language pode ser aplicado a qualquer tipo de mídia – não é
limitado a documentos textuais.
14,13 teor de comprimento
O Content-Length campo de cabeçalho entidade que indica o tamanho da
corpo da entidade, em número decimal de octetos, enviado para o destinatário ou,
No caso do método HEAD, o tamanho do corpo da entidade que
teria sido enviado se o pedido tivesse sido um GET.
Content-Length = “Content-Length”: “1 * DIGIT
Um exemplo é
Content-Length: 3495
As candidaturas deverão utilizar este campo para indicar a transferência de comprimento de
o corpo da mensagem, a menos que isso é proibido pelas regras da secção
4.4.
Fielding, et al. Standards Track [Página 119]
?
HTTP/1.1 RFC 2616 junho 1999
Qualquer Content-Length maior ou igual a zero é um valor válido.
Seção 4.4 descreve como determinar o comprimento de uma mensagem do corpo
Se um Content-Length não é dado.
Note que o significado deste campo é significativamente diferente do
a definição correspondente em MIME, onde é um campo opcional
utilizado na mensagem “/ externo-corpo” tipo de conteúdo. Em HTTP, ele
Deve ser enviado sempre que o comprimento da mensagem pode ser determinada antes
para ser transferido, a menos que seja proibido pelas regras em
secção 4.4.
14,14 Content-Location
O cabeçalho Content-Location entidade-campo pode ser utilizado para fornecer o
localização de recursos para a entidade fechada na mensagem de que quando
entidade é acessível a partir de um local separado da requerida
URI recurso. O servidor deve fornecer um Content-Location para o
variação correspondente a resposta da entidade, especialmente no caso
Sempre que um recurso tem várias entidades associadas a ela, e os
entidades realmente têm posições distintas através das quais puderam ser
acessados individualmente, o servidor deve fornecer um Content-Location
para a variante particular, que é devolvido.
Conteúdo Local = “Conteúdo Local”: “
(AbsoluteURI | relativeURI)
O valor do Conteúdo Local, também define a URI base para o
entidade.
O valor Content-Location não é um substituto para o original
URI solicitado, é apenas uma indicação da localização dos recursos
correspondente a esta entidade particular no momento do pedido.
pedidos futuro pode especificar o URI Content-Location que o pedido de-
URI se o desejo é o de identificar a origem desse particular
entidade.
A cache não pode assumir que uma entidade com um Content-Location
diferente da URI usada para recuperá-lo pode ser usado para responder a
mais tarde, em que solicita URI Content-Location. No entanto, o Content-
Localização pode ser usado para diferenciar entre várias entidades
Obtido a partir de um único recurso solicitado, conforme descrito na secção
13.6.
Se o Content-Location é uma URI relativa, o URI relativo é
interpretado com relação ao Pedido-URI.
O significado do cabeçalho Content-Location de PUT ou pedidos POST
indefinido, e os servidores estão livres para ignorá-lo nesses casos.
Fielding, et al. Standards Track [Página 120]
?
HTTP/1.1 RFC 2616 junho 1999
14,15 Content-MD5
O Content-MD5 campo de cabeçalho entidade, conforme definido na RFC 1864 [23], é
um MD5 da entidade corpo com a finalidade de proporcionar um
fim-de-final de seleção de integridade (MIC) da entidade corpo. (Nota: a
MIC é bom para a detecção de modificação acidental da entidade corpo-
em trânsito, mas não é à prova de ataques maliciosos.)
Content-MD5 = “Content-MD5”: “md5-digest
md5-digest = <base64 MD5 de 128 bits digerir como por RFC 1864>
O cabeçalho Content-MD5 campo pode ser gerado por um servidor de origem ou
cliente para funcionar como uma verificação de integridade da entidade corpo. Apenas
servidores de origem ou de clientes pode gerar o campo de cabeçalho Content-MD5;
proxies e gateways NÃO DEVE gerá-lo, pois isso iria contra o
valor como uma verificação de integridade fim-de-final. Qualquer beneficiário da entidade,
corpo, incluindo gateways e proxies, que o cheque pode digerir valor
neste campo de cabeçalho corresponde ao da entidade do corpo tal como foi recebido.
O MD5 é calculado com base no conteúdo da entidade corpo,
incluindo qualquer conteúdo de codificação que foi aplicada, mas não incluindo
qualquer transferência de codificação aplicada ao corpo da mensagem. Se a mensagem for
recebido com uma transferência de codificação, que a codificação deve ser removido
antes de verificar o valor MD5 Content-contra a entidade recebeu.
Isso tem como resultado que o resumo é calculado sobre os octetos do
corpo, exatamente como entidade, e na ordem em que, eles seriam enviados se
nenhuma transferência de codificação, foram sendo aplicadas.
HTTP estende RFC 1864 para permitir a digerir a ser computado para MIME
composto mídias (por exemplo, multipart / * e message/rfc822), mas
isso não muda a forma como a digerir é calculado conforme definido no
parágrafo anterior.
Há várias conseqüências disso. A entidade corpo-de compósitos
tipos podem conter muitas partes do corpo, cada um com sua própria MIME e HTTP
cabeçalhos (incluindo Content-MD5, Content-Transfer-Encoding e
Content-Encoding cabeçalho). Se uma parte do corpo tem um Content-Transfer-
Codificação ou cabeçalho Content-Encoding, presume-se que o conteúdo
da parte do corpo, teve a aplicação de codificação, ea parte do corpo é
incluído no Content-MD5 como é – ou seja, após o
pedido. O campo de cabeçalho Transfer-Encoding não é permitido dentro
corpo-peças.
A conversão de todas as quebras de linha para CRLF não deve ser feito antes
computação ou verificar a digerir: a Convenção de quebra de linha usada em
o texto realmente transmitida deve ser deixada inalterada quando a computação
a digerir.
Fielding, et al. Standards Track [Página 121]
?
HTTP/1.1 RFC 2616 junho 1999
Nota: embora a definição de Content-MD5 é exatamente o mesmo para
HTTP como no RFC 1864 para a entidade MIME-corpos, existem várias maneiras
em que o pedido de Content-MD5 a entidade HTTP-corpos
difere da sua aplicação a entidade MIME-corpos. Uma delas é que
HTTP, MIME ao contrário, não utilizar o Content-Transfer-Encoding e
usa Transfer-Encoding e Content-Encoding. Outra é que
HTTP mais freqüentemente usa tipos de conteúdo binário de MIME, por isso é
notar que, nesses casos, a ordem de byte usado para calcular
o resumo é a ordem de transmissão byte definido para o tipo.
Por último, HTTP permite a transmissão de tipos de texto com qualquer um dos vários
convenções quebra de linha e não apenas a forma canónica usando CRLF.
14,16 Content-Range
O Content-Range entidade cabeçalho é enviado com um parcial entidade corpo-a
especificar onde no total entidade corpo-corpo deve ser parcial
aplicada. Faixa de unidades estão definidos no ponto 3.12.
Content-Range = “Content-Range”: “gama de conteúdos de spec
conteúdo gama spec = byte com conteúdo gama-spec
byte-conteúdo-range spec = bytes unidade-SP
byte-gama-resp-spec “/”
(| Prazo de instância “*”)
byte-gama-resp-spec = (primeiro byte-pos “-” no último byte-pos)
| * “
Prazo de instância = 1 * DIGIT
O cabeçalho deve indicar o comprimento total do corpo inteiro entidade,
a menos que essa extensão é desconhecida ou difícil de determinar. O asterisco
“*” Caráter significa que a instância de comprimento é desconhecido no momento
quando a resposta foi gerada.
Ao contrário de valores byte varia especificador (ver secção 14.35.1), um byte-
gama-resp-spec deve especificar apenas um intervalo e deve conter
absoluto para ambos os cargos byte byte a primeira ea última do
intervalo.
Um byte com conteúdo gama-spec com uma gama-byte-resp-spec, cuja última
valor de byte-pos é inferior ao seu valor do primeiro byte-pos, ou cuja
valor de comprimento de instância inferior ou igual ao último byte-pos
, o valor é inválido. O destinatário de um byte nulo de conteúdo gama-
spec deve ignorá-lo e qualquer conteúdo transferido junto com ele.
Um servidor de envio de uma resposta com o código de status 416 (faixa não solicitadas
satisfatível) deve incluir um campo Content-Range com um intervalo de byte-
resp-spec de “*”. A instância de comprimento especifica o comprimento atual da
Fielding, et al. Standards Track [Página 122]
?
HTTP/1.1 RFC 2616 junho 1999
o recurso selecionado. A resposta com o código de status 206 (parcial
Content) não deve incluir um campo Content-Range com um intervalo de byte-
resp-spec de “*”.
Exemplos de bytes de conteúdo os valores de gama-spec, supondo que a entidade
contém um total de 1234 bytes:
. Os primeiros 500 bytes:
bytes 0-499/1234
. O segundo 500 bytes:
500-999/1234 bytes
. Todos, exceto para os primeiros 500 bytes:
bytes 500-1233/1234
. Os últimos 500 bytes:
bytes 734-1233/1234
Quando uma mensagem HTTP inclui o conteúdo de um único intervalo (por
exemplo, uma resposta a um pedido de um único intervalo, ou a um pedido
por um conjunto de intervalos que se sobrepõem sem buracos), esse conteúdo é
enviado com um cabeçalho Content-Range, e um cabeçalho Content-Length
mostrando o número de bytes transferidos. Por exemplo,
HTTP/1.1 206 Conteúdo parcial
Date: Wed, 15 de novembro de 1995 06:25:24 GMT
Last-Modified: Wed, 15 nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image / gif
Quando uma mensagem HTTP inclui o conteúdo de vários intervalos (por
exemplo, uma resposta a um pedido de múltipla não se sobrepõem
séries), estas são transmitidas como uma mensagem concatenada. O multipart
tipo de mídia utilizado para esta finalidade é “multipart / byteranges”, conforme definido
em 19,2 apêndice. Veja o apêndice 19.6.3 para um problema de compatibilidade.
Uma resposta a um pedido de uma única faixa não deve ser enviada através do
multipart / byteranges tipo de mídia. Uma resposta a um pedido de
vários intervalos, cujo resultado é uma gama única, pode ser enviado como um
multipart / byteranges tipo de mídia com uma parte. Um cliente que não pode
decodificar uma mensagem multipart / byteranges não deve pedir para múltiplos
byte-intervalos em uma única solicitação.
Quando um cliente solicita vários byte varia de um pedido, a
servidor deverá devolvê-los na ordem em que eles apareceram no
pedido.
Fielding, et al. Standards Track [Página 123]
?
HTTP/1.1 RFC 2616 junho 1999
Se o servidor ignora uma série de byte-spec porque é sintaticamente
inválido, o servidor deve tratar o pedido como se o Range inválido
campo de cabeçalho não existia. (Normalmente, isto significa um retorno 200
resposta contendo a entidade completa).
Se o servidor recebe um pedido (excepto um, incluindo uma Se-
Faixa de campo de cabeçalho de solicitação), com uma insatisfatível Faixa de solicitação
campo de cabeçalho (ou seja, em que todos os byte-gama-spec valores têm um
valor do primeiro byte-pos maior que o comprimento atual do selecionado
recurso), ela deve retornar um código de resposta de 416 Intervalo solicitado (
não satisfatório) (seção 10.4.17).
Nota: os clientes não podem depender de servidores para enviar uma 416 (Solicitada
intervalo não satisfatório) em vez de uma resposta 200 (OK resposta) para
insatisfatível um pedido Faixa de cabeçalho, uma vez que nem todos os servidores
implementar o pedido de cabeçalho.
14,17 Tipo de conteúdo
O Content-Type campo de cabeçalho de entidade indica o tipo de mídia do
corpo da entidade, enviada ao destinatário ou, no caso do método HEAD,
o tipo de mídia que teriam sido enviados se o pedido tivesse sido um GET.
“Content-Type =” Content-Type “:” tipo de mídia
tipos de mídia são definidas no ponto 3.7. Um exemplo do campo é
Content-Type: text / html; charset = ISO-8859-4
Uma discussão mais aprofundada dos métodos para identificar o tipo de mídia de um
entidade é fornecida na seção 7.2.1.
14,18 data
A data do campo de cabeçalho geral representa a data ea hora em que
a mensagem foi originada, com a mesma semântica como a data em orig
RFC 822. O valor do campo é uma data HTTP, como descrito na seção
3.3.1, que deve ser enviado em formato RFC 1123 [8] data.
Data = “Data”: “HTTP data-
Um exemplo é
Date: Tue, 15 nov 1994 08:12:31 GMT
servidores de origem deve incluir um campo de cabeçalho Date em todas as respostas,
exceto nos seguintes casos:
Fielding, et al. Standards Track [Página 124]
?
HTTP/1.1 RFC 2616 junho 1999
1. Se o código de status de resposta é de 100 (Continua) ou 101 (Switching
Protocolos), a resposta pode incluir um campo de cabeçalho Date, em
opção do servidor.
2. Se o código de status de resposta transmite um erro no servidor, por exemplo, 500
(Internal Server Error) ou 503 (Service Unavailable), e é
inconveniente ou impossível gerar uma data válida.
3. Se o servidor não tem um relógio que pode proporcionar uma
aproximação razoável do tempo actual, as suas respostas
Não deve incluir um campo de cabeçalho Date. Neste caso, as regras
no ponto 14.18.1 deve ser seguido.
Uma mensagem recebida que não tem um campo de cabeçalho data deve ser
atribuído um pelo destinatário, se a mensagem será armazenada por que
destinatário ou gateway através de um protocolo que requer uma data. Um HTTP
execução sem um relógio respostas cache NÃO DEVE sem
revalidação los a cada uso. Um cache de HTTP, especialmente um compartilhado
cache, deve usar um mecanismo, como NTP [28], para sincronizar o seu
relógio com um padrão de confiança externa.
Os clientes só deve enviar um campo de cabeçalho Data de mensagens que incluam
uma entidade do corpo, como no caso das solicitações PUT e POST, e até mesmo
então é opcional. Um cliente sem um relógio não deve enviar uma data
campo de cabeçalho em uma solicitação.
A data-HTTP enviou um cabeçalho de data não representar uma data e
momento posterior à geração da mensagem. Ele deve representar
melhor aproximação disponível a partir da data e hora da mensagem
geração, a menos que a aplicação não tem meios de gerar um
data e razoavelmente precisa do tempo. Em teoria, a data deve
representam o momento anterior da entidade é gerado. Em
prática, a data pode ser gerado a qualquer momento durante a mensagem
originação, sem afetar o seu valor semântico.
14.18.1 Operação Server Clockless origem
Algumas implementações do servidor de origem pode não ter um relógio disponível.
Um servidor de origem sem um relógio não deve atribuir Expira ou de última
Modificado em valores para uma resposta, a menos que estes valores foram associados
com o recurso a um sistema ou um usuário com um relógio confiável. É MAIO
Expira em atribuir um valor que é conhecido, antes ou servidor
tempo de configuração, que será no passado (o que permite “pré-termo”
das respostas, sem armazenar valores distintos para cada Expira
de recursos).
Fielding, et al. Standards Track [Página 125]
?
HTTP/1.1 RFC 2616 junho 1999
14,19 ETag
O ETag campo de cabeçalho de resposta fornece o valor atual da
tag entidade para a variante solicitada. Os cabeçalhos usados com entidade
tags são descritos nas secções 14,24, 14,26 e 14,44. A marca entidade
Podem ser utilizados para comparação com outras entidades do mesmo recurso
(Ver secção 13.3.3).
ETag = “ETag”: “tag-entidade
Exemplos:
ETag: “xyzzy”
ETag: W / “xyzzy”
ETag: “”
Espere 14,20
Espere o cabeçalho de solicitação de campo é utilizado para indicar que a particular
comportamentos de servidor são exigidas pelo cliente.
Espere = “Esperar”: “uma expectativa #
expectativa = “100 continuam” | extensão de expectativa
extensão expectativa = [símbolo “=” (token | citou-corda)
* Esperar], params
espera-params = “”; [símbolo “=” (token | citou-corda)]
Um servidor que não entende ou é incapaz de cumprir qualquer uma das
os valores de expectativa no campo de esperar de um pedido deve responder
com status de erro apropriado. O servidor deve responder com uma 417
(Falha na expectativa), se qualquer status das expectativas não podem ser satisfeitas
ou, se existem outros problemas com a solicitação, algumas outras 4xx
status.
Esse campo de cabeçalho é definido com a sintaxe extensível para permitir
futuras ampliações. Se um servidor recebe uma solicitação contendo uma
Espere campo que inclui uma expectativa de extensão que não
apoio, ele deve responder com um status 417 (Falha na expectativa).
A comparação dos valores expectativa é diferencia maiúsculas de minúsculas para não cotadas
tokens (incluindo o 100 continuará token), e é sensível a maiúsculas para
citou-corda-expectativa extensões.
Fielding, et al. Standards Track [Página 126]
?
HTTP/1.1 RFC 2616 junho 1999
Espere o mecanismo é hop-by-hop, ou seja, uma proxy HTTP/1.1 DEVE
retornar um 417 (Falha na expectativa), status, se receber um pedido
com uma expectativa que não pode cumprir. No entanto, o Expect
cabeçalho da solicitação em si é fim-de-final, que deve ser enviada se a
pedido é encaminhado.
Muitos velhos HTTP/1.0 e aplicações HTTP/1.1 não entendem o
Espere cabeçalho.
Consulte a seção 8.2.3 para o uso do 100 (continua) status.
Expira 14,21
O campo de cabeçalho Expires entidade, dá a data / hora depois que o
resposta é considerado obsoleto. A entrada de cache velho não pode normalmente ser
retornado por uma cache (ou um proxy cache ou cache do agente do usuário)
a menos que primeiro é validada com o servidor de origem (ou com um
cache intermediário que tem uma cópia atualizada da entidade). Consulte a seção
13,2 para uma discussão mais aprofundada do modelo de validade.
A presença de um campo Expires não implica que o original
recurso vai mudar ou deixar de existir no antes, ou depois que
tempo.
O formato é uma data e tempo absolutos, tal como definido por HTTP data em
seção 3.3.1, que deve ser em formato RFC 1123 data:
Expires = “Expira”: “HTTP data-
Um exemplo de sua utilização é
Expira em: Thu, 01 dezembro 1994 16:00:00 GMT
Nota: Se a resposta inclui um campo de controle de cache com o max-
directiva idade (ver secção 14.9.3), que substitui a directiva
Expira em campo.
HTTP/1.1 clientes e caches deve tratar de outros formatos de data inválida,
incluindo especialmente o valor “0”, como no passado (ie, “já
expirado “).
Para marcar uma resposta como “já terminou”, disse um servidor de origem envia uma
Expira em data que é igual ao valor de cabeçalho Date. (Veja as regras de
para os cálculos de expiração no ponto 13.2.4.)
Fielding, et al. Standards Track [Página 127]
?
HTTP/1.1 RFC 2616 junho 1999
Para marcar uma resposta como “nunca expira”, disse um servidor de origem envia uma
Expira data cerca de um ano a partir do momento que a resposta seja
enviada. servidores HTTP/1.1 NÃO DEVE enviar Expira datas mais de um
anos no futuro.
A presença de um campo de cabeçalho Expires com um valor de data de alguns
tempo no futuro em uma resposta que de outra forma, por padrão ser
não cacheable indica que a resposta está em cache, a menos
indicação em contrário por um campo de cabeçalho Cache-Control (seção 14.9).
De 14,22
O campo de cabeçalho de pedido, se for dado, deve conter uma Internet
e-mail para o usuário humano que controla o usuário solicitante
agente. O endereço deve ser máquina utilizável, tal como definido pela “caixa”
na RFC 822 [9], actualizado pelo RFC 1123 [8]:
From = “De”: “caixa de entrada
Um exemplo é:
From: webmaster@w3.org
Esse campo de cabeçalho pode ser utilizado para fins de registro e como um meio para
identificar a origem dos pedidos inválidos ou indesejados. NÃO DEVE
ser usado como uma forma insegura de proteção de acesso. A interpretação
deste campo é que o pedido está sendo realizado em nome da
determinada pessoa, que aceita a responsabilidade para o método executado. Em
particular, os agentes robô deve incluir este cabeçalho para que o
pessoa responsável pelo funcionamento do robô pode ser contactado em caso de problemas
ocorrer no final de recebimento.
O endereço de correio electrónico da Internet neste campo pode ser separada da
Internet host que emitiu o pedido. Por exemplo, quando um pedido
é passado através de um proxy endereço do emitente original deve ser
utilizado.
O cliente não deve enviar o campo de cabeçalho sem o usuário
aprovação, uma vez que pode colidir com os interesses da privacidade do utilizador ou
as suas políticas de segurança do site. É altamente recomendável que o
usuário deve ser capaz de desativar, ativar e modificar o valor deste campo
em qualquer momento anterior ao pedido.
14,23 Host
O campo de cabeçalho Host pedido especifica o host da Internet e do porto
número do recurso que está sendo solicitado, obtido a partir do original
URI fornecido pelo usuário ou recurso de referência (geralmente um URL HTTP,
Fielding, et al. Standards Track [Página 128]
?
HTTP/1.1 RFC 2616 junho 1999
conforme descrito na seção 3.2.2). O valor do campo host deve representar
a autoridade de nomeação do servidor de origem ou gateway dada pelo
URL original. Isso permite que o servidor de origem ou gateway para
diferenciar URLs internamente ambíguo, como a raiz “/”
URL de um servidor para vários nomes de host em um endereço IP único.
Host = “Host”: “[” host “porta], Seção 3.2.2
Um “host”, sem qualquer informação porta à direita indica o padrão
porta para o serviço solicitado (por exemplo, “80” para uma URL HTTP). Para
exemplo, uma solicitação no servidor de origem para
<http://www.w3.org/pub/WWW/> corretamente incluem:
GET / pub / WWW / HTTP/1.1
Host: www.w3.org
Um cliente deve incluir um campo de cabeçalho de host em todas pedido HTTP/1.1
mensagens. Se o URI solicitado não incluir um host Internet
nome para o serviço que está sendo solicitado, então o campo de cabeçalho de host deve
ser dada com um valor vazio. Um proxy HTTP/1.1 deve garantir que qualquer
mensagem de solicitação para a frente contém um cabeçalho de host apropriado
campo que identifica o serviço que está sendo solicitado pelo proxy. Todos
Internet baseada em servidores HTTP/1.1 deve responder com um 400 (Bad Request)
código de status para qualquer mensagem de solicitação HTTP/1.1 que não possui um cabeçalho Host
de campo.
Ver secções 5.2 e 19.6.1.1 para outros requisitos relacionados com
Host.
14,24 Se Match-
O If-Match campo de cabeçalho de solicitação é usado com um método para fazê-lo
condicional. Um cliente que tem uma ou mais entidades anteriormente
obtidos a partir do recurso pode verificar que uma dessas entidades é
atual, incluindo uma lista de suas marcas associadas na entidade
campo de cabeçalho If-Match. Entidade tags são definidos na secção 3.11. O
objectivo desta funcionalidade é permitir atualizações eficiente de cache
informações com uma quantidade mínima de sobrecarga de transação. É também
utilizados, os pedidos de actualização, para impedir a modificação inadvertida de
a versão errada de um recurso. Como um caso especial, o valor “*”
corresponde a qualquer entidade atual do recurso.
If-Match = “If-Match”: “(*” | # 1 entidade tag)
Se qualquer uma das marcas entidade corresponde a tag entidade da entidade que
teriam sido devolvidos em resposta a um pedido similar GET
(Sem o cabeçalho-Match Se) sobre esse recurso, ou se “*” é dado
Fielding, et al. Standards Track [Página 129]
?
HTTP/1.1 RFC 2616 junho 1999
e qualquer entidade que existe actualmente para esse recurso, o servidor pode
executar o método solicitado, como se o campo de cabeçalho If-Match não
existe.
Um servidor deve usar a função de comparação forte (ver secção 13.3.3)
para comparar as marcas entidade If-Match.
Se nenhuma das tags entidade jogo, ou se “” * é dado e nenhuma corrente
entidade existe, o servidor não deve executar o método solicitado, e
Deve retornar uma resposta 412 (Requisito Falha). Esse comportamento é
mais útil quando o cliente quer impedir que um método de atualização, como
como colocar, de modificar um recurso que mudou desde que o cliente
passado é recuperado.
Se o pedido seria, sem o campo de cabeçalho If-Match, resultam em
outra coisa senão um status 2xx ou 412, em seguida, o Se-cabeçalho Match
Deve ser ignorado.
O significado de “If-Match: *” é que o método deve ser realizado
se a representação selecionados pelo servidor de origem (ou de um cache,
possivelmente utilizando o mecanismo de Vary, consulte a secção 14,44) existe, e
NÃO DEVE ser executada se a representação não existe.
A pedido destina-se a atualização de um recurso (por exemplo, um PUT) podem incluir uma
Se o campo de cabeçalho de partida para sinalizar que o método de pedido não deve ser
aplicados se a entidade correspondente ao valor-Match Se (a única
entidade tag) já não é uma representação desse recurso. Este
permite ao usuário para indicar que eles não querem o pedido para ser
bem sucedida se o recurso tiver sido alterado sem o seu conhecimento.
Exemplos:
If-Match: “xyzzy”
If-Match: “xyzzy”, “r2d2xxxx”, c3piozzzz “
Se o jogo: *
O resultado de um pedido tendo ambos um campo de cabeçalho If-Match e
quer um If-None-Match ou If-Modified-Since campos do cabeçalho é
indefinida por esta especificação.
14,25 If-Modified-Since
O If-Modified-Since campo de cabeçalho de solicitação é usado com um método para
torná-la condicional: se a variante solicitada não foi modificada
desde o tempo especificado neste campo, uma entidade não será
retornado do servidor, ao invés, uma 304 (não modificado) de resposta
ser devolvido sem qualquer mensagem do corpo.
If-Modified-Since = “If-Modified-Since”: “HTTP data-
Fielding, et al. Standards Track [Página 130]
?
HTTP/1.1 RFC 2616 junho 1999
Um exemplo do campo é:
If-Modified-Since: Sáb, 29 de outubro de 1994 19:43:31 GMT
Um método GET com um cabeçalho If-Modified-Since e nenhum cabeçalho Gama
solicita que a entidade identificada ser transferido somente se ele tiver
foram modificados desde a data indicada pelo cabeçalho If-Modified-Since.
O algoritmo para determinar o que inclui os seguintes casos:
a) Se o pedido normalmente resultar em outra coisa senão uma
200 (OK status), ou se passou a data If-Modified-Since é
inválido, a resposta é exatamente o mesmo que para um GET normal.
Uma data que é posterior à hora atual do servidor é
inválido.
b) Se a variação foi modificado desde o If-Modified-Since
data, a resposta é exatamente o mesmo que para um GET normal.
c) Se a variante não foi modificado desde um válido Se-
Modified-Since data, o servidor deve retornar um 304 (não
Modificado em resposta).
O objectivo desta funcionalidade é permitir atualizações eficiente de cache
informações com uma quantidade mínima de sobrecarga de transação.
Nota: A Faixa de campo de cabeçalho de solicitação modifica o sentido da Se-
Modified-Since, consulte a secção 14,35 para maiores detalhes.
Nota: Se-Modificado-Desde os tempos são interpretados pelo servidor, cuja
relógio não pode ser sincronizado com o cliente.
Nota: Ao manusear um If-Modified-campo de cabeçalho Uma vez que, alguns
servidores usar uma função de comparação exata data, ao invés de um
menos função do que, para decidir se a enviar um 304 (não
Modificado em resposta). Para obter melhores resultados quando do envio de uma Se-
Modificado-Desde campo de cabeçalho de validação cache, os clientes são
aconselhados a usar a seqüência de data exacta recebido em uma versão anterior de última
Modificado em campo de cabeçalho sempre que possível.
Nota: Se um cliente usa uma data arbitrária no If-Modified-Since
cabeçalho, em vez de uma data de retirada do cabeçalho Last-Modified para
o mesmo pedido, o cliente deve estar ciente do fato de que este
data será interpretado na compreensão do servidor de tempo. O
cliente deve considerar relógios sincronizados e problemas de arredondamento
devido às diferentes codificações de tempo entre o cliente eo
servidor. Isso inclui a possibilidade de condições de corrida, se o
documento foi alterado entre o momento em que foi solicitado e
If-Modified-Since data do pedido posterior, eo
Fielding, et al. Standards Track [Página 131]
?
HTTP/1.1 RFC 2616 junho 1999
possibilidade de problemas de clock skew-se relacionada com o If-Modified-
Desde que data é derivado do relógio do cliente sem correção
para o relógio do servidor. Correções para bases de tempo diferentes
entre cliente e servidor são melhores devido a aproximar-se da rede
latência.
O resultado de um pedido tendo ambos um If-Modified-campo de cabeçalho vez
Se quer um e-Match ou If-Unmodified-Como os campos do cabeçalho é
indefinida por esta especificação.
14,26 If-None-Match
O If-None-Match campo de cabeçalho de solicitação é usado com um método para fazer
é condicional. Um cliente que tem uma ou mais entidades anteriormente
obtidos a partir do recurso pode verificar que nenhuma dessas entidades é
atual, incluindo uma lista de suas marcas associadas na entidade
campo de cabeçalho If-None-Match. O objectivo desta funcionalidade é permitir que
atualizações eficiente de informações armazenadas em cache com uma quantidade mínima de
sobrecarga de transação. Ele também é usado para impedir que um método (por exemplo, PUT)
inadvertidamente modificar um recurso existente quando o cliente
acredita que o recurso não existe.
Como um caso especial, o valor “*” corresponde a qualquer entidade atual do
recursos.
If-None-Match = “If-None-Match”: “(*” | uma entidade # tag)
Se qualquer uma das marcas entidade corresponde a tag entidade da entidade que
teriam sido devolvidos em resposta a um pedido similar GET
(Sem o cabeçalho-None-Match Se) sobre esse recurso, ou se “*” é
dado e qualquer entidade actual existe para esse recurso, então o
servidor não deve executar o método solicitado, a menos que requerido
isso porque a data do recurso modificação não corresponder ao
fornecidas em um campo If-Modified-Since no cabeçalho do pedido.
Em vez disso, se o método da requisição GET ou HEAD, o servidor deve
Não responder com um 304 modificado (resposta), incluindo o cache
relacionados com campos de cabeçalho (particularmente ETag) de uma das entidades que
correspondido. Para todos os métodos de outro pedido, o servidor deve responder com
um status de 412 (Requisito Falha).
Consulte a seção 13.3.3 regras sobre como determinar se duas entidades tags
partida. A função de comparação fraca pode ser usado somente com GET ou HEAD
pedidos.
Fielding, et al. Standards Track [Página 132]
?
HTTP/1.1 RFC 2616 junho 1999
Se nenhuma das tags entidade jogo, então o servidor pode realizar o
método solicitado, como se o campo de cabeçalho If-None-Match não existisse,
mas deve também ignorar qualquer If-Modified-campo de cabeçalho Desde (s) no
pedido. Isto é, se não coincidir com tags entidade, o servidor NÃO DEVE
retornar um 304 (não modificado resposta).
Se o pedido seria, sem o campo If-None-Match cabeçalho, o resultado
em outra coisa senão um status 2xx ou 304, então o If-None-Match
cabeçalho deve ser ignorado. (Ver secção 13.3.4 para uma discussão sobre
comportamento do servidor quando ambos If-Modified-Since e If-None-Match aparecer
no mesmo pedido.)
O significado de “If-None-Match:” * é que o método não deve ser
realizada se a representação selecionados pelo servidor de origem (ou
um esconderijo, possivelmente usando o mecanismo Vary, consulte a secção 14,44)
existe, e deve ser realizada se a representação não existe.
Esta funcionalidade destina-se a ser útil na prevenção de raças entre PUT
operações.
Exemplos:
If-None-Match “xyzzy”
If-None-Match: W / “xyzzy”
If-None-Match “xyzzy”, “r2d2xxxx”, c3piozzzz “
If-None-Match: W / “xyzzy”, W / “r2d2xxxx”, W / c3piozzzz “
If-None-Match: *
O resultado de um pedido tendo ambos um campo de cabeçalho If-None-Match e
Se quer um jogo-ou-Se Unmodified-Como os campos do cabeçalho é
indefinida por esta especificação.
14,27 Se Range-
Se um cliente tiver uma cópia parcial de uma entidade em seu cache, e os desejos
ter uma cópia atualizada de toda a entidade em seu cache,
poderia usar o pedido Faixa de cabeçalho com um GET condicional (usando
um ou ambos os Se-Unmodified-Since e If-Match.) No entanto, se o
condição não porque a entidade foi modificado, o cliente
teria, então, fazer um segundo pedido para obter a totalidade do actual
corpo da entidade.
Se o cabeçalho Range permite que um cliente a “curto-circuito” no segundo
pedido. Informalmente, o seu significado é “se a entidade mantém-se inalterado, envie
me a parte (s) que estou em falta, caso contrário, envia-me toda a nova
entidade.
Se-Range = “Se-Range”: “(tag-entidade | HTTP-date)
Fielding, et al. Standards Track [Página 133]
?
HTTP/1.1 RFC 2616 junho 1999
Se o cliente não tem nenhuma marca de entidade para entidade, mas tem uma última
data de modificação, ele PODE usar essa data em um cabeçalho-Range Se. (A
servidor pode distinguir entre uma data válida HTTP e qualquer forma de
tag entidade, examinando mais de dois caracteres.) A Se-Range
cabeçalho deve ser usado apenas em conjunto com um cabeçalho Range, e deve ser
ignorados se o pedido não incluir um cabeçalho Range, ou se o
servidor não suporta a operação sub-escala.
Se a etiqueta dada entidade no caso de cabeçalho Faixa corresponde ao actual
tag de entidade para entidade, então o servidor deverá fornecer o
especificados sub-escala da entidade através de um índice 206 (parcial)
a resposta. Se a marca entidade não corresponder, então o servidor deverá
retornar a entidade inteira usando um 200 (OK resposta).
14,28 Se-Unmodified-Since
A Se-Unmodified-Since campo de cabeçalho de solicitação é usado com um método para
torná-la condicional. Se o recurso solicitado não tenha sido modificado
desde o tempo especificado nesse campo, o servidor deve executar o
operação solicitada, como se o Se-Unmodified header-Desde que não foram
presentes.
Se a variante procurada foi modificada desde o tempo especificado,
o servidor não deve executar a operação solicitada e deve retornar
um 412 Pré-requisito (Falha).
Se-Unmodified-Since = “If-Unmodified-Since”: “HTTP data-
Um exemplo do campo é:
Se-Unmodified-Since: Sat, 29 out 1994 19:43:31 GMT
Se o pedido normalmente (ou seja, sem a Se-Unmodified-Since
cabeçalho) resultaria em outra coisa senão um status 2xx ou 412, o
Se-Unmodified-Desde cabeçalho deve ser ignorada.
Se a data especificada é inválida, o cabeçalho é ignorado.
O resultado de um pedido tendo ambos um cabeçalho If-Unmodified-Since
campo e quer um If-None-Match ou um cabeçalho If-Modified-Since
campos é indefinido por esta especificação.
14,29 Last-Modified
The Last-Modified campo de cabeçalho de entidade indica a data e hora
qual o servidor de origem, acredita que a variante foi modificada pela última vez.
Last-Modified = “Last-Modified”: “HTTP data-
Fielding, et al. Standards Track [Página 134]
?
HTTP/1.1 RFC 2616 junho 1999
Um exemplo de sua utilização é
Last-Modified: Tue, 15 nov, 1994 00:45:26 GMT
O significado exato desse campo de cabeçalho depende da aplicação
do servidor de origem e da natureza do recurso original. Para
imagens, pode ser apenas o sistema de arquivos da última modificação. Para
entidades com as peças incluído dinamicamente, pode ser o mais recente
do conjunto de última modificar os horários dos seus componentes. Para banco de dados
gateways, pode ser a data e hora da última atualização do registro. Para
objetos virtuais, pode ser a última vez que o estado interno alterado.
Um servidor de origem não deve enviar uma data Last-Modified, que é posteriormente
que o tempo do servidor de origem da mensagem. Nesses casos, onde
última modificação do recurso poderia indicar algum tempo no
futuro, o servidor deve substituir essa data com a mensagem
data de originação.
Um servidor de origem deve obter o valor Last-Modified da entidade
o mais próximo possível do tempo que gera o valor da data de
sua resposta. Isso permite que um destinatário para fazer uma avaliação precisa
de tempo, a entidade modificação, especialmente se a entidade alterar a
próximo o momento em que a resposta é gerada.
servidores HTTP/1.1 deve enviar Last-Modified sempre que possível.
14,30 Local
O Situação campo de cabeçalho de resposta é usado para redirecionar o destinatário
para um local diferente do Pedido-URI para a realização do
solicitação ou identificação de um novo recurso. Para 201 (Criado)
respostas, a situação é a do novo recurso que foi criado
pela solicitação. Para 3xx respostas, o local deve indicar o
URI preferido servidor para redirecionamento automático para o recurso. O
valor do campo é composto por um único URI absoluto.
Location = “Local”: “absoluteURI
Um exemplo é:
Localização: http://www.w3.org/pub/WWW/People.html
Nota: O campo de cabeçalho Content-Location (seção 14.14) difere
de Localização de que o Content-Location identifica o original
localização da entidade fechada no pedido. É, portanto,
possível uma resposta para conter campos de cabeçalho para ambos Location
e Localização de conteúdo. Consulte também a seção de cache 13,10
exigências de alguns métodos.
Fielding, et al. Standards Track [Página 135]
?
HTTP/1.1 RFC 2616 junho 1999
14,31 Max-Forwards
O Max-Forwards campo de cabeçalho de solicitação fornece um mecanismo com o
TRACE (seção 9.8) e opções (secção 9.2) Os métodos para limitar a
número de proxies ou gateways que pode encaminhar a solicitação ao
servidor de entrada seguinte. Isso pode ser útil quando o cliente está tentando
traçar uma cadeia de solicitação que parece estar falhando ou em looping
meio de cadeia.
Max-Forwards = “Max-Forwards”: “1 * DIGIT
O valor Max-Forwards é um inteiro decimal indicando os restantes
número de vezes que esta mensagem de solicitação pode ser enviada.
Cada proxy ou gateway destinatário de um traço ou solicitar opções
contendo um campo de cabeçalho Max-Forwards deve verificar e atualizar seus
valor antes de enviar o pedido. Se o valor recebido for igual a zero
(0), o beneficiário não deve encaminhar a solicitação, em vez disso, ele deve
responder como o destinatário final. Se o valor recebido é Max-Forwards
maior que zero, então a mensagem transmitida deve conter uma actualização
Max-Forwards campo com um valor diminuído por um (1).
O Max-Forwards cabeçalho campo pode ser ignorado por todos os outros métodos
definidas por esta especificação e os métodos de extensão para que
não é explicitamente referida como parte do que a definição do método.
14,32 Pragma
O campo de cabeçalho Pragma-geral é usado para incluir implementação
directivas específicas que possam ser aplicados a qualquer destinatário ao longo do
pedido cadeia / resposta. Todas as directivas pragma especificar opcional
comportamento do ponto de vista do protocolo, no entanto, alguns sistemas
Pode exigir que o comportamento seja coerente com as directivas.
Pragma = “Pragma”: “uma diretiva # pragma-
diretiva pragma = “no-cache” | extensão pragma-
extensão pragma = [símbolo “=” (token | citou-corda)]
Quando a diretiva no-cache está presente em uma mensagem de solicitação, um
A aplicação deve encaminhar a solicitação para o servidor de origem, mesmo
se tiver uma cópia em cache do que está sendo solicitado. Este pragma
directiva tem a mesma semântica como a não-cache cache directiva (ver
seção 14.9) e é definida aqui para compatibilidade com versões anteriores
HTTP/1.0. Os clientes devem incluir tanto os campos do cabeçalho quando o cache não-
pedido é enviado para um servidor que não é conhecido o padrão HTTP/1.1.
Fielding, et al. Standards Track [Página 136]
?
HTTP/1.1 RFC 2616 junho 1999
directivas Pragma deve ser passada através de um proxy ou gateway
aplicação, independentemente da sua importância a esse pedido,
vez que as directivas possam ser aplicáveis a todos os destinatários ao longo do
pedido cadeia / resposta. Não é possível especificar um pragma para uma
destinatário específico, no entanto, não qualquer diretiva pragma relevantes para a
beneficiário deve ser ignorado por esse destinatário.
caches HTTP/1.1 deve tratar “Pragma: no-cache”, como se o cliente tinha
enviou “Cache-Control: no-cache”. Nenhum novas directivas Pragma será
definido no HTTP.
Observação: porque o significado de “Pragma: no-cache como uma resposta
campo de cabeçalho não está realmente definido, não proporcionar uma
substituição de confiança para “Cache-Control: no-cache” em uma resposta
14,33 Proxy-Authenticate
O Proxy-Authenticate campo de cabeçalho de resposta deve ser incluído como parte
de uma resposta 407 (Proxy Authentication Required). O campo de valor
consiste em um desafio que indica que o esquema de autenticação e
parâmetros aplicáveis ao proxy para este Pedido-URI.
Proxy-Authenticate = “Proxy-Authenticate”: “um desafio #
O processo de autenticação de acesso HTTP é descrito em “HTTP
Autenticação: Basic e Digest Authentication Access “[43]. Contrário
WWW-Authenticate, o campo de cabeçalho Proxy-Authenticate se aplica apenas a
a conexão atual e não deve ser transferido para jusante
clientes. No entanto, um proxy intermediário pode precisar obter seu próprio
solicitando-lhes credenciais do cliente a jusante, que
algumas circunstâncias, aparecerá como se o proxy está encaminhando a
Proxy-Authenticate campo de cabeçalho.
14,34 Proxy-Autorização
O Proxy-Authorization campo de cabeçalho de solicitação permite que o cliente
identificar-se (ou o seu usuário) para um proxy que exige
autenticação. O valor do campo Proxy-Authorization consiste em
credenciais contendo as informações de autenticação do usuário
agente para o proxy e / ou domínio do recurso que está sendo solicitado.
Proxy-Authorization = “Proxy-Authorization”: “credenciais
O processo de autenticação de acesso HTTP é descrito em “HTTP
Autenticação: Basic e Digest Authentication Access “[43]. Contrário
Autorização, o campo de cabeçalho Proxy-Authorization só se aplica aos
o próximo proxy de saída que exigiu autenticação usando o proxy
campo Authenticate. Quando vários proxies são usados em uma cadeia, a
Fielding, et al. Standards Track [Página 137]
?
HTTP/1.1 RFC 2616 junho 1999
Proxy-Authorization campo de cabeçalho é consumido pela primeira saída
proxy que estava à espera de receber as credenciais. Um relé pode proxy
as credenciais do pedido do cliente para o proxy próximo se for
o mecanismo pelo qual as procurações cooperativamente autenticar um determinado
pedido.
14,35 Faixa
14.35.1 intervalos de bytes
Uma vez que todas as entidades HTTP são representados em mensagens HTTP como seqüências
de bytes, o conceito de um intervalo de bytes é significativo para qualquer HTTP
entidade. (No entanto, nem todos os clientes e servidores devem apoiar-byte
operações de intervalo.)
especificações intervalo de bytes em HTTP se aplica à seqüência de bytes em
a entidade-corpo (não necessariamente o mesmo que o corpo da mensagem).
Um byte faixa de operação pode especificar um único intervalo de bytes, ou um conjunto
de intervalos dentro de uma única entidade.
intervalos de especificador = byte varia especificador
byte varia especificador-bytes = unidade = “byte-range set-
byte-intervalo definido = 1 # (byte-range-spec | sufixo-byte-gama-spec)
byte-gama-spec = primeiro-byte-pos “-“] último byte-pos [
primeiro byte-pos = 1 * DIGIT
último byte-pos = 1 * DIGIT
O valor do primeiro byte-pos em um intervalo de byte-spec dá o byte-offset
do primeiro byte de um intervalo. O valor do último byte-pos dá a
byte-offset do último byte no intervalo, ou seja, o byte
posições previstas são inclusivas. offsets Byte começam em zero.
Se o valor do último byte-pos estiver presente, ele deve ser maior ou
igual ao primeiro-byte-pos em que vão-byte-spec, ou o byte-
gama-spec é sintaticamente inválida. O destinatário de uma gama-byte-
conjunto que inclui um ou mais sintaticamente inválido byte gama-spec
valores deve ignorar o campo de cabeçalho que inclui a faixa-byte-
set.
Se o valor do último byte-pos está ausente, ou se o valor for superior a
ou igual ao comprimento atual da entidade corpo, no último byte é pos-
considerada igual a um menor que o comprimento atual da entidade,
corpo em bytes.
Por sua escolha de última byte-pos, um cliente pode limitar o número de
bytes recuperados sem saber o tamanho da entidade.
Fielding, et al. Standards Track [Página 138]
?
HTTP/1.1 RFC 2616 junho 1999
sufixo-byte-gama-spec = “-” de sufixos de comprimento
sufixo-length = 1 * DIGIT
Um sufixo-byte-gama-spec é usado para especificar o sufixo do
corpo da entidade, de um comprimento dado pelo valor de sufixos de comprimento. (Isto é,
O presente formulário especifica os últimos bytes N de uma entidade do corpo.) Se o
entidade é menor do que o especificado sufixo de comprimento, toda a
corpo da entidade é usado.
Se um byte-sintaticamente válido intervalo definido inclui pelo menos um byte-
gama-spec cujo primeiro byte-pos é menor que o comprimento atual da
a entidade do corpo, ou pelo menos um sufixo-byte gama-spec com um não-
sufixo zero de comprimento, o intervalo de bytes é satisfatório.
Caso contrário, o intervalo de bytes, não é satisfeita. Se o intervalo de bytes-
não é satisfeita, o servidor deve retornar uma resposta com um estatuto
de 416 (Faixa solicitada não satisfatória). Caso contrário, o servidor
Deve retornar uma resposta com um status de 206 (Partial Content)
contendo os intervalos satisfatível da entidade corpo.
Exemplos de byte varia especificador de valores (assumindo que uma entidade de corpo de
comprimento 10000):
– Os primeiros 500 bytes (0-499 offsets de bytes, inclusive): bytes = 0 –
499
– O segundo 500 bytes (offsets byte 500-999, inclusive):
bytes = 500-999
– O final de 500 bytes (offsets de bytes 9500-9999, inclusive):
=- 500 bytes
– Ou bytes = 9500 –
– Bytes O primeiro eo último só (bytes 0 e 9999): bytes = 0-0, -1
– Vários legal, mas não canônico especificações do 500 segundo
bytes (offsets byte 500-999, inclusive):
bytes = 500-600,601-999
bytes = 500-700,601-999
14.35.2 Os pedidos de obtenção Gama
solicitações de recuperação usando HTTP GET condicional ou incondicional
métodos pedido pode um ou mais sub-intervalos da entidade, em vez de
entidade inteira, usando o cabeçalho de solicitação Range, que se aplica a
a entidade retornado como o resultado do pedido:
Range = “Faixa”: “vai especificador
Fielding, et al. Standards Track [Page 139]
?
HTTP/1.1 RFC 2616 junho 1999
Um servidor pode ignorar o cabeçalho Range. No entanto, HTTP/1.1 origem
servidores e caches intermediários devem apoiar intervalos de bytes quando
possível, uma vez que suporta Faixa de recuperação eficiente de parcialmente
transferência falhou, e suporta a recuperação parcial eficiente de grandes
entidades.
Se o servidor suporta o cabeçalho da Gama e do intervalo especificado ou
escalas são apropriadas para a entidade:
– A presença de um cabeçalho de intervalo em uma GET incondicional modifica
o que é devolvido se o GET é outra bem-sucedida. Em outras
palavras, a resposta carrega um código de status 206 (parcial
Content), em vez de 200 (OK).
– A presença de um cabeçalho de intervalo em uma GET condicional (a pedido
utilizando um ou ambos os If-Modified-Since e If-None-Match, ou
um ou ambos os Se-Unmodified-Since e If-Match) modifica o
é devolvido se o GET é outra bem-sucedida eo
condição for verdadeira. Ela não afeta a 304 (Not Modified)
resposta retornado se a condição é falsa.
Em alguns casos, poderia ser mais adequado utilizar a Faixa de Se-
cabeçalho (ver secção 14,27), para além do cabeçalho Range.
Se um proxy que suporta varia recebe uma solicitação Gama, em frente
o pedido para um servidor de entrada, e recebe uma entidade em todo o
resposta, que só deve retornar o intervalo solicitado a seu cliente. Ele
Deve armazenar a resposta inteira recebeu em seu cache se for
coerente com suas políticas de alocação de cache.
14,36 Referer
O Referer [sic] campo de cabeçalho de solicitação permite que o cliente precisar,
em benefício do servidor, o endereço (URI) do recurso de
que o pedido-URI foi obtido (a referência “, embora o
campo de cabeçalho está incorreto.) O pedido de cabeçalho Referer permite uma
servidor para gerar listas de back-links para recursos de interesse,
exploração madeireira, otimizado cache, etc Ele também permite obsoletos ou mal
ligações a ser seguido para a manutenção. O campo Referer NÃO DEVE ser
enviado se o Pedido-URI foi obtida de uma fonte que não tem
sua própria URI, como entrada do teclado do usuário.
Referer = “Referer”: “(absoluteURI | relativeURI)
Exemplo:
Referer: http://www.w3.org/hypertext/DataSources/Overview.html
Fielding, et al. Standards Track [Página 140]
?
HTTP/1.1 RFC 2616 junho 1999
Se o valor do campo é um URI relativa, ela deve ser interpretada
em relação ao Pedido-URI. O URI não deve incluir um fragmento. Ver
seção 15.1.3 para considerações de segurança.
14,37 Retry-After
A repetir-Depois de campo de cabeçalho de resposta pode ser usado com um 503 (Serviço
Indisponível resposta) para indicar quanto tempo o serviço está prevista para
não estar disponível para o cliente solicitante. Este campo pode também ser utilizado
com qualquer 3xx (redirecionamento) resposta ao indicam o tempo mínimo
agente de usuário é solicitado esperar antes de emitir o pedido redirecionado. O
valor deste campo pode ser um HTTP data ou um número inteiro
de segundos (em decimal), após o tempo da resposta.
Repetir-Depois = “Retry-After”: “(HTTP data-| delta-segundos)
Dois exemplos de seu uso são
Retry-After: Fri, 31 dezembro 1999 23:59:59 GMT
Retry-After: 120
Neste último exemplo, o atraso é de 2 minutos.
14,38 Server
O servidor de campo de cabeçalho de resposta contém informações sobre o
software utilizado pelo servidor de origem para processar o pedido. O campo
pode conter vários tokens produto (seção 3.8) e comentários
identificar o servidor e qualquer subprodutos significativa. O produto
tokens listados em ordem de sua importância para a identificação do
pedido.
Server = “Server”: “1 * (produto | comentário)
Exemplo:
Servidor: CERN/3.0 libwww/2.17
Se a resposta está sendo encaminhado através de um proxy, o proxy
pedido não deve modificar a resposta do servidor de cabeçalho. Em vez disso,
Deve incluir um campo de Via (como descrito na seção 14.45).
Nota: Revelar a versão de software específico do servidor pode
permitir que a máquina servidor para tornar-se mais vulnerável a ataques
contra o software que é conhecido por conter falhas de segurança. Server
Os implementadores são encorajados a fazer neste domínio um configurable
opção.
Fielding, et al. Standards Track [Página 141]
?
HTTP/1.1 RFC 2616 junho 1999
14,39 TE
O campo de cabeçalho de solicitação-TE indica que a extensão de transferência de códigos
está disposta a aceitar a resposta e se é ou não
dispostos a aceitar campos trailer em uma transferência de blocos de codificação. Sua
valor pode ser constituído por palavra-chave “trailers” e / ou separados por vírgulas
lista de extensão de transferência de codificação aceitar nomes com opcionais
parâmetros (como descrito na seção 3.6).
TE = “TE”: “# (t-códigos)
t-codificações = “trailers |” ([transferência extensão de aceitar-params])
A presença da palavra chave “trailers” indica que o cliente está
dispostos a aceitar campos trailer em uma transferência de blocos de codificação, como
definido no ponto 3.6.1. Esta palavra-chave é reservado para uso com
transferência de valores de codificação, mesmo que não se representam um
transferência de codificação.
Exemplos de seu uso são:
TE: desinflar
TE:
TE: reboques, esvaziar; q = 0,5
O campo de cabeçalho TE só se aplica para a conexão imediata.
Portanto, a palavra-chave deve ser fornecida dentro de um cabeçalho Connection
campo (seção 14.10) TE sempre está presente em uma mensagem HTTP/1.1.
Um servidor de testes se uma transferência de codificação é aceitável, de acordo com
um campo de TE, usando as seguintes regras:
1. Os “blocos” de transferência de codificação é sempre aceitável. Se o
palavra chave “trailers” está listado, o cliente indica que ele é
dispostos a aceitar campos trailer na resposta fragmentada em
nome próprio e todos os clientes a jusante. A implicação é
que, se for concedida, o cliente está dizendo que quer todos os
clientes a jusante estão dispostos a aceitar campos de reboque na
resposta enviada, ou que ele tentará o buffer
resposta em nome dos beneficiários a jusante.
Nota: HTTP/1.1 não define todos os meios para limitar o tamanho de um
resposta fragmentada de tal forma que um cliente pode ter a certeza de buffering
a resposta inteira.
2. Se a transferência de codificação que está sendo testado é uma das transferência
códigos constantes no campo TE, então é aceitável, a menos que
é acompanhado por um qValue 0. (Tal como definido no ponto 3.9, a
qValue 0 significa “não é aceitável.”)
Fielding, et al. Standards Track [Página 142]
?
HTTP/1.1 RFC 2616 junho 1999
3. Se vários transferência de códigos são aceitáveis, então o
aceitáveis de transferência de codificação com o qValue maior não é zero
preferenciais. Os “blocos” de transferência de codificação tem sempre um qValue
de 1.
Se a TE campo de valor estiver vazio ou se nenhum campo TE está presente, o único
transferência de codificação é “fragmentada”. Uma mensagem sem transferência de codificação é
sempre aceitável.
Trailer 14,40
Trailer do valor do campo geral indica que o dado conjunto de
campos de cabeçalho está presente no trailer de uma mensagem codificada com
fragmentada de transferência de codificação.
Trailer = “Trailer”: “1 # nome-do-campo
Uma mensagem HTTP/1.1 deve incluir um campo de cabeçalho em um Trailer
mensagem usando blocos de transferência de codificação com um trailer não-vazio. Fazer
isso permite que o receptor sabe que os campos de cabeçalho que esperar no
trailer.
Se nenhum campo de cabeçalho Trailer está presente, o reboque não devem incluir
os campos de cabeçalho. Consulte a seção 3.6.1 para as restrições sobre o uso de
campos de reboque em um “blocos” de transferência de codificação.
campos de cabeçalho de mensagens listadas no campo de cabeçalho Trailer NÃO DEVE
incluir os campos de cabeçalho que se segue:
. Transfer-Encoding
. Content-Length
. Reboque
14,41 Transfer-Encoding
O Transfer-Encoding cabeçalho campo-geral indica que (se houver)
tipo de transformação tem sido aplicada ao corpo da mensagem, a fim
transferi-lo de forma segura entre o remetente eo destinatário. Este
difere do conteúdo de codificação em que a transferência é uma codificação
propriedade da mensagem, e não da entidade.
Transfer-Encoding = “Transfer-Encoding”: “1 # transferência de codificação
Transfer-codificações são definidas no ponto 3.6. Um exemplo é:
Transfer-Encoding: blocos
Fielding, et al. Standards Track [Page 143]
?
HTTP/1.1 RFC 2616 junho 1999
Se codificações múltiplas foram aplicadas a uma entidade, a transferência de
códigos devem ser listados na ordem em que foram aplicadas.
Informações adicionais sobre a codificação parâmetros podem ser fornecidos
por outros campos do cabeçalho entidade não definidas por esta especificação.
Muitos aplicativos mais antigos HTTP/1.0 não entendem o Transfer-
Encoding cabeçalho.
Upgrade 14,42
A atualização cabeçalho geral permite ao cliente especificar o que
adicional protocolos de comunicação que apoia e gostaria de usar
se o servidor encontra-lo adequado para mudar os protocolos. O servidor
Deve usar o campo de cabeçalho de atualização dentro de um 101 (Switching Protocols)
resposta para indicar qual protocolo (s) estão sendo trocados.
Upgrade = “Upgrade”: “um produto #
Por exemplo,
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
O campo de cabeçalho de atualização é destinada a fornecer um mecanismo simples
para a transição do protocolo HTTP/1.1 para alguns, outros incompatíveis. Ele
fá-lo, permitindo que o cliente para anunciar seu desejo de utilizar outra
protocolo, como uma versão mais recente do HTTP com uma versão superior principal
número, embora o atual solicitação foi feita usando HTTP/1.1.
Isso facilita a difícil transição entre os dois protocolos incompatíveis por
permitindo que o cliente para iniciar um pedido na mais comumente
protocolo suportado com indicação para o servidor que gostaria
usar um protocolo de “melhor” se disponível (onde “melhor” é determinado
pelo servidor, possivelmente em função da natureza do método e / ou
recurso que está sendo solicitada).
O campo de cabeçalho de atualização se aplica apenas a comutação de camada de aplicação
protocolos sobre a conexão da camada de transporte existentes. Melhorar
não pode ser usado para insistir em uma mudança de protocolo, sua aceitação e utilização
pelo servidor é opcional. As capacidades e natureza das
comunicação da camada de aplicação após a mudança de protocolo é inteiramente
dependente do novo protocolo escolhido, apesar de a primeira ação
depois de mudar o protocolo deve ser uma resposta ao HTTP inicial
solicitação que contém o campo de cabeçalho de atualização.
O campo de cabeçalho de atualização se aplica somente para a conexão imediata.
Portanto, a atualização de palavras-chave devem ser fornecidos no prazo de uma conexão
campo de cabeçalho (seção 14.10), sempre Upgrade está presente em um
HTTP/1.1 mensagem.
Fielding, et al. Standards Track [Página 144]
?
HTTP/1.1 RFC 2616 junho 1999
O campo de cabeçalho de atualização não pode ser usado para indicar uma mudança para um
protocolo em uma conexão diferente. Para esse efeito, é mais
conveniente utilizar uma 301, 302, 303, ou 305 resposta de redirecionamento.
Esta especificação define apenas o nome do protocolo “HTTP” para utilização por
a família de protocolos de transferência de hipertexto, tal como definido pelo HTTP
regras da secção versão 3.1 e futuras atualizações para este
especificação. Qualquer sinal pode ser usado como um nome de protocolo, porém
só será útil se o cliente eo servidor associa o nome
com o mesmo protocolo.
14,43 User-Agent
O campo User-Agent do cabeçalho da solicitação contém informações sobre o
agente do usuário que origina a solicitação. Isto é para fins estatísticos,
a detecção de violações do protocolo, e do reconhecimento automático de usuário
agentes em prol da alfaiataria respostas para evitar determinado usuário
limitações do agente. Os agentes deveriam incluir este campo com
pedidos. O campo pode conter sinais múltiplos produtos (seção 3.8)
e comentários a identificação do agente e quaisquer subprodutos que formam um
parte significativa do agente do usuário. Por convenção, o produto tokens
estão listados em ordem de sua importância para a identificação do
pedido.
User-Agent = “User-Agent”: “1 * (produto | comentário)
Exemplo:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
14,44 Vary
O valor do campo Vary indica o conjunto de campos de cabeçalho de solicitação que
plenamente determina, enquanto a resposta é fresco, se é um cache
autorizada a utilizar a resposta para responder a uma solicitação subseqüente
sem revalidação. Para respostas sem cache ou obsoletos, o Vary
valor do campo aconselha o agente sobre os critérios que foram utilizados
para selecionar a representação. Um valor de campo Vary de “*” significa que
um cache não pode determinar a partir dos cabeçalhos de solicitação de um posterior
pedido, se essa resposta é a representação adequada. Ver
O ponto 13.6 para a utilização do campo de cabeçalho Vary por caches.
Variar = “Vary”: “(*” | # 1 campo de nome)
Um servidor HTTP/1.1 deve incluir um campo de cabeçalho Vary com qualquer
resposta cacheable que é objecto de negociação servidor-driven.
Isso permite que um cache de interpretar corretamente as solicitações futuras do que
recurso e informa o agente do usuário quanto à presença de negociação
Fielding, et al. Standards Track [Página 145]
?
HTTP/1.1 RFC 2616 junho 1999
sobre esse recurso. Um servidor pode incluir um campo de cabeçalho com uma Vary
resposta não cacheable que é objecto de negociação servidor-driven,
uma vez que esta pode proporcionar ao agente de usuário com informação útil sobre
as dimensões em que a resposta varia no tempo da
a resposta.
Um valor de campo Vary composto de uma lista de nomes de domínio que os sinais
da representação selecionada para a resposta é baseada em uma seleção
algoritmo que considera apenas os valores de campo constantes do cabeçalho da solicitação
na seleção da representação mais adequada. A cache pode assumir
que a mesma seleção será feita para futuras solicitações com a
mesmos valores para os nomes de campo na lista, para a duração do tempo de
que a resposta é fresco.
O campo de nomes dados não estão limitados ao conjunto de padrões
cabeçalho da solicitação campos definidos por esta especificação. Os nomes dos campos são
maiúsculas e minúsculas.
Um valor de campo Vary de “*” indica que os parâmetros não especificada
limitado ao pedido-headers (por exemplo, o endereço de rede do
cliente), desempenham um papel na seleção da representação resposta.
* O “valor não deve ser gerado por um servidor proxy, ele só pode ser
gerados por um servidor de origem.
Via 14,45
O campo de cabeçalho Via-geral deve ser utilizado pelos gateways e proxies para
indicar os protocolos intermediários e destinatários entre o usuário
agente eo servidor sobre os pedidos, e entre o servidor de origem e
o cliente sobre as respostas. É análogo ao campo “Recebido de
RFC 822 [9], e se destina a ser utilizado para rastreamento encaminha a mensagem,
evitando loops pedido, e identificando as capacidades de protocolo
todos os remetentes ao longo da solicitação / resposta da cadeia.
Via = “Via”: “1 # (recebido protocolo recebido por [comentário])
recebeu protocolo = [protocolo de nome “/”] protocolo versão
nome do protocolo = token
versão do protocolo = token
recebeu por = host ([“]:” porto) | pseudônimo
pseudônimo = token
O protocolo recebido indica a versão do protocolo da mensagem
recebida pelo servidor ou cliente ao longo de cada segmento da
pedido cadeia / resposta. A versão recebida protocolo é anexado ao
o valor do campo Via quando a mensagem é encaminhada para que a informação
sobre as capacidades de protocolo dos pedidos de upstream continua
visível para todos os destinatários.
Fielding, et al. Standards Track [Página 146]
?
HTTP/1.1 RFC 2616 junho 1999
O nome do protocolo é opcional, se e somente se ele seria “HTTP”. O
recebido pelo campo é normalmente o host eo número da porta opcional de um
servidor do destinatário ou do cliente que, posteriormente, transmitiu a mensagem.
No entanto, se o host real é considerada informações sensíveis,
pode ser substituído por um pseudônimo. Se a porta não é dado, ele pode
ser considerado como a porta padrão do protocolo recebido.
Vários valores de campo Via representa cada proxy ou gateway que tem
enviou a mensagem. Cada beneficiário deve acrescentar suas informações
de tal forma que o resultado final é ordenada de acordo com a seqüência de
pedidos de encaminhamento.
Comentários podem ser utilizados no campo de cabeçalho Via identificar o software
do destinatário proxy ou gateway, análogo ao User-Agent e
cabeçalho campos Server. No entanto, todos os comentários no campo Via são
opcional e pode ser removido por qualquer beneficiário antes de encaminhar o
mensagem.
Por exemplo, uma mensagem de solicitação pode ser enviada de um usuário HTTP/1.0
agente a um proxy interno com o codinome “Fred”, que usa a HTTP/1.1
encaminhar a solicitação de uma procuração pública no nowhere.com, que completa
o pedido, enviando-o para o servidor de origem em www.ics.uci.edu.
O pedido recebido por www.ics.uci.edu teria, então, a seguinte
Via campo de cabeçalho:
Via: 1.0 fred, 1,1 nowhere.com (Apache/1.1)
Proxies e gateways usado como um portal através de um firewall de rede
Não deve, por padrão, encaminhar os nomes de hosts e portas dentro
região firewall. Esta informação só deve ser propagada se
explicitamente habilitado. Se não for habilitado, o recebeu por host de qualquer host
por trás do firewall deve ser substituído por um pseudónimo adequado
para esse acolhimento.
Para as organizações que têm fortes requisitos de privacidade para esconder
estruturas internas, em maio proxy combinar uma subsequência ordenada de
cabeçalho Via entradas de campo com valores idênticos recebeu protocolo em
uma única entrada desse tipo. Por exemplo,
Via: 1.0 ricky, Ethel 1,1, 1,1 fred, 1.0 lucy
poderia ser recolhido para
Via: 1.0 ricky, 1,1 Mertz, 1.0 lucy
Fielding, et al. Standards Track [Página 147]
?
HTTP/1.1 RFC 2616 junho 1999
As candidaturas devem não combinar múltiplas entradas a menos que eles são todos
sob o mesmo controle organizacional e os anfitriões já foram
substituídos por pseudônimos. Aplicações NÃO DEVE combinar as entradas que
têm diferentes valores recebidos protocolo.
Atenção 14,46
O Aviso campo de cabeçalho geral é usado para transportar adicionais
informações sobre o estado ou a transformação de uma mensagem que
pode não ser refletida na mensagem. Esta informação é tipicamente
usado para alertar sobre uma possível falta de transparência semântica de
operações de cache ou transformações aplicadas ao corpo da entidade de
a mensagem.
cabeçalhos de aviso são enviadas com respostas com:
Warning = “Atenção”: “1 # aviso de valor
aviso-valor = avisar código-SP alertam agente-SP alertam texto
[SP] advertir data-
alertar código = 3digit
pseudônimo avisar agente = (host [“:]” porto) |
, O nome ou pseudónimo do servidor adicionando
; O cabeçalho de aviso, para uso na depuração
advertem-text = citou-corda
alertar data = “<<HTTP data”>
A resposta pode levar mais de um cabeçalho de aviso.
O advertir texto deve estar em uma linguagem natural e conjunto de caracteres que
É mais provável que seja inteligível para o usuário humano receber a
a resposta. Esta decisão pode ser baseada nos conhecimentos disponíveis, tais
como a localização da cache ou do usuário, o campo Accept-Language em um
pedido, o campo Content-Language em uma resposta, etc O padrão
língua é o Inglês eo conjunto de caracteres padrão é ISO-8859-1.
Se um conjunto de caracteres que não ISO-8859-1 é usado, ele deve ser codificado
nos avisar texto usando o método descrito no RFC 2047 [14].
cabeçalhos de aviso pode em geral ser aplicada a qualquer mensagem, no entanto
alguns específicos de advertência códigos são específicos para caches e só pode ser
aplicadas às mensagens de resposta. novos cabeçalhos de aviso deve ser acrescentado
após os cabeçalhos de aviso existente. A cache não deve excluir qualquer
Atenção cabeçalho que recebeu com uma mensagem. No entanto, se um cache
sucesso valida uma entrada de cache, ele deve remover qualquer aviso
cabeçalhos anexados anteriormente a essa entrada, exceto conforme especificado para
Fielding, et al. Standards Track [Página 148]
?
HTTP/1.1 RFC 2616 junho 1999
Atenção códigos específicos. Deve, então, adicionar os cabeçalhos de aviso recebido
na resposta de validação. Em outras palavras, são os cabeçalhos de aviso
que seria anexado à resposta mais recentes e relevantes.
Quando vários cabeçalhos de aviso são anexados a uma resposta, o usuário
agente deveria informar o utilizador de que muitos deles possível, no
ordem em que aparecem na resposta. Se não for possível
informar o utilizador de todos os avisos, o agente deve seguir
destas heurísticas:
– Os avisos que aparecem no início da resposta ter prioridade sobre
os que figuram depois na resposta.
– Advertências em caráter preferencial do usuário têm prioridade definida
sobre advertências em outros conjuntos de caracteres, mas com idêntica advertência
códigos e advertir-agentes.
Sistemas que geram vários cabeçalhos de aviso deve ordenar-lhes
esse comportamento do agente do usuário em mente.
Requisitos para o comportamento de caches em relação a avisos são
indicado na seção 13.1.2.
Esta é uma lista de atualmente definido alertar os códigos, cada um com
Recomenda avisar texto em Inglês, e uma descrição do seu significado.
110 A resposta é obsoleto
Deve ser incluído sempre que a resposta retornada é obsoleto.
111 Revalidação falhou
Deve ser incluído se um cache retorna uma resposta, porque um velho
tentativa de revalidar a resposta falhou, devido a uma incapacidade de
alcançar o servidor.
112 operação desconectada
Deve ser incluída, se o cache é intencionalmente desligado
o resto da rede por um período de tempo.
113 termo Heurística
Deve ser incluído se o cache heuristicamente escolheu um frescor
vida útil superior a 24 horas e idade a resposta é maior
de 24 horas.
199 aviso Diversos
O aviso de texto pode incluir informações arbitrárias que será apresentado
para um usuário humano, ou registrado. Um sistema de receber este aviso deve
Não tomar qualquer ação automatizada, além de apresentar o aviso para
o usuário.
Fielding, et al. Standards Track [Página 149]
?
HTTP/1.1 RFC 2616 junho 1999
214 Transformação aplicada
Deve ser adicionado por um proxy cache intermediário ou que se aplique qualquer
transformação alterar o conteúdo de codificação (tal como especificado no
Content-Encoding cabeçalho) ou tipo de mídia (como especificado no
Content-Type cabeçalho) da resposta, a entidade ou organismo do
resposta, a menos que esse código Aviso já aparece na resposta.
299 aviso Diversos persistente
O aviso de texto pode incluir informações arbitrárias que será apresentado
para um usuário humano, ou registrado. O sistema recebe esta advertência deve
Não tomar qualquer ação automatizada.
Se uma aplicação envia uma mensagem com um ou mais cabeçalhos de aviso
cuja versão é HTTP/1.0 ou inferior, o remetente deve incluir no
cada valor de aviso-a advertir data que coincide com a data da resposta.
Se uma aplicação recebe uma mensagem com um aviso de que o valor
inclui um warn data, e que alertam data é diferente da data
valor da resposta, então esse valor de alerta deve ser excluído
a mensagem antes de armazenagem, expedição, ou usá-lo. (Isso evita
conseqüências ruins de cache ingênua de campos de cabeçalho de aviso.) Se todos os
do aviso-valores são excluídos por esse motivo, o cabeçalho de Atenção
Devem ser excluídos também.
14,47 WWW-Authenticate
A WWW-Authenticate campo de cabeçalho de resposta deve ser incluído em 401
(Não autorizada) mensagens resposta. O valor do campo consiste na
pelo desafio que indica o esquema de autenticação (s) e
parâmetros aplicáveis ao Pedido-URI.
WWW-Authenticate = “WWW-Authenticate”: “um desafio #
O processo de autenticação de acesso HTTP é descrito em “HTTP
Autenticação de Usuário: Basic e Digest Authentication Access “[43].
agentes são aconselhados a tomar cuidados especiais na análise do WWW-
Autenticar valor do campo como ele pode conter mais de um desafio,
ou se houver mais de um campo de cabeçalho WWW-Authenticate é fornecido, o
conteúdo de um desafio por si só pode conter uma lista separada por vírgulas
parâmetros de autenticação.
15 Considerações de Segurança
Esta secção destina-se a informar os desenvolvedores de aplicativos, as informações
provedores e usuários das limitações de segurança em HTTP/1.1 como
descrito por este documento. A discussão não inclui
soluções definitivas para os problemas identificados, apesar de não fazer
algumas sugestões para reduzir os riscos de segurança.
Fielding, et al. Standards Track [Página 150]
?
HTTP/1.1 RFC 2616 junho 1999
15,1 Informações Pessoais
HTTP clientes são muitas vezes a par de grandes quantidades de informações pessoais
(Por exemplo, o nome do usuário, local, endereço de e-mail, senhas, criptografia
chaves, etc), e deve ter muito cuidado para evitar intencional
vazamento de informações através do protocolo HTTP para outras fontes.
Nós fortemente recomendamos que uma interface conveniente prever
para o usuário controlar a disseminação dessas informações, e que
designers e implementadores ser particularmente cuidadoso nesta área.
A história mostra que os erros nesta área muitas vezes criam graves de segurança
e / ou problemas de privacidade e gerar publicidade altamente negativas para a
implementador da empresa.
15.1.1 Abuso de informações de log do servidor
Um servidor está em condições de salvar os dados pessoais de um usuário
solicitações que possam identificar os padrões de leitura ou assuntos de
juros. Esta informação é claramente de natureza confidencial e sua
tratamento pode ser restringida por lei em alguns países. Pessoas que usam
o protocolo HTTP para fornecer dados são responsáveis por garantir que
material não seja distribuído sem permissão de qualquer
indivíduos que são identificáveis com os resultados publicados.
15.1.2 A transferência de informações confidenciais
Como qualquer outro protocolo genérico de transferência de dados, o HTTP não pode regular a
conteúdo dos dados que são transferidos, nem existe a priori qualquer
método de determinação da sensibilidade de uma determinada peça de
informação no contexto de qualquer pedido determinado. Por isso,
As candidaturas deverão fornecer tanto controle sobre essas informações como
possível para o provedor de informações. Quatro campos de cabeçalho são
menção especial merece, neste contexto: Server, Via, e De Referer.
Revelar a versão de software específico do servidor pode permitir a
máquina do servidor para se tornar mais vulnerável a ataques contra software
que é conhecido por conter falhas de segurança. Os implementadores devem fazer a
Servidor de campo de cabeçalho uma opção configurável.
Proxies que servem como um portal através de um firewall de rede deve
tomar precauções especiais quanto à transferência de informações de cabeçalho
que identifica os hosts atrás do firewall. Em particular,
Deve remover ou substituir com versões higienizadas, os campos Via
gerada por trás do firewall.
O cabeçalho Referer permite leitura de padrões a serem estudadas e reverso
links desenhada. Embora possa ser muito útil, o seu poder pode ser abusado
Se os detalhes do usuário não são separados das informações contidas no
Fielding, et al. Standards Track [Página 151]
?
HTTP/1.1 RFC 2616 junho 1999
o Referer. Mesmo quando as informações pessoais que tenha sido removido, o
cabeçalho Referer URI pode indicar um documento privado, cuja
publicação seria inadequado.
As informações enviadas no campo de colidir com o usuário
interesses privados ou as suas políticas de segurança do site, e por isso
NÃO DEVE ser transmitida sem que o usuário seja capaz de desativar,
habilitar e modificar o conteúdo do campo. O usuário deve ser capaz
para definir o conteúdo deste campo dentro de uma preferência do usuário ou
configuração padrão do aplicativo.
Sugerimos que, apesar de não exigir que uma interface conveniente alternar
ser fornecido ao usuário habilitar ou desabilitar o envio de de e
informações Referer.
O User-Agent (art. 14,43) ou Server (seção 14.38) cabeçalho
campos podem às vezes ser usados para determinar se um determinado cliente ou
servidor tem um buraco de segurança particular que possa ser explorado.
Infelizmente, esta mesma informação é frequentemente utilizado para outros valiosos
fins para os quais HTTP atualmente não tem nenhum mecanismo melhor.
15.1.3 Informações Encoding Sensitive em URI’s
Devido a origem de um link pode ser privado de informações ou pode
revela uma outra fonte de informação privada, é fortemente
recomendável que o usuário poderá selecionar ou não o
campo Referer é enviado. Por exemplo, um cliente poderia ter um browser
interruptor para navegar abertamente / anonimamente, o que
respectivamente, ativar / desativar o envio de e Referer De
da informação.
Clientes não deve incluir um campo de cabeçalho Referer em um (não seguro)
HTTP pedido se refere a página foi transferida com um seguro
protocolo.
Autores de serviços que usam o protocolo HTTP não deve usar GET
formulários com base para a apresentação de dados sensíveis, porque isto
porque que esses dados sejam codificados em Pedido-URI. Muitos já existente
servidores, proxies, e os agentes do usuário irá registrar o URI de solicitação em alguns
lugar onde poderá ser visível a terceiros. Os servidores podem usar
envio do formulário POST baseados em vez
15.1.4 Problemas de privacidade Connected Aceitar Cabeçalhos
Aceitar o pedido-headers pode revelar informações sobre o usuário para todos os
servidores que são acessados. O cabeçalho Accept-Language, em especial
pode revelar as informações do usuário que consideram ser de particular
natureza, porque a compreensão das línguas em particular é frequentemente
Fielding, et al. Standards Track [Página 152]
?
HTTP/1.1 RFC 2616 junho 1999
fortemente correlacionada com a pertença a um grupo étnico específico.
Os agentes que oferecem a opção de configurar o conteúdo de um
cabeçalho Accept-Language para ser enviado em cada pedido são fortemente
incentivados a deixar o processo de configuração incluem uma mensagem que
torna o usuário consciente da perda de privacidade envolvidos.
Uma abordagem que limite a perda da privacidade seria um agente do usuário
omitir o envio de cabeçalhos Accept-Language, por padrão, e pedir
o usuário se deve ou não iniciar o envio de cabeçalhos Accept-Language a uma
servidor, se ele detecta, procurando por qualquer resposta Vary header-campos
gerado pelo servidor, que tal envio pode melhorar a qualidade
do serviço.
Elaborar aceitar usuário personalizadas campos de cabeçalho enviado em cada pedido,
em especial se estas incluem os valores de qualidade, pode ser usado por servidores
como identificadores de utilizador relativamente confiável e de longa duração. Tais usuário
identificadores que permitem aos provedores de conteúdo para fazer monitoramento de cliques,
e permitiria que os provedores de conteúdo para colaborar jogo entre servidores
clique trilhas ou forma submissões de usuários individuais. Observe que para
muitos usuários não atrás de um proxy, o endereço de rede do host
executar o agente de usuário também servirá como um usuário de longa duração
identificador. Em ambientes onde proxies são usados para aumentar
privacidade, os agentes devem ser conservador em aceitar a oferta
opções de configuração de cabeçalho para os usuários finais. Como uma extrema privacidade
medida, proxies poderiam filtrar a aceitar cabeçalhos retransmitida pedidos.
agentes objetivo geral do usuário que proporcionam um elevado grau de cabeçalho
configurabilidade deve alertar os usuários sobre a perda de privacidade que pode
estar envolvidos.
15,2 ataques baseados em nomes de arquivo e caminho
Implementações de servidores HTTP origem deve ter o cuidado de restringir
os documentos retornados por pedidos HTTP a ser apenas os que foram
destina-se pelos administradores do servidor. Se um servidor HTTP traduz
URIs HTTP diretamente chamadas de sistema de arquivos, o servidor deve ter
especial cuidado para não servir arquivos que não estavam destinados a ser
entregues aos clientes HTTP. Por exemplo, UNIX, Microsoft Windows, e
utilizar outros sistemas operacionais “..” como um componente para indicar um caminho
nível acima do diretório atual. Em tal sistema, um servidor HTTP
servidor deve proibir qualquer construção desse tipo no-Request URI se
de outra forma, permitir o acesso a um recurso de fora aqueles que se destinam a
ser acessível através do servidor HTTP. Da mesma forma, os arquivos destinados a
referência apenas internamente para o servidor (como controle de acesso
, arquivos de configuração e código de script) devem ser protegidos contra
recuperação inadequada, pois pode conter minúsculas
da informação. A experiência tem demonstrado que pequenos bugs no servidor HTTP, tais
implementações transformaram-se em riscos de segurança.
Fielding, et al. Standards Track [Página 153]
?
HTTP/1.1 RFC 2616 junho 1999
15,3 de DNS Spoofing
Clientes que usam HTTP dependem muito do Domain Name Service, e são
assim, geralmente propensas a ataques de segurança com base na deliberada
mis-associação de endereços IP e nomes DNS. Os clientes precisam ser
cautelosos em assumir a manutenção da validade de um número de IP / nome DNS
associação.
Em particular, os clientes HTTP deve confiar em seu nome para resolver
confirmação de um número IP / Associação nome DNS, ao invés de
caching o resultado de pesquisas anteriores nome do host. Muitas plataformas
já pode cache host pesquisas de nome local, quando apropriado, e
Eles devem ser configurados para fazer isso. É bom para essas pesquisas para
ser armazenada em cache, no entanto, somente quando o TTL (Time To Live) informações
relatado pelo servidor de nomes faz com que seja provável que o cache
informações serão úteis.
Se os clientes HTTP cache os resultados das pesquisas de nome do host, a fim de
alcançar uma melhoria de desempenho, elas devem observar o TTL
informações transmitidas pelo DNS.
Se os clientes HTTP não observar essa regra, eles podem ser falsificados, quando
um servidor previamente acessada mudanças de endereço IP. Como rede
renumeração deverá tornar-se cada vez mais comum [24], a
possibilidade de este tipo de ataque vai crescer. Observando este
exigência, portanto, reduz a vulnerabilidade de segurança em potencial.
Esta exigência também melhora o comportamento de balanceamento de carga de clientes
para servidores replicados usando o mesmo nome DNS e reduz a
probabilidade de falha experimentando um usuário em acessar sites que
utilizar essa estratégia.
15,4 Headers Localização e falsificação
Se um único servidor suporta múltiplas organizações que não confiam
um outro, em seguida, deve verificar os valores de Localização e de conteúdo
Localização cabeçalhos nas respostas que são geradas sob o controle de
referidas organizações, para se certificar de que eles não tentam
invalidar os recursos sobre os quais eles não têm autoridade.
Questões 15,5 Content-Disposition
RFC 1806 [35], a partir do qual muitas vezes o executado Content-Disposition
(Ver secção 19.5.1) no cabeçalho HTTP é derivado, tem um número muito
sérias considerações de segurança. Content-Disposition não faz parte do
o padrão HTTP, mas já é amplamente aplicada, estamos
documentando a sua utilização e riscos para implementadores. Consulte RFC 2183 [49]
(Que atualiza RFC 1806) para mais detalhes.
Fielding, et al. Standards Track [Página 154]
?
HTTP/1.1 RFC 2616 junho 1999
15,6 credenciais de autenticação e Idle clientes
Os clientes existentes e os agentes do usuário HTTP normalmente mantêm a autenticação
informações indefinidamente. HTTP/1.1. não fornece um método para um
servidor para clientes diretos para descartar essas credenciais em cache. Isto é
um defeito significativo que exige novas prorrogações HTTP.
Circunstâncias em que o cache de credenciais podem interferir com a
modelo de aplicativo de segurança incluem, mas não estão limitados a:
– Clientes que têm estado parados por um longo período seguinte
qual o servidor pode querer causar o cliente para o reprompt
usuário para credenciais.
– As aplicações que incluem uma indicação encerramento da sessão
(Como um logout ‘ou `commit’ botão em uma página), após o que
o servidor da aplicação «sabe» que há
razão adicional para o cliente a manter as credenciais.
Esta está a ser estudada em separado. Há uma série de trabalhos
arounds a partes do problema, e nós incentivamos o uso de
proteção de senha no protetor de tela, tempo ocioso-outs e outros
métodos que reduzem os problemas de segurança inerentes a este
problema. Em particular, os agentes que as credenciais de cache são
encorajados a fornecer um mecanismo de fácil acesso para o descarte
credenciais em cache sob controle do usuário.
15,7 Proxies e Caching
Pela sua própria natureza, proxies HTTP são homens-in-the-middle, e
representar uma oportunidade para ataques man-in-the-middle. Compromisso de
os sistemas em que as procurações executado pode resultar em graves de segurança
e problemas de privacidade. Proxies ter acesso aos relacionados com a segurança
informações, informações pessoais sobre usuários individuais e
organizações, e informações confidenciais pertencentes aos usuários e
provedores de conteúdo. Um proxy comprometida, ou um proxy implementadas ou
configurado sem levar em conta considerações de segurança e privacidade,
podem ser utilizados na prática de um vasto leque de potenciais ataques.
operadores Proxy deve proteger os sistemas em que são executados como proxies
iriam proteger todo o sistema que contém ou transporta sensíveis
da informação. Em especial, informações de log, reuniram-se na proxies vezes
contém informações pessoais altamente sensíveis e / ou informações
sobre as organizações. Log informações devem ser cuidadosamente guardada, e
orientações adequadas para o uso desenvolvido e seguido. (Seção
15.1.1).
Fielding, et al. Standards Track [Página 155]
?
HTTP/1.1 RFC 2616 junho 1999
proxies de cache adicional fornecer vulnerabilidades em potencial, pois
o conteúdo do cache representar um alvo atraente para
exploração mal-intencionado. Porque o conteúdo cache persistem após um HTTP
pedido está completo, um ataque à cache pode revelar informações
muito tempo após o usuário acredita que a informação tenha sido removido
da rede. Portanto, o conteúdo de cache deve ser protegida como
informações confidenciais.
implementadores Proxy deve considerar a segurança e privacidade
implicações das suas decisões de design e codificação, e do
opções de configuração que eles fornecem aos operadores de proxy (especialmente o
configuração padrão).
Usuários de uma necessidade proxy estar ciente de que eles não estão mais confiável do que
as pessoas que dirigem o proxy, HTTP em si não pode resolver este problema.
A utilização criteriosa de criptografia, quando for o caso, podem ser suficientes para
proteção contra uma ampla gama de segurança e ataques de privacidade. Tal
criptografia está fora do escopo da especificação HTTP/1.1.
15.7.1 Ataques de negação de serviço em Proxies
Eles existem. Eles são difíceis de defender. A investigação continua.
Cuidado.
16 Agradecimentos
Esta especificação faz uso pesado da BNF aumentada e genérico
construções definidas por David H. Crocker para a RFC 822 [9]. Da mesma forma,
reutiliza muitas das definições fornecidas por Nathaniel Borenstein e
Ned Freed para MIME [7]. Esperamos que a sua inclusão neste
especificação vai ajudar a reduzir a confusão do passado sobre a relação
entre HTTP e formatos de mensagens de correio da Internet.
O protocolo HTTP tem evoluído consideravelmente nos últimos anos. Tem
beneficiou de uma grande comunidade de desenvolvedores e ativo – os muitos
pessoas que tenham participado na lista de discussão www-talk – e é
essa comunidade que tem sido mais responsável pelo sucesso de
HTTP e da World Wide Web em geral. Marc Andreessen, Robert
Cailliau, Daniel W. Connolly, Denny Bob, Frank John, Jean-Francois
Groff, Phillip Hallam-Baker M., Hakon Lie W., Ari Luotonen, Rob
McCool, Montulli Lou, Raggett Dave, Tony Sanders, e Marc
VanHeyningen merecem especial reconhecimento por seus esforços em
definição de aspectos iniciais do protocolo.
Este documento tem beneficiado muito com os comentários de todos os
participação no GT-HTTP. Além dos já mencionados,
as seguintes pessoas contribuíram para esta especificação:
Fielding, et al. Standards Track [Página 156]
?
HTTP/1.1 RFC 2616 junho 1999
Gary Ross Patterson Adams
Harald Lunde Albert Tveit Alvestrand
Keith John Ball C. Mallery
Behlendorf Brian Jean-Philippe Martin Flatin-
Paul Mitra Burchard
David Morris Maurizio Codogno
Mike Nicol Gavin Cowlishaw
Roman Bill Perry Czyborra
Michael Perry Dolan Jeffrey A.
David J. Scott Powers Fiander
Alan Rees Freier Owen
Marc Hedlund Luigi Rizzo
Greg Herlihy David Robinson
Koen Marc Salomon Holtman
Alex Rich Salz Hopmann
Bob Jernigan Allan Schiffman M.
Shel Seidman Jim Kaphan
Rohit Shotton Chuck Khare
John Klensin Eric Sink W.
Martijn Koster E. Simon Spero
Alexei Kosut Richard N. Taylor
David M. Kristol Robert Thau S.
Daniel Bill LaLiberte (BearHeart) Weinman
Ben Laurie Francois Yergeau
Paul J. Leach Zurko Mary Ellen
DuBois Daniel Josh Cohen
Grande parte do conteúdo e da apresentação do projeto de cache é devido a
sugestões e comentários de pessoas, incluindo: Shel Kaphan,
Paul Leach, Holtman Koen, David Morris, e Masinter Larry.
A maioria das especificações das faixas é baseado no trabalho feito originalmente
por Ari Luotonen e John Franks, com entrada adicional de Steve
Zilles.
Graças aos “homens da caverna”, de Palo Alto. Você sabe quem você é.
Jim Gettys (o atual editor do presente documento) desejos em particular
agradecer Roy Fielding, o editor anterior do presente documento, juntamente
com John Klensin, Mogul Jeff, Paul Leach, Dave Kristol, Koen
Holtman, Frank John, Josh Cohen, Hopmann Alex, Lawrence Scott, e
Larry Masinter pela sua ajuda. E os agradecimentos vão especialmente para Jeff
Mogul e Lawrence Scott para realizar o “dever / poder / dever de auditoria”.
Fielding, et al. Standards Track [Página 157]
?
HTTP/1.1 RFC 2616 junho 1999
O Grupo Apache, Anselm Baird-Smith, autor de Jigsaw, e Henrik
Frystyk implementado RFC 2068 adiantado, e queremos agradecer-lhes pela
descoberta de muitos dos problemas que este documento tenta
retificar.
17 Referências
[1] Alvestrand, H., “Tags para a identificação das Línguas”, RFC
1766, Março de 1995.
[Anklesaria 2], F., McCahill, M., Lindner, P. Johnson, D., Torrey,
D. e B. Alberti, “O Gopher Internet Protocol (uma distribuídos
pesquisa de documentos e protocolo de recuperação) “, RFC 1436, março de 1993.
[3] Berners-Lee, T., “Universal Resource Identificadores na WWW”, RFC
1630, Junho de 1994.
[4] Berners-Lee, T., Masinter, L. e M. McCahill, “Uniform Resource
Localizadores (URL) “, RFC 1738, dezembro de 1994.
[5] Berners-Lee, T. e D. Connolly, “Hypertext Markup Language –
2.0 “, RFC 1866, novembro de 1995.
[6] Berners-Lee, T., Fielding, R. e H. Frystyk, “Hypertext Transfer
Protocol – HTTP/1.0 “, RFC 1945, maio de 1996.
[7] Freed, N. e N. Borenstein, “Multipurpose Internet Mail
Extensions (MIME) Part One: Formato da Internet Message Corpos “,
RFC 2045, novembro de 1996.
[Braden 8], R., “Requisitos para a Internet Hosts – Comunicação
Layers “, STD 3, RFC 1123, outubro de 1989.
[9] Crocker, D., “Standard para o formato de ARPA Internet Texto
Mensagens “, STD 11, RFC 822, agosto de 1982.
[10] Davis, F., Kahle, B., Morris, H., Santos, J., Shen, T., Wang, R.,
Sui, J. e M. Grinbaum, “Prototype WAIS Protocol Interface
Especificação funcional “(v1.5), Thinking Machines
Corporation, de abril de 1990.
[Fielding 11], R., “Uniform Resource localizadores Relativa”, RFC 1808,
Junho de 1995.
[Horton 12], M. e R. Adams, “Norma para Intercâmbio de USENET
Mensagens “, RFC 1036, dezembro de 1987.
Fielding, et al. Standards Track [Página 158]
?
HTTP/1.1 RFC 2616 junho 1999
[Kantor 13], B. e P. Lapsley, “Network News Transfer Protocol”, RFC
977, Fevereiro de 1986.
[Moore 14], K., “MIME (Multipurpose Internet Mail Extensions) Parte
Três: Extensões cabeçalho da mensagem de texto não-ASCII “, RFC 2047,
Novembro de 1996.
[15] Nebel, E. e L. Masinter, “Form-Based File Upload em HTML”, RFC
1867, Novembro de 1995.
Postel [16], J., “Simple Mail Transfer Protocol”, STD 10, RFC 821,
Agosto de 1982.
Postel [17], J., “Media Type processo de registo”, RFC 1590,
Novembro de 1996.
Postel [18], J. e J. Reynolds, “File Transfer Protocol”, STD 9, RFC
959, Outubro de 1985.
[19] Rocha, J. e J. Postel, “Assigned Numbers”, STD 2, RFC 1700,
Outubro de 1994.
[20] Sollins, K. e L. Masinter, “Requisitos Funcionais para
Uniform Resource Names “, RFC 1737, dezembro de 1994.
[21] US-ASCII. Coded Character Set – Código 7-Bit American Standard para
Intercâmbio de informações. Standard ANSI X3.4-1986, ANSI, 1986.
[22] ISO-8859. International Standard – Processamento de Informações –
8-bit Single-Byte Coded conjuntos de caracteres gráficos –
Parte 1: Alfabeto latino No. 1, ISO-8859-1: 1987.
Parte 2: Alfabeto latino No. 2, ISO-8859-2, 1987.
Parte 3: Alfabeto latino No. 3, ISO-8859-3, de 1988.
Parte 4: Alfabeto latino No. 4, ISO-8859-4, 1988.
Parte 5: alfabeto / América cirílico, ISO-8859-5, de 1988.
Parte 6: América / alfabeto árabe, ISO 8859-6, 1987.
Parte 7: alfabeto / latim grego, ISO-8859-7, 1987.
Parte 8: América / alfabeto hebraico, ISO-8859-8, 1988.
Parte 9: Alfabeto latino No. 5, ISO-8859-9, 1990.
[23] Meyers, J. e M. Rose, “o campo de cabeçalho Content-MD5”, RFC
1864, Outubro de 1995.
[Carpenter 24], B. e Y. Rekhter, Renumbering “Necessidades de Trabalho”, RFC
1900, fevereiro 1996.
[25], Deutsch, P., “arquivo GZIP versão de especificação de formato de 4,3”, RFC
1952, Maio de 1996.
Fielding, et al. Standards Track [Página 159]
?
HTTP/1.1 RFC 2616 junho 1999
[26] Venkata Padmanabhan N., e Jeffrey C. Mogul. “HTTP Melhorar
Latência “, Redes de Computadores e Sistemas ISDN, v. 28, pp. 25-35,
Dezembro 1995. Ligeiramente versão revista de papel em Proc. 2
Conferência Internacional WWW ’94: Mosaic e da Web, outubro de 1994,
que está disponível em
http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/HTTPLat
ency.html.
[27] Touch Joe, John Heidemann e Obraczka Katia. “Análise de HTTP
Performance “, <URL: http://www.isi.edu/touch/pubs/http-perf96/>,
ISI Research ISI/RR-98-463 Report, relatório (original datada de agosto
1996), USC / Information Sciences Institute, agosto de 1998.
[28] Mills, D., “Network Time Protocol (Versão 3) Especificação,
Implementação e “Análise, 1305 RFC, Março de 1992.
[Deutsch 29], P., “deflacionar Compressed Data Format Specification
versão 1.3 “, RFC 1951, maio de 1996.
[30] S. Spero, “Análise de Problemas HTTP Performance”
http://sunsite.unc.edu/mdma-release/http-prob.html.
[31], Deutsch, P. e J. Gailly, “ZLIB compactados formato dos dados
Specification versão 3.3 “, RFC 1950, maio de 1996.
[32] Franks, J., Hallam-Baker, P. Hostetler, J., Leach, P.,
Luotonen, A., Sink, E. e L. Stewart “, uma extensão de HTTP:
Autenticação Digest Access “, RFC 2069, janeiro de 1997.
[Fielding 33], R., Gettys, J., Mogul, J., Frystyk, H. e T.
Berners-Lee, “Hypertext Transfer Protocol – HTTP/1.1”, RFC
2068, Janeiro de 1997.
[34] Bradner, S., “palavras-chave para uso em RFCs para indicar Requisito
Níveis “, BCP 14, RFC 2119, março de 1997.
[35] Troost, R. e Dorner, S., “Comunicar Apresentação
Informações em mensagens na Internet: O Content-Disposition
Cabeçalho “, RFC 1806, junho de 1995.
[Mogul 36], J., Fielding, R., Gettys, J. e H. Frystyk, “Uso e
Interpretação dos números HTTP Version “, RFC 2145, maio de 1997.
[Jg639]
[Palme 37], J., “Message Headers Common Internet”, RFC 2076, fevereiro
1997. [Jg640]
Fielding, et al. Standards Track [Página 160]
?
HTTP/1.1 RFC 2616 junho 1999
[38] Yergeau, F., “UTF-8, um formato de transformação Unicode e
“ISO-10646, RFC 2279, janeiro de 1998. [Jg641]
[39] Nielsen, HF, Gettys, J., Baird-Smith, A., Prud’hommeaux, E.,
Mentira, H. e C. Lilley. “Network Performance Efeitos das
HTTP/1.1, CSS1, e PNG, “Proceedings of ACM SIGCOMM 97, Cannes
França, Setembro de 1997. [Jg642]
[40] Freed, N. e N. Borenstein, “Multipurpose Internet Mail
Extensions (MIME) Part Two: Tipos de Mídia de Novembro “, RFC 2046,
1996. [Jg643]
[41] Alvestrand, H., “Política IETF em conjuntos de caracteres e Línguas”,
BCP 18, RFC 2277, janeiro de 1998. [Jg644]
[42] Berners-Lee, T., Fielding, R. e L. Masinter, “Uniform Resource
Identifiers (URI): Generic Syntax e semântica “, RFC 2396,
Agosto de 1998. [Jg645]
[43] Franks, J., Hallam-Baker, P. Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., Sink, E. e L. Stewart, “HTTP
Autenticação: Basic e Digest Authentication Access “, RFC
2617, Junho de 1999. [Jg646]
[44] Luotonen, A., “protocolos TCP Tunneling feita através de Web proxy
servidores, “Work in Progress. [jg647]
[45] Palme, J. e A. Hopmann “MIME Encapsulation E-mail do
Documentos agregados, tais como HTML (MHTML) “, RFC 2110, março
1997.
[Bradner 46], S., “A Internet Standards Process – Revisão 3”, BCP
9, RFC 2026, outubro de 1996.
[Masinter 47], L., “Hyper Text Control Protocol Coffee Pot
(HTCPCP/1.0) “, RFC 2324, 01 de abril de 1998.
[48] Freed, N. e N. Borenstein, “Multipurpose Internet Mail
Extensions (MIME) Parte V: Critérios de Conformidade e exemplos “
RFC 2049, novembro de 1996.
[Troost 49], R., Dorner, S. e K. Moore, “Comunicar Apresentação
Informações em mensagens na Internet: O cabeçalho Content-Disposition
Campo “, RFC 2183, agosto de 1997.
Fielding, et al. Standards Track [Página 161]
?
HTTP/1.1 RFC 2616 junho 1999
Endereços de 18 autores
Roy Fielding T.
Informação e Ciência da Computação
University of California, Irvine
Irvine, CA 92697-3425, E.U.A.
Fax: +1 (949) 824-1715
EMail: fielding@ics.uci.edu
James Gettys
World Wide Web Consortium
MIT Laboratório de Ciência da Computação
545 Tecnologia Square
Cambridge, MA 02139, E.U.A.
Fax: +1 (617) 258 8682
EMail: jg@w3.org
Jeffrey Mogul C.
Laboratório de Pesquisa Western
Compaq Computer Corporation
250 University Avenue
Palo Alto, Califórnia, 94305, E.U.A.
EMail: mogul@wrl.dec.com
Henrik Nielsen Frystyk
World Wide Web Consortium
MIT Laboratório de Ciência da Computação
545 Tecnologia Square
Cambridge, MA 02139, E.U.A.
Fax: +1 (617) 258 8682
EMail: frystyk@w3.org
Larry Masinter
Xerox Corporation
Hill Road 3333 Coyote
Palo Alto, CA 94034, E.U.A.
EMail: masinter@parc.xerox.com
Fielding, et al. Standards Track [Página 162]
?
HTTP/1.1 RFC 2616 junho 1999
Paul Leach J.
Microsoft Corporation
1 Way Microsoft
Redmond, WA 98052, E.U.A.
EMail: paulle@microsoft.com
Tim Berners-Lee
Director, World Wide Web Consortium
MIT Laboratório de Ciência da Computação
545 Tecnologia Square
Cambridge, MA 02139, E.U.A.
Fax: +1 (617) 258 8682
EMail: timbl@w3.org
Fielding, et al. Standards Track [Página 163]
?
HTTP/1.1 RFC 2616 junho 1999
19 Apêndices
19,1 mensagem Internet Media Tipo http / e aplicação http /
Além de definir o protocolo HTTP/1.1, este documento serve
como a especificação do tipo de mídia na Internet “mensagem / http” e
“Http / aplicação”. A mensagem do tipo http / pode ser usado para incluir um
única solicitação HTTP ou uma mensagem de resposta, desde que obedeça a
restrições MIME para todos “mensagem” sobre tipos de linha de comprimento e
codificações. O tipo http / aplicação pode ser usada para incluir um
pipeline de uma ou mais solicitações HTTP ou mensagens de resposta (não
misturados). A seguir está a ser registrado com a IANA [17].
Tipo de mídia nome: mensagem
Media subtipo nome: http
Os parâmetros obrigatórios: none
Parâmetros opcionais: versão MsgType
Versão: O número de HTTP-Version da mensagem incluído
(Por exemplo, “1.1”). Se não estiver presente, a versão pode ser
determinada a partir da primeira linha do corpo.
MsgType: O tipo de mensagem – “pedido” ou “resposta”. Se não
Actualmente, o tipo pode ser determinado desde o primeiro
linha do corpo.
Codificação considerações: apenas “7bit”, “8bit”, ou “binário” são
permitido
As considerações de segurança: nenhuma
Media nome Type: application
Media subtipo nome: http
Os parâmetros obrigatórios: none
Parâmetros opcionais: versão MsgType
Versão: O número de HTTP-Version das mensagens fechados
(Por exemplo, “1.1”). Se não estiver presente, a versão pode ser
determinada a partir da primeira linha do corpo.
MsgType: O tipo de mensagem – “pedido” ou “resposta”. Se não
Actualmente, o tipo pode ser determinado desde o primeiro
linha do corpo.
Codificação considerações: As mensagens HTTP fechados por este tipo
Está em formato “binário, o uso de um adequado
Content-Transfer-Encoding é necessária quando
transmitido via e-mail.
As considerações de segurança: nenhuma
Fielding, et al. Standards Track [Página 164]
?
HTTP/1.1 RFC 2616 junho 1999
19,2 Internet Media Tipo multipart / byteranges
Quando uma mensagem de resposta HTTP 206 (Partial Content) inclui o
conteúdo de vários intervalos (uma resposta a um pedido de vários
não sobrepõem), estes são transmitidos como um multipart
corpo da mensagem. O tipo de mídia para esse efeito é chamado
“Multipart / byteranges”.
O multipart / byteranges tipo de mídia inclui duas ou mais partes, cada uma
com os seus próprios campos Content-Type e Content-Range. O necessário
parâmetro especifica o limite de seqüência de fronteira usadas para separar
cada parte do corpo.
Media nome Type: multipart
Media subtipo nome: byteranges
Os parâmetros obrigatórios: limite
Parâmetros opcionais: nenhum
Codificação considerações: apenas “7bit”, “8bit”, ou “binário” são
permitido
As considerações de segurança: nenhuma
Por exemplo:
HTTP/1.1 206 Conteúdo parcial
Date: Wed, 15 de novembro de 1995 06:25:24 GMT
Last-Modified: Wed, 15 nov 1995 04:58:08 GMT
Content-type: multipart / byteranges; fronteira = THIS_STRING_SEPARATES
– THIS_STRING_SEPARATES
Content-type: application / pdf
Conteúdo de gama: bytes 500-999/8000
… A primeira faixa …
– THIS_STRING_SEPARATES
Content-type: application / pdf
Conteúdo de gama: bytes 7000-7999/8000
… O intervalo de segunda
– THIS_STRING_SEPARATES –
Notas:
1) CRLFs adicionais podem preceder a string em primeiro lugar na fronteira
entidade.
Fielding, et al. Standards Track [Página 165]
?
HTTP/1.1 RFC 2616 junho 1999
2) Embora RFC 2046 [40] permite a seqüência de fronteira a ser
citado, algumas implementações existentes lidar com um limite citado
string incorretamente.
3) Um certo número de navegadores e servidores foram codificadas a um projecto inicial
da especificação byteranges usar um tipo de mídia
multipart / x-byteranges, que é quase, mas não muito
compatível com a versão documentada na HTTP/1.1.
19,3 aplicações tolerantes
Embora este documento especifica os requisitos para a geração
HTTP/1.1 de mensagens, nem todos os aplicativos serão corretos em sua
implementação. Recomendamos, portanto, que as aplicações operacionais
ser tolerante com desvios sempre que os desvios podem ser
interpretado de forma inequívoca.
Os clientes devem ser tolerantes em analisar o Status-Line e servidores
Tolerante ao analisar o Pedido-Line. Em particular, devem
aceitar qualquer quantia de SP ou caracteres HT entre os campos, apesar de
apenas um único SP é necessária.
O terminador de linha para os campos de cabeçalho da mensagem é a seqüência CRLF.
No entanto, recomendamos que os pedidos, ao analisar os cabeçalhos tal,
reconhecer um LF único como um terminador de linha e ignorar o CR líder.
O conjunto de caracteres de uma entidade do corpo deve ser rotulado como o mais baixo
denominador comum dos códigos de caracteres usados no âmbito desse órgão, com
a ressalva de que não rotular a entidade é preferido sobre rotulagem
da entidade com os rótulos US-ASCII ou ISO-8859-1. Consulte a seção 3.7.1
e 3.4.1.
Regras adicionais para requisitos de análise e codificação das datas
e outros problemas potenciais com codificações data incluem:
– Os clientes HTTP/1.1 e caches deve presumir que uma data RFC-850
o que parece ser mais de 50 anos no futuro, é na verdade
no passado (o que ajuda a resolver o ano de “2000” problema).
– Um HTTP/1.1 implementação pode representar internamente uma analisada
Expira data, mais cedo do que o valor adequado, mas não deve
internamente representam uma Expira analisado como data posterior à
valor adequado.
– Todos os cálculos relacionados com vencimento deve ser feito em GMT. O
fuso horário local não deverão influir no cálculo ou comparação
de idade ou tempo de expiração.
Fielding, et al. Standards Track [Página 166]
?
HTTP/1.1 RFC 2616 junho 1999
– Se um cabeçalho HTTP incorretamente carrega um valor de data com um tempo
zona diferente GMT, ele deve ser convertido em Brasília com o
mais conservadora possível conversão.
19,4 Diferenças entre as entidades HTTP e RFC 2045 Entidades
HTTP/1.1 usa muitos dos construtos definidos para Internet Mail (RFC
822 [9]) e Polivalentes Internet Mail Extensions (MIME) [7] para
permitirá que as entidades devem ser transmitidos em uma variedade de abrir
representações e com mecanismos extensíveis. No entanto, RFC 2045
discute-mail, HTTP e tem algumas características diferentes das
aqueles descritos na RFC 2045. Estas diferenças foram cuidadosamente escolhidas
para otimizar o desempenho em conexões binárias, permitindo maior
liberdade na utilização de novos tipos de mídia, para fazer comparações data
mais fácil, e reconhecer a prática de alguns servidores HTTP cedo
e clientes.
Este apêndice descreve áreas específicas em que difere do HTTP RFC
2045. Proxies e gateways para ambientes MIME rigorosa, deverá ser
cientes dessas diferenças e fornecer as conversões adequadas
sempre que necessário. Proxies e gateways de ambientes MIME para HTTP
também precisa estar ciente das diferenças, porque algumas conversões
pode ser necessária.
19.4.1 MIME-Version
HTTP não é um protocolo MIME-compliant. No entanto, poderá HTTP/1.1 mensagens
incluir um único MIME-Version campo de cabeçalho-geral para indicar o
versão do protocolo MIME foi usado para construir a mensagem. Utilização
do campo de cabeçalho MIME-Version indica que a mensagem está em
plena conformidade com o protocolo MIME (conforme definido na RFC 2045 [7]).
Proxies / gateways são responsáveis pelo cumprimento integral (onde
possível) ao exportar HTTP mensagem MIME ambientes rigorosos.
MIME-Version = “MIME-Version”: “1” * DIGIT “. 1 * DIGIT
MIME versão “1.0” é o padrão para uso em HTTP/1.1. No entanto,
HTTP/1.1 análise da mensagem e semânticas são definidas por este documento
e não a especificação MIME.
19.4.2 Conversão para a forma canônica
RFC 2045 [7], exige que uma entidade de correio da Internet ser convertido em
forma canônica antes de serem transferidos, conforme descrito na seção 4
da RFC 2049 [48]. O ponto 3.7.1 do presente documento descreve as formas
permitido para os subtipos do texto “tipo de mídia quando são transmitidas
HTTP. RFC 2.046 exige que o conteúdo de um tipo de texto “representam
como quebras de linha CRLF e proíbe o uso de CR ou LF fora de linha
Fielding, et al. Standards Track [Página 167]
?
HTTP/1.1 RFC 2616 junho 1999
seqüências de pausa. HTTP permite CRLF, CR nua, nua e LF para indicar uma
quebra de linha dentro do conteúdo de texto quando uma mensagem é transmitida através
HTTP.
Sempre que for possível, um gateway ou proxy de HTTP para uma estrita MIME
ambiente deve traduzir todas as quebras de linha dentro do texto de mídia
tipos descritos no ponto 3.7.1 deste documento para o RFC 2049
forma canônica de CRLF. Note, no entanto, que isso pode ser complicado
pela presença de um Content-Encoding e pelo facto de HTTP
permite o uso de alguns conjuntos de caracteres que não utilizem octetos 13 e
10 para representar CR e LF, como é o caso de alguns multi-byte
conjuntos de caracteres.
Os implementadores devem notar que a conversão vai quebrar nenhuma criptografia
checksums aplicada ao conteúdo original menos o conteúdo original
já está na forma canônica. Portanto, a forma canônica é
recomendado para qualquer conteúdo que usa checksums como no HTTP.
19.4.3 Conversão de formatos de data
HTTP/1.1 usa um conjunto limitado de formatos de data (secção 3.3.1) para
simplificar o processo de comparação de datas. Proxies e gateways de
outros protocolos devem garantir que qualquer campo de cabeçalho Date presentes em um
mensagem está em conformidade com um dos formatos HTTP/1.1 e reescrever a data
se necessário.
19.4.4 introdução de conteúdos-Encoding
RFC 2045 não inclui qualquer conceito equivalente ao HTTP/1.1 ‘s
Content-Encoding cabeçalho campo. Uma vez que este actua como um modificador do
tipo de mídia, proxies e gateways de HTTP para MIME-compliant
protocolos deve alterar o valor do cabeçalho Content-Type
campo ou decodificar o corpo entidade antes de a mensagem de encaminhamento. (Alguns
aplicações experimentais do tipo de conteúdo para Internet mail usaram
um parâmetro de tipo de mídia “, conversões = <content-coding>” para executar
uma função equivalente à Content-Encoding. No entanto, este parâmetro é
não fazem parte da RFC 2045).
19.4.5 Não Content-Transfer-Encoding
HTTP não usar o Content-Transfer-Encoding (ETC) domínio da RFC
2045. Proxies e gateways de protocolos MIME-compliant HTTP devem
remover qualquer CTE não-identidade (“quoted-printable” ou de “base64”) codificação
antes de entregar a mensagem de resposta a um cliente HTTP.
Proxies e gateways de protocolos HTTP MIME-conformes são
responsável por garantir que a mensagem está no formato correto
e codificação para o transporte seguro de que o protocolo, onde “seguro
Fielding, et al. Standards Track [Página 168]
?
HTTP/1.1 RFC 2616 junho 1999
transporte “é definida pelos limites do protocolo está sendo usado.
Essa proxy ou gateway deve rotular os dados com um adequado
Content-Transfer-Encoding se isso irá melhorar a probabilidade de
transporte seguro sobre o protocolo de destino.
19.4.6 Introdução Transfer-Encoding
HTTP/1.1 introduz o campo de cabeçalho Transfer-Encoding (secção
14,41). Proxies / gateways deve remover qualquer transferência de codificação antes da
encaminhar uma mensagem através de um protocolo MIME-compliant.
Um processo para decodificar os “blocos” de transferência de codificação (seção 3.6)
pode ser representado em pseudo-código:
comprimento: = 0
leia tamanho do pedaço, pedaço de extensão (se houver) e CRLF
while (tamanho de bloco-> 0) (
leia trecho de dados e CRLF
anexar pedaço de dados ao corpo de entidade
Comprimento: comprimento = + pedaço de tamanho
leia tamanho do pedaço e CRLF
)
ler o cabeçalho de entidade
while (cabeçalho entidade não-vazia) (
anexar cabeçalho entidade para campos de cabeçalho existente
ler o cabeçalho de entidade
)
Content-Length: comprimento =
Remover “blocos” de Transfer-Encoding
19.4.7 MHTML e limitações de comprimento de linha
implementações HTTP que code share com MHTML [45] implementações
precisa estar ciente das limitações do comprimento MIME linha. Desde HTTP não
tem essa limitação, HTTP não se dobra longas filas. mensagens MHTML
ser transportado por HTTP seguir todas as convenções da MHTML, incluindo
linha limitações de comprimento e dobradura, de canonização, etc, uma vez que
HTTP transporta toda a mensagem de órgãos como carga (ver secção 3.7.2) e
não interpretar o conteúdo ou as linhas de cabeçalho MIME que podem ser
nele contidas.
19,5 Recursos adicionais
RFC 1945 e RFC 2068 documento protocolo elementos utilizados por alguns
existentes implementações HTTP, mas não consistentemente e corretamente
na maior parte dos pedidos HTTP/1.1. Os implementadores são aconselhados a ser
conhecimento dessas características, mas não pode invocar a sua presença, ou
interoperabilidade com, outras aplicações HTTP/1.1. Algumas destas
Fielding, et al. Standards Track [Página 169]
?
HTTP/1.1 RFC 2616 junho 1999
descrever características proposta experimental, e alguns deles descrevem características
que a implantação experimental encontrados falta que agora são abordadas em
a base de especificação HTTP/1.1.
Um número de cabeçalhos de outras, tais como Content-Disposition e título,
de SMTP e MIME também são aplicadas (ver RFC 2076 [37]).
19.5.1 Content-Disposition
O Content-Disposition campo de cabeçalho de resposta tem sido proposta como um
meios para o servidor de origem para sugerir um nome de arquivo padrão se o usuário
solicita que o conteúdo é guardado em um arquivo. Esse uso é derivado
da definição de Content-Disposition na RFC 1806 [35].
disposição do conteúdo = “Content-Disposition”: “
* Disposição de tipo (“;” disposição parm)
disposição type = “apego” | extensão disp-token
disposição parm = nome de arquivo parm | extensão disp-parm-
parm filename = “filename” = “citou-corda
disp-extension-token = token
disp-extensão parm = “token =” (token | citou-corda)
Um exemplo é
Content-Disposition: attachment; fname.ext filename = “”
O agente não deve receber o respeito de qualquer caminho de diretório
apresentar a informação no parâmetro parm nome, que é a única
parâmetro Acredita-se que se aplicam às implementações HTTP neste momento. O
filename deve ser tratado como um componente terminal só.
Se este cabeçalho é usado em uma resposta com o application/octet-
stream tipo de conteúdo, a sugestão implícita é que o agente
não deve mostrar a resposta, mas diretamente entre a `salvar resposta
como … ” diálogo.
Consulte a seção 15,5 por questões de segurança Content-Disposition.
19,6 compatibilidade com versões anteriores
Está além do escopo de uma especificação de protocolo de mandato
conformidade com versões anteriores. HTTP/1.1 foi deliberadamente
concebidas, no entanto, para fazer de apoio versões anteriores fácil. É
notar que, no momento de compor esta especificação
(1996), que seria de esperar comercial HTTP/1.1 servidores:
– Reconhece o formato do Pedido-Line para HTTP/0.9, 1.0, e
1,1 pedidos;
Fielding, et al. Standards Track [Página 170]
?
HTTP/1.1 RFC 2616 junho 1999
– Compreender qualquer pedido válido, no formato de HTTP/0.9, 1.0, ou
1.1;
– Responder de forma adequada com uma mensagem na mesma versão principal
utilizado pelo cliente.
E esperamos que os clientes HTTP/1.1 para:
– Reconhece o formato do Status-Line para HTTP/1.0 e 1.1
respostas;
– Compreender qualquer resposta válida, no formato de HTTP/0.9, 1.0, ou
1.1.
Para a maioria das implementações de HTTP/1.0, cada conexão é estabelecida
pelo cliente antes do pedido e fechada pelo servidor depois
enviar a resposta. Algumas implementações de implementar a Keep-Alive
versão de conexões persistentes descritas na seção 19.7.1 da RFC
2068 [33].
19.6.1 Mudanças em HTTP/1.0
Esta seção resume as principais diferenças entre as versões HTTP/1.0
e HTTP/1.1.
19.6.1.1 mudanças para simplificar Multi-homed servidores Web e IP Conserve
Endereços
Os requisitos que os clientes e servidores de apoio ao acolhimento de solicitação
cabeçalho, um relatório de erro, caso o pedido Host cabeçalho (art. 14,23) é
falta de uma solicitação HTTP/1.1, e aceitam URIs absoluto (secção
5.1.2) estão entre as mais importantes mudanças definidas por esta
especificação.
Os clientes mais antigos HTTP/1.0 assumiu um relacionamento one-to-one de IP
endereços e servidores, não havia outro mecanismo criado para
distinguir o servidor desejado de uma solicitação do endereço IP
a que o pedido foi dirigido. As alterações descritas acima
permitir que a Internet, os clientes mais velhos, uma vez HTTP já não são comuns,
suporte a vários sites de um endereço IP único, muito
simplificação de grandes servidores operacionais Web, em que a atribuição de muitos
Endereços IP para um único host tem criado sérios problemas. O
Internet também será capaz de recuperar os endereços IP que foram
alocados para o único propósito de permitir domínio para fins especiais
nomes a serem usados no nível da raiz URLs HTTP. Dada a taxa de crescimento da
a Web, bem como o número de servidores já está implantado, é extremamente
Fielding, et al. Standards Track [Página 171]
?
HTTP/1.1 RFC 2616 junho 1999
importante que todas as implementações de HTTP (incluindo atualidades
aplicações existentes HTTP/1.0) implementar corretamente esses
requisitos:
– Clientes e servidores devem apoiar o pedido de acolhimento de cabeçalho.
– Um cliente que envia uma requisição HTTP/1.1 deve enviar um cabeçalho de host.
– Servidores devem informar um erro 400 (Bad Request) se um HTTP/1.1
pedido não incluir um pedido Host header.
– Servidores devem aceitar URIs absoluto.
19.6.2 Compatibilidade com HTTP/1.0 conexões persistentes
Alguns clientes e servidores pode querer ser compatível com alguns
implementações anteriores de conexões persistentes em HTTP/1.0
clientes e servidores. Conexões persistentes são em HTTP/1.0
explicitamente negociados como eles não são o comportamento padrão. HTTP/1.0
implementações experimentais de conexões persistentes são defeituosos,
e as novas instalações em HTTP/1.1 são projetados para corrigir essas
problemas. O problema foi que alguns actuais clientes 1.0 podem ser
envio de Keep-Alive para um servidor proxy que não entende
Conexão, que seria então erroneamente enviá-lo para a próxima
servidor de entrada, que permita estabelecer a conexão Keep-Alive e
resultar em um proxy HTTP/1.0 pendurado esperando o próximo na
a resposta. O resultado é que os clientes HTTP/1.0 deve ser impedida de
usando Keep Alive, quando falar com proxies.
No entanto, conversando com proxies é o uso mais importante da persistente
conexões, de modo que a proibição é claramente inaceitável. Por isso,
precisamos de algum outro mecanismo para indicar uma conexão persistente
é desejado, que é segura de usar, mesmo quando se fala de um proxy de idade
que ignora a conexão. Conexões persistentes são o padrão para
HTTP/1.1 mensagens, nós introduzimos uma nova palavra-chave (Connection: close) para
declarando não persistência. Consulte a seção 14.10.
A forma original HTTP/1.0 de conexões persistentes (a conexão:
Keep-Alive e cabeçalho Keep-Alive) está documentado no RFC 2068. [33]
19.6.3 Alterações da RFC 2068
Esta especificação foi cuidadosamente controlados para corrigir e
disambiguate uso da palavra-chave; RFC 2068 teve muitos problemas em relação à
as convenções estabelecidas no RFC 2119 [34].
Esclarecido que o código de erro deve ser utilizado por falhas no servidor de entrada
(Por exemplo, falhas de DNS). (Seção 10.5.5).
Fielding, et al. Standards Track [Página 172]
?
HTTP/1.1 RFC 2616 junho 1999
CREATE teve uma corrida que exigiu uma ETag ser enviadas quando um recurso é
criado pela primeira vez. (Seção 10.2.2).
Content-Base foi suprimido a partir da especificação: não foi
implementada amplamente, e não há nenhuma maneira simples e segura de introduzi-lo
sem um mecanismo robusto de extensão. Além disso, é usado em um
semelhantes, mas não da forma idêntica em MHTML [45].
Transferência de codificação de mensagens todos os comprimentos e interagir de maneiras que
necessário fixar exatamente quando a codificação fragmentada é usado (para permitir
codificação de transferência que não pode ser delimitando self), que foi importante
endireitar para fora exatamente como comprimentos mensagem são computados. (Seções
3.6, 4.4, 7.2.2, 13.5.2, 14,13, 14,16)
A codificação de conteúdo de “identidade” foi introduzido, para resolver problemas
descoberto em cache. (Seção 3.5)
Qualidade Valores de zero deve indicar que “eu não quero algo”
para permitir que os clientes se recusam a representação. (Seção 3.9)
A utilização e interpretação dos números de versão HTTP foi esclarecido
pela RFC 2145. Exigir que os proxies pedidos de upgrade para o mais alto protocolo
versão que suporte para lidar com os problemas descobertos em HTTP/1.0
implementações (Secção 3.1)
Charset curinga é introduzida para evitar explosão de conjunto de caracteres
nomes em aceitar os cabeçalhos. (Seção 14.2)
Um caso foi perdido no modelo de controle de cache do HTTP/1.1; maxage s-
foi introduzida para adicionar este caso perdido. (Seções 13.4, 14.8, 14.9,
14.9.3)
O Cache-Control: max-age directiva não foi devidamente definido para
respostas. (Seção 14.9.3)
Há situações em que um servidor (especialmente um proxy) não
conhecer a todo o comprimento de uma resposta, mas é capaz de atender a um
byterange pedido. Precisamos, portanto, um mecanismo que permita byteranges
com um teor de intervalo não indicando o comprimento total da mensagem.
(Secção 14,16)
Faixa de pedir as respostas seria muito detalhado, se todos os meta-dados
sempre foram devolvidos, ao permitir que o servidor para enviar apenas necessário
cabeçalhos em uma resposta 206, esse problema pode ser evitado. (Seção
10.2.7, 13.5.3 e 14,27)
Fielding, et al. Standards Track [Página 173]
?
HTTP/1.1 RFC 2616 junho 1999
Corrigir o problema com solicitações de intervalo insatisfatível, existem dois casos:
problemas sintáticos, alcance e não existe no documento. A 416
código de status era necessária para resolver essa ambigüidade necessária para indicar
um erro para um pedido de intervalo de bytes que cai fora do real
conteúdo de um documento. (Seção 10.4.17, 14,16)
Reescreva os requisitos de transmissão de mensagem para tornar muito mais difícil
Os implementadores de errar, como as consequências de erros aqui
podem ter impacto significativo sobre a Internet, e para lidar com a
seguintes problemas:
1. Mudar “HTTP/1.1 ou mais tarde” para “HTTP/1.1”, em contextos onde
Esta foi incorretamente colocar um requisito sobre o comportamento de
uma implementação de uma futura versão do HTTP/1.x
2. Claro que user-agents devem repetir os pedidos, não
“Clientes” em geral.
3. Requisitos de conversão para os clientes ignoram inesperado 100
(Continua) respostas, e proxies para a frente de 100 respostas,
em uma obrigação geral de 1xx respostas.
4. Modificado em alguma linguagem de TCP específica, para torná-lo mais claro que
transportes não-TCP são possíveis para HTTP.
5. Exigir que o servidor de origem não deve aguardar o pedido
corpo antes que ele envia uma resposta exigia 100 (Continua).
6. Permitir, ao invés de exigir, um servidor que omitir 100 (Continua) se
já vi algumas do corpo solicitação.
7. Permitir que os servidores se defender contra ataques de negação de serviço ataques e
clientes quebrado.
Esta alteração acrescenta o cabeçalho esperar e 417 do código de status. A mensagem
fixa os requisitos de transmissão estão nas seções 8.2, 10.4.18,
8.1.2.2, 13,11 e 14,20.
Proxies deve ser capaz de adicionar Content-Length, quando apropriado.
(Seção 13.5.2)
Clean up confusão entre 403 e 404 respostas. (Seção 10.4.4,
10.4.5 e 10.4.11)
Avisos podem ser armazenadas em cache incorretamente, ou não atualizados apropriadamente.
(Seção 13.1.2, 13.2.4, 13.5.2, 13.5.3, 14.9.3 e 14,46) Atenção
também precisava ser um cabeçalho geral, PUT ou outros métodos podem ter
necessidade de que nos pedidos.
Fielding, et al. Standards Track [Página 174]
?
HTTP/1.1 RFC 2616 junho 1999
Transferência de codificação teve problemas significativos, nomeadamente com
interações com a codificação fragmentada. A solução é que a transferência
codificações se tornar tão cheio de conteúdo como verdadeiro codificações. Trata-se de
adicionar um registro IANA para transferência de códigos (separado do conteúdo
códigos), um novo campo de cabeçalho (TE) e permitindo que os cabeçalhos no trailer
futuro. Transferência de codificação é um benefício de desempenho importante, por isso foi
pena de fixação [39]. TE também resolve outro, obscuro, descendente
problemas de interoperabilidade que pode ter ocorrido devido às interações
entre reboques autenticação, codificação fragmentada e HTTP/1.0
clientes. (Seção 3.6, 3.6.1, e 14,39)
O patch, LINK, métodos UNLINK foram definidos, mas que normalmente não são
implementada nas versões anteriores desta especificação. Consulte RFC 2068
[33].
Os suplentes, versão de conteúdo, derivada de, Link, URI, públicos e
campos de cabeçalho Content-base foram definidos em versões anteriores do presente
especificação, mas não é comumente aplicada. Consulte RFC 2068 [33].
20 Index
Por favor, consulte a versão PostScript deste RFC para o índice.
Fielding, et al. Standards Track [Página 175]
?
HTTP/1.1 RFC 2616 junho 1999
21. Copyright plena afirmação
Copyright (C) A Internet Society (1999). Todos os direitos reservados.
Este documento e traduções de que pode ser copiado e decorados para
outros, e que trabalhos derivados comentar ou outra forma explicar isso
ou ajudar na sua implementação pode ser preparado, copiado, publicado
e distribuídos, no todo ou em parte, sem restrições de qualquer
espécie, desde que o aviso de copyright acima e este número é
incluídos em todas as cópias e obras derivadas. No entanto, esta
documento em si não pode ser modificado de qualquer forma, tais como a remoção
o aviso de copyright ou referências a Sociedade da Internet ou outros
Internet organizações, exceto conforme necessário para fins de
desenvolver padrões Internet, caso em que os procedimentos de
direitos autorais definidos na Internet Standards processo deve ser
seguido, ou como necessário para traduzi-lo em outras línguas que não
Inglês.
As permissões concedidas acima são limitados perpétua e não será
revogada pela Internet Society ou seus sucessores ou cessionários.
Este documento e as informações contidas neste documento é fornecido por um
“COMO ESTÁ” base e Internet Society e Engenharia da Internet
Força-Tarefa renuncia quaisquer garantias, EXPRESSA OU IMPLÍCITA, INCLUINDO
MAS não limitados a qualquer garantia de que o USO DA INFORMAÇÃO
AQUI não irá infringir quaisquer direitos ou quaisquer garantias implícitas de
COMERCIALIZAÇÃO OU ADEQUAÇÃO A UMA FINALIDADE ESPECÍFICA.
Reconhecimento
Financiamento para o RFC Editor função é actualmente assegurada pela
Internet Society.
Fielding, et al. Standards Track [Página 176]
Rede Grupo de Trabalho R. Fielding
Request for Comments: 2616 UC Irvine
Obsoletes: Gettys 2068 J.
Categoria: Standards Track Compaq/W3C
J. Mogul
Compaq
H. Frystyk
W3C/MIT
L. Masinter
Xerox
P. Leach
Microsoft
T. Berners-Lee
W3C/MIT
Junho 1999
Nossa eu só precisava dos cabeçários de redirecionamentos ….. mais acabei encontrando tudo aqui !!!
Cara, essa tradução tá um lixo. Se fosse pra usar um tradutor, não era pra ter publicado isso aqui. LIXO…
Se não pode fazer melhor, então não fale mal.
Cara: Lixo é vc entrar aqui e criticar a boa vontade que o sujeito teve em traduzir.
Vc veio criticar mas nao fez absolutamente nada para melhorar o post.
seu intelecto é de uma ameba, nem chega a inseto, o mundo nao precisa de “gente”
quem nem vc. Te mata, vc nao vale o ar que respira
Tradução muito ruim. Dá pra entender pouquissima coisa.