Falando de HTTP: O que os Browsers fazem?
Resumidamente, o cliente e o server trocam informações via protocolo HTTP. Ok, então vamos ver como isso funciona.
Métodos HTTP:
Ao fazer uma requisição, é necessário informar qual método será utilizado. Esses métodos identificam qual ação tem que ser executada em um determinado recurso. Os métodos mais utilizados são: GET, POST, DELETE, PUT e HEAD
GET — É através desse método que é feita a requisição de um recurso, que pode ser um arquivo tipo HTML, XML, JSON, etc.
POST — Esse método e usado para criar um recurso. Quando se utiliza esse método, os dados são enviados no corpo da mensagem e não na URI.
Êpa, o que é URI? 😵 Caso queira dar uma lida, indico esse artigo bacanudo aqui .
URL vem de UNIFORM RESOURCE LOCATOR, o que significa LOCALIZADOR DE RECURSOS UNIVERSAL. É o host(local) que você quer acessar determinado recurso. O objetivo da URL é fazer uma associação de endereço remoto com um nome de recurso na internet. Ex: google.com, google.com.br, google.com.xx
Acessando esses endereços, você cai no servidor aonde existe essa página, e aí sim o servidor vai fazer essa solicitação. Resumindo, a URL é parte da URI.
Uri vem de UNIFORM RESOURCE IDENTIFIER, o que significa IDENTIFICADOR DE RECURSOS UNIVERSAL. É o identificador do recurso e pode ser uma página, imagem ou qualquer outra coisa, já que estando na internet, tudo precisa de um identificador para que não seja confundido.
Ex de URI: www.twitter.com/alessandraluzr , www.facebook.com/profile/aledskywalker
DNS resolution: esse processo garante que assim que o usuário digitar uma URL o browser sabe em qual server conectar. ex: www.vairobozito.com.br vira 216.58.022.110
HTTP Exchange: Inicia uma conexão TCP com o server e começa o HTTP Exchange. Essa é a maneira do browser se comunicar com o server e poder receber resposta.
Os browsers conversam com os servers através do protocolo HTTP, isso envolve um cliente(nosso browser) mandando um request e o server respondendo de volta com um response.
Depois de se conectar com o server por trás do google, ele irá mandar um request que se parece com isso:
GET / HTTP/1.1
Host: vairobozito.com
Accpet: */*GET/ HTTP/1.1 — na primeira linha o browser pede ao server para recuperar o documento na localização /, adicionando isso, o resto do request vão seguir o protocolo HTTP/1.1
Host: google.com — esse é o único HTTP header no HTTP/1.1 Desde que os servers podem ter vários domínios(google.com, google.com.br, google…) o cliente aqui menciona que o request foi para aquele específico host
Accept: */* — Um header opcional, aonde o browser diz ao server que irá aceitar todos os tipos de response de volta. O server pode ter conteúdos disponíveis nos formatos Json, XML e HTML, então pode-se pegar em qualquer formato desejado.
Depois que o browser, que atua como um cliente, termina esse request, é a vez do server responder de volta. Essa resposta se parece com isso:
HTTP /1.1 200 OK
Cache-Control: private, max-age=0
Content-Type: text/html; charset=ISO-8859-1
Server: gws
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Set-Cookie: NID=1234; expires=Fri, 18-Jan-2019 18:25:04 GMT; path=/; domain=.google.com; HttpOnly
<!doctype html><html">
...
...
</html>O servidor nos deixa saber que o request foi um sucesso (200 OK) e adiciona alguns headers a resposta. Por exemplo, avisa qual server processa nosso request(server: gws), qual é a política de resposta do X-XSS-Protection e assim por diante.
Por último existe o RENDERING PROCESS:
No body response o servidor inclui a representação da resposta de acordo com o header ‘Content-Type’ . Nesse exemplo, o tipo de conteúdo retorna como um text/html, então esperamos um HTML de resposta, que é o que encontramos dentro do body.
É aqui que a mágica acontece e o browser nos mostra todo o conteúdo bonitinho, carregando todos os adicionais como CSS e JavaScript.
Se tratando da segurança, é aqui nessa troca de informações e renderizações via HTTP que a galerinha do mal se aproveita das vulnerabilidades do processo. Imagina só você estar enviando os dados do seu cartão de crédito e no meio desse caminho, alguém intercepta esses dados e os rouba? Pois é, complicado né?
Para combater esses perigos, os browsers (como Mozilla, Chrome, Safari, Edge…) possuem certos padrões web com requerimentos mínimos para os browsers trabalharem. É através do W3C (principal organização de padronização da web) que eles estabelecem esses padrões.
Mesmo com esses padrões, os browsers vão além e criam suas próprias features e isso inclui questões de segurança, afinal de contas eles competem entre si e precisam conquistar seus usuários mantendo a segurança.
Essa foi uma pequena introdução para você aí, que estava curioso sobre como essa mágica acontece. :)
