Re: HTTP redirects while still allowing keep-alive

[Willy Tarreau]

On Fri, Jan 27, 2017 at 08:31:01PM +0200, Ciprian Dorin Craciun wrote:
> No patch yet :) but I just wanted to confirm that this small change
> seems to work just fine in production for the last two weeks.
> (Granted I didn't make a thorough analysis of the traffic, but so far
> no one complained, and the traffic isn't quite small.)
> 
> Perhaps later this week or next week I'll be back with a patch.

OK I finally made the patch and committed it now. I'll backport it
to 1.7.3.

Thanks Ciprian!
Willy

Re: HTTP redirects while still allowing keep-alive

[Ciprian Dorin Craciun]

On Wed, Jan 11, 2017 at 8:59 PM, Willy Tarreau  wrote:
>> [I can't speak with much confidence as this is the first time I see
>> the HAProxy code, but...]
>>
>>
>> >From what I see the main culprit for the connection close is the code:
>>
>>  [starting with line 4225 in `proto_http.c`] 
>> if (*location == '/' &&
>> (req->flags & HTTP_MSGF_XFER_LEN) &&
>> ((!(req->flags & HTTP_MSGF_TE_CHNK) && !req->body_len) ||
>> (req->msg_state == HTTP_MSG_DONE)) &&
>> ((txn->flags & TX_CON_WANT_MSK) == TX_CON_WANT_SCL ||
>>  (txn->flags & TX_CON_WANT_MSK) == TX_CON_WANT_KAL)) {
>> /* keep-alive possible */
>> 
>>
>>
>> Which might be rewrites just as:
>>
>>  [starting with line 4225 in `proto_http.c`] 
>> if (
>>(req->flags & HTTP_MSGF_XFER_LEN) &&
>> ((!(req->flags & HTTP_MSGF_TE_CHNK) && !req->body_len) ||
>> (req->msg_state == HTTP_MSG_DONE)) &&
>> ((txn->flags & TX_CON_WANT_MSK) == TX_CON_WANT_SCL ||
>>  (txn->flags & TX_CON_WANT_MSK) == TX_CON_WANT_KAL)) {
>> /* keep-alive possible */
>> 
>>
>>
>> I.e., just remove `*location == '/' &&`, and I assume not much will be
>> impacted, thus I guess no regressions should stem from this
>> correction.
>
> Absolutely. Feel free to provide a patch doing this (please check
> CONTRIBUTING for the format, the commit message and the subject line),
> tag it BUG/MINOR and I'll merge it.


No patch yet :) but I just wanted to confirm that this small change
seems to work just fine in production for the last two weeks.
(Granted I didn't make a thorough analysis of the traffic, but so far
no one complained, and the traffic isn't quite small.)

Perhaps later this week or next week I'll be back with a patch.

Ciprian.

Re: HTTP redirects while still allowing keep-alive

[Willy Tarreau]

On Wed, Jan 11, 2017 at 08:53:18PM +0200, Ciprian Dorin Craciun wrote:
> On Wed, Jan 11, 2017 at 8:27 PM, Lukas Tribus  wrote:
> > But if we do remove those conditions, I guess we break a number of "old
> > assumptions"
> > and we will hit new code paths, so there is a potential for bugs :)
> 
> 
> [I can't speak with much confidence as this is the first time I see
> the HAProxy code, but...]
> 
> 
> >From what I see the main culprit for the connection close is the code:
> 
>  [starting with line 4225 in `proto_http.c`] 
> if (*location == '/' &&
> (req->flags & HTTP_MSGF_XFER_LEN) &&
> ((!(req->flags & HTTP_MSGF_TE_CHNK) && !req->body_len) ||
> (req->msg_state == HTTP_MSG_DONE)) &&
> ((txn->flags & TX_CON_WANT_MSK) == TX_CON_WANT_SCL ||
>  (txn->flags & TX_CON_WANT_MSK) == TX_CON_WANT_KAL)) {
> /* keep-alive possible */
> 
> 
> 
> Which might be rewrites just as:
> 
>  [starting with line 4225 in `proto_http.c`] 
> if (
>(req->flags & HTTP_MSGF_XFER_LEN) &&
> ((!(req->flags & HTTP_MSGF_TE_CHNK) && !req->body_len) ||
> (req->msg_state == HTTP_MSG_DONE)) &&
> ((txn->flags & TX_CON_WANT_MSK) == TX_CON_WANT_SCL ||
>  (txn->flags & TX_CON_WANT_MSK) == TX_CON_WANT_KAL)) {
> /* keep-alive possible */
> 
> 
> 
> I.e., just remove `*location == '/' &&`, and I assume not much will be
> impacted, thus I guess no regressions should stem from this
> correction.

Absolutely. Feel free to provide a patch doing this (please check
CONTRIBUTING for the format, the commit message and the subject line),
tag it BUG/MINOR and I'll merge it.

Thanks Ciprian!
Willy

Re: HTTP redirects while still allowing keep-alive

[Willy Tarreau]

On Wed, Jan 11, 2017 at 07:27:08PM +0100, Lukas Tribus wrote:
> Hello,
> 
> 
> Am 11.01.2017 um 14:44 schrieb Willy Tarreau:
> > On Wed, Jan 11, 2017 at 01:41:27PM +0200, Ciprian Dorin Craciun wrote:
> > > 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.)
> > I didn't think about that case, it definitely makes sense. In fact I
> > mostly focused on first redirection without thinking about systematic
> > redirection caused by a migration (for example). Now I'm starting to
> > think that we should never close by default and that we should change
> > this behaviour as it's counter-intuitive.
> > 
> > I don't know what others think.
> 
> I agree; in a full keep-alive world, we should not try to close "by
> default", but let
> the actual keep-alive code do its job.
> 
> But if we do remove those conditions, I guess we break a number of "old
> assumptions"
> and we will hit new code paths, so there is a potential for bugs :)

No there are really no assumptions regarding this one, the way it's
done is already a hack. In fact it made quite some sense before 1.6
because keeping 2 buffers allocated for an idle connection was
expensive. Since 1.6, the request and response buffers are released
so we don't use much memory and the idle connection is cheap.

In my opinion it's a bit late to change 1.6 now but I'm even fine for
tagging this as a minor bug (in that it's an inheritage from the past)
and backporting it to 1.7.

Thanks!
Willy

Re: HTTP redirects while still allowing keep-alive

[Ciprian Dorin Craciun]

On Wed, Jan 11, 2017 at 8:27 PM, Lukas Tribus  wrote:
> But if we do remove those conditions, I guess we break a number of "old
> assumptions"
> and we will hit new code paths, so there is a potential for bugs :)


[I can't speak with much confidence as this is the first time I see
the HAProxy code, but...]


>From what I see the main culprit for the connection close is the code:
X-Bogosity: Ham, tests=bogofilter, spamicity=0.00, version=1.2.4

 [starting with line 4225 in `proto_http.c`] 
if (*location == '/' &&
(req->flags & HTTP_MSGF_XFER_LEN) &&
((!(req->flags & HTTP_MSGF_TE_CHNK) && !req->body_len) ||
(req->msg_state == HTTP_MSG_DONE)) &&
((txn->flags & TX_CON_WANT_MSK) == TX_CON_WANT_SCL ||
 (txn->flags & TX_CON_WANT_MSK) == TX_CON_WANT_KAL)) {
/* keep-alive possible */



Which might be rewrites just as:

 [starting with line 4225 in `proto_http.c`] 
if (
   (req->flags & HTTP_MSGF_XFER_LEN) &&
((!(req->flags & HTTP_MSGF_TE_CHNK) && !req->body_len) ||
(req->msg_state == HTTP_MSG_DONE)) &&
((txn->flags & TX_CON_WANT_MSK) == TX_CON_WANT_SCL ||
 (txn->flags & TX_CON_WANT_MSK) == TX_CON_WANT_KAL)) {
/* keep-alive possible */



I.e., just remove `*location == '/' &&`, and I assume not much will be
impacted, thus I guess no regressions should stem from this
correction.

Ciprian.

Re: HTTP redirects while still allowing keep-alive

[Lukas Tribus]

Hello,


Am 11.01.2017 um 14:44 schrieb Willy Tarreau:

On Wed, Jan 11, 2017 at 01:41:27PM +0200, Ciprian Dorin Craciun wrote:

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.)

I didn't think about that case, it definitely makes sense. In fact I
mostly focused on first redirection without thinking about systematic
redirection caused by a migration (for example). Now I'm starting to
think that we should never close by default and that we should change
this behaviour as it's counter-intuitive.

I don't know what others think.


I agree; in a full keep-alive world, we should not try to close "by 
default", but let

the actual keep-alive code do its job.

But if we do remove those conditions, I guess we break a number of "old 
assumptions"

and we will hit new code paths, so there is a potential for bugs :)


Lukas

Re: HTTP redirects while still allowing keep-alive

[Willy Tarreau]

On Wed, Jan 11, 2017 at 01:41:27PM +0200, Ciprian Dorin Craciun wrote:
> 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.)

I didn't think about that case, it definitely makes sense. In fact I
mostly focused on first redirection without thinking about systematic
redirection caused by a migration (for example). Now I'm starting to
think that we should never close by default and that we should change
this behaviour as it's counter-intuitive.

I don't know what others think.

Willy

Re: HTTP redirects while still allowing keep-alive

[Ciprian Dorin Craciun]

On Wed, Jan 11, 2017 at 1:07 PM, Willy Tarreau  wrote:
> This one is obsolete, the format of the Location header field is
> described here :
>
>https://tools.ietf.org/html/rfc7231#page-68
>
> and it uses this format :
>
>https://tools.ietf.org/html/rfc3986#section-4.2
>
> As you can see, "//" authority path, path-absolute etc... are permitted.
>
> However while I understand it could solve your issue, I think it's an
> ugly trick in that you use it only to work around an undesirable haproxy
> behaviour. We'd rather ensure haproxy doesn't behave this way if not
> needed. Of course it could be a short-term workaround saving your from
> modifying the code.


Quick reply:  this would work only if we assume that we want to keep
the traffic on the same "transport", namely TLS or non-TLS.  But these
days, when TLS is starting to become widely deployed, I assume most
redirects are on the form of `https://canonical-domain.com`.

Ciprian.

Re: HTTP redirects while still allowing keep-alive

[Ciprian Dorin Craciun]

On Wed, Jan 11, 2017 at 1:02 PM, Willy Tarreau  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.

Re: HTTP redirects while still allowing keep-alive

[Willy Tarreau]

On Wed, Jan 11, 2017 at 12:05:43AM +0200, Ciprian Dorin Craciun wrote:
> On Tue, Jan 10, 2017 at 11:00 PM, Bryan Talbot
>  wrote:
> > Whatever the reason for forcing the connection closed -- it only closes 
> > when the scheme changes. Redirecting to a different host or port when using 
> > a ???scheme less??? URI allows the connection to be kept open.
> >
> >
> > listen http
> > bind :8000
> > http-request redirect location //127.0.0.2:8001/redir
> >
> >
> [...]
> >
> >
> > Maybe that will be useful to Ciprian to make the redirect to a new hostname 
> > but keep the connection to the old host open if that???s what is needed.
> 
> 
> 
> Thanks for the suggestion, however there are two issues with this proposal:
> 
> 
> (A)  I'm not sure how would browsers in general behave when faced with
> a schema-less URL in the `Location` header.
> 
> A quick survey of the internet (i.e. the top search on Google points
> to a StackOverflow question) suggests that browsers would handle these
> "protocol-relative" URL's just fine when loading assets;  however the
> HTTP standard seems to mandate "absolute" URL's with regard of the
> `Location` header:
> 
>   https://tools.ietf.org/html/rfc2616#section-14.30

This one is obsolete, the format of the Location header field is
described here :

   https://tools.ietf.org/html/rfc7231#page-68

and it uses this format :

   https://tools.ietf.org/html/rfc3986#section-4.2

As you can see, "//" authority path, path-absolute etc... are permitted.

However while I understand it could solve your issue, I think it's an
ugly trick in that you use it only to work around an undesirable haproxy
behaviour. We'd rather ensure haproxy doesn't behave this way if not
needed. Of course it could be a short-term workaround saving your from
modifying the code.

Willy

Re: HTTP redirects while still allowing keep-alive

[Willy Tarreau]

Hi Ciprian,

On Wed, Jan 11, 2017 at 12:58:57AM +0200, Ciprian Dorin Craciun wrote:
> On Tue, Jan 10, 2017 at 9:36 AM, Cyril Bonté  wrote:
> > This is because haproxy behaves differently depending on the the Location
> > URL :
> > - beginning with /, it will allow HTTP keep-alived connections (Location:
> > /redir/foo)
> > - otherwise it unconditionnally won't, and there's no option to change this
> > (Location: http://mysite/redir)
> 
> 
> 
> 
> Quickly looking through the latest HAProxy code on the 1.7 branch, I
> think I found the piece of code which is responsible for closing the
> connections on redirects that do not start with `/`:
> 
> 
>  [starting with line 4225] 
> if (*location == '/' &&
> (req->flags & HTTP_MSGF_XFER_LEN) &&
> ((!(req->flags & HTTP_MSGF_TE_CHNK) && !req->body_len) ||
> (req->msg_state == HTTP_MSG_DONE)) &&
> ((txn->flags & TX_CON_WANT_MSK) == TX_CON_WANT_SCL ||
>  (txn->flags & TX_CON_WANT_MSK) == TX_CON_WANT_KAL)) {
> /* keep-alive possible */
> 
> 
> 
> (This also explains why protocol-relative URL's (i.e.
> `//some-domain.com/...`) work.)
> 
> Thus if I were to patch my HAProxy build to eliminate the just the
> `*location == '/'` expression, I would obtain keep-alive regardless of
> where I redirect the browser.
> 
> Could someone more experienced in the HAProxy source code advise if
> this is the only place I should give a look?

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.

But maybe your use case is different and that's something we should
revisit or make a bit more configurable ?

Willy

Re: HTTP redirects while still allowing keep-alive

[Ciprian Dorin Craciun]

On Tue, Jan 10, 2017 at 9:36 AM, Cyril Bonté  wrote:
> This is because haproxy behaves differently depending on the the Location
> URL :
> - beginning with /, it will allow HTTP keep-alived connections (Location:
> /redir/foo)
> - otherwise it unconditionnally won't, and there's no option to change this
> (Location: http://mysite/redir)




Quickly looking through the latest HAProxy code on the 1.7 branch, I
think I found the piece of code which is responsible for closing the
connections on redirects that do not start with `/`:


 [starting with line 4225] 
if (*location == '/' &&
(req->flags & HTTP_MSGF_XFER_LEN) &&
((!(req->flags & HTTP_MSGF_TE_CHNK) && !req->body_len) ||
(req->msg_state == HTTP_MSG_DONE)) &&
((txn->flags & TX_CON_WANT_MSK) == TX_CON_WANT_SCL ||
 (txn->flags & TX_CON_WANT_MSK) == TX_CON_WANT_KAL)) {
/* keep-alive possible */



(This also explains why protocol-relative URL's (i.e.
`//some-domain.com/...`) work.)

Thus if I were to patch my HAProxy build to eliminate the just the
`*location == '/'` expression, I would obtain keep-alive regardless of
where I redirect the browser.




Could someone more experienced in the HAProxy source code advise if
this is the only place I should give a look?

Thanks,
Ciprian.

Re: HTTP redirects while still allowing keep-alive

[Ciprian Dorin Craciun]

On Tue, Jan 10, 2017 at 11:00 PM, Bryan Talbot
 wrote:
> Whatever the reason for forcing the connection closed -- it only closes when 
> the scheme changes. Redirecting to a different host or port when using a 
> “scheme less” URI allows the connection to be kept open.
>
>
> listen http
> bind :8000
> http-request redirect location //127.0.0.2:8001/redir
>
>
[...]
>
>
> Maybe that will be useful to Ciprian to make the redirect to a new hostname 
> but keep the connection to the old host open if that’s what is needed.



Thanks for the suggestion, however there are two issues with this proposal:


(A)  I'm not sure how would browsers in general behave when faced with
a schema-less URL in the `Location` header.

A quick survey of the internet (i.e. the top search on Google points
to a StackOverflow question) suggests that browsers would handle these
"protocol-relative" URL's just fine when loading assets;  however the
HTTP standard seems to mandate "absolute" URL's with regard of the
`Location` header:

  https://tools.ietf.org/html/rfc2616#section-14.30


(B)  Moreover in my particular case it still doesn't fully solve the
issue, mainly because the organization I'm working for is migrating
quite a handful of sites and is applying two major changes:  moving to
TLS (via LetsEncrypt issued certificates) and making sure all sites
follow the policy of `www`-less prefix.  Thus the majority of our
redirects are of the form `https://subdomain.domain.com`.


Thanks,
Ciprian.

Re: HTTP redirects while still allowing keep-alive

[Bryan Talbot]

> On Jan 10, 2017, at Jan 10, 12:28 AM, Ciprian Dorin Craciun 
>  wrote:
> 
> On Tue, Jan 10, 2017 at 9:36 AM, Cyril Bonté  wrote:
>> This is because haproxy behaves differently depending on the the Location
>> URL :
>> - beginning with /, it will allow HTTP keep-alived connections (Location:
>> /redir/foo)
>> - otherwise it unconditionnally won't, and there's no option to change this
>> (Location: http://mysite/redir)
> 
> 


Whatever the reason for forcing the connection closed -- it only closes when 
the scheme changes. Redirecting to a different host or port when using a 
“scheme less” URI allows the connection to be kept open.


listen http
bind :8000
http-request redirect location //127.0.0.2:8001/redir




$> curl -L -v 127.0.0.1:8000/foo
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 8000 (#0)
> GET /foo HTTP/1.1
> Host: 127.0.0.1:8000
> User-Agent: curl/7.52.1
> Accept: */*
>
< HTTP/1.1 302 Found
< Cache-Control: no-cache
< Content-length: 0
< Location: //127.0.0.2:8001/redir
<
* Curl_http_done: called premature == 0
* Connection #0 to host 127.0.0.1 left intact
* Issue another request to this URL: 'http://127.0.0.2:8001/redir'
*   Trying 127.0.0.2…


Maybe that will be useful to Ciprian to make the redirect to a new hostname but 
keep the connection to the old host open if that’s what is needed.

-Bryan

Re: HTTP redirects while still allowing keep-alive

[Ciprian Dorin Craciun]

On Tue, Jan 10, 2017 at 9:36 AM, Cyril Bonté  wrote:
> This is because haproxy behaves differently depending on the the Location
> URL :
> - beginning with /, it will allow HTTP keep-alived connections (Location:
> /redir/foo)
> - otherwise it unconditionnally won't, and there's no option to change this
> (Location: http://mysite/redir)


First of all, sorry for providing an incomplete email by not
specifying the HAProxy version (which is 1.6.10), and a configuration
example.

Also thanks Cyril for pointing out to this behaviour, as in fact this
is exactly my use-case, redirecting a `www` site to its prefix-less
name.  (And perhaps towards `HTTPS`, but this could be solved by
specifying the `Content-Security-Policy:  ugrade-insecure-requests`.)
(Also my redirects are 307, i.e. temporary and instructing the browser
to use the same HTTP method.)


Might I ask why this behaviour?

I assume that it was presumed that these redirects will happen only
once for a particular client, and keeping alive that connection would
be useless, as the client would initiate a different one, given that
the host in the URL changed.




Perhaps can someone point me to the piece of code responsible for this
behaviour?  (I could write a patch and apply it only to my particular
deployment.)


However, might the following trick solve the problem:

* I create a frontend dedicated to make the redirects;
* I create a backend which uses as server the previously defined
frontend, and specifies the `http-server-close` behaviour;
* in the "main" frontend (where the redirects used to be) I just
forward (via `use-server`) the requests needed to be redirected to the
newly introduced backend;

Would this solve the connection closing on redirects?

(I'll have to test this sometime these days, and report back.)


Thanks,
Ciprian.

Re: HTTP redirects while still allowing keep-alive

[Cyril Bonté]

Hi all,

Le 10/01/2017 à 01:28, Bryan Talbot a écrit :



On Jan 8, 2017, at Jan 8, 2:03 PM, Ciprian Dorin Craciun 
 wrote:

Quick question:  how can I configure HAProxy to redirect (via
`http-request redirect ...`) without HAProxy sending the `Connection:
close` header, thus still allowing keep-alive on this connection.


I do not see the behavior you describe, but I also do no know what haproxy 
version you might be using or what your config might be like.

haproxy version 1.7.1 with a proxy config like that shown below does not close 
the connection and contains no “connection: close” header for me.

listen http
bind :8000
http-request redirect prefix /redir



$> curl -v http://127.0.0.1:8000/foo
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 8000 (#0)

GET /foo HTTP/1.1
Host: 127.0.0.1:8000
User-Agent: curl/7.52.1
Accept: */*


< HTTP/1.1 302 Found
< Cache-Control: no-cache
< Content-length: 0
< Location: /redir/foo
<
* Curl_http_done: called premature == 0
* Connection #0 to host 127.0.0.1 left intact


This is because haproxy behaves differently depending on the the 
Location URL :
- beginning with /, it will allow HTTP keep-alived connections 
(Location: /redir/foo)
- otherwise it unconditionnally won't, and there's no option to change 
this (Location: http://mysite/redir)




My use-case is the following:  I have a stubborn server that insists
on pointing to the "wrong" resource URL's, thus on a page load, I get
a storm of redirects, each with a different connection (due to the
`Connection: close` reply header).


I tried to skim the documentation and search the internet (and the
mailing list archives), but no such topic popped-up, thus I have the
feeling this is quite impossible as of now...

Thanks,
Ciprian.







--
Cyril Bonté

Re: HTTP redirects while still allowing keep-alive

[Bryan Talbot]

> On Jan 8, 2017, at Jan 8, 2:03 PM, Ciprian Dorin Craciun 
>  wrote:
> 
> Quick question:  how can I configure HAProxy to redirect (via
> `http-request redirect ...`) without HAProxy sending the `Connection:
> close` header, thus still allowing keep-alive on this connection.

I do not see the behavior you describe, but I also do no know what haproxy 
version you might be using or what your config might be like.

haproxy version 1.7.1 with a proxy config like that shown below does not close 
the connection and contains no “connection: close” header for me.

listen http
bind :8000
http-request redirect prefix /redir



$> curl -v http://127.0.0.1:8000/foo
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 8000 (#0)
> GET /foo HTTP/1.1
> Host: 127.0.0.1:8000
> User-Agent: curl/7.52.1
> Accept: */*
>
< HTTP/1.1 302 Found
< Cache-Control: no-cache
< Content-length: 0
< Location: /redir/foo
<
* Curl_http_done: called premature == 0
* Connection #0 to host 127.0.0.1 left intact


-Bryan



> 
> My use-case is the following:  I have a stubborn server that insists
> on pointing to the "wrong" resource URL's, thus on a page load, I get
> a storm of redirects, each with a different connection (due to the
> `Connection: close` reply header).
> 
> 
> I tried to skim the documentation and search the internet (and the
> mailing list archives), but no such topic popped-up, thus I have the
> feeling this is quite impossible as of now...
> 
> Thanks,
> Ciprian.
> 

HTTP redirects while still allowing keep-alive

[Ciprian Dorin Craciun]

Quick question:  how can I configure HAProxy to redirect (via
`http-request redirect ...`) without HAProxy sending the `Connection:
close` header, thus still allowing keep-alive on this connection.

My use-case is the following:  I have a stubborn server that insists
on pointing to the "wrong" resource URL's, thus on a page load, I get
a storm of redirects, each with a different connection (due to the
`Connection: close` reply header).


I tried to skim the documentation and search the internet (and the
mailing list archives), but no such topic popped-up, thus I have the
feeling this is quite impossible as of now...

Thanks,
Ciprian.