Error de 405 explicado: Causas, correcciones y consejos de prevención

Cada código de estado HTTP cuenta una historia sobre lo que está sucediendo entre un cliente (por ejemplo, navegador web) y un servidor.Algunas historias son simples;200 significa éxito, 404 significa que la página no existe.Pero cuando ves el método 405 no permitido, la historia es un poco más interesante.

Desglosemos lo que significa el error 405, por qué sucede y cómo solucionarlo

Lo que significa el código de estado 405

El método 405 no permitido la respuesta ocurre cuando un cliente (como su navegador o una herramienta API) hace una solicitud utilizando un método HTTP que el servidor no permite ese recurso.

Por ejemplo:

• Una presentación del formulario envía un CORREO solicitud, pero el servidor solo acepta CONSEGUIR para esa url.
  
• Un guión envía un PONER solicitud, pero el punto final está configurado para permitir solo CORREO y BORRAR.

El detalle importante es que la página que está intentando alcanzar existe, pero el servidor no lo permite el método de solicitud utilizado para interactuar con ella.

¿Qué podría causar un error de 405?

El error 405 no siempre tiene una única causa obvia.Puede provenir de la forma en que se realiza una solicitud, cómo se configura el servidor o incluso de capas de seguridad adicionales en su lugar.Estas son las situaciones más comunes que lo activarían:

1. Método HTTP incorrecto

Cada recurso en un servidor está configurado para aceptar ciertos métodos HTTP.Por ejemplo:

• Una página de producto puede permitir CONSEGUIR (para buscar detalles) pero rechazar CORREO (para enviar datos).
  
• Un punto final de la API podría permitir CORREO Para crear un artículo nuevo pero devuelve un 405 si lo intenta BORRAR.

Un escenario común es cuando un desarrollador envía un CORREO Solicitud a una URL que solo fue diseñada para manejar CONSEGUIR.El servidor reconoce el recurso, pero dado que el método no es compatible, responde con 405.

Esta es una de las causas más frecuentes, especialmente cuando se trabaja con formularios, API o scripts que interactúan con los servicios web.

2. Reglas de servidor mal configuradas

Los servidores web como Apache, Nginx e IIS brindan control a los administradores sobre el cual están permitidos los métodos HTTP.Las directivas de configuración como el límite de Apache o Limit_Except de Nginx pueden bloquear explícitamente ciertos verbos.

Por ejemplo:

• Un administrador del servidor podría configurar un sitio para permitir solo CONSEGUIR y CORREO, bloqueo PONER y BORRAR Para la seguridad.
  
• Si las reglas son demasiado estrictas (o malcritas), las solicitudes legítimas pueden rechazarse con un 405.

Esto a menudo puede suceder después de los cambios en .htaccess archivos, bloques de servidor o configuración de filtrado de solicitudes de IIS.Incluso una pequeña directiva tipográfica o por alto puede dar como resultado que los métodos estén bloqueados involuntariamente.

3. Restricciones de API

Las API están diseñadas con reglas de método estricto.En una API RESTful, diferentes verbos HTTP generalmente corresponden a acciones específicas:

• CONSEGUIR → Recuperar datos
  
• CORREO → Crear nuevos datos
  
• Poner/parche → Actualizar los datos existentes
  
• BORRAR → eliminar datos

Si un desarrollador llama a un punto final con el método incorrecto, como enviar un PONER a una URL que solo permite CORREO, el servidor responde con un 405.

Esto es intencional, ya que las API están destinadas a aplicar patrones de interacción consistentes.Por ejemplo, la API de Github no te dejará BORRAR Un repositorio por error a través de una llamada de método incorrecto, requiere el verbo correcto, o obtendrá una respuesta 405.

4. Forma incorrecta o configuración de AJAX

Los formularios web y las solicitudes de JavaScript (AJAX) son otra fuente común de 405 errores:

• Una forma podría tener el Método = "Post" atributo, pero el servidor solo permite CONSEGUIR en esa url.
  
• JavaScript's buscar() o Xmlhttprequest puede codificarse para enviar una solicitud de poner cuando el backend solo admite la publicación.

Dado que los navegadores manejan la forma y los envíos de AJAX automáticamente, incluso un pequeño desajuste en la forma en que se codifica una solicitud en comparación con cómo el servidor espera que pueda activar este error.

Los principiantes a menudo encuentran esto cuando aprenden a configurar formularios en PHP o cuando trabajan con Frontend Frameworks que hacen llamadas API.

5. Herramientas de seguridad

Incluso cuando un servidor está configurado correctamente, las capas de seguridad pueden intervenir y bloquear las solicitudes.Los ejemplos incluyen:

• Firewalls de aplicaciones web (WAFS): Estos monitorean el tráfico entrante y pueden rechazar métodos como PUT, Eliminar o rastrear para reducir el riesgo de ataques.
  
• Complementos de seguridad: En plataformas como WordPress, algunos complementos deshabilitan ciertos métodos en todo el sitio para evitar solicitudes no autorizadas.

En estos casos, el servidor en sí podría admitir el método, pero la solicitud se intercepta antes de llegar a la aplicación.Esto a menudo lleva a la confusión porque los registros pueden mostrar que el servidor "rechazar" el método cuando en realidad es una capa de seguridad que realiza el filtrado.

Cómo 405 difiere de códigos de estado similares

A primera vista, el error 405 se puede confundir con Otros errores de cliente y servidor.Pero los detalles son importantes, y conocer las diferencias lo ayudarán a diagnosticarlo correctamente.

404 No encontrado

• Lo que significa: El servidor no puede encontrar el recurso que está solicitando.
  
• Ejemplo: Intenta visitar ejemplo.com/page.html, pero la página no existe en absoluto.
  
• Diferencia clave de 405: Con un 404, el problema es que el recurso en sí no está allí, mientras que con un 405, el recurso existe, solo está utilizando el método incorrecto para interactuar con él.

403 Prohibido

• Lo que significa: El recurso existe, pero el servidor le está bloqueando el acceso a él.
  
• Ejemplo: Es posible que esté tratando de ver un directorio privado sin los permisos adecuados.
  
• Diferencia clave de 405: Un 403 trata sobre los derechos de acceso, mientras que un 405 se trata de restricciones de métodos.

501 No implementado

• Lo que significa: El servidor no reconoce ni admite el método HTTP en absoluto, para cualquier recurso.
  
• Ejemplo: Un servidor que no admite solicitudes de parche lanzará este error sin importar qué recurso intente.
  
• Diferencia clave de 405: Se aplica un 501 a todo el servidor, mientras que un 405 se aplica solo a un recurso específico.

Diagnosticar el error 405

Puede ser difícil diagnosticar el 405 porque el servidor reconoce que el recurso existe, pero se niega a procesar la solicitud de la forma en que se envió.Para rastrear la causa raíz, ayuda a resolver el problema paso a paso.

1. Verifique los métodos permitidos

Cuando un servidor devuelve un 405, la respuesta debe incluir un listado de encabezado permitido qué métodos son compatibles con ese recurso.Esta es la forma del servidor de decir: "No puedes hacer eso, pero esto es lo que puedes hacer".

Ejemplo:

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

• Si lo intentó Put, esta respuesta le dice que solo Get y Public son válidos.
  
• Puede ver esto usando las herramientas de desarrollador de navegador (pestaña de red) o una herramienta como Postman.
  
• La automatización de las verificaciones de encabezado en un flujo de trabajo de depuración puede resaltar rápidamente el uso de métodos desalineados en múltiples puntos finales.

2. Revise los registros del servidor

Los registros son a menudo la forma más rápida de descubrir la causa, ya que generalmente darán una explicación directa de por qué la solicitud fue rechazada y confirma que no es un problema de conectividad más profundo.

• Apache: Comprobar el error_log archivo, generalmente en /var/log/apache2/ o /var/log/httpd/.
  
• Nginx: Revisar error.log y acceso.log, generalmente en /var/log/nginx/.
  
• IIS: Abra el visor de eventos o verifique los archivos de registro de IIS en %SystemDrive%\ inetpub \ logs \ logFiles \.

Los registros pueden mostrar entradas como:

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

3. Prueba el punto final

Herramientas como rizo o Cartero son invaluables para confirmar qué métodos funcionan realmente.La prueba de puntos finales de esta manera descarta conjeturas y le brinda una visibilidad clara sobre cómo el servidor responde a diferentes solicitudes.

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

• Si Get and Post tiene éxito pero Put Fails con un 405, ha identificado el desajuste.

Postman ofrece una interfaz visual donde puede alternar los métodos de solicitud y ver instantáneamente las respuestas, por lo que es más amigable para principiantes.

4. Verifique su código

Si el servidor permite el método pero aún obtiene un 405, el problema puede estar en su código de aplicación.

Formularios: Asegúrese de que el atributo del método del elemento <formulario coincida con lo que el servidor espera.Ejemplo:

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

Ajax/buscar: Verifique que el método de solicitud se establezca correctamente en JavaScript:

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

• Frameworks: algunos marcos (como Angular, React o Django) pueden predeterminar ciertos métodos si no los establece explícitamente.Compruebe dos veces el código del lado del cliente y el lado del servidor para desajuste.

Nota: Este paso es a menudo donde los principiantes son tropezados, enviando datos al punto final correcto pero con el verbo incorrecto.

5. Examine la configuración del servidor

Si tanto los encabezados como el código se ven bien, el problema puede ser restricciones a nivel de servidor.Los administradores a menudo bloquean los métodos por razones de seguridad, pero si se detienen las solicitudes legítimas, es necesario ajustar estas configuraciones.

Apache: Busque directivas Limit o Limitexcept en su .htaccess o configuración principal.Ejemplo:

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

• Si se falta aquí, cualquier solicitud de put devolverá un 405.

Nginx: Verifique las directivas Limit_Except:

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

• Esto rechazaría métodos que no sean Get and Post.
  
• IIS: Abra el gerente de IIS, vaya al filtrado de solicitud y revise la pestaña Verbos HTTP.Los verbos bloqueados como Put o Delete aparecerán aquí.

Arreglar un error 405 por plataforma/entorno

La reparación de un error 405 depende de la plataforma o entorno en el que se ejecuta su sitio web o aplicación.Dado que cada tipo de servidor y sistema de administración de contenido manejan las solicitudes HTTP de manera diferente, la solución puede variar.Revisemos algunas plataformas comunes y atraviesemos los pasos que podemos tomar para revisar las configuraciones y ajustar la configuración para que se permitan los métodos HTTP correctos.

Pre-verificación rápida (se aplica a todos)

1.Producir el error y leer encabezados

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

2. Si ve que lo permite, ajuste su solicitud/cliente para que coincida.Si no lo hace, continúe a continuación.

apache

1.Colle la configuración

• Configuración del sitio: /etc/apache2/sites-available/*.conf o /etc/httpd/conf.d/*.conf
  
• Reglas de Per-Dir: proyecto .htaccess

2. Realice una copia de seguridad del archivo que editará

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

3. Buscar restricciones de métodos

• Buscar <Límite ...>, <Limitexcept ...>o Rewriterule Patrones que bloquean los verbos.

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

4. Agregue los métodos necesarios o elimine el bloque restrictivo

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

5. Validar y recargar

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

6. Vuelva a probar con curl

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

7. Si aún se bloquea, verifique las capas de seguridad (por ejemplo, registros de auditoría MOD_SECURITY) y prioridad virtualhost.

Nginx

1. Abre el bloque del servidor para su sitio

• Caminos comunes: /etc/nginx/sites-available/, /etc/nginx/conf.d/*.conf

2. Realice una copia de seguridad del archivo

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

3. Busque Limit_except bloques

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

4. Agregue los métodos necesarios o retire el bloque si es innecesario

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

5. Prueba y recarga

sudo nginx -t
sudo systemctl reload nginx

6. Vuelva a probar con curl

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

7. Si está proxy a un servidor de aplicaciones, confirme que Upstream también permite el método.

IIS (Windows Server)

1. Abierta Gerente de IIS → Seleccione el sitio.
   
2. Ir Filtrado de solicitud → verbos HTTP.
   
3. Elimine las entradas de Denegar para los verbos que necesita (por ejemplo, poner, eliminar) o agregar entradas para permitir si su póliza requiere un permiso explícito.
   
4. Cheque Mapeos de controlador: si Webdav está instalado e interceptando verbos que necesita, elimina o deshabilita el controlador WebDAV para ese sitio (o desinstale WebDav si no es necesario).
   
5. Si está 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. Recicla el grupo de aplicaciones o reinicie el sitio.

7. Vuelva a probar con curl/postman.

WordPress y otras plataformas CMS

1. Volver a salvar los enlaces permanentes
   • Configuración → enlaces permanentes → Guardar cambios (Esto refresca las reglas de reescritura).
2. Prueba de conflictos de complementos
   • Deshabilite temporalmente todos los complementos.
     
   • Vuelva a habilitar uno por uno para encontrar el delincuente (seguridad, descanso/API, almacenamiento en caché y complementos de firewall son causas comunes).
3. Verifique las reglas generadas por la plataforma
   • Apache: Secciones de Htaccess agregadas por complementos.
     
   • Nginx: Bloques de servidor agregados para almacenamiento en caché/seguridad que podrían contener filtros Limit_Except o Method.
4. Si usa la API REST CMS, verifique los métodos aceptados en el punto final y ajuste el cliente o la configuración de la ruta en consecuencia.
   
5. Vuelva a probar acciones clave (formularios, inicios de sesión, acciones de administración) después de cada cambio.

API (general)

1. Confirmar el contrato

• Verifique los documentos de API para los métodos permitidos de cada punto final y las rutas esperadas.

2, sondea el punto final

# 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. Arregle el cliente o servidor (ejemplos)

• Corrección del cliente: envíe el método que el punto final realmente admite (por ejemplo, publicar en lugar de poner).
  
• 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.

• Frasco (pitón)

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

4. Establezca un 405 útil con el encabezado permitido (lado del servidor)

• Si su marco no lo establece automáticamente, agregue los métodos permitidos en la lista de encabezados.

5. Si está liderado por una puerta de enlace API/WAF, revisar las reglas de filtrado del método allí también.

6. Vuelva a probar con Postman/Curl y confirme el flujo esperado 2xx/3xx/4xx.

Después de la solución: lista de verificación rápida

• La acción ahora devuelve un éxito o el error correcto (no 405).
  
• Permitir el encabezado enumera con precisión los métodos permitidos.
  
• Los registros muestran un manejo normal, no un verbo bloqueado.
  
• Las pruebas automatizadas (si las tiene) cubren la ruta y el método corregidos.

Prevención de 405 errores en el futuro

Arreglar un error 405 cuando parece es solo la mitad del desafío: prevenirlo de nuevo es lo que le ahorra tiempo y frustración a largo plazo.Al colocar las prácticas correctas durante el desarrollo y la configuración, puede reducir las posibilidades de que los usuarios o aplicaciones se encuentren con métodos no respaldados.Aquí hay varios enfoques que ayudan a evitar que 405 errores se conviertan en problemas recurrentes.

Validar métodos en código

Al escribir formularios, scripts o llamadas API, verifique que solo esté utilizando los métodos HTTP que el servidor permite.Por ejemplo, si su servidor acepta una publicación para enviar datos, asegúrese de no usar accidentalmente GET o PUT.Los métodos de validación temprano en el desarrollo también ayudan a captar errores antes de alcanzar la producción.Muchos marcos le permiten definir métodos permitidos directamente en rutas o controladores, lo que facilita la aplicación del uso correcto.

Reglas del servidor de documentos

Los servidores a menudo tienen restricciones de métodos definidas en sus archivos de configuración (como .htaccess, nginx.conf o configuración de puerta de enlace de la API).Mantener un registro de qué métodos son compatibles facilitan tanto a los desarrolladores como a los administradores comprender los límites.Esta documentación es especialmente útil en equipos más grandes o proyectos a largo plazo, donde las reglas del servidor pueden perderse o olvidarse con el tiempo.

Manejo de errores

Incluso con una planificación cuidadosa, las solicitudes de métodos no compatibles pueden pasar.Es por eso que es útil proporcionar mensajes de error claros cuando ocurre un 405.En lugar de un "método no permitido" vago, personalice la respuesta para que el usuario o desarrollador comprenda lo que salió mal y cómo corregirlo, por ejemplo, incluido la lista de métodos permitidos en el encabezado de respuesta o sugiriendo el método correcto en su documentación.

Seguir los estándares

Si está construyendo API, mantener las mejores prácticas y los estándares HTTP facilitan que los clientes sepan qué esperar.Por ejemplo, si diseña un punto final para actualizar un recurso, use Put o Patch de manera consistente.Esta previsibilidad reduce el riesgo de que se envíen métodos no compatibles y ayuden a los desarrolladores externos a interactuar correctamente con su API.

Terminando

El error del método 405 no permitido le dice que el servidor sabe que el recurso existe, pero no permite el método que probó.

La conclusión clave: Verifique el encabezado de permitir, revise los registros y asegúrese de que sus reglas de código y servidor coincidan con los métodos que tiene la intención de admitir.