Erro 405 num link: compare HEAD e GET

Não considere o link avariado apenas pelo número

O navegador abre uma página, mas uma verificação devolve 405. A diferença pede investigação, não a eliminação imediata do link. Segundo a resposta recebida, o método solicitado não é suportado para esse recurso. Isto não confirma que o conteúdo existe, é público ou está disponível para cada visitante. Guarde o endereço exato e identifique a ferramenta que produziu o resultado.

Numa pergunta do Stack Overflow, substituir GET por HEAD numa verificação provocava erros 405. Outra pergunta, no Reddit, descreve falsos positivos ao verificar links com um programa. São problemas relatados, não provas da causa do seu caso. Esta abordagem compara pedidos e confirma o conteúdo antes de decidir se deve corrigir o link, o verificador ou a configuração do site.

O que muda entre HEAD e GET

GET solicita uma representação do recurso; HEAD pede os metadados correspondentes a GET, sem o corpo dessa resposta. A MDN documenta esta distinção. Pedir apenas cabeçalhos pode poupar transferência, mas não permite ler a página nem confirmar que inclui o documento esperado. Também não garante que uma aplicação ou intermediário trate corretamente ambos os métodos. Registe qual foi utilizado quando ocorrer uma rejeição.

A RFC 9110 exige que uma resposta 405 inclua Allow com os métodos atualmente suportados pelo recurso. Consulte esse cabeçalho se a ferramenta o mostrar. Se estiver ausente, registe a ausência; não invente valores nem presuma que permitir qualquer método resolveria o problema. A resposta de exemplo é ilustrativa, não uma captura de um site real. Allow não substitui o teste do método necessário.

HTTP/1.1 405 Method Not Allowed
Allow: GET

Compare pedidos que consiga interpretar

Se administra o site e sabe utilizar um terminal, compare HEAD e GET no mesmo endereço público de consulta. Os comandos mostram cabeçalhos; o segundo descarta o corpo depois de o receber, pelo que pode descarregar dados. Substitua example.invalid pela sua página autorizada. Esse domínio é fictício, não um serviço disponível para testar. Não experimente ações de compra, eliminação ou encerramento de sessão.

Mantenha iguais a URL e as condições que controla. Registe hora, método, estado e eventual redirecionamento. Os comandos não seguem redirecionamentos: examine primeiro o destino e decida se deve repetir aí. Não acrescente credenciais nem copie cookies privados para ferramentas públicas. Um navegador com sessão iniciada e um pedido anónimo de outra máquina não formam uma comparação equivalente. Documente essa diferença antes de responsabilizar o método.

curl --head --max-time 20 "https://example.invalid/guide"
curl --silent --show-error --max-time 20 --dump-header - --output /dev/null "https://example.invalid/guide"

Interprete sem conclusões precipitadas

Se HEAD receber 405 e GET receber 200 em condições comparáveis, pode afirmar que esses pedidos receberam respostas diferentes. Ainda precisa de abrir a página e verificar o conteúdo. Se GET também receber 405, não demonstrou um problema exclusivo de HEAD. Se receber 404, a verificação HEAD anterior não comprovava a existência da página pedida. Separe cada observação da sua hipótese.

Não altere um formulário de POST para GET para eliminar a mensagem de erro. Pode modificar o funcionamento e expor dados no endereço. Não desative proteções nem permita métodos de escrita por conveniência. Num site seu, entregue os resultados a quem revê as rotas e regras do servidor. Num site alheio, peça um link público adequado ou comunique o problema sem dados sensíveis.

Acrescente uma verificação do WikiURL

Cole o endereço público completo no verificador de URL do WikiURL e guarde o estado HTTP e o endereço final detetado. É uma observação adicional feita pelo servidor do serviço. Não presuma que reproduz o navegador, a sessão ou os comandos anteriores. A interface não permite escolher manualmente HEAD ou GET; não lhe atribua uma comparação que não apresenta.

Abra depois o destino real num navegador e confirme que é a página prevista para o seu público. Se houver divergências, preserve ambos os resultados e as respetivas condições. Um 200 não certifica conteúdo nem segurança; um 405 isolado não decide por si só a remoção do link. Reúna provas úteis para corrigir o componente concreto, sem transformar uma etiqueta num diagnóstico completo.

Guarde uma decisão verificável antes de partilhar

Prepare um registo breve com URL, data, ferramenta, método conhecido ou não observado, estado, destino final e conteúdo verificado. Assinale como pendente qualquer teste em falta. Guarde os cabeçalhos necessários sem tokens, cookies ou dados pessoais. Para outra pessoa rever o caso, forneça este resumo e o comportamento esperado, em vez de uma conclusão ainda não sustentada pelas observações.

Após uma correção concreta, repita uma verificação proporcionada e confirme o conteúdo antes de encurtar o endereço ou gerar um QR com o WikiURL. Esses formatos facilitam a partilha, mas não alteram os métodos suportados pelo servidor nem reparam o recurso. Preserve o link de referência junto do ficheiro publicado. Assim distinguirá diferenças entre clientes, métodos rejeitados e destinos errados sem eliminar um endereço válido por causa de uma única resposta.