La solicitud PATCH devuelve 404, POST y GET funcionan

La solicitud PATCH devuelve 404, POST y GET funcionan

Estoy trabajando en una aplicación web que interactúa con una API REST personalizada. Básicamente es una tabla de datos que se actualiza a través de la aplicación. Estoy tratando de usar elPARCHEmétodo para las actualizaciones, pero Apache devuelve un error 404 cuando envío la solicitud.

Lo extraño es que las solicitudes GET y POST a la misma URL funcionan bien. Puedo cambiar el código de la API REST como solución alternativa, pero tengo entendido que PATCH es más "correcto"para saber cómo usamos la solicitud en la API.

Algunos detalles:

  • Parece que Apache está bloqueando la solicitud antes de que llegue a la API REST personalizada. Puedo ver solicitudes PATCH y GET en los registros de acceso de Apache, pero solo aparece la solicitud GET en el registro de API REST personalizado (FWIW, la API REST personalizada está implementada enMatraz) usandogunicorniocomo servidor de alojamiento.

    Ejemplos de registros de acceso de Apache:

    192.168.0.1 - desconocido [27/ago/2021:18:23:27 +0000] "PATCH /admin-api/services/12872 HTTP/1.1" 404 14 "https://www.example.com/admin-dashboard /"...

    192.168.0.1 - usuario administrador [27/ago/2021:18:23:43 +0000] "GET /admin-api/services/12872 HTTP/1.1" 200 988 "-"...

  • Una cosa que noté es que la solicitud PATCH reemplaza el nombre de usuario por "desconocido". Esto me llevó a creer que algo andaba mal con CORS. Encontre un "Encabezamiento" configuración a la que le faltaban OPCIONES y PARCHE, así que los agregué. Sigo viendo el mismo problema. A continuación se muestra la configuración actual de la opción:

    Header always set Access-Control-Allow-Methods "POST, GET, OPTIONS, PATCH"
    
  • No veo solicitudes de OPCIONES previas al vuelo en los registros de Apache ni en la ventana de la consola del navegador. Lo intenté con Google Chrome (92.0) y Firefox (91.0).

  • Las solicitudes de PATCH tienen el encabezado "access-control-allow-origin" configurado en "POST, GET, OPTIONS, PATCH".

  • La configuración del proxy Apache utiliza un socket Unix para enviar proxy a Gunicorn:

    <Location /admin-api>
      ProxyPass unix:/run/admin-api.sock|http://127.0.0.1
    </Location>
    
  • Solicitud de recuperación de JavaScript: ( apiUrly idson variables establecidas anteriormente en la función):

    let resp = await fetch(`${apiUrl}/services/${id}`, {
       credentials: "include",
       method: "PATCH",
       headers: {
         "Content-Type": "application/json",
         Accept: "application/json",
       },
       body: JSON.stringify({
         data: { min: 1, max: 3 },
       }),
     });
    
  • Apache versión 2.4.6. Yo sé esotécnicamenteLos sockets Unix se implementaron en2.4.7, pero todas las demás funciones funcionan. También intenté cambiar a puertos "normales", pero obtengo el mismo resultado.

información relacionada