A solicitação PATCH retorna 404, POST e GET funcionam

A solicitação PATCH retorna 404, POST e GET funcionam

Estou trabalhando em um aplicativo Web que interage com uma API REST personalizada. É basicamente uma tabela de dados que é atualizada através do aplicativo. Estou tentando usar oCORREÇÃOmétodo para as atualizações, mas o Apache está retornando um erro 404 quando envio a solicitação.

O estranho é que as solicitações GET e POST para a mesma URL funcionam bem. Posso alterar o código da API REST como uma solução alternativa, mas meu entendimento é que PATCH é mais "correto" para saber como estamos usando a solicitação na API.

Alguns detalhes:

  • Parece que o Apache está bloqueando a solicitação antes que ela chegue à API REST personalizada. Posso ver solicitações PATCH e GET nos logs de acesso do Apache, mas apenas a solicitação GET aparece no log da API REST personalizada (FWIW, a API REST personalizada é implementada emFrasco) usandoGunicórniocomo um servidor de hospedagem.

    Exemplo de registros de log de acesso do Apache:

    192.168.0.1 - desconhecido [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 - usuário administrador [27/ago/2021:18:23:43 +0000] "GET /admin-api/services/12872 HTTP/1.1" 200 988 "-" ...

  • Uma coisa que notei é que a solicitação PATCH está substituindo o nome de usuário por “desconhecido”. Isso me levou a acreditar que algo estava errado com o CORS. Achei um "Cabeçalho"configuração que estava faltando OPTIONS e PATCH, então eu os adicionei. Ainda vendo o mesmo problema. Abaixo está a configuração atual da opção:

    Header always set Access-Control-Allow-Methods "POST, GET, OPTIONS, PATCH"
    
  • Não estou vendo solicitações de OPTIONS pré-voo nos logs do Apache ou na janela do console do navegador. Eu tentei com Google Chrome (92.0) e Firefox (91.0).

  • As solicitações PATCH têm o cabeçalho "access-control-allow-origin" definido como "POST, GET, OPTIONS, PATCH"

  • A configuração do proxy Apache usa um soquete Unix para fazer proxy para Gunicorn:

    <Location /admin-api>
      ProxyPass unix:/run/admin-api.sock|http://127.0.0.1
    </Location>
    
  • Solicitação de busca JavaScript: ( apiUrle idsão variáveis ​​definidas anteriormente na função):

    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 versão 2.4.6. eu sei quetecnicamenteSoquetes Unix foram implementados em2.4.7, mas todas as outras funcionalidades funcionam. Também tentei mudar para portas "regulares", mas obtive o mesmo resultado.

informação relacionada