On Wed, Jan 11, 2017 at 1:02 PM, Willy Tarreau <[email protected]> wrote: > Yes that's indeed the place. The reason for this behaviour is that > (normally) when the client gets a redirect to another host or scheme, > it will no longer use the current connection and will have to close > it. The typical use case is when redirecting from HTTP to HTTPS, you > definitely don't want to keep the connection active on port 80 since > it will not be used anymore.
I guessed this was the main reason, and in general I think it is the right behaviour, especially if this redirection is done only once when the browser first contacts the server, and assuming that the resources in the underlying site don't need to be redirected also. However (see below)... > But maybe your use case is different and that's something we should > revisit or make a bit more configurable ? However, in my particular use-case we are migrating quite a handful of sites to be routed through HAProxy (around 100-200 different sites, each with its own domain and aliases). At the same time trying to apply a policy of non-www prefixed domains (previously there wasn't much consistency), redirecting aliases to the "canonical" domain, etc.; plus everything now should go over HTTPS. Thus quite a handful of redirects of the form `https://subdomain.domain.com`. Unfortunately a lot of these sites have hard-coded resources with the `www` alternative domain and HTTP-only. Therefore at least until we rewrite those (which given their low-value might be delayed forever), we'll end up with a lot of redirects (10-20 redirects first page view), and because the close behaviour of HAProxy, we end up with a lot of short-lived connections. (This is not so much a load issue, as it is a page load latency issue due to the TCP connection establishment overhead.) We have solved the HTTPS automatic upgrade by the browser by using the `Content-Security-Policy: upgrade-insecure-requests` response header, but nothing can be done for the non-`www` redirects. What would help me in this situation: * (best solution) a "knob" to disable the close behaviour; * (most likely solution) I'll patch and build HAProxy myself to remove that expression from that condition; * (workarounds) I described previously (an untested) solution involving a secondary front-end / backend to handle the redirects; alternatively I could write a small Go application that will issue the redirects, but this would add another "moving part" which might decrease the reliability; Thanks, Ciprian.
