Guia completo dos códigos de estado HTTP: série 400

Os problemas com um cliente user-agent podem ir desde pedidos de recursos que já não estão disponíveis (por um URI mal escrito) até à reação do servidor a pedidos que correspondem à assinatura de um ataque.

O mais comum é o 404. O 404 Not Found é devolvido quando um cliente pede um recurso que o servidor web não consegue encontrar:

Vejamos os códigos de resposta mais comuns e interessantes da série 400 com um pouco mais de detalhe.

400 Bad Request

O 400 Bad Request é (normalmente) o resultado de um user-agent enviar no pedido algo que o servidor web não conseguiu processar. Vamos gerar um 400 Bad Request para perceber o que pode causar este erro.

Vamos à moda antiga, em Linux, com uma ferramenta chamada netcat. O netcat pode ser usado para enviar dados em bruto através de sockets. Afinal, os pedidos HTTP/1.1 são exatamente isso: texto em bruto.

Primeiro, enviemos um pedido HEAD legítimo à google:

Forcemos um 400 Bad Request:

image: src /blog/wp-content/uploads/2017/12/3CEEAuo-e1513087453173.jpg (unchanged); alt: Pedido inválido forçado a gerar um 400

Enviámos de propósito um pedido que o servidor não conseguia entender. Vejamos o método de pedido usado:

$ nc www.google.com 80 BAD / HTTP/1,1 Host: www.google.com

O servidor web não conseguiu processar o método: BAD

É improvável que um browser moderno envie pedidos malformados como o acima. No entanto, se estiver a usar uma aplicação HTTP desenvolvida à medida, como um web scraper, está na hora de fazer debugging.

Estes passos resolvem os erros 400 mais comuns.

1. Verifique o URL

Se clicou numa ligação, é bem possível que o autor da página tenha cometido uma gralha. Examine o URL completo, com particular atenção ao caminho, ao título do documento e à query string.

2. Limpe todos os cookies e a cache

Limpar os cookies e a cache corrige muitos erros 400, e é também um bom primeiro passo para muitos outros códigos de estado 400.

1. limpe todos os cookies e o histórico de navegação
2. tente o pedido de novo

No Chrome, no Edge e no Firefox a opção está nas definições do browser, em Privacidade, normalmente com o nome «Limpar dados de navegação». Os nomes dos menus variam com a versão. Limpar apenas os cookies do site afetado é muitas vezes suficiente.

Limpar todos os cookies e o histórico de navegação garante que tudo o que estava em cache ou corrompido (como os cookies) desapareceu. Isto corrige frequentemente um 400 Bad Request.

3. Tamanho do ficheiro carregado

O problema pode muito bem ser um script de backend, o carregamento de um ficheiro demasiado grande ou de um ficheiro com um tipo de media incorreto.

1. Se o 400 bad request surgir ao carregar um ficheiro, tente um ficheiro mais pequeno.
2. Confirme que o tipo de ficheiro é aceite.
3. Se estiver a carregar uma imagem, experimente ambos os formatos, jpeg e png.
4. Se estiver a carregar um documento, o texto simples e os formatos de escritório comuns são normalmente permitidos.

4. Cabeçalhos malformados

Os cabeçalhos malformados são um problema de nível bastante baixo e podem muito bem deixar a própria aplicação web como responsável.

As ferramentas de programador incluídas em todos os browsers modernos (o separador Network) permitem-nos observar toda a transação HTTP à procura de algo fora do comum.

5. Atualize o browser e desative os plugins

Se o browser estiver desatualizado, pode muito bem estar a enviar cabeçalhos e pedidos antiquados.

Experimente também remover ou desativar todos os plugins e extensões. Tentar o mesmo pedido noutro browser também pode ajudar a isolar o problema.

6. Experimente terminar a sessão

Se estiver a usar uma aplicação web com autenticação de utilizadores e sessões, experimente terminar a sessão e depois limpar a cache do browser.

(hr)

401 Unauthorized

O 401 Unauthorized é devolvido quando um servidor web pede credenciais para um documento protegido.

403 Forbidden

O 403 Forbidden é normalmente uma de quatro coisas:

• a listagem de diretórios não é permitida
• o utilizador atualmente autenticado não tem permissões suficientes
• o processo do servidor web tem permissões inadequadas
• o endereço que faz o pedido foi bloqueado

Listagem de diretórios não permitida

Aqui o servidor web não permite listagens de diretórios a utilizadores não autenticados. A correção mais simples é colocar um ficheiro index no diretório. Caso contrário, as listagens de diretórios para utilizadores não autenticados terão de ser definidas explicitamente.

O utilizador autenticado não tem permissões

O melhor método nesta situação é criar um grupo para todos os utilizadores que precisam de acesso a um recurso. Dê a esse grupo as permissões necessárias ao nível do sistema de ficheiros. Depois, adicione os utilizadores permitidos ao grupo.

O processo do servidor web não tem permissões suficientes

image: src /blog/wp-content/uploads/2017/12/XSkGl4h-e1513087253567.jpg (unchanged); alt: Acesso negado

Não conseguimos aceder à página test.php no webroot em /var/www/html. Em RHEL e nos seus derivados (Oracle Linux, AlmaLinux, Rocky Linux) há duas coisas a verificar: as permissões clássicas de ficheiros e o contexto SELinux.

Primeiro, verifique a propriedade e as permissões:

# ls -ld /var/www/html/ drwx------. 3 root root 4096 Nov 24 03:47 /var/www/html/

O diretório pertence ao utilizador root e ao grupo root, sem acesso para mais ninguém, pelo que o processo do servidor web (utilizador apache no Apache httpd, nginx no nginx) não o consegue ler. Dê ao grupo do servidor web acesso de leitura, sem escrita:

# chgrp -R apache /var/www/html # chmod 750 /var/www/html # chmod 640 /var/www/html/test.php # ls -ld /var/www/html/ drwxr-x---. 3 root apache 4096 Nov 24 03:47 /var/www/html/ # ls -l /var/www/html/test.php -rw-r-----. 1 root apache 91 Nov 16 06:52 /var/www/html/test.php

Segundo, verifique o contexto SELinux. Os ficheiros movidos para o webroot a partir de outro sítio mantêm a etiqueta antiga, e o SELinux bloqueia então o servidor web mesmo quando as permissões estão certas:

# ls -Z /var/www/html/test.php # restorecon -Rv /var/www/html

O conteúdo em /var/www/html deve ter o tipo httpd_sys_content_t. Corrija a etiqueta com restorecon. Nunca desative o SELinux para fazer desaparecer um 403.

Como boa prática de segurança, o grupo do servidor web não deve ter permissões de escrita em ficheiros e pastas. Onde um sistema de gestão de conteúdos precisar de escrever (uma pasta de uploads, por exemplo), conceda acesso de escrita apenas a essa pasta e, em RHEL, atribua-lhe o tipo SELinux httpd_sys_rw_content_t.

Negar permissões de escrita em ficheiros e pastas pode acrescentar uma camada de segurança no caso de uma falha da aplicação web ser explorada por um atacante para modificar conteúdo, apagar ficheiros ou acrescentar ficheiros.

Num ambiente de staging, coloque os programadores no grupo do servidor web e dê a esse grupo acesso de escrita. Mantenha a produção apenas de leitura.

Outro cenário comum para um estado 403 Forbidden pode ser um endereço IP ou um intervalo de IP bloqueado num ficheiro .htaccess pelo administrador do servidor.

404 Not Found

O 404 Not Found significa que o servidor web não conseguiu encontrar um recurso pedido. Ao encontrar um erro 404, há algumas coisas que pode fazer:

• verifique a ortografia do host, do domínio, do caminho e do documento
• verifique maiúsculas e minúsculas no ficheiro e no caminho. Os servidores web em Linux e Unix (salvo configuração em contrário) distinguem normalmente maiúsculas de minúsculas, sendo tradição usar tudo em minúsculas.
• use o Google para encontrar um URL alternativo para o recurso
• experimente uma cópia arquivada da página no Wayback Machine do Internet Archive

Utilizar operadores de pesquisa avançada do Google

image: src /blog/wp-content/uploads/2017/12/KbnaNqB-e1513087331180.jpg (unchanged); alt: Google: obter todos os ficheiros PDF

Uma pesquisa como a acima, com operadores como site: e filetype:, encontra muitas vezes um documento cuja ligação antiga devolve agora um 404.

Se a página tiver sido retirada, o Wayback Machine do Internet Archive pode ainda guardar uma cópia mais antiga.

405 Method Not Allowed

Um 405 Method Not Allowed é apresentado quando se tenta um método de pedido não permitido pelo servidor web.

406 Not Acceptable

O 406 Not Acceptable é devolvido quando o servidor não consegue fornecer o recurso em nenhum dos tipos de conteúdo, codificações, idiomas ou conjuntos de caracteres que o cliente declara aceitar.

Para resolver um 406, veja os cabeçalhos do pedido nas ferramentas de programador do browser (separador Network).

Os valores de cabeçalhos enviados pelo cliente que vale a pena rever incluem:

• Accept
• Accept-Charset
• Accept-Encoding
• Accept-Language

Os browsers modernos raramente o provocam. Se o seu o fizer, experimente atualizá-lo para uma versão mais recente.

407 Proxy Authentication Required

O 407 Proxy Authentication Required significa normalmente que o user-agent precisa de fornecer credenciais para aceder a um servidor proxy.

image: src /blog/wp-content/uploads/2017/12/GpVOCul.jpg (unchanged); alt: Fornecer credenciais de proxy em Linux

408 Request Timeout

O 408 significa que o servidor esperou demasiado tempo que o cliente terminasse de enviar o pedido. Aponta normalmente para uma ligação do cliente lenta ou instável, e não para o servidor.

429 Too Many Requests

O 429 significa normalmente que foi ativado rate limiting no servidor. O rate limiting só permite um certo número de pedidos num intervalo de tempo definido.

Ao receber 429 Too Many Requests, abrande. O servidor pode enviar um cabeçalho Retry-After que indica quanto tempo esperar antes de tentar de novo. Os clientes e scripts bem comportados respeitam-no e recuam.

451 Unavailable for Legal Reasons

O 451 é devolvido quando o servidor é legalmente obrigado a bloquear o acesso a um recurso, por exemplo na sequência de uma decisão judicial.