405 Erro explicado: causas, correções e dicas de prevenção

Cada código de status HTTP conta uma história sobre o que está acontecendo entre um cliente (por exemplo, navegador da web) e um servidor.Algumas histórias são simples;200 significa sucesso, 404 significa que a página não existe.Mas quando você vê o método 405 não permitido, a história é um pouco mais interessante.

Vamos quebrar o que o erro 405 significa, por que isso acontece e como solucionar problemas

O que significa o código de status 405

O método 405 não permitido a resposta ocorre quando um cliente (como seu navegador ou uma ferramenta de API) faz uma solicitação usando um método HTTP de que o servidor não permite esse recurso.

Por exemplo:

• Um envio de formulário envia um PUBLICAR solicitação, mas o servidor aceita apenas PEGAR Para esse URL.
  
• Um script envia um COLOCAR solicitação, mas o endpoint está configurado para permitir apenas PUBLICAR e EXCLUIR.

O detalhe importante é que a página que você está tentando alcançar existe, mas o método de solicitação usado para interagir não é permitido pelo servidor.

O que pode causar um erro 405

O erro 405 nem sempre tem uma causa única e óbvia.Pode vir da maneira como uma solicitação é feita, como o servidor está configurado ou mesmo a partir de camadas de segurança extras.Aqui estão as situações mais comuns que o desencadeariam:

1. Método HTTP errado

Todo recurso em um servidor está configurado para aceitar certos métodos HTTP.Por exemplo:

• Uma página de produto pode permitir PEGAR (para buscar detalhes), mas rejeite PUBLICAR (para enviar dados).
  
• Um endpoint da API pode permitir PUBLICAR Para criar um novo item, mas retorne um 405 se você tentar EXCLUIR.

Um cenário comum é quando um desenvolvedor envia um PUBLICAR solicitação a um URL que foi projetado apenas para lidar PEGAR.O servidor reconhece o recurso, mas como o método não é suportado, ele responde com 405.

Essa é uma das causas mais frequentes, especialmente ao trabalhar com formulários, APIs ou scripts que interagem com os serviços da Web.

2. Regras de servidor mal configuradas

Servidores da Web como Apache, Nginx e IIs dão aos administradores controle sobre quais métodos HTTP são permitidos.Diretivas de configuração, como o limite do Apache ou o limite_excep do nginx, podem bloquear explicitamente determinados verbos.

Por exemplo:

• Um administrador do servidor pode configurar um site para permitir apenas PEGAR e PUBLICAR, bloqueando COLOCAR e EXCLUIR para segurança.
  
• Se as regras forem muito rigorosas (ou escritas incorretas), solicitações legítimas podem ser rejeitadas com um 405.

Isso geralmente pode acontecer após mudanças para .htaccess Arquivos, blocos de servidor ou configurações de filtragem de solicitação do IIS.Mesmo um pequeno erro de digitação ou uma diretiva esquecida pode resultar em métodos bloqueados sem querer.

3. Restrições da API

As APIs são projetadas com regras rigorosas do método.Em uma API RESTful, diferentes verbos HTTP geralmente correspondem a ações específicas:

• PEGAR → Recuperar dados
  
• PUBLICAR → Crie novos dados
  
• Put/Patch → Atualizar dados existentes
  
• EXCLUIR → Remova dados

Se um desenvolvedor chama um ponto de extremidade com o método errado, como enviar um COLOCAR a um URL que só permite PUBLICAR, o servidor responde com um 405.

Isso é intencional, pois as APIs destinam -se a impor padrões de interação consistentes.Por exemplo, a API do Github não vai deixar você EXCLUIR Um repositório por engano através de uma chamada de método errada, requer o verbo correto ou você receberá uma resposta 405.

4. Formulário incorreto ou configuração de Ajax

As solicitações de formulários da Web e JavaScript (AJAX) são outra fonte comum de 405 erros:

• Um formulário pode ter o Método = "Post" atributo, mas o servidor apenas permite PEGAR naquele URL.
  
• JavaScript buscar() ou XmlHttPrequest pode ser codificado para enviar uma solicitação de put quando o back -end apenas suporta postagem.

Como os navegadores lidam com os envios de formulário e AJAX automaticamente, mesmo uma pequena incompatibilidade na maneira como uma solicitação é codificada em comparação com a forma como o servidor espera que possa acionar esse erro.

Os iniciantes geralmente encontram isso ao aprender a configurar formulários no PHP ou ao trabalhar com estruturas de front -end que fazem chamadas de API.

5. Ferramentas de segurança

Mesmo quando um servidor é configurado corretamente, as camadas de segurança podem intervir e bloquear solicitações.Exemplos incluem:

• Firewalls de aplicativos da web (WAFS): Eles monitoram o tráfego recebido e podem rejeitar métodos como put, excluir ou rastrear para reduzir o risco de ataques.
  
• Plugins de segurança: Em plataformas como o WordPress, alguns plugins desativam certos métodos em todo o local para evitar solicitações não autorizadas.

Nesses casos, o próprio servidor pode suportar o método, mas a solicitação é interceptada antes de atingir o aplicativo.Isso geralmente leva à confusão porque os logs podem mostrar o servidor "rejeitando" o método quando, na realidade, é uma camada de segurança que está fazendo a filtragem.

Como 405 difere de códigos de status semelhantes

À primeira vista, o erro 405 pode ser confundido com Outros erros de clientes e servidores.Mas os detalhes são importantes, e conhecer as diferenças ajudará você a diagnosticar corretamente.

404 não encontrado

• O que isso significa: O servidor não pode encontrar o recurso que você está solicitando.
  
• Exemplo: Você tenta visitar exemplo.com/page.html, mas a página não existe.
  
• Diferença -chave de 405: Com um 404, o problema é o próprio recurso não estar lá, enquanto que com um 405, o recurso existe - você está apenas usando o método errado para interagir com ele.

403 Proibido

• O que isso significa: O recurso existe, mas o servidor está bloqueando você de acessá -lo.
  
• Exemplo: Você pode estar tentando visualizar um diretório privado sem permissões adequadas.
  
• Diferença -chave de 405: Um 403 é sobre direitos de acesso, enquanto um 405 é sobre restrições de método.

501 não implementado

• O que isso significa: O servidor não reconhece ou suporta o método HTTP, para qualquer recurso.
  
• Exemplo: Um servidor que não suporta solicitações de patches lançará esse erro, independentemente do recurso que você tente.
  
• Diferença -chave de 405: Um 501 se aplica a todo o servidor, enquanto um 405 se aplica apenas a um recurso específico.

Diagnosticando o erro 405

Pode ser complicado diagnosticar o 405 porque o servidor está reconhecendo que o recurso existe, mas está se recusando a processar a solicitação da maneira como foi enviado.Para rastrear a causa raiz, ajuda a trabalhar com o problema passo a passo.

1. Verifique os métodos permitidos

Quando um servidor retorna um 405, a resposta deve incluir uma listagem de cabeçalho de permitir quais métodos são suportados para esse recurso.Esta é a maneira do servidor de dizer: "Você não pode fazer isso, mas aqui está o que você pode fazer".

Exemplo:

HTTP/1.1 405 Method Not Allowed
Allow: GET, POST

• Se você tentou colocar, essa resposta informa que apenas obter e postar são válidas.
  
• Você pode ver isso usando ferramentas de desenvolvedor de navegador (guia de rede) ou uma ferramenta como o Postman.
  
• Automatando as verificações do cabeçalho em um fluxo de trabalho de depuração pode destacar rapidamente o uso de métodos desalinhados em vários pontos de extremidade.

2. Revise os logs do servidor

Os registros geralmente são a maneira mais rápida de descobrir a causa, pois normalmente dão uma explicação direta de por que a solicitação foi rejeitada e confirmar que não é um problema de conectividade mais profundo.

• Apache: Verifica a error_log arquivo, geralmente dentro /var/log/apache2/ ou /var/log/httpd/.
  
• Nginx: Análise error.log e access.log, geralmente em /var/log/nginx/.
  
• IIS: Abra o visualizador de eventos ou verifique os arquivos de log do IIS em %SystemDrive%\ inetpub \ logs \ logfiles \.

Os logs podem mostrar entradas como:

client sent an unsupported method (PUT) to /index.php

3. Teste o terminal

Ferramentas como ondulação ou Carteiro são inestimáveis ​​para confirmar quais métodos realmente funcionam.Testando pontos de extremidade dessa maneira exclui adivinhação e oferece uma visibilidade clara sobre como o servidor responde a diferentes solicitações.

Usando CURL:

curl -i -X GET https://example.com/resource
curl -i -X POST https://example.com/resource
curl -i -X PUT https://example.com/resource

• Se Get and Post ter sucesso, mas a colocação falhar com um 405, você identificou a incompatibilidade.

O Postman fornece uma interface visual na qual você pode alternar os métodos de solicitação e ver instantaneamente respostas, tornando-o mais amigável para iniciantes.

4. Verifique seu código

Se o servidor permitir o método, mas você ainda estiver obtendo um 405, o problema poderá estar no código do seu aplicativo.

Formulários: Verifique se o atributo de método do elemento <form> corresponde ao que o servidor espera.Exemplo:

 <form action="/submit" method="post">

Ajax/busca: Verifique se o método de solicitação está definido corretamente no JavaScript:

 fetch('/api/data', {
  method: 'POST'
})

• Estruturas: Algumas estruturas (como Angular, React ou Django) podem padrão para determinados métodos se você não os definir explicitamente.Verifique duas vezes o código do lado do cliente e do lado do servidor para incompatibilidades.

Nota: Esta etapa é frequentemente onde os iniciantes são tropeçados, enviando dados para o ponto final direito, mas com o verbo errado.

5. Examine a configuração do servidor

Se os cabeçalhos e o código parecerem bem, o problema poderá ser restrições no nível do servidor.Os administradores geralmente bloqueiam os métodos por razões de segurança, mas se as solicitações legítimas estiverem sendo interrompidas, é necessário ajustar essas configurações.

Apache: Procure as diretivas de limite ou limitexcept em sua configuração .htaccess ou principal.Exemplo:

 <Limit GET POST>
   Require all granted
</Limit>

• Se estiver faltando aqui, qualquer solicitação de put retornará um 405.

Nginx: Verifique as diretrizes limit_except:

 location /api/ {
   limit_except GET POST {
      deny all;
   }
}

• Isso rejeitaria outros métodos além de obter e postar.
  
• IIS: Abra o gerente do IIS, vá para solicitar filtragem e revise a guia HTTP Verbs.Verbos bloqueados como put ou delete aparecerão aqui.

Corrigindo um erro 405 por plataforma/ambiente

Corrigir um erro 405 depende da plataforma ou ambiente em que seu site ou aplicativo está em execução.Como cada tipo de servidor e sistema de gerenciamento de conteúdo lida com solicitações HTTP de maneira diferente, a solução pode variar.Vamos analisar algumas plataformas comuns e seguir as etapas que podemos seguir para revisar as configurações e ajustar as configurações, para que os métodos HTTP corretos sejam permitidos.

PRÉ-CHECK rápido (aplica-se a todos)

1.Reproduzir o erro e ler cabeçalhos

curl -i -X PUT https://example.com/path

2. Se você vir permitir, ajuste sua solicitação/cliente para corresponder.Se não o fizer, continue abaixo.

Apache

1.Locate Config

• Config do site: /etc/apache2/sites-available/*.conf ou /etc/httpd/conf.d/*.conf
  
• Regras por DIR: Projeto .htaccess

2. Faça backup do arquivo que você editará

sudo cp /etc/apache2/sites-available/site.conf /etc/apache2/sites-available/site.conf.bak

3. Pesquise as restrições de método

• Procurar <Limite ...>, <Limitexcept ...>, ou Reescriture padrões que bloqueiam os verbos.

# Example: only GET/POST allowed here
<LimitExcept GET POST>
  Require all denied
</LimitExcept>

4. Adicione o (s) método (s) necessário (s) ou remova o bloco restritivo

<LimitExcept GET POST PUT>
  Require all denied
</LimitExcept>

5. Validar e recarregar

sudo apachectl -t
sudo systemctl reload apache2   # or: sudo systemctl reload httpd

6. Reteste com cacho

curl -i -X PUT https://example.com/path

7. Se ainda for bloqueado, verifique as camadas de segurança (por exemplo, mod_security audit logs) e precedência virtualhost.

Nginx

1. Abra o bloco do servidor para o seu site

• Caminhos comuns: /etc/nginx/sites-Available/, /etc/nginx/conf.d/*.conf

2. Faça backup do arquivo

sudo cp /etc/nginx/sites-available/site.conf /etc/nginx/sites-available/site.conf.bak

3. Procure limite_except blocos

location /api/ {
  limit_except GET POST {
    deny all;
  }
}

4. Adicione o (s) método (s) necessário (s) ou remova o bloco se desnecessário

location /api/ {
  limit_except GET POST PUT {
    allow all;
  }
}

5. Teste e recarregar

sudo nginx -t
sudo systemctl reload nginx

6. Reteste com cacho

curl -i -X PUT https://example.com/api/resource

7. Se você procurar um servidor de aplicativos, confirme o upstream também permite o método.

IIS (servidor Windows)

1. Abrir Gerente do IIS → Selecione o site.
   
2. Vamos para Filtragem de solicitação → verbos http.
   
3. Remova todas as entradas de negação para os verbos necessários (por exemplo, coloque, exclua) ou adicione as entradas Permitir se sua política exigir permitir explícito.
   
4. Verifica Mapeamentos do manipulador: se Webdav está instalado e interceptando os verbos necessários, remova ou desative o manipulador WebDav para esse site (ou desinstale webdav, se não for necessário).
   
5. Se estiver presente, revise web.config para:

<system.webServer>
  <handlers> ... </handlers>
  <security>
    <requestFiltering>
      <verbs>
        <!-- Remove Deny for verbs you need -->
        <add verb="PUT" allowed="true" />
      </verbs>
    </requestFiltering>
  </security>
</system.webServer>

6. Recicle o pool de aplicativos ou reinicie o site.

7. Reteste com Curl/Postman.

WordPress e outras plataformas CMS

1. Revestir os Permalinks
   • Configurações → Permalinks → Salvar alterações (Isso atualiza as regras de reescrita).
2. Teste para conflitos de plug -in
   • Desative temporariamente todos os plugins.
     
   • Reative um por um para encontrar o agressor (plugins de segurança, REST/API, cache e firewall são causas comuns).
3. Verifique as regras geradas pela plataforma
   • Apache: .htaccess Seções adicionadas por plugins.
     
   • Nginx: Blocos de servidor adicionados para cache/segurança que podem conter filtros limit_except ou método.
4. Se você usar a API REST CMS, verifique os métodos aceitos no terminal e ajuste o cliente ou a configuração de rota de acordo.
   
5. Reteste as ações -chave (formulários, logins, ações de administrador) após cada alteração.

APIs (Geral)

1. Confirme o contrato

• Verifique os documentos da API para obter os métodos permitidos de cada endpoint e os caminhos esperados.

2, sonda o terminal

# Discover allowed methods (if supported)
curl -i -X OPTIONS https://api.example.com/v1/items/123
# Then try the method you intend
curl -i -X PATCH https://api.example.com/v1/items/123

3. Corrija o cliente ou servidor (exemplos)

• Correção do cliente: envie o método que o terminal realmente suporta (por exemplo, postagem em vez de put).
  
• Express (Node.js)

 app.post('/items', createItem);
app.put('/items/:id', updateItem);
// If PUT not defined, add it—or switch your client to POST if that's the design.

• Balão (python)

 @app.route('/items/<id>', methods=['GET','POST','PUT','DELETE'])
def item(id): ...

4. Defina um 405 útil com o cabeçalho de permitir (lado do servidor)

• Se sua estrutura não defini-la automaticamente, adicione a listagem de cabeçalho permitida.

5. Se liderado por um gateway/waf de API, também revise as regras de filtragem por lá.

6. Reteste com Postman/Curl e confirme o fluxo esperado 2xx/3xx/4xx.

Após a correção: lista de verificação rápida

• A ação agora retorna um sucesso ou o erro correto (não 405).
  
• Permitir que o cabeçalho lista com precisão os métodos permitidos.
  
• Os logs mostram manuseio normal, não um verbo bloqueado.
  
• Os testes automatizados (se você os possuem) cobrem o caminho e o método corrigidos.

Prevendo 405 erros no futuro

Corrigir um erro 405 quando aparece é apenas metade do desafio - prevê -lo de acontecer novamente é o que economiza tempo e frustração a longo prazo.Ao implementar as práticas certas durante o desenvolvimento e a configuração, você pode reduzir as chances de usuários ou aplicativos que se deparam com métodos não suportados.Aqui estão várias abordagens que ajudam a impedir que 405 erros se tornem problemas recorrentes.

Validar métodos no código

Ao escrever formulários, scripts ou chamadas de API, verifique se você está usando apenas os métodos HTTP que o servidor permite.Por exemplo, se o seu servidor aceitar postagem para enviar dados, verifique se você não usa acidentalmente GET ou PUST.A validação de métodos no início do desenvolvimento também ajuda a capturar erros antes de atingirem a produção.Muitas estruturas permitem definir métodos permitidos diretamente em rotas ou controladores, facilitando a aplicação do uso correto.

Regras do servidor de documentos

Os servidores geralmente têm restrições de método definidas em seus arquivos de configuração (como configurações .htaccess, nginx.conf ou API Gateway).Manter um registro de quais métodos são suportados facilita para os desenvolvedores e administradores entenderem os limites.Esta documentação é especialmente útil em equipes maiores ou projetos de longo prazo, onde as regras do servidor podem ser perdidas ou esquecidas ao longo do tempo.

Manuseio de erros

Mesmo com um planejamento cuidadoso, solicitações de método não suportadas podem passar.É por isso que é útil fornecer mensagens de erro claras quando um 405 ocorre.Em vez de um vago "método não permitido", personalize a resposta para que o usuário ou desenvolvedor entenda o que deu errado e como corrigi -lo - por exemplo, incluindo a lista de métodos permitidos no cabeçalho da resposta ou sugerindo o método certo em sua documentação.

Siga os padrões

Se você estiver construindo APIs, manter as melhores práticas e os padrões HTTP facilitam o que os clientes saibam o que esperar.Por exemplo, se você projetar um terminal para atualizar um recurso, use o put ou o patch de forma consistente.Essa previsibilidade reduz o risco de métodos não suportados serem enviados e ajuda os desenvolvedores externos a interagir com sua API corretamente.

Empacotando

O método 405 não permitido por um erro indica que o servidor sabe que o recurso existe, mas não permite o método que você tentou.

O principal argumento: Verifique o cabeçalho Aportar, revisar os logs e verifique se as regras de código e servidor correspondem aos métodos que você pretende suportar.