On Wed, May 28, 2014 at 3:57 PM, Souda Burger <soudabur...@gmail.com> wrote:
> Baptiste,
>
> Thanks for the heads up. Just to make sure I understand, you're saying that
> my "balanced" application server, in this case a tomcat pair, needs to
> account for the header modification and it does not appear that it is
> currently doing that? If so, thanks for your help, I can take that to my
> developers!
>
>
> On Wed, May 28, 2014 at 8:45 AM, Baptiste <bed...@gmail.com> wrote:
>>
>> On Wed, May 28, 2014 at 3:00 PM, Souda Burger <soudabur...@gmail.com>
>> wrote:
>> > I have an haproxy server set up with a compiled 1.5-dev25 version of
>> > HaProxy. I am needing SSL and since SSL isn't available in 1.4, I
>> > compiled
>> > 1.5. I have everything working, but I noticed something peculiar and
>> > wasn't
>> > sure if this was expected behavior or not. Below is my SSL haproxy.cfg
>> > file
>> > along with the wget that I performed against my websserver. It appears
>> > to
>> > initially redirect HTTPS to HTTP which then rewrites the connection back
>> > to
>> > HTTPS. Again, is this expected behavior or is something in my config
>> > incorrect? Thanks!
>> >
>> > global
>> > daemon
>> > log 127.0.0.1 local2
>> > maxconn 4096
>> > user haproxy
>> > group haproxy
>> > chroot /var/chroot/haproxy
>> >
>> > defaults
>> > log global
>> > mode http
>> > retries 3
>> > option httplog
>> > option dontlognull
>> > option redispatch
>> > timeout server 50000
>> > timeout client 50000
>> > timeout connect 5000
>> >
>> > frontend http_in
>> >
>> > bind *:80
>> > default_backend portalbackend
>> >
>> > frontend https_in
>> > reqadd X-Forwarded-Proto:\ https
>> > bind *:443 ssl crt /etc/haproxy/haproxy.crt
>> > default_backend portalbackend
>> >
>> > backend portalbackend
>> > balance leastconn
>> > redirect scheme https if !{ ssl_fc }
>> > option httpchk GET /login.jsp
>> > option forwardfor
>> > option http-server-close
>> > server node1 <ip1>:8080 check inter 5000
>> > server node2 <ip2>:8080 check inter 5000
>> >
>> >
>> >
>> > 07:53:18 ~$ wget https://haproxy --no-check-certificate
>> > --2014-05-28 07:59:55-- https://haproxy/
>> > Resolving haproxy... 192.168.8.213
>> > Connecting to haproxy|192.168.8.213|:443... connected.
>> > WARNING: cannot verify haproxy's certificate, issued by
>> > '/CN=www.exceliance.fr':
>> > Self-signed certificate encountered.
>> > WARNING: certificate common name 'www.exceliance.fr' doesn't match
>> > requested host name 'haproxy'.
>> > HTTP request sent, awaiting response... 302 Found
>> > Location: http://haproxy/login.jsp [following]
>> > --2014-05-28 07:59:55-- http://haproxy/login.jsp
>> > Connecting to haproxy|192.168.8.213|:80... connected.
>> > HTTP request sent, awaiting response... 302 Found
>> > Location: https://haproxy/login.jsp [following]
>> > --2014-05-28 07:59:55-- https://haproxy/login.jsp
>> > Reusing existing connection to haproxy:443.
>> > HTTP request sent, awaiting response... 200 OK
>> > Length: 7327 (7.2K) [text/html]
>> > Saving to: 'index.html.1'
>> >
>> >
>> > 100%[=====================================================================================================================>]
>> > 7,327 --.-K/s in 0s
>> >
>> > 2014-05-28 07:59:55 (81.3 MB/s) - 'index.html.1' saved [7327/7327]
>> >
>>
>>
>> Hi Souda,
>>
>> The first 302 seems to be sent by your application server which does
>> not seems to take into account you "X-Forwarded-Proto" header.
>>
>> Baptiste
>
>
Yes, this is what I meant.
Your application should read this header and write the redirect in consequence.
The first 302 response should be "https://haproxy/login.jsp";.
Or you could use HAProxy to rewrite it on the fly, but it's a dirty workaround.
Baptiste
