ing to the logs the client
produced about 12k 400-Errors
$ grep [REDACTED] /var/log/haproxy.log | grep BADREQ | wc -l
12383
It seems to me like a Problem with Version 1.8, because i tested it with
Version 2.0 in a Staging Environment were everything works like
expected. For me it's another
Hi Willy,
thank for your support, this perfectly make sense. I've changed the
configuration and will investigate if it works.
Marco
Am 12.12.19 um 16:39 schrieb Willy Tarreau:
Hi Marco,
On Wed, Dec 11, 2019 at 12:50:21PM +0100, Marco Nietz wrote:
Hi,
i'm running Haproxy 1.8.21 on a Debi
Hi Marco,
On Wed, Dec 11, 2019 at 12:50:21PM +0100, Marco Nietz wrote:
> Hi,
>
> i'm running Haproxy 1.8.21 on a Debian 9 Box.
>
> We use stick-tables to track http-connections and http-error-rate and block
> clients (bots) that cause a high error-rate. But Today i recognize a lot of
> 400 / Bad
Hi,
i'm running Haproxy 1.8.21 on a Debian 9 Box.
We use stick-tables to track http-connections and http-error-rate and
block clients (bots) that cause a high error-rate. But Today i recognize
a lot of 400 / Bad Requests Error (~15/s) in the logs. The rate
definitely exceeds the defined limit
> On Tue, Feb 24, 2015 at 01:33:32PM -0700, NuSkooler wrote:
>> Thanks, this has all been very helpful.
>>
>> Unfortunately it seems that some of the pieces to create a debuggable
>> version of these old clients are currently missing here. If I can get
>> that together I'll debug and hopefully find
Hi,
On Tue, Feb 24, 2015 at 01:33:32PM -0700, NuSkooler wrote:
> Thanks, this has all been very helpful.
>
> Unfortunately it seems that some of the pieces to create a debuggable
> version of these old clients are currently missing here. If I can get
> that together I'll debug and hopefully find
Thanks, this has all been very helpful.
Unfortunately it seems that some of the pieces to create a debuggable
version of these old clients are currently missing here. If I can get
that together I'll debug and hopefully find something. Until then,
we'll be attempting to route their traffic around H
> Attached are two captures:
>
> 1) ha_lukas-allow-allow.pcap: This is a capture of the bind line you provided:
> bind *:443 ssl crt /home/bashby/Lukas/TEST_cert_and_key.pem ciphers \
> AES128-SHA verify optional ca-ignore-err all crt-ignore-err all ca-file \
> /etc/ssl/certs/cw_client_ca.pem
>
> 2
Hi all,
I'm only reposting below Lukas' mail without mixed text/plain
Content-Type and html inside, in case someone couldn't read it ;-)
Le 24/02/2015 01:04, Lukas Tribus a écrit :
Attached is the information you requested -- and hopefully performed
correctly :)
* no_haproxy.pcap: This is a
I apologize, the email was destroyed by the mailer...
> Attached is the information you requested -- and hopefully performed
> correctly :)
>
> * no_haproxy.pcap: This is a successful connection + POST to the
> original Mochiweb server. Note that here the port is 8443 not 443
> (IP=10.3.3.3)
> *
> Attached is the information you requested -- and hopefully
performed> correctly :)>> * no_haproxy.pcap: This is a
successful connection + POST to the> original Mochiweb server. Note that
here the port is 8443 not 443> (IP=10.3.3.3)> *
ha_self_signed.pcap: Failed attempt against HAProxy with a
On 23/02/2015 10:55 μμ, NuSkooler wrote:
> Attached is the information you requested -- and hopefully performed
> correctly :)
>
> * no_haproxy.pcap: This is a successful connection + POST to the
> original Mochiweb server. Note that here the port is 8443 not 443
> (IP=10.3.3.3)
> * ha_self_signed
A bit late to this discussion but the issues sound familiar.
I've seen this type of issue in the past between openssl and java's ssl
implementation, primarily in java 6 and java 7. I don't remember the
full details but from what I recall avoiding the EC based ciphers from
the supported list resol
Attached is the information you requested -- and hopefully performed
correctly :)
* no_haproxy.pcap: This is a successful connection + POST to the
original Mochiweb server. Note that here the port is 8443 not 443
(IP=10.3.3.3)
* ha_self_signed.pcap: Failed attempt against HAProxy with a self
signe
> Attached is a pcap with the bind line cut+paste from your link.
>
> In this case I see Encrypted Alert, but I'm struggling to decrypt it
> in WS with this setup.
Ok, so as expected, this didn't really change anything, but at least
we have a config/capture consistency.
Now, it looks like the cli
Attached is a pcap with the bind line cut+paste from your link.
In this case I see Encrypted Alert, but I'm struggling to decrypt it
in WS with this setup.
On Mon, Feb 23, 2015 at 11:36 AM, Lukas Tribus wrote:
> There's some confusion here.
>
> For the sake of clarity, please, for the time bein
Do you use any reqrep/resprep rules? I'm asking because I had the same kind
of problem, also with java apps.
First I changed the global section to:
tune.ssl.default-dh-param 1024
ssl-default-bind-ciphers
EECDH+aRSA+AES:kRSA+AES:+AES256:RC4-SHA:!kEDH:!LOW:!EXP:!MD5:!aNULL:!eNULL
ssl-default-bind-op
Hi,
> I'm not currently sure on the JRE version. These are Android clients
> written with a old Android SDK. All new clients are C++ / OpenSSL
> based.
>
> I have set the DH param size to 1024 with the same results.
> Additionally, I set up a bind statement that reflects that of the
> backward co
We do not expect SPDY to be used, no. The expected behavior is HTTP on
TLS with JSON-RPC payloads (POST/response body).
Perhaps I'm not reading something right here: Looking at #61 in
Wireshark, I see the following:
61 16.127749 10.3.2.74 10.1.1.93 TLSv1 279 Application Data
TLSv1 Record Layer: Ap
The TLS handshake is working fine. The issue is that HAProxy is trying
to speak SPDY
with your clients, and they most likely don't support it.
In the Haproxy_1 capture, look at packet #61 send by haproxy to the
client. The application
data protocol is set to SPDY. Is this the expected behavior
ately he said there were zero errors. The BADREQ here is the
> result of the failed handshake leading to the connection being closed
> before a request is received. That makes me think that we don't start
> the full session until a handshake is completed, so if we see this log,
&g
I have since set DH to 1024 in my configuration. Here is the results
from cipherscan:
Target: 10.3.2.74:443
prio ciphersuite protocols pfs_keysize
1 AES128-SHA TLSv1,TLSv1.1,TLSv1.2
2 DHE-RSA-AES256-SHA TLSv1,TLSv1.1,TLSv1.2 DH,1024bits
Certificate: UNTRU
I'm not currently sure on the JRE version. These are Android clients
written with a old Android SDK. All new clients are C++ / OpenSSL
based.
I have set the DH param size to 1024 with the same results.
Additionally, I set up a bind statement that reflects that of the
backward compatibility link yo
On 2015-02-21 05:15, Lukas Tribus wrote:
Out of the blue, I would suggest to make sure DH params for DHE
ciphers
are fixed to 1024 bit (known Java limitation to only support 1024 bit
with
DHE ciphers in the older releases) - this can be either in the
certificate
file or generated by haproxy at
milar
> capture in the view of Wireshark is below that. Lastly, *with* HAProxy
> when the NOSRV/BADREQ is issued, the client is sent a encrypted 400
> Bad Request.
>
> Any help/tips appreciated! This represents a large client base that
> unfortunately cannot be updated for t
d to allow them through HAProxy.
> > Below is a s_server log. Note the read failure at the end. A similar
> > capture in the view of Wireshark is below that. Lastly, *with* HAProxy
> > when the NOSRV/BADREQ is issued, the client is sent a encrypted 400
> > Bad Request.
> >
we can't even properly connect to s_server, that may be the end
> of the road for those clients. However, I'm hoping there may be
> something that could be configured to allow them through HAProxy.
> Below is a s_server log. Note the read failure at the end. A similar
> capture i
igured to allow them through HAProxy.
Below is a s_server log. Note the read failure at the end. A similar
capture in the view of Wireshark is below that. Lastly, *with* HAProxy
when the NOSRV/BADREQ is issued, the client is sent a encrypted 400
Bad Request.
Any help/tips appreciated! This
0, tx flags 0x
> >
> > We can see "HTTP msg state 27", which means that haproxy has
> > successfully passed the request parsing (27 = HTTP_MSG_BODY). Without
> > "option accept-invalid-http-request", it would have failed on state 26
> > (HTTP_MSG_ERRO
gt;> src :49803, session #24184, session flags 0x0080
>> HTTP msg state 27, msg flags 0x, tx flags 0x
>
> We can see "HTTP msg state 27", which means that haproxy has
> successfully passed the request parsing (27 = HTTP_MSG_BODY). Without
>
gt;HTTP msg state 27, msg flags 0x, tx flags 0x
We can see "HTTP msg state 27", which means that haproxy has
successfully passed the request parsing (27 = HTTP_MSG_BODY). Without
"option accept-invalid-http-request", it would have failed on state 26
(HTT
> OK, got it.
>
> What should I do with HAProxy to handle with them? (option
> accept-invalid-http-request is set already)
You can't. HAproxy will not support those URI's.
accept-invalid-http-request allows a limited set of forbidden
chars, but not the ones you are using (> 127/0x7f ASCII).
You
OK, got it.
What should I do with HAProxy to handle with them? (option
accept-invalid-http-request is set already)
On Mon, Dec 22, 2014 at 8:10 PM, Lukas Tribus wrote:
> > Hi,
> >
> > could anyone explain what is wrong with following HTTP-request? Nginx
> > (btw) is working fine.
>
> The conten
> Hi,
>
> could anyone explain what is wrong with following HTTP-request? Nginx
> (btw) is working fine.
The content of objectKey (everything after "objectKey=").
Lukas
Hi,
could anyone explain what is wrong with following HTTP-request? Nginx (btw)
is working fine.
--
[22/Dec/2014:16:33:11.765] frontend https_frontend_ssl_terminate (#3):
invalid request
backend (#-1), server (#-1), event #7
src :49803, session #24184, session flags 0x008
Guillaume Castagnino wrote on 11/25/2014 01:20 PM:
[CUT]
Look at this timeout ;)
30ms timeout is quite short don’t you think ?
dooh.. thank you for the spot - that helped a whole lot :)
--
Regards,
Klavs Klavsen, GSEC - k...@vsen.dk - http://www.vsen.dk - Tlf. 61281200
"Those who do not unde
Hi,
Le mardi 25 novembre 2014 13:14:45 Klavs Klavsen a écrit :
> out haproxy config:
> defaults
>log global
>maxconn 8000
>option redispatch
>retries 3
>stats enable
>timeout http-request 10s
>timeout queue 1m
>timeout connect 10s
>timeout client 1m
>
We have some odd bug.. haproxy seems to work fine locally - but when we
access from "internet hosts" and not local hosts, using the public IP -
haproxy says:
188.40.40.69:40599 [25/Nov/2014:13:07:50.359] pbutik pbutik/
-1/-1/-1/-1/31 408 0 - - cR-- 0/0/0/0/0 0/0 ""
(this public ip is a serve
Hi,
On Tue, Oct 21, 2014 at 02:50:58PM +0200, Robert Bartl wrote:
> yep. that worked around the broken URL.
>
> BTW. this behaviour started with Copy & Pasting a URL with an umlaut
> into Internet explorer.
We've already had some cases where users had to use the option to accept
invalid request
ugh haproxy
and produces a HTTP 400 BADREQ.
You may have invalid characters in URL, and HAProxy filters it by default.
To change this behaviour, take a look at option
accept-invalid-http-request.
http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#4-option%20accept-invalid-http-req
> Hy,
>
> I've got a problem with a specific URL which runs through haproxy and
> produces a HTTP 400 BADREQ.
> it seems haproxy doesnt like the encoding of the URL, when i remove the
> umlaut in it it gets through correctly
>
> i've tested it with haproxy "1
Hello,
2014-10-21 14:17 GMT+02:00 Robert Bartl :
>
> I've got a problem with a specific URL which runs through haproxy and
> produces a HTTP 400 BADREQ.
>
You may have invalid characters in URL, and HAProxy filters it by default.
To change this behaviour, take a look at opti
Hy,
I've got a problem with a specific URL which runs through haproxy and
produces a HTTP 400 BADREQ.
it seems haproxy doesnt like the encoding of the URL, when i remove the
umlaut in it it gets through correctly
i've tested it with haproxy "1.5.5-1~bpo70+1" from debian.
Thank you very very much for the keyword "pre-connect" in your email.
I got the reason why so many 400 requests. Most of the requests are sent
from flash player, this is so weird they send pre-connect request.
I add option dontlognull in haproxy.cfg. The haproxy.log did not log any
these empty co
On Fri, Jun 20, 2014 at 03:30:29PM +0800, Jie Jin wrote:
> In order to get output from stats socket, What parameter do I need to put
> in haproxy.cfg ?
>
> I tried show errors, but nothing returned.
>
> [www@front tmp]$ echo "show errors" | sudo socat stdio /tmp/haproxysock
> Total events capture
w why so many 400 requests, and fix it.
> >
> > I have analyze the log, most of the 4xx requests are 400 requests which
> > marked as BADREQ
> > below is the sample of log, ip address has been anonymized. (Our clients
> > continuously send a heartbeat every 30 seconds)
&
400 requests, and fix it.
>
> I have analyze the log, most of the 4xx requests are 400 requests which
> marked as BADREQ
> below is the sample of log, ip address has been anonymized. (Our clients
> continuously send a heartbeat every 30 seconds)
Then I suspect that your client's
Hi Bar,
On Mon, May 14, 2012 at 03:20:12AM +0300, Bar Ziony wrote:
> Willy,
>
> I tried fetching 1 packets into a file with tcpdump, then seeing which
> IPs in the haproxy log were doing the BADREQ errors at the time I was
> running tcpdump. I used -A -vvn to see the packets c
Willy,
I tried fetching 1 packets into a file with tcpdump, then seeing which
IPs in the haproxy log were doing the BADREQ errors at the time I was
running tcpdump. I used -A -vvn to see the packets content. This is a
sample of a packet I see a lot, and I saw the IP+port combination in
Hi Willy,
On Sat, May 12, 2012 at 7:08 PM, Willy Tarreau wrote:
> On Sat, May 12, 2012 at 06:54:06PM +0300, Bar Ziony wrote:
> > I have no problem increasing the RAM if needed, but how do I know if it's
> > needed? Where can I see the number of connections per second to see if I
> > somehow rea
On Sat, May 12, 2012 at 06:54:06PM +0300, Bar Ziony wrote:
> I have no problem increasing the RAM if needed, but how do I know if it's
> needed? Where can I see the number of connections per second to see if I
> somehow reached 20k ?
I have not said 20k conns/s, but 20k concurrent conns. Concurren
I have no problem increasing the RAM if needed, but how do I know if it's
needed? Where can I see the number of connections per second to see if I
somehow reached 20k ? I don't think I reached 20k because the global
maxconn is 20K
This is my TCP tuning config for the LB:
# TCP stack tuning
net
On Sat, May 12, 2012 at 01:23:17PM +0200, Baptiste wrote:
> On Sat, May 12, 2012 at 1:01 PM, Bar Ziony wrote:
> > Willy,
> >
> > Thank you, I will follow up with your suggestions soon.
> >
> > But I just had a production down-time with the haproxy machine:
> > After posting something to our Facebo
On Sat, May 12, 2012 at 1:01 PM, Bar Ziony wrote:
> Willy,
>
> Thank you, I will follow up with your suggestions soon.
>
> But I just had a production down-time with the haproxy machine:
> After posting something to our Facebook wall (it happened twice, yesterday
> and 3 days ago), which usually b
Willy,
Thank you, I will follow up with your suggestions soon.
But I just had a production down-time with the haproxy machine:
After posting something to our Facebook wall (it happened twice, yesterday
and 3 days ago), which usually brings more traffic (but not more than we
can usually handle (fo
Hi Bar,
On Thu, May 10, 2012 at 07:02:58PM +0300, Bar Ziony wrote:
> Hey,
>
> We're running haproxy 1.4.20 as our LB, nginx is listening on the same
> machine on port 443 and terminating SSL, proxying the unencrypted requests
> to haproxy on localhost:80.
>
> I see many of these errors on the ha
Hey,
We're running haproxy 1.4.20 as our LB, nginx is listening on the same
machine on port 443 and terminating SSL, proxying the unencrypted requests
to haproxy on localhost:80.
I see many of these errors on the haproxy log:
May 10 15:54:06 lb-01 haproxy[6563]:
1.1.1.1:50929[10/May/2012:15:54:01
ied temporarely accept-invalid-http-request with no success, also
> I've set the "timeout http-request" parameter to 30s, with no difference.
>
> Partial log of the BADREQ: http://pastebin.com/uHJ2qztb
>
> My haproxy.cfg file: http://pastebin.com/EJi18bqV
>
>
Hello list,
I'm getting some (~400 per hour) ... entries in my log
file. I've tried temporarely accept-invalid-http-request with no
success, also I've set the "timeout http-request" parameter to 30s, with
no difference.
Partial log of the BADREQ: http://
Hi Seth,
On Sat, Jan 29, 2011 at 11:52:16PM +1100, Seth Yates wrote:
> Hi,
>
> We're getting quite a few BADREQ entries in the logs, and we're thinking its
> because some clients are accumulating a lot of cookies. Is HAPROXY
> returning 400 Bad Request when a request or
Hi,
We're getting quite a few BADREQ entries in the logs, and we're thinking its
because some clients are accumulating a lot of cookies. Is HAPROXY
returning 400 Bad Request when a request or cookie or header size is
exceeded? If so, is there a way to turn off these checks? We&#x
ying the request to the log buffer. When it wants to log,
no request was logged, hence the "BADREQ".
I'll see if it can make sense to emit a warning in such a case.
Regards,
Willy
Hi, am getting these results in haproxy logs:
Feb 2 13:17:40 localhost haproxy[3245]:
10.10.10.62:54164[02/Feb/2010:13:17:40.774] load_balanced
load_balanced/www1 -1/1/1/-1/4 0
715 - - 0/0/0/0/0 0/0 ""
I need to log the requests and I cannot understand why we are getting
instead of the act
w minutes without any reason (nothing in any log down
> stream).
The most important part is the "BADREQ" part, it indicates that the
client has sent you a bad request and that haproxy did not forward it
to any server :
208.54.90.71:47640 = client's IP:port
[22/Nov/2009:0
Hi, we are using HA-Proxy version 1.3.19 2009/07/27
For the second time in the last week we seem to be getting NOSRV in the
haproxy logs for a few minutes without any reason (nothing in any log down
stream).
I noticed one thing during each outage is that before the NOSRV starts
happening this is
65 matches
Mail list logo
