Construindo um Web server com Login & Logout
Na última seção vimos como construir um web server simples. Passamos por fundamentos e anatomia de uma mensagem HTTP.
Como próximo passo, vamos construir um web server completo, com funcionalidade de Login e também Logout. Desta forma poderemos compreender mais algumas partes fundamentais da Web.
Para os mais ansiosos, segue este link para o Gist com o código completo de um web server com Login & Logout em bash. Já para quem quer entender como funciona esse tipo de sistema na web, continue acompanhando o guia até ao fim.
Provendo uma resposta dinâmica
Até agora, temos visto uma representação estática de resposta do server:
Não importando qual request será enviado, o response será sempre o mesmo:
Entretanto, precisamos de uma resposta dinâmica, onde, dependendo do caminho da URL no request, o server poderá devolver uma mensagem diferente. Mas como fazemos isto?
Para chegarmos a uma solução, vamos entender o mecanismo de redirecionamentos de streams com o comando netcat
.
O comando netcat fica bloqueado à espera de mensagens no socket
Assim que o comando nc
é iniciado, um socket é criado na porta escolhida e portanto fica à espera de mensagens em novas conexões criadas no socket.
O input (STDIN) do comando é utilizado posteriormente como resposta HTTP no socket
Qualquer input passado ao comando nc
, seja via interface STDIN ou redirecionado com UNIX pipe, é enviado posteriormente como resposta.
Qualquer request HTTP é enviado para o output (STDOUT) do comando
Quando uma mensagem chega em conexão no socket, esta é enviada para o STDOUT, ou pode ser redirecionada com UNIX pipe.
Em resumo, STDIN do nc
é enviado como HTTP response. E requests HTTP são enviados para o STDOUT.
Sabendo disto, podemos utilizar UNIX pipes para criar uma pipeline de request-response dinâmica, assim deixamos nosso server um pouco mais sofisticado pronto a receber funcionalidades mais avançadas.
Agora, ao fazer o request com curl
:
O problema da resposta estática ainda não foi resolvido. E se, ao invés de fazermos o cat
a partir de um arquivo estático, optarmos por fazer o cat
a partir de uma estrutura dinâmica?
Tal estrutura pode funcionar como uma fila síncrona, onde o conteúdo da estrutura só é lido quando algum outro processo tiver escrito.
Sim, estamos falando de named pipes.
Isto é incrível!
E se, ao invés de escrever no named pipe separadamente, o fizermos depois do tratamento do HTTP request? Sim, como sabemos que o request é enviado para o STDOUT, tudo o que temos de fazer é ler o STDOUT, processá-lo, e depois escrever no named pipe (response) adequadamente, para posteriormente ser enviado no socket como resposta.
Onde handleRequest
será uma função bash que iremos implementar, a qual terá como principal função ler o HTTP request do STDOUT, processá-lo e depois escrever uma resposta dinâmica no response named pipe.
Processando o HTTP request
Hora de iniciar a implementação do server com a funcionalidade mínima na função handleRequest
:
Processar o headline
Ainda dentro da função handleRequest
, dentro do loop que faz a leitura de cada linha, e utilizando expressões regulares, vamos processar o headline, que é basicamente a primeira linha da mensagem HTTP:
Okay, mas apenas o headline é necessário? E quanto às outras linhas da mensagem HTTP?
Para continuarmos com o fluxo, precisamos antes entender como funciona um login na web, o que será assunto para a próxima seção.
Last updated