Comment ajouter des en-têtes de réponse avec HAproxy 1.6 en fonction de l'URI de la demande?

J'utilise HAproxy 1.6 comme équilibreur de charge devant les serveurs tomcat.

J'ai besoin d'ajouter des en-têtes de réponse en fonction de l'URI de la demande.

Par exemple, je voudrais ajouter l'en-tête de réponse Cache-Control public,max-age="600"lorsque l'URI de la demande est, /apimais pas lorsque l'URI de la demande est autre chose.

Mon premier essai a été d'utiliser acl en fonction du chemin pour ajouter les en-têtes à http-response:

acl api path_reg ^/api/(.*)$
http-response add-header Cache-Control public,max-age="600" if api

Lorsque je démarre haproxy avec -d, j'ai un avertissement disant que path_reg(ou path) est incompatible avec http-response:

Dec  6 15:22:29 ip-10-30-0-196 haproxy-systemd-wrapper[315]: 
[WARNING] 340/152229 (2035) : parsing 
[/etc/haproxy/haproxy.cfg:78] : acl 'api' will never match because 
it only involves keywords that are incompatible with 'backend 
http-response header rule'

J'ai essayé d'ajouter l'en-tête au http-requestlieu de http-response:
```
acl api path_reg ^/api/(.*)$
http-request add-header Cache-Control public,max-age="600" if api
```
Cela a fonctionné mais j'en ai besoin dans la réponse

J'ai également essayé d'utiliser des variables haproxy:

http-request set-var(txn.path) path
acl path_acl %[var(txn.path)] -m ^/api/(.*)$
http-response add-header Cache-Control public,max-age="600" if path_acl

Mais lorsque j'essaie HAproxy ne démarre pas d'événement et j'ai l'erreur suivante:

[ALERT] 340/162647 (2241) : parsing [/etc/haproxy/haproxy.cfg:48] 
: error detected while parsing ACL 'path_acl' : unknown fetch 
method '%[var' in ACL expression '%[var(txn.path)]'.

Comment puis-je utiliser le chemin de demande dans un acl pour définir l'en-tête de réponse?

haproxy cache http-headers

— jmlrt
source

Essaye ça:

http-response set-header Cache-Control no-cache,\ max-age=600 if { capture.req.uri -m beg /api/ }

capture.req.uripersiste jusqu'à ce que la réponse soit traitée, contrairement à pathce qui n'est pas le cas.

Quelques notes:

Cet exemple utilise une ACL anonyme. Vous pouvez également le faire avec une ACL nommée, mais cela prend 2 lignes.

Il n'y a aucune raison pour laquelle je sais pourquoi vous devriez citer la valeur max-age.

Vous ne voulez probablement pas add-header, vous voulez set-header, ce qui garantit que si l'un est déjà présent, il sera supprimé.

acl path_acl %[var(txn.path)] -m ^/api/(.*)$est probablement correctement écrit comme acl path_acl var(txn.path) -m ^/api/(.*)$. HAProxy est un peu capricieux quand il attend %[ ]et quand il ne le fait pas. Je suis sûr qu'il y a un schéma, mais je ne sais pas exactement ce qu'il en est.

— Michael - sqlbot
source

Merci pour votre réponse. Les deux en utilisant la méthode capture.req.uriet les variables tout en éliminant %[ ]en acl̀travaillent. Vous avez également raison sur les citations autour de la max-agevaleur et de la set-headerplace de add-header.

— jmlrt

Notez qu'en interne, je fais quelque chose de similaire, si le back-end ne fournit pas de Cache-Controlréponse: j'ajoute un en- Cache-Control-Authority: implicit, gatewaytête pour donner au développeur / dépanneur / testeur un avertissement que moi, le proxy, je fournis cet en-tête, pas l'application , mais l'application peut me désactiver en fournissant simplement son propre en-tête. Notez que cet en-tête n'a rien de standard - je viens de l'inventer, pour aider les autres membres de l'équipe à savoir que je fournissais cela en ligne, pas l'application. Les procurations sont si sans problème qu'elles ont la mauvaise habitude d'oublier qu'elles sont sur le chemin du tout.

— Michael - sqlbot