HTTP 405 Method Not Allowed en servidor: método no admitido

Aviso: Sigue el orden documentado. Un código identifica el sistema afectado, pero por sí solo no demuestra qué pieza está averiada.

1. 1

   Leer el campo de cabecera Allow devuelto en la respuesta 405 y contrastarlo con el método enviado

   Requiere herramientas

   Quién:

   Tú como desarrollador o integrador del cliente HTTP, inspeccionando las cabeceras de respuesta.

   Cómo:

   Comprueba en la traza de red el método exacto enviado en la línea de solicitud y lee el valor del campo de cabecera Allow incluido en la respuesta 405 Method Not Allowed (así como la representación explicativa del cuerpo si no era una petición HEAD).

   Resultado que importa:

   Identificas qué métodos anuncia el servidor de origen como válidos para ese recurso concreto.

   Si la cabecera Allow lista otros métodos (por ejemplo, Allow:

   GET, HEAD) y tu cliente envió un verbo distinto por apuntar al endpoint equivocado, confirma un desajuste de método o ruta en el cliente.

   Si la respuesta 405 carece por completo de la cabecera Allow o si Allow está vacío, confirma respectivamente un incumplimiento de RFC 9110 sección 15.5.6 en el servidor o que el recurso está deshabilitado por configuración.

   Evidencia a conservar:

   Conserva la línea de solicitud, el estado 405 y el valor literal de la cabecera Allow recibida.

   No desactives reglas de seguridad ni fuerces llamadas de escritura sobre rutas de solo lectura; verifica primero el contrato de la API.

   Evidencia: IANA HTTP Status Code Registry · RFC 9110 - HTTP Semantics

2. 2

   Comprobar si el rechazo 405 proviene del servidor de origen, de un intermediario o de una caché

   Sin herramientas especiales

   Quién:

   Tú como persona administradora del servidor o responsable de plataforma revisando los registros de acceso.

   Cómo:

   Verifica en los logs del proxy inverso, pasarela y servidor de origen qué componente emitió el 405, comprobando si existen cabeceras de acierto de caché (dado que 405 es heurísticamente cacheable) y recordando que un proxy no debe modificar la cabecera Allow del origen (RFC 9110 sección 10.2.1).

   Resultado que importa:

   Determinas si la petición llegó al manejador de rutas del servidor de origen o quedó retenida antes.

   Si el registro del servidor de origen muestra la petición y el envío del 405 con su cabecera Allow, descarta bloqueos en la red intermedia y confirma que la restricción reside en el recurso de origen.

   Si el servidor de origen ya admite el método pero una caché intermedia sigue devolviendo un 405 antiguo almacenado heurísticamente, confirma que debes invalidar esa entrada de caché.

   Evidencia a conservar:

   Guarda las líneas de registro correlacionadas entre el borde y el servidor de origen junto con las cabeceras de caché.

   Evidencia: RFC 9110 - HTTP Semantics

3. 3

   Verificar en métodos WebDAV si se envió PUT sobre una colección existente en lugar de MKCOL

   Sin herramientas especiales

   Quién:

   Tú como desarrollador backend o integrador cuando el endpoint opera sobre colecciones.

   Cómo:

   Revisa si el URI de destino termina en barra o corresponde a un recurso de colección existente al que tu cliente envió un método PUT o POST no admitido por ese contenedor.

   Resultado que importa:

   Compruebas si el tipo de recurso del URI coincide con la operación que intenta realizar el cliente.

   Si el cliente enviaba PUT o POST a la ruta de una colección de solo lectura en vez de a la ruta del recurso individual (o del endpoint correcto), confirma que debes corregir el URI o el método en el cliente.

   Si el endpoint sí debía aceptar ese método según la especificación de tu servicio pero el enrutador no lo tiene registrado, indica corregir el registro de rutas en el servidor.

   Evidencia a conservar:

   Anota el URI exacto solicitado, el método empleado y la tabla de rutas configurada para ese controlador.

   Evidencia: RFC 9110 - HTTP Semantics

Un código solo tiene significado dentro del producto y la versión correctos.

Definido en la sección 15.5.6 de RFC 9110 e inscrito en IANA en la clase 4xx (Client Error), el estado HTTP 405 (Method Not Allowed) señala que el método enviado en la línea de solicitud es conocido por el servidor de origen, pero no está soportado por el recurso de destino. El servidor de origen debe generar en toda respuesta 405 un campo de cabecera Allow (sección 10.2.1) con la lista de métodos soportados por ese recurso (un Allow vacío indica que no permite ninguno temporalmente), y un proxy no puede modificar esa cabecera Allow. Además, una respuesta 405 es heurísticamente almacenable en caché. Por sí solo, 405 nunca demuestra una caída del servidor.

• Atención altaadvertencia editorial

  No desactives controles de autenticación, cortafuegos de aplicaciones (WAF) ni validaciones de métodos en todo el servidor solo para evitar un HTTP 405: habilita únicamente los métodos que el recurso deba soportar.

  Evidencia: RFC 9110 - HTTP Semantics

• Precauciónverificada con fuente

  Recuerda que una respuesta 405 es heurísticamente almacenable en caché según RFC 9110 sección 15.5.6: si devuelves 405 durante un mantenimiento temporal sin cabeceras Cache-Control adecuadas, las cachés pueden seguir sirviendo el 405 tras reactivar el recurso.

  Evidencia: RFC 9110 - HTTP Semantics

1. 1

   IANA HTTP Status Code Registry

   Internet Assigned Numbers Authority · 2025 · standard

2. 2

   RFC 9110 - HTTP Semantics

   IETF / RFC Editor · 2022 · standard