EA878:2009 2S:atividade5

De DCA-Wiki

Contents

EA878 - Laboratório de Micro e Minicomputadores: Software

Atividade 5

Tema: Funções básicas de servidor HTTP

Introdução

Esta atividade objetiva criar as funções básicas necessárias para um servidor http. O programa obtido irá interagir apenas com arquivos nesta etapa, operando com requisições e respostas em disco. Nas próximas etapas, faremos o servidor operar diretamente com a rede.

Todas as decisões de projeto devem estar bem documentadas no relatório da atividade. Os programas implementados também deverão estar devidamente documentados com comentários dentro do código fonte, além de explicações sobre seu funcionamento e sobre os resultados de seus testes.

Atividades de Projeto

  1. A fim de obter requisições completas e bem formatadas para fazer testes, altere o programa http-dump (Atividade 2) de modo que o mesmo salve as requisições de browsers comerciais em arquivos em disco, os quais serão usados como entradas do servidor implementado nesta atividade. Use diferentes requisições (arquivos existentes ou não, diretórios existentes ou não, etc. ) e diferentes browsers, para ter uma ampla gama de requisições para seus testes.
    • Obs:
      • observe que o protocolo HTTP 1.1 documentado na RFC2616 determina que todas as linhas devem ser terminadas pelos caracteres não-imprimíveis CR (Carriage Return) e LF (Line Feed). Portanto, as requisições colhidas de navegadores estarão seguindo esta determinação, o que faz com que haja mais caracteres do que é visto em cada linha do arquivo de entrada;
      • as requisições que não podem ser enviadas livremente a partir de um browser (caso de OPTIONS, HEAD e TRACE, por exemplo) devem ser criadas com um editor de texto, de acordo com a RFC2616. Neste caso, os dois caracteres especiais (CR/LF) não estarão presentes (se o arquivo foi criado em ambiente Unix). Uma forma de inseri-los é editar tal arquivo em ambiente Windows ou usar um editor (hexadecimal) que permita introduzir caracteres de controle diretamente. Uma outra forma é guardar em um arquivo as requisições que o http-dump (usando a porta P) recebe quando ele é acessado via o comando telnet na porta P;
      • cada arquivo deverá ter informações referentes a apenas uma requisição.
  2. A função criada na Atividade 4 já está bem próxima de uma função para processar requisições GET vindas de um browser. Ela também pode ser usada como base para uma função dedicada à requisição HEAD. Portanto faça as adaptações necessárias e crie as funções específicas para atender a requisições GET e HEAD.O recurso retornado por estas funções deve ser acompanhado de um cabeçalho formal, seguindo rigorosamente o formato das mensagens de retorno definidas na RFC2616 e observadas na Atividade 2. O valor do parâmetro Date do cabeçalho deverá refletir a data e hora reais, as quais podem ser obtidas e formatadas por chamadas de sistema tais como gettimeofday() e asctime(). Os valores dos parâmetros Content-Length e Last-Modified poderão ser obtidos pela chamada fstat().
  3. Complemente este repertório de funções, criando outras para processar requisições TRACE e OPTIONS (lembre-se de que estas duas não estão ligadas a um recurso em particular, mas precisam de um cabeçalho de retorno também).
  4. Crie também uma função para processar os erros (arquivos não encontrados, acesso negado, etc.), a qual deve gerar mensagens (ou arquivos) em html orientando o usuário a respeito do tipo de erro ocorrido. Os tipos de erro possíveis podem ser encontrados na RFC2616.
  5. Integre todas as funções ao parser que ficou pronto na Atividade 3. Esta integração completa a versão inicial de nosso servidor. Ele deverá obter uma requisição HTTP de um arquivo em disco, imprimir a requisição na tela e enviar o resultado do processamento da requisição para outro arquivo em disco. A forma de uso desta versão inicial do servidor deverá ser a seguinte:
    • ./servidor <Web Space> requisicao_n.txt resposta_n.txt registro_log.txt
    • onde:
      • servidor é o nome do programa,
      • <Web Space> é a raiz do espaço web escolhido,
      • requisicao_n.txt é o n-ésimo arquivo com uma requisição http,
      • resposta_n.txt é o arquivo com a resposta completa à n-ésima requisição e
      • registro_log.txt é um arquivo que conterá cópias das requisições, sendo cada cópia seguida da resposta (mas sem o conteúdo do recursos solicitado, no caso de GET)
    • Obs:
      • as requisições lidas dos arquivos de teste deverão ser completamente analisadas pelo parser e armazenadas na estrutura de dados especificada na Atividade 3;
      • é possível fazer com que o parser leia de um arquivo e não da entrada padrão mudando o conteúdo do descritor de entrada yyin;
      • é possível fazer com que o parser leia de um buffer na memória (que contenha o que foi lido de um arquivo previamente) usando a chamada yy_scan_string();
      • a impressão dos detalhes das requisições na tela deverá ser feita a partir de uma varredura do conteúdo desta estrutura de dados;
      • o parser deverá considerar a questão das linhas terminadas em CR/LF para poder funcionar adequadamente;
      • cada novo par requisição/resposta deverá ser anexado ao final do arquivo registro_log.txt.
  6. O relatório de atividades deve documentar e explicar detalhadamente:
    • as funções criadas
    • os resultados dos testes feitos com cada uma das funções, usando os diversos arquivos gerados por http-dump no item 1. Todas as funções devem ser testadas, incluindo a de tratamento de erros em suas diversas possibilidades.
  • Obs: se o conteúdo da página html enviada em resposta a uma requisição GET for muito extenso, ele poderá ser truncado no relatório.

A figura abaixo ilustra algumas etapas e componentes desta atividade. Imagem:Estrutura.jpg

Ferramentas pessoais