Tradução RFC 2616

rfc-2616

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

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
1. Finalidade e Requisitos
2. Terminologia
3. operação global
Duas convenções notacionais e gramática genérica
1. Augmented BNF
2. Regras básicas
Parâmetros Protocolo
1. HTTP versão
2. Uniform Resource Identificadores
3. Sintaxe Geral
4. http URL
5. Comparação URI
6. Data / Hora formatos
7. Data Full
8. Seconds Delta
9. Conjuntos de caracteres
10. Charset Missing
11. Codificações de conteúdo
12. Codificações
13. Transfer
14. Transferência Chunked Codificação
15. Tipos de Mídia
16. Canonização e Padrões Texto
17. Tipos Multipart
18. Tokens
19. Produto
20. Valores Qualidade
21. Tags Linguagem
22. Tags Entidade
23. Unidades de gama
Mensagem HTTP
1. Tipos de mensagens
2. Cabeçalhos de mensagens
3. Corpo da mensagem
4. Message Length
5. Geral Campos de cabeçalho
Pedido
1. Request-Line
2. Método
3. Pedido-URI
4. O recurso identificado por um pedido
5. Pedido de campos de cabeçalho
Resposta
1. Status-Line
2. Frase Código de status e Razão
3. Response Header Campos
Entidade
1. Entidade Campos de cabeçalho
2. Corpo Entidade
3. Tipo
4. Duração Entidade
ligações
1. conexões persistentes
2. Finalidade
3. Operação geral
4. Servidores Proxy
5. Considerações práticas
6. requisitos de transmissão de mensagens
7. Conexões persistentes e Controle de Fluxo
8. Monitorando Conexões para mensagens de erro Status
9. Utilização do 100 (Continua) Status
10. Comportamento Client Server prematuramente se fecha conexão
Definições Método
1. Métodos de segurança e idempotentes
2. Métodos de segurança
3. Métodos idempotent
4. OPÇÕES
5. GET
6. HEAD
7. POST
8. PUT
9. DELETE
10. TRACE
11. CONNECT
Status Definições Código
1. 1xx informativos
2. Continue
3. 101 Mudando Protocolos
4. 2xx Sucesso
5. 200 OK
6. 201 Criado
7. 202 Aceito
8. 203 Informação não-autorizada
9. 204 Nenhum conteúdo
10. 205 Reset Content
11. 206 Conteúdo parcial
12. redirecionamento 3xx
13. 300 Múltipla Escolha
14. 301 Moved Permanently
15. 302 encontrados
16. 303 Ver Outros
17. 304 Not Modified
18. 305 Use Proxy
19. 306 (não utilizado)
20. 307 Redirecionamento temporário
21. erro 4xx Cliente
22. 400 Bad Request
23. 401 Unauthorized
24. 402 Pagamento necessário
25. 403 Forbidden
26. 404 Not Found
27. 405 Método Não Permitido
28. 406 Não Aceitável
29. 407 Autenticação de proxy necessária
30. 408 Request Timeout
31. 409 Conflito
32. 410
33. 411 Comprimento necessário
34. 412 Requisito Falha
35. 413 Entidade de solicitação muito grande
36. 414 Pedido-URI Too Long
37. 415 Tipo de mídia incompatível
38. 416 Intervalo solicitado não satisfatório
39. 417 Falha na expectativa
40. Server Error 5xx
41. 500 Internal Server Error
42. 501 Não implementado
43. 502 Bad Gateway
44. 503 Service Unavailable
45. 10.5.5 504 Gateway Timeout
46. 10.5.6 505 Versão HTTP não suportada
Autenticação de acesso
Negociação de conteúdo
1. Negociação Server-driven
2. Negociação Agent-driven
3. negociação transparente
Cache em HTTP
1. Exatidão Cache
2. Avisos
3. Cache Mecanismos de controle
4. Avisos User Agent Explicit
5. Exceções, Regras e Avisos
6. Comportamento do cliente controlada
7. Modelo de Termo
8. Termo servidor especificado
9. Termo Heurística
10. Cálculos Idade
11. Cálculos Termo
12. disambiguating Valores Termo
13. disambiguating respostas múltiplas
14. modelo de validação
15. Datas Last-Modified
16. Entidade Tag Validators Cache
17. validadores fracos e fortes
18. Regras para quando usar Tags Entidade e Last-Modified Dates
19. Não validar Condicionais
20. Cacheabilidade resposta
21. Respostas Construindo dos esconderijos
22. Fim-de-final e cabeçalhos Hop-by-hop
23. Cabeçalhos não modificáveis
24. Headers Combinando
25. Combinando Escalas Byte
26. Caching Respostas negociada
27. Caches compartilhados e não compartilhados
28. Erros ou comportamento Cache incompleta resposta
29. Efeitos colaterais de GET e HEAD
30. Invalidação após as atualizações ou exclusões
31. write-through obrigatórios
32. Substituição Cache
33. Lista História
Definições de campo de cabeçalho
1. Aceitar
2. accept-charset
3. Accept-Encoding
4. Accept-Language
5. Accept-Ranges
6. Idade
7. Permitir
8. Autorização
9. Cache Control
10. O que é Cacheable
11. O que pode ser armazenado por Caches
12. Modificações do Mecanismo de Vencimento Básico
13. Revalidação Cache e Controles Atualizar
14. No-Transform Directiva
15. Extensões para Controle de Cache
16. conexão
17. Content-Encoding
18. Content Language
19. Content-Length
20. Content-Location
21. Content-MD5
22. Content-Range
23. Content-Type
24. Data
25. Operação Server Clockless Origem
26. ETag
27. Espere
28. Expira
29. De
30. Host
31. If-Match
32. If-Modified-Since
33. If-None-Match
34. Se Range
35. Se-Unmodified-Desde
36. Last-Modified
37. Localização
38. Max-Forwards
39. Pragma
40. Proxy-Authenticate
41. Proxy-Autorização
42. Faixa
43. intervalos de bytes
44. Faixa de solicitações de recuperação
45. Referer
46. Retry-After
47. Server
48. TE
49. Trailer
50. Transfer-Encoding
51. Upgrade
52. User-Agent
53. Vary
54. Via
55. Atenção
56. WWW-Authenticate
Considerações de Segurança
1. informações pessoais
2. Abuso de Information Server Log
3. A transferência de informações confidenciais
4. Informações Encoding Sensitive em URI
5. Problemas de privacidade Connected Aceitar Cabeçalhos
6. ataques baseados em nomes de arquivo e caminho
7. DNS Spoofing
8. Headers Localização e falsificação
9. Content-Disposition Problemas15,6 credenciais de autenticação e clientes Idle
10. Proxies e cache
11. Ataques de negação de serviço em Proxies
Agradecimentos
Referências
Endereços de 18 autores
Apêndices
1. Mensagem Internet Media Tipo http / e aplicação http /
2. Internet Media Tipo multipart / byteranges19,3 aplicações tolerantes
3. Diferenças entre as entidades HTTP e RFC 2045 Entidades …. 167
4. MIME-Version 167
5. Conversão para a forma canônica
6. Conversão de formatos de data
7. Introdução de conteúdos-Encoding
8. No Content-Transfer-Encoding
9. Introdução Transfer-Encoding
10. MHTML e limitações de comprimento Line
11. Características Adicionais
12. Content-Disposition
13. Compatibilidade com versões anteriores
14. Mudanças de HTTP/1.0
15. Compatibilidade com HTTP/1.0 conexões persistentes
16. 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.

– 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.

– 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

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

5 Comments

Felipe no 24 de junho de 2010 a partir do 9:16 pm

Nossa eu só precisava dos cabeçários de redirecionamentos ….. mais acabei encontrando tudo aqui !!!
Caramba que Lixo no 15 de fevereiro de 2012 a partir do 12:05 pm

Cara, essa tradução tá um lixo. Se fosse pra usar um tradutor, não era pra ter publicado isso aqui. LIXO…
rock no 28 de março de 2013 a partir do 10:26 pm

Caramba que Lixo :
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.
rubens no 16 de abril de 2013 a partir do 7:53 pm

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
Yuri no 17 de maio de 2015 a partir do 3:10 pm

Tradução muito ruim. Dá pra entender pouquissima coisa.

About The Author

Fernando

5 Comments

Leave a reply Cancelar resposta

Newsletter

Categorias

Lista de Links

Tradução RFC 2616

About The Author

Fernando

Related Posts

PageRank

Licença GPL

5 Comments

Leave a reply Cancelar resposta

Newsletter

Categorias

Tags

Lista de Links