Hypertext Transfer Protocol

31/03/2018 Hypertext Transfer Protocol – Wikipédia, a enciclopédia livre
Hypertext Transfer Protocol

Origem: Wikipédia, a enciclopédia livre.
O Hypertext Transfer Protocol, sigla HTTP (em português Protocolo de Transferência de Hipertexto) é
um protocolo de comunicação (na camada de aplicação segundo o Modelo OSI) utilizado para sistemas de informação
de hipermídia, distribuídos e colaborativos.[1] Ele é a base para a comunicação de dados da World Wide Web.
Hipertexto é o texto estruturado que utiliza ligações lógicas (hiperlinks) entre nós contendo texto. O HTTP é o
protocolo para a troca ou transferência de hipertexto.
Coordenado pela World Wide Web Consortium e a Internet Engineering Task Force, culminou na publicação de uma
série de Requests for Comments; mais notavelmente o RFC 2616, de junho de 1999, que definiu o HTTP/1.1. Em
Junho de 2014 foram publicados 6 RFC's para maior clareza do protocolo HTTP/1.1.[2] Em Março de 2015, foi
divulgado o lançamento do HTTP/2. A atualização deixará o navegador com um tempo de resposta melhor e mais
seguro. Ele também melhorará a navegação em smartphones. [3]
Para acedermos a outro documento a partir de uma palavra presente no documento actual ypodemos utilizar
hiperligações (ou âncoras). Estes documentos se encontram no sítio com um endereço de página da Internet – e para
acessá-los deve-se digitar o respectivo endereço, denominado URI (Universal Resource Identifier ou Identificador
Universal de Recurso), que não deve ser confundido com URL (Universal Resource Locator ou Localizador Universal
de Recurso), um tipo de URI que pode ser directamente localizado.
Índice
Visão técnica geral
História
Sessão HTTP
Cookies
Funcionamento
Mensagem HTTP
Cabeçalho da mensagem
Corpo da mensagem
Requisição
Métodos de solicitação
GET
HEAD
POST
PUT
DELETE
TRACE
OPTIONS
CONNECT
Códigos de estado
Conexões persistentes
Estado de sessão HTTP
https://pt.wikipedia.org/wiki/Hypertext_Transfer_Protocol 1/10
Resposta
Códigos de retorno
Conexões
Outros protocolos
Esquema de comunicação
Ver também
Referências
Bibliografia
Ligações externas
Visão técnica geral

O HTTP funciona como um protocolo de requisição-resposta no modelo computacional cliente-servidor. Um
navegador web, por exemplo, pode ser o cliente e uma aplicação em um computador que hospeda um sítio da web
pode ser o servidor. O cliente submete uma mensagem de requisição HTTP para o servidor. O servidor, que fornece os
recursos, como arquivos HTML e outros conteúdos, ou realiza outras funções de interesse do cliente, retorna uma
mensagem resposta para o cliente. A resposta contém informações de estado completas sobre a requisição e pode
também conter o conteúdo solicitado no corpo de sua mensagem.
Um navegador web é um exemplo de agente de usuário (AU). Outros tipos de agentes de usuário incluem o software
de indexação usado por provedores de consulta (web crawler), navegadores vocais, aplicações móveis e outros
software que acessam, consomem ou exibem conteúdo web.
O HTTP é projetado para permitir intermediações de elementos de rede para melhorar ou habilitar comunicações
entre clientes e servidores. Sites web de alto tráfego geralmente se beneficiam dos servidores de cache web que
entregam conteúdo em nome de servidores de upstream para melhorar o tempo de resposta. Navegadores web
armazenam os recursos web acessados anteriormente e reutilizam-nos quando possível para reduzir o tráfego de rede.
Servidores proxy HTTP nas fronteiras de redes privadas podem facilitar a comunicação para o cliente sem um
endereço globalmente roteável, transmitindo mensagens com servidores externos.
História
O HyperText Transfer Protocol é um protocolo de aplicação responsável pelo tratamento de pedidos e respostas entre
cliente e servidor na World Wide Web. Ele surgiu da necessidade de distribuir informações pela Internet e para que
essa distribuição fosse possível foi necessário criar uma forma padronizada de comunicação entre os clientes e os
servidores da Web e entendida por todos os computadores ligados à Internet. Com isso, o protocolo HTTP passou a ser
utilizado para a comunicação entre computadores na Internet e a especificar como seriam realizadas as transacções
entre clientes e servidores, através do uso de regras básicas.
Este protocolo tem sido usado pela WWW desde 1990. A primeira versão de HTTP, chamada HTTP/0.9, era um
protocolo simples para a transferência de dados no formato de texto ASCII pela Internet, através de um único método
de requisição, chamado GET. A versão HTTP/1.0 foi desenvolvida entre 1992 e 1996 para suprir a necessidade de
transferir não apenas texto. Com essa versão, o protocolo passou a transferir mensagens do tipo MIME44
(Multipurpose Internet Mail Extension) e foram implementados novos métodos de requisição, chamados POST e HEAD.
No HTTP/1.1, versão actual do protocolo descrito na RFC 2616,[4] foi desenvolvido um conjunto de implementações
adicionais ao HTTP/1.0, como por exemplo: o uso de conexões persistentes; o uso de servidores proxy que permitem
uma melhor organização da cache; novos métodos de requisições; entre outros. Afirma-se que o HTTP também é
usado como um protocolo genérico para comunicação entre os agentes de utilizadores e proxies/gateways com outros
protocolos, como o SMTP, NNTP, FTP, Gopher, e WAIS, permitindo o acesso a recursos disponíveis em aplicações
diversas.[4]
Sessão HTTP
Uma sessão HTTP é uma sequência de transações de rede de requisição-resposta. Um cliente HTTP inicia uma
requisição estabelecendo uma conexão Transmission Control Protocol (TCP) para uma porta particular de um servidor
(normalmente a porta 80. Veja Lista de portas dos protocolos TCP e UDP). Um servidor HTTP ouvindo naquela porta
espera por uma mensagem de requisição de cliente. Recebendo a requisição, o servidor retorna uma linha de estado,
como "HTTP/1.1 200 OK", e uma mensagem particular própria. O corpo desta mensagem normalmente é o recurso
solicitado, apesar de uma mensagem de erro ou outra informação também poder ser retornada.
Cookies
O termo cookie é derivado do inglês que significa biscoito. Recebeu esse nome de uma antiga gíria usada pelos
programadores que consistia em um programa chamava um procedimento e recebia de volta algo que seria necessário
apresentar novamente mais tarde para realizar algum trabalho. Foi criado pela Netscape para solucionar o problema
do envio e solicitação de arquivos, que era esquecido pelo servidor e que poderia ser usado por outros computadores
com o mesmo IP conforme (TANEMBAUM, 2003), o que causava problemas, pois não se sabia na realidade se era ou
não aquele usuário mesmo. Os cookies são arquivos ou strings e não são programas executáveis. Eles são tratados
como dados pelo navegador, não existe nenhuma maneira dele ser usado como vírus, apesar de que podem ser
explorados bugs no servidor e causar a ativação de um cookie como vírus, por um hacker. Basicamente ele é um grupo
de dados trocados entre o servidor de páginas e o navegador colocado em um ficheiro criado no computador do
usuário. Serve para manter a persistência das sessões HTTP. Ele funciona da seguinte forma: Um usuário solicita uma
página da Web, nisso o servidor pode fornecer informações adicionais acompanhando a página solicitada. Essas
informações podem incluir um cookie, um pequeno arquivo ou string (com quatro KB no máximo). Este cookie pode
ter até 5 campos (figura abaixo): Domain, Path, Content, Expires, Secure. Domain informa de onde veio o cookie. O
navegador confirma que os servidores estão enviando dados fieis a respeito de seu domínio. Cada domínio pode
armazenar no máximo 20 cookies por cliente. O campo Path é um caminho na estrutura de diretórios do servidor que
identifica as partes da árvore de arquivos do servidor que podem usar o cookie. Frequentemente, ele obtém o símbolo
/ (barra), que representa a árvore inteira. O campo Content utiliza a forma nome = valor, podendo o servidor definir
da maneira que quiser tanto o valor quanto o nome, e é nele que fica armazenado o conteúdo do cookie. Expires é o
campo que faz o cookie persistir, nele contém a data e o horário, e se ele estiver ausente o navegador descartara
automaticamente após o termino da sessão. O último campo define se ele é seguro ou não.
Domain Path Content Expires Secure

15 de outubro de 2002
toms-casino.com / CustomerlD=497793521 17:00 Yes
11 de outubro de 2002
joes-store.com / Cart=1-00501;1-07031;2-13721 14:22 No
Prefs=Stk:SUNW+ORCL;Spt:Jet 31 de dezembro de 2010

aportal.com / s 23:59 No
12-12
sneaky.com 31- / UserID=3627239101 23:59 No
Figura x: Alguns exemplos de cookie.↵Fonte: (TANEMBAUM, 2003).
O cookie é usado para identificar um usuário que configurou uma página web, para que na próxima vez que ele entrar
ela esteja configurada do modo em que ele deixou. Pode ser usado também quando se faz a solicitação de
armazenamento de senha, na vez posterior em que entrar no site, a sua senha será lembrada. É usado também em
sites de compra, como e-commerce, armazenando os produtos que o cliente colocou no carrinho para que no final da
compra não necessite fazer todo o processo novamente.
Funcionamento
Um sistema de comunicação em rede possui diversos protocolos que trabalham em conjunto para o fornecimento de
serviços. Para que o protocolo HTTP consiga transferir seus dados pela Web, é necessário que os protocolos TCP e IP
(Internet Protocol, Protocolo de Internet) tornem possível a conexão entre clientes e servidores através de sockets
TCP/IP.
De acordo com Fielding,[5] o HTTP utiliza o modelo cliente-servidor, como a maioria dos protocolos de rede,
baseando-se no paradigma de requisição e resposta. Um programa requisitante (cliente) estabelece uma conexão com
um outro programa receptor (servidor) e envia-lhe uma requisição, contendo a URI, a versão do protocolo, uma
mensagem MIME (padrão utilizado para codificar dados em formato de textos ASCII para serem transmitidos pela
Internet) contendo os modificadores da requisição, informações sobre o cliente e, possivelmente, o conteúdo no corpo
da mensagem.
O servidor responde com uma linha de status (status line) incluindo sua versão de protocolo e com os códigos de erro
informando se a operação foi bem sucedida ou fracasso, seguido pelas informações do servidor, metainformações da
entidade e possível conteúdo no corpo da mensagem. Após o envio da resposta pelo servidor, encerra-se a conexão
estabelecida.
Mensagem HTTP
O protocolo HTTP faz a comunicação entre o cliente e o servidor por meio de mensagens. O cliente envia uma
mensagem de requisição de um recurso e o servidor envia uma mensagem de resposta ao cliente com a solicitação.
Segundo Foscarini,[6] os dois tipos de mensagens existentes no protocolo utilizam um formato genérico, definido na
RFC 822, para a transferência de entidades.
Uma mensagem, tanto de requisição quanto de resposta, é composta, conforme definido na RFC 2616,[7] por uma
linha inicial, nenhuma ou mais linhas de cabeçalhos, uma linha em branco obrigatória finalizando o cabeçalho e por
fim o corpo da mensagem, opcional em determinados casos. Nessa sessão serão apresentados os campos que
compõem uma mensagem mais detalhadamente; ou seja, o HTTP apresenta o sítio ou local onde está a página da
Internet.
Cabeçalho da mensagem
O cabeçalho da mensagem (header) é utilizado para transmitir informações adicionais entre o cliente e o servidor. Ele
é especificado imediatamente após a linha inicial da transação (método), tanto para a requisição do cliente quanto
para a resposta do servidor, seguido de dois pontos (:) e um valor. Existem quatro tipos de cabeçalhos que poderão ser
incluídos na mensagem os quais são: general-header, request-header, response-header e entity-header.[8]
Esses cabeçalhos são utilizados para enviar informações adicionais sobre a mensagem transmitida (general-header), a
requisição e os clientes (request-header) que comunicam suas configurações e os formatos de documentos desejados
como resposta.[9] Além disso, são utilizados pelo servidor ao retornar o recurso no qual foi requisitado pelo cliente,
para transmitir informações que descrevem as configurações do servidor e do recurso identificado pelo URI de
requisição, e que não pertence à linha de status (response-header). Na RFC 2616,[10] estão descritos todos os campos
que pertencem a esses cabeçalhos.
Corpo da mensagem
Alguns tipos MIME[11]
Uma mensagem HTTP pode conter um
Exemplo Descrição
corpo de dados que são enviados abaixo das
linhas de cabeçalho. Em uma mensagem de text/plain Arquivo no formato texto (ASCII)
resposta, o corpo da mensagem é o recurso Arquivo no formato HTML, utilizado
text/html
que foi requisitado pelo cliente, ou ainda como padrão para documentos Web
uma mensagem de erro, caso este recurso Image/gif Imagem com o formato GIF
não seja possível. Já em uma mensagem de Image/jpeg Imagem com o formato JPEG
requisição, o corpo pode conter dados que
application/zip Arquivo compactado
serão enviados diretamente pelo usuário ou
um arquivo que será enviado para o application/json Arquivo no formato JSON
servidor. Quando uma mensagem HTTP application/xml (ou text/xml) Arquivo no formato XML
tiver um corpo, poderão ser incluídos
cabeçalhos de entidades que descrevem
suas características, como por exemplo, o Content-Type que informa o tipo MIME dos dados no corpo da mensagem e
o Content-Length que informa a quantidade de bytes que o corpo da mensagem contém. A tabela ao lado apresenta
alguns tipos MIME.
Requisição
De acordo com Fielding,[12] uma mensagem de requisição do cliente é composta pelos seguintes campos: uma linha
inicial (Request-Line); linhas de cabeçalhos (Request-header); uma linha em branco obrigatória e um corpo de
mensagem opcional. A linha inicial de uma requisição é composta por três partes separadas por espaços: o método
(Method), a identificação do URI (Request-URI) e a versão do HTTP (HTTP-Version) utilizado.
Segundo Bastos & Ladeira,[13] Request-URI é um identificador uniforme de recurso (Uniform Resource Identifier)
que identifica sobre qual recurso será aplicada a requisição. No protocolo HTTP, o tipo de URI utilizado é chamado de
URL (Uniform Resource Locator), composto pela identificação do protocolo, pelo endereço do computador servidor e
pelo documento requisitado.[14]
Métodos de solicitação
O protocolo HTTP define oito métodos (GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS e CONNECT) que
indicam a ação a ser realizada no recurso especificado. Conforme Bastos e Ladeiras,[15] o método determina o que o
servidor deve fazer com o URL fornecido no momento da requisição de um recurso. Um servidor HTTP deve
implementar ao menos os métodos GET e HEAD.
Uma solicitação HTTP, ou HTTP Request é uma maneira do navegador mostrar uma página da internet utilizando
um dos oito métodos de solicitação do protocolo HTTP.[16]
Além de solicitar um determinado arquivo, envia várias informação para o servidor, sendo elas: o seu IP, a versão do
navegador que está usando, que página utilizou para pedir a HTTP Request e a idioma que você usa, entre outros.[16]
GET
O método GET requisita uma representação do recurso especificado. Requisições usando GET devem apenas
recuperar dados e não devem ter qualquer outro efeito. (Isto também é verdade para alguns outros métodos HTTP.) O
W3C publicou princípios de orientações sobre esta distinção, "O projeto de aplicações web devem ser informados pelos
princípios acima, mas também por limitações relevantes."
Abaixo segue um exemplo de uma comunicação entre um cliente e um servidor HTTP. O servidor possui a URL
www.exemplo.com, porta 80.
O pedido do cliente (seguido por uma linha em branco, de maneira que o pedido termina com um newline duplo, cada
um composto por um carriage return seguido de um Line Feed):
GET /index.html HTTP/1.1

Host: www.exemplo.com
O cabeçalho Host reconhece vários diferentes nomes DNS que tenham o mesmo IP.
A resposta do servidor (seguida por uma linha em branco e o texto da página solicitada):
HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Server: Apache/1.3.27 (Unix) (Red-Hat/Linux)
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Etag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Content-Length: 438
Connection: close
Content-Type: text/html; charset=UTF-8
HEAD
Variação do GET em que o recurso não é retornado. É usado para obter metainformações por meio do cabeçalho da
resposta, sem ter que recuperar todo o conteúdo.
POST
Envia dados para serem processados (por exemplo, dados de um formulário HTML) para o recurso especificado. Os
dados são incluídos no corpo do comando. Sua utilização em uma requisição ocorre quando é necessário enviar dados
ao servidor para serem processados, geralmente por um programa script identificado no Request-URI. Uma
requisição por meio desse método sempre requer que as informações submetidas sejam incluídas no corpo da
mensagem e formatadas como uma query string, além de conter cabeçalhos adicionais especificando seu tamanho
(Content-Length) e seu formato (Content-Type). Por isso, esse método oferece uma maior segurança em relação aos
dados transferidos, ao contrário do método GET que os dados são anexados a URL, ficando visíveis ao usuário.[17] Por
exemplo:
POST /index.html HTTP/1.0

Accept: text/html
If-modified-since: Sat, 29 Oct 1999 19:43:31 GMT
Content-Type: application/x-www-form-urlencoded
Content-Length: 41
Nome=NomePessoa&Idade=99&Curso=Computacao
PUT
Edita as informações de um determinado recurso.
DELETE
Exclui o recurso.
TRACE
Ecoa o pedido, de maneira que o cliente possa saber o que os servidores intermediários estão mudando em seu pedido.
OPTIONS
Recupera os métodos HTTP que o servidor aceita.
CONNECT
Serve para uso com um proxy que possa se tornar um túnel SSL (um túnel pode ser usado, por exemplo, para criar
uma conexão segura).
Códigos de estado
Ver também: Anexo:Lista de códigos de status HTTP
Do HTTP/1.0 em diante, a primeira linha da resposta HTTP é chamada linha de estado e inclui um código de estado
numérico (como "404") e uma frase de razão textual (como "Not Found" - Não Encontrado). A maneira que o agente
de usuário manipula a resposta depende primeiramente do código e secundariamente nos cabeçalhos de resposta.
Códigos de estado personalizados podem ser usados, uma vez que, se o agente de usuário encontrar um código que ele
não reconheça, ele pode usar o primeiro dígito do código para determinar a classe geral da resposta.
Da mesma forma, as frases de razão padrões são apenas recomendações e podem ser substituídas com "equivalentes
locais" a critério do desenvolvedor web. Se o código de estado indicou um problema, o agente de usuário pode mostrar
a frase de razão para o usuário, para que sejam fornecidas informações adicionais sobre a natureza do problema. O
padrão também permite que o agente de usuário tente interpretar a frase de razão, apesar disto poder ser imprudente
uma vez que o padrão especifica explicitamente que os códigos de estado são legíveis por máquina e as frases de razão
são legíveis por homens.
Conexões persistentes
No HTTP/0.9 e 1.0, a conexão é fechada após um único par de requisição/resposta. No HTTP/1.1 um mecanismo de
persistência de vida (keep-alive) foi introduzido, onde uma conexão pode ser reutilizada para mais de uma requisição.
Tais conexões persistentes reduzem a latência de requisição perceptível, pois o cliente não precisa renegociar a
conexão TCP após a primeira requisição ter sido enviada. Outro efeito colateral positivo é que em geral a conexão se
torna mais rápida com o tempo devido ao mecanismo de início-lento do TCP.
A versão 1.1 do protocolo também faz melhoras na otimização de comprimento de banda para o HTTP/1.0. Por
exemplo, o HTTP/1.1 introduziu a codificação de transferência em partes para permitir que o conteúdo em conexões
persistentes sejam transmitidos em vez de armazenados temporariamente para posterior transmissão. O pipelining
HTTP reduz ainda mais o tempo de atraso, permitindo que os clientes enviem várias requisições antes de esperar por
cada resposta. Outra melhoria para o protocolo foi o byte serving, onde um servidor transmite apenas a porção de um
recurso solicitado explicitamente por um cliente.
Estado de sessão HTTP

O HTTP é um protocolo sem estado. Um protocolo sem estado não exige que o servidor HTTP retenha informações ou
estado sobre cada usuário para a duração de várias solicitações. Entretanto, algumas aplicações web implementam
estado ou sessões do lado servidor usando um ou mais de um dos métodos a seguir:
Variáveis ocultas dentro de formulários web

Cookies HTTP
Parâmetros de query string, por exemplo, /index.php?session_id=algum_código_único_de_sessão
Resposta
Para Fielding,[18] uma mensagem de resposta do servidor é composta pelos seguintes campos: uma linha inicial
(Status-Line); linhas de cabeçalhos (Responseheader); uma linha em branco obrigatória e um corpo de mensagem
opcional. A linha inicial de uma resposta, chamada de linha de status, possui por sua vez três partes separadas por
espaços: a versão do protocolo HTTP (HTTP-Version), um código de status (Status-Code) da resposta, que fornece o
resultado da requisição, e uma frase de justificativa (Reason-Phrase) que descreve o código do status.
Códigos de retorno
A linha inicial de uma resposta HTTP indica ao cliente se sua requisição foi bem sucedida ou não.[19] Essa situação é
fornecida através de um código de retorno (Status-Code) e uma frase explicativa (Reason-Phrase). De acordo com
Fielding,[20] o código de status é formado por três dígitos e o primeiro dígito representa a classe que pertence
classificada em cinco tipos:
1xx: Informational (Informação) – utilizada para enviar informações para o cliente de que sua requisição foi
recebida e está sendo processada;
2xx: Success (Sucesso) – indica que a requisição do cliente foi bem sucedida;
3xx: Redirection (Redirecionamento) – informa a ação adicional que deve ser tomada para completar a
requisição;
4xx: Client Error (Erro no cliente) – avisa que o cliente fez uma requisição que não pode ser atendida;
5xx: Server Error (Erro no servidor) – ocorreu um erro no servidor ao cumprir uma requisição válida.
O protocolo HTTP define somente alguns códigos em cada classe descritos na RFC 2616, mas cada servidor pode
definir seus próprios códigos.
Conexões
Segundo Hirata,[21] o HTTP/1.0 é um protocolo sem estado. Isto significa que as conexões entre um cliente e um
servidor são encerradas após o envio de cada requisição ou resposta. Cada vez que uma conexão é estabelecida ou
encerrada, é consumida uma grande quantidade de tempo da CPU, de largura de banda e de memória.
Na maioria das vezes, para se obter o resultado esperado, é necessário realizar mais de uma solicitação de recursos
através de várias conexões. Por exemplo, no caso de uma página Web, que consiste de diversos arquivos (.html, .gif,
.css, etc) é preciso que sejam feitas várias requisições para compor a página, uma conexão não-persistente. O ideal
seria que apenas uma conexão fosse utilizada para os pedidos e as respostas HTTP, diminuindo, assim, a sobrecarga
ocasionada pelas conexões, uma conexão persistente.
A conexão persistente, implementada como conexão padrão no protocolo HTTP/1.1, possibilita que uma conexão seja
estabelecida para enviar várias requisições em seqüência sem a necessidade de esperar por cada resposta, no qual
serão recebidas na mesma ordem em que as solicitações foram enviadas, um processo chamado de pipelining.[22]
Pode também dar-se o caso de ser estabelecida uma conexão sem pipelining, em que o cliente só faz nova requisição
quando o servidor lhe envia a resposta, ou seja, o servidor fica inactivo até o objecto (.html, .gif, .css, etc) atingir o seu
destino no cliente.
Se uma requisição incluir o cabeçalho Connection: close, a conexão será encerrada após o envio da resposta
correspondente. Utiliza-se este cabeçalho quando não há suporte a conexões persistentes, quando for a última
requisição a ser enviada nesta conexão, ou ainda, sempre que quiser encerrar a conexão mesmo que nem todas as
requisições tenham sido completadas. Além disso, o servidor pode fechar uma conexão se estiver ociosa por um
determinado período de tempo.
Outros protocolos
Existem outros tipos de protocolos como o FTP (File Transfer Protocol, ou Protocolo de Transferência de Arquivos),
usado para envio de arquivos do computador para um servidor na Web, o SMTP (Simple Mail Transfer Protocol, ou
Protocolo de Transferência de Correio Simples), protocolo usado para correio eletrônico, entre outros protocolos.
Esquema de comunicação
Pedido básico de HTTP cliente-servidor:
GET <ficheiro> HTTP/1.1

Host: <ip>
User-Agent: <Agente>
Connection: <tipo>
O agente é quem faz a ligação ao servidor, normalmente um navegador. O tipo indica como o servidor deve proceder
com a conexão. É comumente utilizado para requisições persistentes.
Uma requisição completa pode exigir muitas informações. A requisição abaixo - utilizando o método POST - fora
retirada do Mozilla Firefox v3.6b5 (pt-BR, para Windows):
POST /diretorio/arquivo.html HTTP/1.1

Host: www.exemplo.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; pt-BR; rv:1.9.2b5) Gecko/20091204 Firefox/3.6b5
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: pt-br,pt;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-alive: 115
Cookie: nome=valor; nome2=valor2
Connection: keep-alive
Content-Length: 28
usuario=exemplo&senha=123456
Ver também
Hyper Text Transfer Protocol Secure (HTTPS)
Representational State Transfer (REST)
SPDY – An HTTP enhancement proposed by Google
Web cache
WebSockets
HTTP referrer
World Wide Web (WWW)
Lista de códigos de status HTTP
Referências
6. Foscarini (2001, p. 13)
1. T. Berners-Lee et all, 1996
7. Fielding et al, 1999, p. 21
2. Mark Nottingham (7 de Junho de 2014). «RFC2016
está morto» (https://www.mnot.net/blog/2014/06/07/rf 8. cf. Fielding et al, 1999, p. 21
c2616_is_dead) (em inglês). Mark Nottingham. 9. cf. Bastos & Ladeira, 2001
Consultado em 13 de junho de 2015 10. cf. Fielding et al, 1999
3. «HTTP/2: Internet mais rápida» (http://www.psafe.co 11. Fielding et al, 1999
m/blog/http2-internet-mais-rapida/) 12. Fielding (1999, p. 24)
4. Fielding et al 1999, p. 7 13. Bastos & Ladeira
5. Fielding et al (1999, p. 10) 14. cf. Embratel, 2002
15. Bastos & Ladeiras (2001) 18. Fielding et al (1999, p. 26)

16. «O que é um 'HTTP request'?» (http://www.portais.w 19. cf. Herrman, 1997, p. 53
s/?page=art_det&ida=1354). www.portais.ws. 20. Fielding et al (1999, p. 37)
Consultado em 15 de março de 2011
21. Hirata, 1999
17. Herrmann, 1997
22. cf. Fielding et al, 1999, p. 30
Bibliografia
T. Berners-Lee, R. Fielding, H. Frystyk (maio de 1996). «Hypertext Transfer Protocol -- HTTP/1.0» (http://www.rfc-
editor.org/cgi-bin/rfcdoctype.pl?loc=RFC&letsgo=1945&type=ftp&file_format=txt) (em inglês). Internet Engineering
Task Force. Consultado em 21 de junho de 2009
BASTOS, Leonara de Oliveira; LADEIRA, Adriane Cristina. Protocolo HTTP.
cf. 46 HERRMANN, Eric. Aprenda em 1 semana programação CGI em Perl 5. Rio de Janeiro: Campus, 1997
Ligações externas
Desenvolvimento do protocolo HTTP (http://www.w3.org/Protocols/) (em inglês)
Obtida de "https://pt.wikipedia.org/w/index.php?title=Hypertext_Transfer_Protocol&oldid=51658700"
Esta página foi editada pela última vez à(s) 07h16min de 30 de março de 2018.
Este texto é disponibilizado nos termos da licença Creative Commons - Atribuição - Compartilha Igual 3.0 Não
Adaptada (CC BY-SA 3.0); pode estar sujeito a condições adicionais. Para mais detalhes, consulte as condições de
uso.

Hypertext Transfer Protocol - Wikipédia, A Enciclopédia Livre PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Hypertext Transfer Protocol - Wikipédia, A Enciclopédia Livre PDF

Enviado por

Direitos autorais:

Formatos disponíveis

31/03/2018 Hypertext Transfer Protocol – Wikipédia, a enciclopédia livre

Visão técnica geral

Domain Path Content Expires Secure

Prefs=Stk:SUNW+ORCL;Spt:Jet 31 de dezembro de 2010

Figura x: Alguns exemplos de cookie.↵Fonte: (TANEMBAUM, 2003).

GET /index.html HTTP/1.1

POST /index.html HTTP/1.0

Estado de sessão HTTP

Variáveis ocultas dentro de formulários web

GET <ficheiro> HTTP/1.1

POST /diretorio/arquivo.html HTTP/1.1

15. Bastos & Ladeiras (2001) 18. Fielding et al (1999, p. 26)

Você também pode gostar