CODEWITHSUNDEEP
httpshaproxy
u123
u123

Reputation: 16287

X-Forwarded-Proto https in frontend or backend (HAProxy)?

I have setup a HAProxy in front of my backend server application to enable HTTPS. I have read that I need to set X-Forward-Proto https.

In the haproxy.cfg file I have tried to do that in the frontend with:

frontend haproxy
  bind :8443 ssl crt frontend/server.pem
  reqadd X-Forwarded-Proto:\ https
  default_backend my-backend

and that seems to make it work - e.g. I can both login to my backend server and navigate to the different pages. If I DON'T have the proto option I can only login but not navigate to any other pages.

Now I if add the option in the backend instead (removing it from the front end) with:

backend my-backend
  http-request add-header X-Forwarded-Proto https if { ssl_fc }
  server my-backend 127.0.0.1:9000

it also works, I can navigate the different pages in my backend server application.

So which is the correct way to do it? In the frontend or in the backend or does it not matter?

Upvotes: 14

Views: 45571

Answers (1)

Michael - sqlbot
Michael - sqlbot

Reputation: 179104

It doesn't matter. When you have multiple backends, it usually makes sense to do this on the frontend.

You could also use http-request set-header X-Forwarded-Proto in the front-end, rather than using reqadd.

The req* directives are much older functionality than http-request so the latter is preferred, generally, but there's an important reason why you should prefer it, here and why you should be using set-header instead of add-header: you don't want the client to be able to forge headers that only the proxy should be injecting. For non-https front-ends, you should also http-request set-header X-Forwarded-Proto http so that there is no possibility of an incorrect upstream header. The add-header option, just like reqadd, does not remove any existing headers of the same name, while set-header does.

Upvotes: 24

Related Questions