Comment modifier le code d'état d'une réponse de serveur proxy dans nginx?

Question

J'ai du mal à configurer nginx comme proxy d'un point de terminaison public S3. Mon cas d'utilisation nécessite de modifier le code d'état de la réponse S3, tout en préservant la charge utile de réponse.

Les codes d'état possibles retournés par S3 comprennent 200 et 403. Pour mon cas d'utilisation, je dois cartographier les codes d'état à 503.

J'ai essayé les éléments suivants qui ne fonctionne pas:

location ~* ^/.* { 
    [...] 
    proxy_intercept_errors on; 
    error_page    200 =503 $upstream_http_location 
} 

Nginx génère l'erreur suivante:

nginx: [emerg] value "200" must be between 300 and 599 in /etc/nginx/nginx.conf:xx

Voici un extrait plus complet:

server { 
    listen  80; 

    location ~* ^/.* { 
    proxy_http_version   1.1; 
    proxy_method    GET; 
    proxy_pass     http://my-s3-bucket-endpoint; 
    proxy_pass_request_body off; 

    proxy_set_header  Content-Length ""; 
    proxy_set_header  Connection ""; 
    proxy_set_header  Host my-s3-bucket-endpoint; 
    proxy_set_header  Authorization ''; 

    proxy_hide_header  x-amz-id-2; 
    proxy_hide_header  x-amz-request-id; 
    proxy_hide_header  Set-Cookie; 
    proxy_ignore_headers "Set-Cookie"; 

    proxy_cache   S3_CACHE; 
    proxy_cache_valid  200 403 503 1h; 
    proxy_cache_bypass  $http_cache_purge; 
    add_header    X-Cached $upstream_cache_status; 

    proxy_intercept_errors on; 
    error_page    200 =503 $upstream_http_location; 
    } 
} 

Est-il possible de réaliser ce dont j'ai besoin avec nginx?

Answer 1

J'ai trouvé une solution plus ou moins adaptée. C'est un peu hackish mais ça marche.

La clé consistait à définir le document d'index de mon compartiment S3 sur un nom de fichier inexistant. Cela provoque des demandes à/sur le point de terminaison de compartiment S3 pour aboutir à 403.

Comme le proxy nginx mappe toutes les demandes entrantes vers/sur le point de fin de compartiment S3, le résultat est toujours 403 que le proxy nginx peut intercepter. À partir de là, la directive error_page lui demande de répondre en demandant un document spécifique (dans ce cas, error.json) dans le noeud final S3 et d'utiliser 503 comme code d'état de réponse.

location ~* ^/. { 
    proxy_intercept_errors on; 
    error_page    403 =503 /error.json; 
} 

Cette solution implique deux demandes envoyées à l'extrémité du godet S3 (/, /error.json), mais au moins la mise en cache semble être activé pour les requêtes en utilisant la configuration dans l'extrait ci-dessus plus complète.

Answer 2

Lisez ce que le système vous indique. Vous ne pouvez pas modifier le code de retour "succès". Cela n'a aucun sens.