Parsear flag error_page que irá conter o numero do erro e o path da página destino.

Exemplo de arquivo:

server {
     error_page 404 /404.html
}

• Esse arquivo define que quando houver um erro 404 (not found) para esse server o arquivo 404.html será enviado.
• criar uma um map com código de erro como chave e path de destino com valor.

Desenvolver um metodo em Route que baseado no request tenha com sua resposta o status code e um FD.

• O FD deve ser nulo caso não seja necessário carregar um arquivo do sistema.
• O FD deve conter o FD do arquivo cadastrado no epoll caso seja necessário ler um arquivo do sistema.
• Caso sejá um directory deve conter o FD do directory e uma flag que identifique como um directory.

Como é o funcionamento da definição de error page:

• Quando definido no server: seta os destinos, página ou arquivo o mais comum é um .html com o nome do código, para todas as location. Se em alguma location não for definido o error_page por padrão ele irá pegar o error_page do server.
• Quando definido no location: seta os destinos, página ou arquivo o mais comum é um .html com o nome do código, para esse location em especifico e substitui o que tinha sido definido pelo server no location em que foi definido.

No caso de uma definição assim:

server {
    error_page 404 /404.html

    location /static {
        error_page 404 /static/404.html
        error_page 500 504 50x.html
    }

    location /images {

    }
}

• O error page do server é 404.html, então caso ocorra um acesso em uma página que não exista em qualquer location do server que não tenha reescrito o error page ele irá chamar /404.html.
• No location /static se alguma página não for encontrada com o erro 404 ele irá entregar o arquivo em /static/404.html.
• Os error pages 500 e 504 são duas chaves que contem o mesmo valor. no caso 50x.html

Implementar Class Parser para leitura do arquivo de configuração.

Parsear flag server_name que irá conter uma lista de host para o server.

Exemplo de arquivo:

server {
    server_name www.webserver.com webserver.com
}

• armazenar em um array.
• será os nomes usados para acessar o server.

Como funciona a definição do listen:

• O listen será a porta (socket) responsável por receber os request.
• Cada Server deve possuir um listen.

No caso de uma definição assim:

server {
    server_name mundo.com;
    listen 9000;
}

• O server mundo.com está ouvindo na porta 9000.

Como funciona o Http allow methods:

• Se definido no server: Defino os metodos http permitidos para todos os locations do server.
• Se definido no location: sobrescreve os valores default do server para a location especifica.

Se definido dessa forma:

server {
    server_name caramelo.com;
    listen 80;

    allow_methods GET;

    location /static/images {
        allow_methods GET POST;
    }

    location /static {

    }
}

• O server caramelo.com somente o método GET é permitido como default
• O location /static/images tem os métodos GET e POST.
• O location /static tem as permissões padrão (default) no caso o método GET.

Parser a flag listen que contem a porta onde o server estará ouvindo.

Exemplo de arquivo:

server {

     listen 80;
}

• essa flag fica dentro de server.
• armazenar em um unsigned short

Criar classe server que irá conter as informações do server.

• server_name - Host #5
• listen - Port #4
• locations
• limit_client_body_size
• routes

Como funciona a definição de um server_name:

• O server name é uma lista de URI que corresponder a um server do arquivo de configuração.
• Ele pode ser definido ou não. Quando não é definido é um assunto que precisamos ir mais a fundo para definir.
• Ele é definido somente no server.

No caso de uma definição assim:

server {
    server_name example.com www.example.com mysite.com
}

• Se um request for enviado para example.com, www.example.com ou mysite.com esse server será responsável por responder.

Parsear flag client_max_body_size que irá conter o tamanho máximo da mensagem.

exemplo de arquivo:

server {
     client_max_body_size 10M;
}

• armazenar o tamanho em bytes;
• K: Kilobytes (1024 bytes)
• M: Megabytes (1048576 bytes)
• G: Gigabytes (1073741824 bytes)

Como é a configuração do limit_client_body_size:

• Se definido no server: Será o default para todas as locations.
• Se definido no location: sobrescreve o default para aquela location especifica.
• Em seu valor temos um valor inteiro e uma letra que representa a unidade em bytes que deve ser multiplicada.
• É a quantidade de dados que pode ser enviada no payload http.

Em caso de uma configuração assim:

server {
     server_name amigo.com;
     listen 8000;

     limit_client_body_size 8M;

     location / {
        limit_client_body_size 2M;
     }

     location /static/images {
        limit_client_body_size 1G;
     }

     location /static {
        limit_client_body_size 2K;
     }

     location /img {

     }
}

• O default é de um payload de 8.388.608 bytes.
• O location / é de um payload de 2.097.152 bytes.
• O location /static/images é de um payload de 1.073.741.824 bytes.
• O location /staic é de um payload de 2048 bytes.
• O location /img recebe o payload default do server 8.388.608 bytes.

Parser a flag root do arquivo, responsável por definir um diretório raiz para uma location.

Exemplo do PDF: kapouet tem como root /tmp/www então quando chegar na url www.webserver.com/kapouet no sistema ela vai buscar por /tmp/www ao contrário de padrão que seria buscar de onde o executável foi chamado.

Como fica no arquivo:

server {
   location / {
       root   /app
   }

    location /kapouet {
        root /tmp/www
    }
}

No caso o cada uma dessas locations estará em diretórios diferentes do sistema. O root pode ser definido no server ou nas locations caso queira ao mais especifico.

Definir um map que contenha como chave o path da url e como valor o path no sistema.

Referência para o root

Criar parser da leitura do arquivo que irá transformar a linha allow_methods em uma Array de métodos permitidos para a rota.

O allowed Methods estará nessa posição do arquivo de configuração:

server {

    location <path> {
    
    allow_methods GET POST;

    }
}

Strings que pode ser passadas:

GET | POST | PUT | PATCH | DELETE | HEAD | OPTIONS | CONNECT | TRACE

o que identifica o allow_methdos é a string de mesmo nome, está dentro de uma location e terminar com ponto e vírgula na mesma linha.

Definição do server default

• A definição do server default para request ao server é baseada no primeiro item definido.

No caso de uma definição assim:

server {
    server_name secondsite.com
}

server {
     server_name firstsite.com;
}

• O server secondsite.com será o server default.

Parser de informações para o Server:

• server_name
• host
• port (listen)
• define default the first server
• error_pages
• limit client body size
• root
• Http methods

Parser de informações para o Route:

• Http Methods (allow_methods)
• redirection (rewrite)
• root
• directory listing (autoindex)
• arquivo padrão de resposta da requisição caso o caminho seja um directory (index)
• CGI
• upload files

Finalizar quando todas essas implementações forem atingidas.

Criar parser da flag rewrite que tem como objetivo redirecionar o trafego que está indo para um caminho para outro.

No arquivo de configuração irá ficar assim:

server {

   location /old_path {
       rewrite ^ /new_path;
   }

    location /new_path {

    }
}

O resultado do parser deve ser um Map com chave /old_path valor /new_path.

Nesse caso todo o trafego que chegue em /old_path será redirecionado para new_path Exemplo:

https://www.webserver/old_path será redirecionado para https://www.webserver/new_path
https://www.webserver/old_path/42 será redirecionado para https://www.webserver/new_path/42

o símbolo de ^ representa que todo o caminho que começar /old_path será rescrito. Como no exemplo da 42 acima.

Referência no Nginx