Hi
We have a backend cluster of 18 api servers which normally get hit from an
haproxy instance on the public subnet. We like to use hash-type consistent
to load balance and pin clients to specific servers in order to take
advantage of local cache on the api servers. We recently deployed a few
On Tue, Sep 30, 2014 at 11:44 AM, Paul McIntire p...@skout.com wrote:
Hi
api servers and cause them to melt. Is it possible to use hash-type
consistent on the x-forwarded-for information from the request hitting the
frontend nginx servers?
If you're using 1.5 the balance
Hi Matthieu,
On Thu, Sep 15, 2011 at 01:55:22PM +0200,
matthieu.lochegn...@altissemiconductor.com wrote:
Hi,
I'm facing a problem with the 'X-Forwarded-For' header.
Although the HTTP RFC (2616) allows multiple occurences of the same header
field, and describes how the values must
I am using haproxy in combination with stunnel to perform SSL. My
backend servers expect an X-Forwarded-Proto: https header to indicate
that the request was sent over SSL. If this header is missing, the
request is redirected to the https:// flavor of the URL.
However, with haproxy-1.5-dev5, I am
I found the issue. From the haproxy manual:
By default HAProxy operates in a tunnel-like mode with regards to persistent
connections: for each connection it processes the first request and forwards
everything else (including additional requests) to selected server. Once
established, the
On Thu, Mar 24, 2011 at 09:12:46PM +0100, Willy Tarreau wrote:
Hello Dmitry,
On Thu, Mar 24, 2011 at 05:28:13PM +0300, Dmitry Sivachenko wrote:
Hello!
With option forwardfor, haproxy adds X-Forwarded-For header at the end
of header list.
But according to wikipedia:
http
Hello!
With option forwardfor, haproxy adds X-Forwarded-For header at the end
of header list.
But according to wikipedia:
http://en.wikipedia.org/wiki/X-Forwarded-For
and other HTTP proxies (say, nginx)
there is standard format to specify several intermediate IP addresses:
X-Forwarded
Hello Dmitry,
On Thu, Mar 24, 2011 at 05:28:13PM +0300, Dmitry Sivachenko wrote:
Hello!
With option forwardfor, haproxy adds X-Forwarded-For header at the end
of header list.
But according to wikipedia:
http://en.wikipedia.org/wiki/X-Forwarded-For
and other HTTP proxies (say, nginx
I know there have been several emails about this, but what is the most
secure way of logging the client's IP address in the application code?
Do you just log the full X-Forwarded-For comma delimited value?
Also, can't they manipulate the X-Forwarded-For header in the HTTP
request?
Regards
they manipulate the X-Forwarded-For header in the HTTP
request?
Delete any existing headers using reqdel/reqidel.
reqidel X-Forwarded-For
option forwardfor
This will ensure the only one the backed sees is the one you added.
On Thu, Mar 24, 2011 at 5:01 PM, Ben Timby bti...@gmail.com wrote:
Delete any existing headers using reqdel/reqidel.
reqidel X-Forwarded-For
option forwardfor
This will ensure the only one the backed sees is the one you added.
Sorry, more like:
reqidel ^X-Forwarded-For:.*
Found that in
the X-Forwarded-For header in the HTTP
request?
Anyone can manipulate it. However, standards are clear : when headers
are folded into one, the order must be respected. If a product such as
haproxy, squid, nginx, apache or whatever says that when it sets the
IP address in x-forwarded-for, it APPENDS
Hi,
I'm using HAproxy 1.4.8 on RHEL5 (fully up-to-date).
I'm using the 'option forwardfor'
In certain circumstances, the client has already got an X-Forwarded-For
header in the request.
HAproxy in this instance adds a second X-Forwarded-For header rather than
extending the existing header
On Dec 10, 2010, at 6:42 AM, Brett Delle Grazie wrote:
Hi,
I'm using HAproxy 1.4.8 on RHEL5 (fully up-to-date).
I'm using the 'option forwardfor'
In certain circumstances, the client has already got an X-Forwarded-For
header in the request.
HAproxy in this instance adds a second X
the 'option forwardfor'
In certain circumstances, the client has already got an X-Forwarded-For
header in the request.
HAproxy in this instance adds a second X-Forwarded-For header rather than
extending the existing header.
This causes a problem on our Tomcat backend because
I am seeing (with option forwardfor) that HAProxy is replacing
X-Fowarded-For instead of chaining the proxy chain. I know it's not an RFC
but the defacto standard is to chain the proxies by appending to the header.
For my usage it is not necessary but thought I'd point it out (Varnish also
doesn't
would need a list of upstream IPs for which it
will trust the X-Forwarded-For header and chain it.
We would very much like this functionality as well. We are in a
situation where we're using HAProxy simply to bounce requests onwards
to another HAProxy (for legacy issues related to IP address
ownership
-For can be spoofed by clients, and to
prevent this, the proxy would need a list of upstream IPs for which it
will trust the X-Forwarded-For header and chain it.
We would very much like this functionality as well. We are in a
situation where we're using HAProxy simply to bounce requests onwards
this, the proxy would need a list of upstream IPs for which it
will trust the X-Forwarded-For header and chain it.
We would very much like this functionality as well. We are in a
situation where we're using HAProxy simply to bounce requests onwards
to another HAProxy (for legacy issues
On Wed, Sep 02, 2009 at 05:06:01PM -0400, Miguel Pilar Vilagran wrote:
The problem with this header (and a few others such as Via) is that it
can appear multiple times, but it must always be chained in the correct
sequence. Haproxy respects this. However I've already seen some applications
20 matches
Mail list logo
