Quelle est l'utilisation de la directive ProxyPassReverse

La définition de apache.org dit:

Cette directive permet à Apache httpd d'ajuster l'URL dans les en-têtes Location, Content-Location et URI sur les réponses de redirection HTTP. Ceci est essentiel lorsque Apache httpd est utilisé comme proxy inverse (ou passerelle) pour éviter de contourner le proxy inverse à cause des redirections HTTP sur les serveurs principaux qui restent derrière le proxy inverse.

Seuls les en-têtes de réponse HTTP spécifiquement mentionnés ci-dessus seront réécrits. Apache httpd ne réécrira pas les autres en-têtes de réponse, pas plus qu'il ne réécrira par défaut les références URL dans les pages HTML. Cela signifie que si le contenu mandaté contient des références URL absolues, ils contournent le proxy. Pour réécrire le contenu HTML pour correspondre au proxy, vous devez charger et activer mod_proxy_html.

chemin est le nom d'un chemin virtuel local; url est une URL partielle pour le serveur distant. Ces paramètres sont utilisés de la même manière que pour la directive ProxyPass.

Quelqu'un peut-il m'expliquer comment cela fonctionne? En général, que fait cette directive?

Si le serveur qui gère réellement une demande effectue une redirection vers une URL différente sur ce serveur, la ProxyPassReversedirective réécrit l'URL en termes de serveur proxy inverse. Par exemple, comme indiqué dans la documentation Apache , si:

 http://reverseproxy.com/mirror/foo/bar

est envoyé (proxy inversé) à

 http://backend.example.com/bar

pour la gestion, mais sur le serveur principal, il est déterminé que l'URL correcte aurait dû être quux, c'est-à-dire que la demande doit être redirigée vers

 http://backend.example.com/quux

la ProxyPassReversedirective réécrit l'URL (au proxy inverse) pour

 http://reverseproxy.com/mirror/foo/quux

avant de transmettre la réponse de redirection HTTP au client. De cette façon, le client ne connaît que le serveur proxy inverse, mais peut néanmoins faire la demande requise à l'URL correcte, http://reverseproxy.com/mirror/foo/quuxqui sera ensuite transmise par proxy inverse au serveur principal et traitée comme d'habitude. En bref, cela permet simplement au proxy inverse de renvoyer les en-têtes URI corrects sur les réponses de redirection HTTP.

Dans le guide du proxy inverse Apache 2.4 :

Pour garantir que et les en-têtes Location: générés à partir du backend sont modifiés pour pointer vers le proxy inverse, au lieu de revenir vers lui-même, la directive ProxyPassReverse est le plus souvent requise:

ProxyPass "/" " http://www.example.com/ "

ProxyPassReverse "/" " http://www.example.com/ "

Si vous avez un client et 2 serveurs, Proxy et Origin, où Origin fait le travail réel (génération de réponse) et Proxy se contente de demander des procurations à Origin, une bonne architecture de serveur est lorsque

1. L'origine ne connaît pas le proxy
2. et chaque demande passe par Proxy.

Si Origin ne connaît pas le proxy, il peut arriver qu'Origin renvoie au client une redirection HTTP (HTTP 301 ou 302) via Proxy, qui pointe directement vers lui-même, Origin. Et c'est un problème parce que le navigateur contactera directement Origin au prochain tour, ce qui violerait le point 2.

Au fur et à mesure que les réponses de redirection HTTP reviennent au proxy vers le client, le proxy peut / doit modifier ces redirections afin que l'emplacement pointe toujours vers le proxy. De cette façon, une application autonome exécutée sur Origin sans connaître le proxy peut générer n'importe quelle URL de redirection tant que le proxy est bien configuré.