Double reverse proxies with https lead to double X-Scheme headers generated by haproxy

[foosel]

See OctoPrint/OctoPrint#1391 and specifically this comment.

The current haproxy.cfg as shipped with OctoPi will always add an X-Scheme header to the request towards OctoPrint, even if an X-Scheme header already exists on the request. That lead to problems within OctoPrint since it would read two (or more) X-Scheme headers as https,https, generating wrong URLs as a consequence. While that has now been solved (and the corresponding fix will be part of the next release) we should still make sure to not generate secondary X-Scheme headers - if a header is already set, we need to just forward it and not touch it in any way.

I've experimented a bit with haproxy.cfg and I think I've found a proper way to solve this:

backend octoprint
        acl needs_scheme req.hdr_cnt(X-Scheme) eq 0

        reqrep ^([^\ :]*)\ /(.*) \1\ /\2
        reqadd X-Scheme:\ https if needs_scheme { ssl_fc }
        reqadd X-Scheme:\ http if needs_scheme !{ ssl_fc }
        option forwardfor
        server octoprint1 127.0.0.1:5000

This should ensure X-Scheme: https to only be set if haproxy is accessed through SSL and there's not already an existing X-Scheme header. Likewise for X-Scheme: http if haproxy is not accessed through SSL and there's no existing header already.

I'd like to give this a bit more testing before preparing a PR though.

[foosel]

Fixed through merged PR #317