Informações úteis sobre cabeçalhos HTTP e tipos MIME

Este texto apresenta uma coletânea de informações úteis para designers e programadores que criam páginas e aplicações para a Web, relativa a cabeçalhos de resposta do protocolo HTTP e tipos de conteúdo especificados no padrão MIME.

Sumário

• Códigos de resposta HTTP
• Tipos MIME
• Download
• Redirecionamento
• Sem cache

Códigos de resposta HTTP

RFC 2616, Seção 6.1.1: Status Code e Reason Phrase

O protocolo Hypertext Transfer Protocol - HTTP versão 1.1 — bem como a versão anterior 1.0, ainda em uso por muitos servidores Web — define, no cabeçalho da resposta correspondente a uma requisição HTTP, o código de retorno.

O elemento Status-Code é um código de inteiro de 3 dígitos do resultado da tentativa do servidor em entender e processar a requisição (request). Estes códigos são definidos em detalhes na seção 10 da RFC 2616. A Reason-Phrase visa fornecer uma breve descrição textual do Status-Code. O Status-Code é voltado para a interpretação automatizada (programa cliente) e a Reason-Phrase é voltada para o usuário humano. O cliente HTTP não precisa necessariamente examinar ou exibir a Reason-Phrase.

O primeiro dígito do Status-Code define a classe da resposta. Os 2 dígitos finais definem um significado específico. Existem cinco valores (classes) para o primeiro dígito:

1xx: Informacional

Requisição recebida, processo continua;

2xx: Sucesso

A ação foi recebida, compreendida e aceita com sucesso;

3xx: Redirecionamento (Transitório)

Deve haver ação consecutiva para que a requisição seja completada;

4xx: Erro Cliente

A requisição enviada pelo cliente contém sintaxe errada ou não pode ser atendida;

5xx: Erro Servidor

O servidor falhou em atender requisição aparentemente válida. Erros e exceções em programas CGI e servidores de aplicação para Web (Java, .NET, PHP etc.) são casos típicos de erros da série 500.

Os valores individuais dos códigos de estado numéricos definidos pelo HTTP/1.1 e as frases de significado correspondentes são apresentados a seguir. As Reason-Phrases listadas são apenas recomendações; elas podem ser substituídas por equivalentes sem afetar o protocolo. Os estados de resposta mais comuns estão destacados em negrito.

Status-Code =
  "100"  : Continue (1.1)
| "101"  : Switching Protocols (1.1)
| "200"  : OK
| "201"  : Created
| "202"  : Accepted
| "203"  : Non-Authoritative Information (1.1)
| "204"  : No Content
| "205"  : Reset Content (1.1)
| "206"  : Partial Content (1.1)
| "300"  : Multiple Choices (1.1)
| "301"  : Moved Permanently
| "302"  : Found (1.1), Moved Temporarily (1.0)
| "303"  : See Other (1.1)
| "304"  : Not Modified
| "305"  : Use Proxy (1.1)
| "307"  : Temporary Redirect (1.1)
| "400"  : Bad Request
| "401"  : Unauthorized
| "402"  : Payment Required (1.1)
| "403"  : Forbidden
| "404"  : Not Found
| "405"  : Method Not Allowed (1.1)
| "406"  : Not Acceptable (1.1)
| "407"  : Proxy Authentication Required (1.1)
| "408"  : Request Time-out (1.1)
| "409"  : Conflict (1.1)
| "410"  : Gone (1.1)
| "411"  : Length Required (1.1)
| "412"  : Precondition Failed (1.1)
| "413"  : Request Entity Too Large (1.1)
| "414"  : Request-URI Too Large (1.1)
| "415"  : Unsupported Media Type (1.1)
| "416"  : Requested range not satisfiable (1.1)
| "417"  : Expectation Failed (1.1)
| "500"  : Internal Server Error
| "501"  : Not Implemented
| "502"  : Bad Gateway
| "503"  : Service Unavailable
| "504"  : Gateway Time-out (1.1)
| "505"  : HTTP Version not supported (1.1)
| extension-code

Referência:

• Hypertext Transfer Protocol - HTTP/1.1 - RFC 2616, R. Fielding at alii, IETF, junho 1999; veja seções 6.1.1: Status Code and Reason Phrase e 10: Status Code Definitions. Também disponível no W3C.

Tipos MIME

RFC 2616, Seção 19.4: Diferenças entre Entidades HTTP e RFC 2045

HTTP/1.1 usa várias construções definidas para Internet Mail (RFC 822) e o Multipurpose Internet Mail Extensions (MIME), permitindo a transmissão de entidades (conteúdo) em uma ampla e aberta variedade de representações e com mecanismos extensíveis. Entretanto, RFC 2045 discute e-mail, enquanto HTTP tem alguns poucos recursos que diferem dos descritos na RFC 2045. Estas diferenças foram cuidadosamente escolhidas para otimizar o desempenho em conexões binárias, permitindo maior liberdade no uso de novos tipos de mídia, para tornar comparações de data mais fáceis, e para reconhecer a prática de alguns servidores e clientes HTTP representativos já existentes.

O formato da especificação de tipo de mídia (conteúdo) MIME é definido basicamente como se segue na RFC 2045, sendo usado de forma equivalente também no HTTP (RFC 2616).

Content-Type = tipo "/" subtipo *( ";" parâmetro )
tipo :=	"text" | "image" | "audio" | "video" |
"application" | extension-token
extension-token := ietf-token | x-token

ietf-token := <Um token (nome) de extensão definido em RFC e registrado pela IANA.>
x-token := <Os dois caracteres "X-" ou "x-" seguidos, sem nenhum espaço em branco separando, por qualquer token>
subtipo := extension-token | iana-token
iana-token := <Token de extensão publicamente definido, Registrado pela IANA segundo a RFC 2048.>
parâmetro := atributo "=" valor

Tipos MIME padronizados pela IANA e de uso comum

Os tipos MIME a seguir são formatos comuns de conteúdo utilizados na web, padronizados pela IANA, autoridade responsável pela coordenação de alguns recursos globais da Internet.

Alguns tipos MIME não padronizados mas de uso comum

Segundo a RFC 2046, um nome iniciado por "x-" indica sua situação de não padronizado, para evitar um potencial conflito com um futuro nome oficial. Porém, existem alguns formatos de conteúdo não padronizados cujos tipos MIME em geral definidos arbitrariamente em configurações de servidores e clientes HTTP simplesmente ignoram esta regra, não incluindo o prefixo "x-". Eis alguns tipos não padronizados de ocorrência comum na web:

Referências:

• Media Types: MIME Content Types and Subtypes assigned by the IANA, IANA.
• MIME References, lista de tipos MIME por Content Type e por File Extension, W3Schools.
• Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies - RFC 2045, IETF, novembro 1996.
• Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types - RFC 2046, IETF, novembro 1996.
• Hypertext Transfer Protocol - HTTP/1.1 - RFC 2616, R. Fielding at alii, IETF, junho 1999. Também disponível no W3C.
• Web server MIME types required for serving Flash movies, Flash Player TechNote 4151, Macromedia, abril 2001.
• URI Fragment Identifiers for the text/plain Media Type - RFC 5147, por Erik Wilde e Martin Dürst, IETF, janeiro 2008.
• Describing Media Content of Binary Data in XML, W3C Working Group Note 4, por Anish Karmarkar, Oracle, e Ümit Yalçinalp, SAP, W3C, maio 2005.

Download

Arquivo para download via HTTP

Cabeçalhos HTTP:

Content-Type (formato) e Content-Disposition (download)

Conteúdo:

Content-Type: T/S
Content-Disposition: attachment; filename=A

Valores:

T/S = tipo/subtipo MIME do arquivo enviado; A= nome sugerido para o arquivo a ser salvo

Exemplo:

Content-Type: text/plain
Content-Disposition: attachment; filename="arquivo.txt"

Em Java:

response.setContentType("application/octet-stream");
response.setHeader("Content-Disposition",
	"attachment; filename=\"" + nomeArq + "\"");

Referência:

• Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field - RFC 2183, IETF, agosto 1997.

Redirecionamento

Redirecionamento por Refresh

Cabeçalho HTTP:

Refresh

Conteúdo:

Refresh: S; URL=E

Valores:

S = espera para atualização automática, em segundos; E = endereço da página de destino

Exemplos:

Refresh: 0; URL=http://www.mhavila.com.br/

Página HTML estática:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="pt-br" xml:lang="pt-br">
<head>
<meta http-equiv="Refresh" content="0; URL=http://www.mhavila.com.br/" />
<title>Redirecionamento</title>
</head>

<body>
Se o redirecionamento falhar, clique aqui:
<a href="http://www.mhavila.com.br/">http://www.mhavila.com.br/</a>
</body>
</html>

Em Java:

response.setHeader("Refresh", segundos + "; URL=" + url);

Redirecionamento por resposta HTTP - Redirect

Cabeçalhos HTTP:

HTTP (código de status 301/permanente ou 302/temporário) e Location (destino)

Conteúdo:

HTTP/1.x 301 Moved Permanently
Location: E
Connection: close

Valor:

E = URI de endereço da página destino

Exemplo:

HTTP/1.x 301 Moved Permanently
Location: http://www.mhavila.com.br/
Connection: close

Em Java:

response.setStatus(HttpServletResponse.SC_MOVED_PERMANENTLY);
response.setHeader("Location", "http://www.mhavila.com.br/");
response.setHeader("Connection", "close");

ou

response.sendRedirect(response.encodeRedirectURL(
	"http://www.mhavila.com.br/"));

Diagrama:

Redirect × Forward

Descrição:

Em Java, existe um recurso para uma página (JSP) ou componente (servlet) no lado servidor encaminhar ou delegar o processamento de uma requisição para outro componente. Este recurso é denominado forward.

O encaminhamento via forward para um novo componente [B] ocorre no lado servidor e é, portanto, alheio ao cliente web (navegador) que fez a requisição. Assim, para o cliente, é como se a resposta estivesse vindo do componente que recebeu originalmente a requisição [A]. Vide figura a seguir.

Este comportamento é diferente do redirecionamento (redirect), em que o componente inicial servidor [A] apenas informa ao cliente que deve solicitar nova requisição a outro componente [B]. No caso do redirect, ocorrem efetivamente duas requisições e o cliente participa desse encaminhamento. Vide figura da seção anterior.

Diagrama:

Referências:

• 301, Parking and Other Redirects for SEOs (FAQ); Apache Domain Redirects - 301 vs. 302; Redirects Using On-Page Scripting and Headers (inglês); por Ian McAnerin, outubro 2005.
• Redirecionar páginas - 301 Redirect, por Paulo Rodrigo Teixeira, março 2007.
• Permanent Redirect with HTTP 301 (inglês), por Shailesh N. Humbad, 2007-06-07, Somacon.com, com exemplos em ASP/VBScript, PHP, ColdFusion, Perl, Apache mod_rewrite, Javascript e HTML META tag.
• How to Redirect a Web Page (inglês), webconfs.com, 2006, com exemplos em IIS, ColdFusion, PHP, ASP/VBScript, ASP.NET, Java JSP, Perl CGI lib, Ruby on Rails, Apache mod_rewrite.
• HttpServletResponse - sendRedirect() (inglês), Java EE 5 API.
• JSP (Java) Redirect (inglês), Snipplr.
• 301 Redirect for JSP / Java (inglês), por Joshua J. Steimle, janeiro 2008.
• Repitam comigo: Redirect não é forward, por Rafael Ponte, 2008-07-12.
• Forward versus redirect (inglês), Java Practices.

Sem cache

Cabeçalhos HTTP:

Cache-Control (HTTP 1.1), Pragma  (HTTP 1.0), Expires

Conteúdo:

Cache-Control: no-cache
Pragma: no-cache
Expires: D

Valor:

D = data, em um dos formatos aceitos pelo HTTP

Exemplo:

Cache-Control: no-cache
Pragma: no-cache
Expires: ...

Referências:

• Hypertext Transfer Protocol - HTTP/1.1 - RFC 2616, R. Fielding at alii, IETF, junho 1999; veja seções 13.1.3: Cache-control Mechanisms, 14.9: Cache-Control, 14.32: Pragma, 14.21: Expires e 3.3.1: Full Date. Também disponível no W3C.

© 2003-2014, Márcio d'Ávila, mhavila.com.br, direitos reservados. O texto e código-fonte apresentados podem ser referenciados, distribuídos e utilizados, desde que expressamente citada esta fonte e o crédito do(s) autor(es). A informação aqui apresentada, apesar de todo o esforço para garantir sua precisão e correção, é oferecida "como está", sem quaisquer garantias explícitas ou implícitas decorrentes de sua utilização ou suas conseqüências diretas e indiretas.