https://twitter.com/connolly_s/status/961223121981399040
for example, here is a working haproxy configuration without any crazy
rewrite rules:
frontend jenkins
mode http
bind *:80
use_backend jenkins
frontend jenkins-tls
mode https
bind *:443 crt /path/to/server.pem
use_backend jenkins
backend jenkins
mode http
option forwardfor
http-request set-header X-Forwarded-Host %[req.hdr(Host)]
http-request del-header X-Forwarded-Port
http-request set-header X-Forwarded-Proto https if { ssl_fc }
server jenkins jenkins.internal.example.com:8080 check
and that works perfectly fine, no reverse proxy warnings, all urls
generated correctly irrespective of the url you access the reverse proxy
with.
I would love to know why we are pushing much more complex and brittle (and
probably subtly broken... *cough*
https://issues.jenkins-ci.org/browse/JENKINS-44006 and similar *cough*
*cough*
Don't get me started on how complex all the other configurations are for
apache, iis, squid, nginx, etc
I suspect all could be simplified to just set X-Forwarded-Host to the Host
header (and remove any X-Forwarded-Port that evil hacker injected in their
request to the reverse proxy) or parse the Host header and set
X-Forwarded-Host to the parsed requested hostname and X-Forwarded-Port to
the parsed requested port... no rewrite rules... and everyone would be
happy.
Thoughts?
--
You received this message because you are subscribed to the Google Groups
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMyCVRaSkqOJEVH7BLt_%2B4o2n57wbLyD3wcEUCknDKkH4w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
