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.
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:
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-Phrase
s 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
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
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.
Tipo MIME | Descrição | Extensões comuns | Referência |
---|---|---|---|
text/html | HTML | .html |
RFC 2854 |
text/css | Cascade Style Sheet (CSS) | .css |
RFC 2318 |
text/javascript (obsoleto) | JavaScript / ECMA Script | .js |
RFC 4329 |
text/plain | Texto puro | .txt |
|
text/xml | XML | .xml |
RFC 3023 |
text/richtext | Rich Text Format (RTF) | .rtf |
|
text/rtf | Rich Text Format (RTF) | .rtf |
|
application/javascript | JavaScript / ECMA Script | .js |
RFC 4329 |
application/octet-stream | Binário (download) | (diversas) | |
application/pdf | Adobe Acrobat PDF | .pdf |
RFC 3778 |
application/zip | Archive ZIP | .zip |
|
application/msword | Microsoft Word | .doc, .dot |
|
application/vnd.ms-excel | Microsoft Excel | .xls |
|
application/vnd.ms-powerpoint | Microsoft PowerPoint | .ppt, .pps |
|
application/mp4 | Mídia MPEG-4 | .mp4 |
RFC 4337 |
application/mpeg4-generic | Mídia MPEG-4 | .mpeg4 |
RFC 4337 |
image/jpeg | Imagem JPEG | .jpg, .jpeg |
|
image/gif | Imagem GIF | .gif |
|
image/png | Imagem PNG | .png |
|
image/tiff | Imagem TIFF | .tif, .tiff |
RFC 2302 |
audio/mpeg | Áudio MPEG | .mp3 |
RFC 3003 |
video/mpeg | Vídeo MPEG | .mpg, .mpeg |
|
video/quicktime | Vídeo Apple QuickTime | .mov |
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:
Tipo MIME (não padrão) | Descrição | Extensões comuns |
---|---|---|
application/x-shockwave-flash | Animação Flash | .swf |
audio/x-midi | Melodia MIDI | .mid, .midi |
audio/x-wav | Som Wave | .wav |
audio/x-ms-wma | Windows Media Audio (WMA) | .wma |
application/x-gzip | Arquivo compactado GNUzip | .gz |
application/x-excel | Microsoft Excel (variante não padrão) | .xls |
application/x-powerpoint | Microsoft PowerPoint (variante não padrão) | .ppt, .pps |
video/x-msvideo | Microsoft Video | .msv |
video/avi | .avi |
Content-Type:
T/SContent-Disposition: attachment; filename=
AContent-Type: text/plain Content-Disposition: attachment; filename="arquivo.txt"
Em Java:
response.setContentType("application/octet-stream"); response.setHeader("Content-Disposition", "attachment; filename=\"" + nomeArq + "\"");
Refresh:
S; URL=
ERefresh: 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);
HTTP/1.x 301 Moved Permanently
Location:
EConnection: close
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/"));
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.
Cache-Control: no-cache
Pragma: no-cache
Expires:
DCache-Control: no-cache Pragma: no-cache Expires: ...
© 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.