Eh why are we suggesting such a complex reverse proxy configuration?

[Stephen Connolly]

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?

[Marco Brondani]

+1  to this.

I’m using a very similar configuration in my own setup.

And I see that the X-Forwarded* headers on Apache without rewrite rules get the Job done as well.

 

Cheers

--
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 jenkinsci-de...@googlegroups.com.
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.

 

[Devin Nusbaum]

+1, I support editing the pages to focus on a simple config that just changes X-Forwarded headers.

I created the HAProxy wiki page while testing the HTTP duplex CLI mode with various reverse proxies, so I am fully to blame :) I had no prior knowledge about HAProxy and pieced together a working config based on some googling, so please edit the page if there is something much simpler that will work!

I think a lot of the complexity in these pages comes from things that many users don’t need (for example, serving static files directly, using a different context path, special buffering and/or timeout options to get the HTTP duplex CLI working, or a fix for a random issue specific to one user’s environment). I am hesitant to delete these settings from the wiki outright, but we should at least move them into a clearly labeled subsection that explains why they should and shouldn’t be used (for example, turning off request buffering might get the HTTP duplex CLI mode working, but it might also tank performance).

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/5a7b01a9.11b8500a.2b51a.8357%40mx.google.com.

[Daniel Beck]

> On 7. Feb 2018, at 16:25, Devin Nusbaum <dnus...@cloudbees.com> wrote:
>
> using a different context path

I think this is one that's too relevant to just remove.

- Jenkins on /, reverse proxy serves at /jenkins
- Jenkins on /jenkins, reverse proxy serves at /
- Jenkins on /jenkins, reverse proxy serves at /builds (seems unusual)

Given the wiki-ness of the content it should be no surprise all possible permutations are listed.

These reverse proxy pages have long a concern to me (my most popular example why the docs primarily should be on the site), but just ripping out all the content without being able to say "Don't even try changing context path, it's not going to work no matter what you do" still doesn't sit right with me.

Perhaps shove those more unusual use cases into a secondary page and primarily highlight the simple, straightforward config?

[Daniel Beck]

> On 7. Feb 2018, at 20:04, Daniel Beck <m...@beckweb.net> wrote:
>
>>
>> On 7. Feb 2018, at 16:25, Devin Nusbaum <dnus...@cloudbees.com> wrote:
>>
>> using a different context path
>
> I think this is one that's too relevant to just remove.

Stephen pointed out in private chat that just setting the context path for Jenkins to match whatever the reverse proxy serves is easier, and is of course completely correct.

With the note about that in place, we can remove all the complicated and error prone rewrite configurations.