Le 01/02/2018 à 20:44, Martin Goldstone a écrit :
Yes, the exact same configuration file, no caching or threads. We've not
tried HTTP/2 just yet, I'll have a look at this when I'm in the office
tomorrow.
Hi,
As Willy said, this is probably a breakage in the way we handle the end
of the stre
On Thu, Feb 01, 2018 at 11:58:59PM +0100, Lukas Tribus wrote:
> Remove the old suggestion to use http-server-close mode, from the
> beginnings of keep-alive mode in commit 16bfb021 "MINOR: config: add
> option http-keep-alive").
>
> We made http-keep-alive default in com
Remove the old suggestion to use http-server-close mode, from the
beginnings of keep-alive mode in commit 16bfb021 "MINOR: config: add
option http-keep-alive").
We made http-keep-alive default in commit 70dffdaa "MAJOR: http:
switch to keep-alive mode by default".
---
doc/c
On Thu, Feb 01, 2018 at 07:44:57PM +, Martin Goldstone wrote:
> Yes, the exact same configuration file, no caching or threads. We've not
> tried HTTP/2 just yet, I'll have a look at this when I'm in the office
> tomorrow.
No rush, I'll still be burried in a meeting for the last day in the week
bus wrote:
> Hello Martin,
>
> On 1 February 2018 at 17:18, Martin Goldstone
wrote:
> > Hi,
> >
> > We've been using haproxy in docker for quite some time to provide
reverse
> > proxy facilities for many and varied application servers. Typically,
we've
>
acilities for many and varied application servers. Typically, we've
> > always used option http-server-close in the config, except for rare
> > occasions where we might need http-keep-alive (eg ntlm authentication). We
> > also have the following in our front end configs:
>
Hello Martin,
On 1 February 2018 at 17:18, Martin Goldstone wrote:
> Hi,
>
> We've been using haproxy in docker for quite some time to provide reverse
> proxy facilities for many and varied application servers. Typically, we've
> always used option http-server-close
Hi,
We've been using haproxy in docker for quite some time to provide reverse
proxy facilities for many and varied application servers. Typically, we've
always used option http-server-close in the config, except for rare
occasions where we might need http-keep-alive (eg ntlm authentic
>
> *If* you would use an ancient release (<= 1.5-dev21) that defaults
> http-tunnel, http-server-close would indeed be needed, and it would
> be missing in the photo_upload_backend backend.
>
> But since thats not the case, I would suggest you remove
> http-server-close comp
>> Below is my haproxy.cfg:
*If* you would use an ancient release (<= 1.5-dev21) that defaults
http-tunnel, http-server-close would indeed be needed, and it would
be missing in the photo_upload_backend backend.
But since thats not the case, I would suggest you remove
http-server-close co
Right, sorry.
I compiled 1.6.3 from source with the options: TARGET=custom USE_PCRE=1
USE_LINUX_SPLICE=1 USE_LINUX_TPROXY=1 USE_OPENSSL=yes
Gustavo
On 28 January 2016 at 16:47, Lukas Tribus wrote:
> Hi Gustavo,
>
>
> > Below is my haproxy.cfg:
>
> We will need to know the exact release you are
Hi Gustavo,
> Below is my haproxy.cfg:
We will need to know the exact release you are using, because they
have different defaults.
Regards,
Lukas
pload
backend lighttpd_backend
option http-server-close
server lighttpd_server 127.0.0.1:8081 maxconn 2048 check
backend websocket_backend
timeout queue 5000
timeout server 8640
timeout connect 8640
server websocket_server 127.0.0.1:8080 maxconn
/6dBysTBCgOU440s
* Backend pcap: https://cloud.openmailbox.org/index.php/s/Q7fpSzcwzhv1diA
Regards,
Brendan Hubble
From: Lukas Tribus
Sent: Thursday, 18 June 2015 3:12AM
To: Brendan Hubble, Haproxy
Subject: RE: http-server-close when a request timeouts after a success HAProxy
does not send 504
Hi Brendan,
> Hi I am having an issue with HAProxy in http-server-close mode, when more
> then one request is sent in a stream and one timeouts after a success it
> re-sends that request. On the second request HAProxy send the 504 and the
> request is not resent again.
I'm sorr
Hi I am having an issue with HAProxy in http-server-close mode, when more
then one request is sent in a stream and one timeouts after a success it
re-sends that request. On the second request HAProxy send the 504 and the
request is not resent again.
Is this intended behaviour or am missing a
Hi Andrey,
> # acl CX(custcare_cu)
> acl is_custcare_cu url_beg /custcare_cu
> # VIX-s
> default_backend vix
>
>
>
> backend custcare_cu
> balance roundrobin
> cookie SERVERID insert indirect nocache maxlife 24h maxidle 8h
> server s1cm1_cx_cu s1cm1:8088 check port 8088 cookie cx_cu3 weight 100
>
Hi Andrey,
> Hi! I use options "option http-server-close" for my haproxy. And I
> faced with next problems: After logging on my site (ISSA), customers
> execute different steps and their logout on the start page for enter
> log/pass.
Are you saying that persistence doesn&
Hi! I use options "option http-server-close" for my haproxy. And I faced with
next problems: After logging on my site (ISSA), customers execute different
steps and their logout on the start page for enter log/pass. After turn off
options option http-server-close problems disappe
On Thu, Feb 20, 2014 at 12:13:15AM +0100, Cyril Bonté wrote:
> Add a missing "r" on "option http-server-close" and put double-quotes
> everywhere to ease keywords parsing.
Applied, thank you Cyril.
Willy
Add a missing "r" on "option http-server-close" and put double-quotes
everywhere to ease keywords parsing.
---
doc/configuration.txt | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/doc/configuration.txt b/doc/configuration.txt
in
27;s been great.
> >
> > We are using it in front of a series of Apache web servers using mod_php.
> > I've seen some notes around that indicate you can (or should) disable
> > KeepAlive on your Apache servers and use option http-server-close to do
> > client
notes around that indicate you can (or should) disable
> KeepAlive on your Apache servers and use option http-server-close to do
> client side keepalive using HAproxy, which seems like a good idea in our
> case.
>
> What I'm wondering is, what is the case for using http-server-c
ion http-server-close to do
client side keepalive using HAproxy, which seems like a good idea in our
case.
What I'm wondering is, what is the case for using http-server-close in a
frontend vs. backend, or both? I have some other front and backends that I
specifically don't want keepalive,
On Thu, Oct 18, 2012 at 04:42:58PM +0900, seri0...@naver.com wrote:
> This is our configuration!!
OK thanks, nothing unusual here, I'm often running similar configs.
Do you think the issue affects all connections or just some of them ?
Would it be possible for you to take a tcpdump capture of a
/https.socks uid 0 level admin
tune.maxpollevents 400
spread-checks 5
defaults
log global
option http-server-close
option dontlognull
option log-health-checks
option log-separate-errors
option redispatch
option contstats
option tcp-smart-accept
option tcp
Hi,
On Thu, Oct 18, 2012 at 04:11:57PM +0900, seri0...@naver.com wrote:
> Hi!!
>
> I'm using haproxy 1.4 in our production environment very well!
>
>
> Recently, I've been testing haproxy 1.5(dev11, dev12)
> I've found different operation in http-server
Hi!!
I'm using haproxy 1.4 in our production environment very well!
Recently, I've been testing haproxy 1.5(dev11, dev12)
I've found different operation in http-server-close option between 1.4 and 1.5.
In 1.4,
TCP TIMEWAIT state isn't increased in server-side!!
(haproxy se
Hi Jinge,
On Mon, Jul 23, 2012 at 11:17:42AM +0800, jinge wrote:
> Hi list.
> Sorry for my poor English.
> i use haproxy nowadays.But i just don't now thats the difference between
> http-server-close in frontend or in backends.Can someone help me?
They're similar. You ne
Hi list.
Sorry for my poor English.
i use haproxy nowadays.But i just don't now thats the difference between
http-server-close in frontend or in backends.Can someone help me?
Hi Willy,
On 31-03-2012 23:18, Willy Tarreau wrote:
Hi Aleks,
On Sat, Mar 31, 2012 at 10:33:26PM +0200, Aleksandar Lazic wrote:
[snipp]
Is there a flag or option in the haproxy custom log format
http://haproxy.1wt.eu/git?p=haproxy.git;a=blob;f=doc/configuration.txt;h=2ede20860576f17e2ee91
Hi Aleks,
On Sat, Mar 31, 2012 at 10:33:26PM +0200, Aleksandar Lazic wrote:
> Hi,
>
> I thought that
>
> no option http-server-close
>
> activate the server keep-alive handling but I get
It only disables this option, but maybe you were having
option httpclose somewhere el
Hi,
I thought that
no option http-server-close
activate the server keep-alive handling but I get
...
2012/03/31 22:04:41 [debug] 32644#0: *94159 http header: "Connection:
close"
...
in my nginx log.
Is there a flag or option in the haproxy custom log format
http://haproxy.1w
On Wed, Mar 28, 2012 at 09:06:33AM -0500, Rusty Geldmacher wrote:
> Hi Willy,
>
> Thanks so much for your responses! We're using version 1.4.19. I'll work
> on getting a network capture for you -- what tcpdump params would help the
> most? I usually use "-vv -A -w ". Probably the most helpful thin
e we're
>>observing in
>> our setup. When we have "option http-server-close" set, then file
>>uploads via
>> multipart form data will not work. By "not work" I mean that the HTTP
>> content-length header will be reported as 0, which in turn cause
Hi Rusty,
On Mon, Mar 26, 2012 at 02:07:40PM -0500, Rusty Geldmacher wrote:
> Hi all,
>
> Was hoping someone could help shed some light on an issue we're observing in
> our setup. When we have "option http-server-close" set, then file uploads via
> multipart form da
Thanks Baptiste :)
---
posted at http://www.serverphorums.com
http://www.serverphorums.com/read.php?10,447778,447858#msg-447858
Hey,
httpclose disables HTTP keepalive on both the client and server sides
while http-server-close only disable keepalive on the server side.
The name comes from the Connection header which is set to Close.
cheers
On Fri, Feb 17, 2012 at 8:11 PM, wrote:
> Reading the v1.5 documentation, i
Reading the v1.5 documentation, i am confused as to when these 2 options should
be used and their difference
option http-server-close
http://code.google.com/p/haproxy-docs/wiki/http_server_close
vs
option httpclose
http://code.google.com/p/haproxy-docs/wiki/httpclose
??
---
posted at http
Hi Baptiste,
On Tue, Nov 22, 2011 at 10:10:17PM +0100, Baptiste wrote:
> Using http-server-close, HAProxy is able to take routing decision for
> the HTTP connection, so, objects can be downloaded from any server in
> a farm.
Sorry to be picky, but it will take a routing decision
Hi,
It will work as you said, if you have not enabled cookie persistence.
(cookie line in your backend conf).
by default, without http-server-close option, HAProxy will "tunnel"
requests and responses.
It will be able to analyze only the first request, taking rooting
decision, then all
Hi,
In my condition, I set the http-server-close option for client-side keepalive.
(You know this will save the time of establish connections)
My question is will haproxy re-assign backend server for every HTTP request in
this connection? I also configure 'balance uri' and
Hi,
In order to be able to process layer 7 manipulation (what you want to
achieve) for *each* request, then you must enable http mode on your
frontebd/backend and to enable the option http-server-close.
cheers
On Thu, Oct 27, 2011 at 12:21 AM, Vivek Malik wrote:
> The documentation also s
es, javascript, css and make ajax calls
> > over it.
>
> > From a haproxy request processing and manipulating perspective, Is
> > there a difference between http-server-close and httpclose? Would
> > reqadd/reqidel/use_backend work on subsequent requests during client
> &g
ake ajax calls
> over it.
> From a haproxy request processing and manipulating perspective, Is
> there a difference between http-server-close and httpclose? Would
> reqadd/reqidel/use_backend work on subsequent requests during client
> side keep alive too?
Yes. From the documentation:
ver-close and httpclose? Would
reqadd/reqidel/use_backend work on subsequent requests during client side
keep alive too?
I tried running some tests and I was able to reqadd/reqidel and use_backend
while using http-server-close, but I wanted to check with the group before
pushing the change to product
Hi Cyril,
On Tue, Sep 13, 2011 at 10:13:14PM +0200, Cyril Bonté wrote:
> More seriously, I've got a first version that looks to work quite well.
> I couldn't raise keep-alive connections but - 1, due to
> the way haproxy pauses the listener when they are full or when the proxy is.
I don't know
Hi Willy,
A small update on this development.
Le Lundi 29 Août 2011 18:01:23 Willy Tarreau a écrit :
> > > If you're interested in doing this, I'd be glad to merge it and to
> > > provide help if needed. We need a "struct list fe_idle" in the
> > > struct
> > > proxy and add/remove idle connectio
On Mon, Aug 29, 2011 at 04:39:27PM +0200, Cyril Bonté wrote:
> I really like the idea and it could be a great improvement for haproxy.
> The advantage of this solution is also that it doesn't add another keyword in
> the long list of possibilities haproxy offers.
Indeed, that's also another point
On Monday 29 August 2011 10:52:29 Willy Tarreau wrote:
> After this long reading, I must say I'm not fond of this at all for
> several reasons :
> - if a maxconn limit is too low to sustain keep-alive connections,
> it will be too low to support higher response times, so the maxconn
> mus
he possibility to limit the number of HTTP keep-alive
> connections to allow a better concurrency between clients.
>
> I propose to add a suboption to the "http-server-close" one to let haproxy
> fall back to a "httpclose" mode once a certain number of connection
ose to add a suboption to the "http-server-close" one to let haproxy
fall back to a "httpclose" mode once a certain number of connections on the
frontend is reached.
The value can be defined :
- as an absolute limit
Example :
maxconn 1000
option http-server-close limit
ponse and request headers?
yes.
> 3) How does this behave with "option http-server-close" ?
exactly the same.
The principle is that due to keep-alive, it is possible to have multiple
successive HTTP requests over a single TCP connection. Earlier versions
of haproxy would only check
When capturing headers from Logs, as I understand it you will get the header
for every request if "option httpclose" is set.
1) Is this correct?
2) Is this true for both captured response and request headers?
3) How does this behave with "option http-server-close" ?
Thank you,
Kyle
Hello!
We are using haproxy version 1.4.
We are trying to setup HTTP mode backend with support of HTTP keep-alive
between clients and haproxy.
For that reason we add "option http-server-close" in backend configuration.
But we also want to pass real client IP address in X-Forwarded-For h
Hi Kyle,
On Sun, Mar 20, 2011 at 10:30:39AM -0400, Kyle Brandt wrote:
> Hi all,
>
> With round robin load balancing and the http-server-close option, do
> connections that were part of the same keep alive session on the client side
> all hit the same web server, or do those reques
Hi all,
With round robin load balancing and the http-server-close option, do
connections that were part of the same keep alive session on the client side
all hit the same web server, or do those requests end up being round robin
as well?
Thanks!
Kyle
Hi Bryan,
On Mon, Feb 14, 2011 at 08:08:25PM -0800, Bryan Talbot wrote:
> I can't find in the documentation anything about how haproxy handles
> client keep-alive (using http-server-close) when the maximum number of
> client connections has been reached.
>
> If there are idl
I can't find in the documentation anything about how haproxy handles
client keep-alive (using http-server-close) when the maximum number of
client connections has been reached.
If there are idle client connections, will the proxy close them to
allow new connections to be established? Or,
# HG changeset patch
# User Patrick Mezard
# Date 1276351667 -7200
# Node ID 665a0f2365f59ddf58e862ff8ccf830568c89fb9
# Parent e62ef7ba49a979f308fc9ff653e4dfb51652e1f0
doc: mention 'option http-server-close' effect in Tq section
diff --git a/doc/configuration.txt b/doc/configuration
retend-keepalive
Good job ! It's always better to improve products than to work around
their limitations.
> http://marc.info/?l=tomcat-dev&m=127066772025778&w=2
>
> Willy, maybe you can include in the documentation of
> "http-pretend-keepalive" something like t
can include in the documentation of
"http-pretend-keepalive" something like this:
"This option is recommended when using http-server-close for backends
running: Tomcat 5.5.28 or below, Tomcat 6.0.26 or below, or Jetty.".
2010/4/1 Óscar Frías Barranco
> I have "forw
On Tue, Apr 06, 2010 at 11:01:15PM +0200, Cyril Bonté wrote:
> Le lundi 5 avril 2010 20:27:41, Willy Tarreau a écrit :
> > Hi Cyril,
> >
> > On Mon, Apr 05, 2010 at 05:12:57PM +0200, Cyril Bonté wrote:
> > > Good news, I'll try to make some tests with tomcat today or tomorrow.
> >
> > fine.
>
>
Le lundi 5 avril 2010 20:27:41, Willy Tarreau a écrit :
> Hi Cyril,
>
> On Mon, Apr 05, 2010 at 05:12:57PM +0200, Cyril Bonté wrote:
> > Good news, I'll try to make some tests with tomcat today or tomorrow.
>
> fine.
Tested with Tomcat 6.0.26, 5.5.27, 4.1.40 and Jetty 6.1.23. "option
http-prete
Patrik does digest authentication work for you? I've just tried 1.4.3 and
got a :- org.mortbay.jetty.EofException when attempting digest auth with
http-server-close or httpclose set.
It works as expected if I don't set any of those options.
Matt
On 30 March 2010 13:34, Patrik Nils
Hi Cyril,
On Mon, Apr 05, 2010 at 05:12:57PM +0200, Cyril Bonté wrote:
> Good news, I'll try to make some tests with tomcat today or tomorrow.
fine.
> > I intend to release 1.4.4 soon with that.
>
> Ok, FYI I'm currently working on a patch to add if/unless conditions to the
> "cookie" and "app
Hi,
Le lundi 5 avril 2010 16:39:27, Willy Tarreau a écrit :
> Hi Cyril,
>
> Since we got positive feedback with your proposed patch, I have
> merged it associated with "option http-pretend-keepalive".
>
> I have slightly modified it so that "option httpclose" still has
> precedence over it, as i
Hi Cyril,
Since we got positive feedback with your proposed patch, I have
merged it associated with "option http-pretend-keepalive".
I have slightly modified it so that "option httpclose" still has
precedence over it, as it is defined as adding the close header.
I have run several tests here wit
On Thu, Apr 01, 2010 at 11:32:29AM +0200, Patrik Nilsson wrote:
> Hi,
>
> 2010/3/30 Óscar Frías Barranco :
> <...>
> > It seems to me that when http-server-close option is enabled, haproxy
> > replaces the original request header "Connection: Keep-Alive&quo
I have "forwarded" the issue (with your explanation, thank you Willy) to
Tomcat developers mailing list and it has got several replies, maybe you
want to participate:
http://marc.info/?t=12701162342&r=1&w=2
Regards,
Óscar
2010/4/1 Willy Tarreau
> Hi Oscar,
>
> On Wed, Mar 31, 2010 at 07:
Hi,
On Wed, Mar 31, 2010 at 6:43 AM, Willy Tarreau wrote:
<...>
> I think this is an excellent idea. From a protocol point of view,
> it is very dirty because you ask the othe side to maintain a connection
> open longer, but it should definitely do the trick.
>
> If this works for the persons who
On Thu, Apr 1, 2010 at 11:32, Patrik Nilsson wrote:
> Hi,
>
> 2010/3/30 Óscar Frías Barranco :
> <...>
> > It seems to me that when http-server-close option is enabled, haproxy
> > replaces the original request header "Connection: Keep-Alive" by
>
Hi,
2010/3/30 Óscar Frías Barranco :
<...>
> It seems to me that when http-server-close option is enabled, haproxy
> replaces the original request header "Connection: Keep-Alive" by
> "Connection: close". And this change is making Tomcat change its behavio
Hi Oscar,
On Wed, Mar 31, 2010 at 07:15:34PM +0200, Óscar Frías Barranco wrote:
> I have been looking at Tomcat source code and apparently it looks like there
> is an easy fix.
That's good news !
> Here is the class where the logic is implemented:
> http://svn.apache.org/repos/asf/tomcat/trunk/j
> > In any case, if you consider that this Tomcat behavior is buggy we could
> > report the issue to Tomcat team and maybe they can fix it.
>
> If we're certain that it's just "Connection: close" which automatically
> disables use of chunked encoding, then yes it's a buggy behaviour and maybe
> the
on after the
first request. It is perfectly valid and should not disable use of any form
of encoding in the response.
> As I explained in a previous email, we are using "http-server-close" to
> force "forwardfor" option to include the "X-Forwared-For" header in all the
> requests.
This is a very valid concern too !
Regards,
Willy
> > As a quick and dirty test, I've applied the following patch.
> > Note this is maybe not OK for production, it's a first look on the
> problem, so be careful (I only took some minutes on a tomcat server with
> gzip compression, which removes the Content-Length when "Connection: close"
> is provi
he issue to Tomcat team and maybe they can fix it.
>
> > Why do you want to use http-server-close option ?
> > Why not to use directly Keep-Alive ability of tomcat Connector and
> specify
> > 'no option httpclose' in haproxy ? This way, haproxy should act
> >
Hi Cyril,
On Wed, Mar 31, 2010 at 01:06:38AM +0200, Cyril Bonté wrote:
> Hi,
> Le Mardi 30 Mars 2010 23:36:41, Craig a écrit :
> > Hi,
> >
> > I've got the same problem here with forwardfor, and are looking forward
> > to full HTTP/1.1 support (or a dirty fix ;) that won't force option
> > httpcl
ange that some servers disable chunked encoding
when close is specified. What I suspect is that internally they don't
support the "connection" header and simulate an 1.0 HTTP version when
they see a close. That would explain why they refrain from sending
the length in response (tho
Hi,
Le Mardi 30 Mars 2010 23:36:41, Craig a écrit :
> Hi,
>
> I've got the same problem here with forwardfor, and are looking forward
> to full HTTP/1.1 support (or a dirty fix ;) that won't force option
> httpclose on me...
As a quick and dirty test, I've applied the following patch.
Note this i
I did not know about TPROXY. It looks like a quite complex setup.
I would prefer either to:
- improve "forwardfor" option to include the X-Forwarded-For header in all
the requests arriving to the backend servers, or
- improve "http-server-close" to support client-side kee
ing. Maybe that's an option for
you, too?
regards,
Craig
Am 30.03.2010 23:55, schrieb Óscar Frías Barranco:
> I am forced to use http-server-close because in our application we need to
> know the remote IP addresses of the users which are connecting to our
> service.
> And for t
I am forced to use http-server-close because in our application we need to
know the remote IP addresses of the users which are connecting to our
service.
And for this we need to use "option forwardfor". And the problem when using
forwardfor and keepalive is that only some of the reques
nks
So chunk transfers need a keep-alive connection. If a connection: close
header is present, server should not proceed with chunk transfer ...
Why do you want to use http-server-close option ?
Why not to use directly Keep-Alive ability of tomcat Connector and specify
'no option httpclose'
/30 Óscar Frías Barranco
> Hello.
>
> I have just read Patrik Nilsson email about http-server-close and Jetty.
> Unfortunately I cannot reply to that email because I read it in the archives
> and I was not subscribed to the list.
>
> We are facing a very similar problem using
Hello.
I have just read Patrik Nilsson email about http-server-close and Jetty.
Unfortunately I cannot reply to that email because I read it in the archives
and I was not subscribed to the list.
We are facing a very similar problem using Tomcat 6.0.20 in the backend (and
haproxy 1.4.2).
When we
Sorry, forgot to mention what version I was using. This was with
haproxy 1.4.2. I just tried with 1.4.3 and the problem remains.
Thanks,
Patrik
On Tue, Mar 30, 2010 at 11:51 AM, Patrik Nilsson wrote:
> Hi,
>
> We have been trying to get the new keep-alive functionality, with the
>
Hi,
We have been trying to get the new keep-alive functionality, with the
http-server-close option, to work with our Jetty back-end web servers.
There seems to be something in the response from the Jetty servers
that makes HaProxy always add a Connection: close header in the
response to the
89 matches
Mail list logo
