Autododo - dedicat lumii motoarelor
Use this area to offer a short preview of your email's content. View this email in your browser ( *%7CARCHIVE%7C* ) *** ( http://autododo.ro/ ) *** Anunturile Zilei ! ( http://autododo.ro/ad/3864419/ford-mondeo-zetec-tdci-automatic-diesel-2010-5-door-grays- ) Ford Mondeo Zetec TDCI, AUTOMATIC, DIESEL, 2010 ( http://autododo.ro/ad/3864419/ford-mondeo-zetec-tdci-automatic-diesel-2010-5-door-grays- ) 7,074 euro ( http://autododo.ro/ad/5657225/audi-a4-avant-20-tdi-dpf-multitronic-attraction-als-kombi-in-pfungstadt ) Audi A4 Avant 2.0 TDI DPF multitronic Attraction ( http://autododo.ro/ad/5657225/audi-a4-avant-20-tdi-dpf-multitronic-attraction-als-kombi-in-pfungstadt ) ( http://autododo.ro/ad/5657225/audi-a4-avant-20-tdi-dpf-multitronic-attraction-als-kombi-in-pfungstadt ) 7,400 euro Incercati autododo.ro. ( http://autododo.ro/ ) Noi iti punem la dispozitie anunturile de pe cele mai importante site-uri auto. Autododo.ro ( http://autododo.ro/ ) este cea mai mare platforma specializata pe vanzarea de masini second-hand si automobile noi cu un numar total de 6 milioane masini. Zilnic platforma culege aproximativ 50 000 de anunturi noi postate pe site-urile de profil. Testeaza gratuit platforma ( http://autododo.ro/ ), iar daca ai idei asupra imbunatatirii site-ului, trimite-le pe adresa de mail petruta.te...@mydomains.ro si vei beneficia de o reducere de 50 % dupa perioada de testare. Dat fiind faptul ca autovehiculele avantajoase se vand in primele 5 minute de la publicarea anuntului, in acest moment exista posibilitatea ca unele dintre aceste anunturi sa fie deja inexistente. Cautari active : Setezi cat de des vrei sa fi anuntat, prin email, atunci cand una sau mai multe masini corespund preferintelor tale (din 15 in 15 minute, din ora in ora, din 6 in 6 ore sau zilnic). Reclama ta aici : Este singurul loc unde afaceri ca leasing, asigurari auto, piese si dezmembrari auto merita sa se promoveze eficient. De ce? pentru ca 99.8% dintre clientii nostri sunt interesati de aceste afaceri. Nicio alta platforma online nu este atat de targetata ca si autododo.ro Contacteaza-ne chiar acum pentru a beneficia de o luna de reclama gratuita. Autododo pentru calitate, siguranta si incredere. ( http://autododo.ro/ad/1744093/bmw-320-d-cat-touring-attiva ) BMW 320 d cat Touring Attiva ( http://autododo.ro/ad/1744093/bmw-320-d-cat-touring-attiva ) 6,500 euro ( http://autododo.ro/ad/1567933/vauxhall-insignia-sri-sat-nav-160cdti-paisley- ) VAUXHALL INSIGNIA SRI SAT NAV 160CDTI ( http://autododo.ro/ad/1567933/vauxhall-insignia-sri-sat-nav-160cdti-paisley- ) 6,660 euro ( http://autododo.ro/ad/5107811/mercedes-benz-w-245-b-klasse-b-180-cdi-taxi-leder-als-van-kleinbus-in-neumalsch ) Mercedes-Benz W 245 B-Klasse B 180 CDI ( http://autododo.ro/ad/5107811/mercedes-benz-w-245-b-klasse-b-180-cdi-taxi-leder-als-van-kleinbus-in-neumalsch ) 7,900 euro Tecar Petruta -- Tel / Fax : 0362 226 778 E-mail : petruta.te...@mydomains.ro Website : www.autododo.ro Address : str. Carbunari nr. 8 City : Baia Mare -- unsubscribe from this list ( *%7CUNSUB%7C* ) update subscription preferences ( *%7CUPDATE_PROFILE%7C* )
Configuring HAProxy to send X_FORWARDED_FOR and X_REAL_IP at the same time.
Hello, I'm working for company which have software based on both headers, and if one of them is missing, the software is not working properly. I find a way to configure HAProxy to send each of them but separated. I need to find solution which will make HAProxy to send both. Can I use reqadd or http-request add-header/set-header to set a the second header? Best Regards, Daniel Todorov
Re: Configuring HAProxy to send X_FORWARDED_FOR and X_REAL_IP at the same time.
On Mon, May 26, 2014 at 10:03 AM, Daniel Todorov leinad...@gmail.com wrote: Hello, I'm working for company which have software based on both headers, and if one of them is missing, the software is not working properly. I find a way to configure HAProxy to send each of them but separated. I need to find solution which will make HAProxy to send both. Can I use reqadd or http-request add-header/set-header to set a the second header? Best Regards, Daniel Todorov Hi Daniel Yes, you can use http-request add-header to add headers. You can extract source IP address using the acl 'src'. Baptiste
Re: Error 408 with Chrome
Hi [Sorry for top-posting] 2014-05-23 16:08 GMT+02:00 Willy Tarreau w...@1wt.eu: Hi Kevin, [guys, please could you stop top-posting, it's a total mess to try to respond to this thread, I cannot easily take out the useless parts, thanks]. On Fri, May 23, 2014 at 02:35:21PM +0200, Kevin Maziere wrote: 2014-05-23 14:34 GMT+02:00 Baptiste bed...@gmail.com: Kevin, Do you (still) see 408 errors printed in the browser??? Baptiste On Fri, May 23, 2014 at 2:17 PM, Kevin Maziere ke...@kbrwadventure.com wrote: Hi I've just applied the first patch, here are the debug log : In the logs : 2014-05-23T12:03:20+00:00 images-access haproxy[13409]: 127.0.0.1:56596 [23/May/2014:12:03:17.972] ipv4-yyy-443~ ipv4-yyy-443/NOSRV -1/-1/-1/-1/2041 408 212 - - cR-- 9/3/0/0/0 0/0 BADREQ Well, here I'm seeing a standard 408 after 2 seconds which should match a timeout http-request of 2 seconds. Can you check if you don't have one ? Also, this observation from the logs doesn't seem consistent with your first claim that the 408 is immediate, here it's only after 2 seconds. Or again we are facing this bogus preconnect feature of Chrome. People complain all the time that not only it connects before you want to go to the site, but above all it displays the error that it receives without checking that it got an error prior to using the connection :-( You can see the 408 displaying immediatly by browsing on http://shoppingadventure.fr with chrome. The probleme occured on haproxy 1.4 also, not only on 1.5dev. In the debug log, correspond lines: 2014-05-23T12:03:20+00:00 servername haproxy[13409]: Timeout detected: fe=ipv4-yyy-443 s-flags=0080 txn-flags= req-flags=00c88000 msg-flags= now_ms=687261517 req-analyse_exp=687261515 (-2) At least that's good, it's the first request of the connection and nothing except the regular request timeout occurred. There was an interesting thread here about the nasty behaviour of chrome : https://code.google.com/p/chromium/issues/detail?id=85229#c33 Thansk for this link. I'm testing a big value for timeout client so that chrome will expired before haproxy close the socket. Some people suggest closing without ever emitting the 408. You can do that this way : errorfile 408 /dev/null Note that this fantastic browser breaks HTTP by preventing any server from using the well-defined HTTP status code indicating a timeout occurred. The problem happens recently, I used to browse with Chrome without seeing it before I do agree with you. Kévin, I think the reason why you have the issue only on one OS is not related to the OS but to your browsing history on that system. The browser doesn't pre-connect there and you don't have the trouble. Yes it is. I flush my history and after few click I have the 408 error, and the error in immediat, Chrome is not loading and then showing 408 page. Regards, Willy Thanks Willy for the help.
Re: Error 408 with Chrome
On Mon, May 26, 2014 at 11:16 AM, Kevin Maziere ke...@kbrwadventure.com wrote: Yes it is. I flush my history and after few click I have the 408 error, and the error in immediat, Chrome is not loading and then showing 408 page. Kevin, Have you tried to make your HAProxy to return void data on 408, as Willy stated? Too long timeouts can lower strength of your HAProxy and your website in general. Baptiste
Re: Error 408 with Chrome
2014-05-26 11:24 GMT+02:00 Baptiste bed...@gmail.com: On Mon, May 26, 2014 at 11:16 AM, Kevin Maziere ke...@kbrwadventure.com wrote: Yes it is. I flush my history and after few click I have the 408 error, and the error in immediat, Chrome is not loading and then showing 408 page. Kevin, Have you tried to make your HAProxy to return void data on 408, as Willy stated? Too long timeouts can lower strength of your HAProxy and your website in general. No I don't, I miss it. I'm trying it from know, Iit could be better that long timemout I do agree Baptiste
Re: Error 408 with Chrome
On Mon, May 26, 2014 at 11:37:52AM +0200, Kevin Maziere wrote: 2014-05-26 11:24 GMT+02:00 Baptiste bed...@gmail.com: On Mon, May 26, 2014 at 11:16 AM, Kevin Maziere ke...@kbrwadventure.com wrote: Yes it is. I flush my history and after few click I have the 408 error, and the error in immediat, Chrome is not loading and then showing 408 page. Kevin, Have you tried to make your HAProxy to return void data on 408, as Willy stated? Too long timeouts can lower strength of your HAProxy and your website in general. No I don't, I miss it. I'm trying it from know, Iit could be better that long timemout I do agree Temporarily yes I think it's the best approach, but it disrupts the web for normal browsers, because sending a silent close doesn't let the client know if the request was processed or not, while 408 clearly states it was not. I'm currently having an off-list discussion with Will Chan and Ilya on the subject. Cheers, Willy
Re: Add Domain redirects using API or ?
Hi guys.
Now I have this working I see it's a real redirect and I actually need a
rewrite, is this possible too in this matter ?
Cheers,
Matt
2014-05-24 0:46 GMT+02:00 Matt . yamakasi@gmail.com:
Hi,
I'm getting a strange error, which is various when I change it in the
frontend.
Is there maybe a typo in yours ?
2014-05-23 16:34 GMT+02:00 Baptiste bed...@gmail.com:
You can set a map entry, it will erase then create the entry.
And HAProxy will take it into account on the fly, without doing anything.
You could even forward traffic to your webservers and let haproxy
learn the redirect on the fly.
Remember, HAProxy is art:
https://twitter.com/malditogeek/status/243020846875152384#
Baptiste
On Fri, May 23, 2014 at 4:00 PM, Matt . yamakasi@gmail.com wrote:
So when you remove a line and there is no line like it... just nothing
happens as it should ?
But what if you add one that is already there ? Will it be added twice
? If
so and you do a remove will both be removed ?
2014-05-23 15:22 GMT+02:00 Baptiste bed...@gmail.com:
There is no reply, it is silently performed.
Baptiste
On Fri, May 23, 2014 at 3:07 PM, Matt . yamakasi@gmail.com
wrote:
Hi,
OK, that is a very good explanation!
It's also very flexible in my opinion.
Does hsproxy give a reply/callback after adding/removing ? I'm not
sure
but
I thought it did.
I also did a reply-all this time, sorry for last time!
Cheers,
Matt
2014-05-23 14:07 GMT+02:00 Baptiste bed...@gmail.com:
Hi Matt,
I'm Ccing the ML since the answer can interest everybody here.
Thanks for you explanation... I found something indeed on the
devel
version
yesterday, you can also remove this way I saw ?
yes, you can delete content from a map thanks to the socket or
through
information found in HTTP headers.
What do you mean by filecontents on reload ?
I mean that the content of the map is read from a flat file.
If you modify running map, HAProxy only updates its memory, not the
flat
file.
So after a reload, if the flat file does not contain same content as
HAProxy's memory, then updates are lost.
What I add this was is added to memory and not to the file ?
exactly
So, I need to sync the file with the memory in some way ?
yes.
This can be done easily with a tool since you can dump a map content
from HAProxy's socket.
Baptiste
2014-05-23 10:17 GMT+02:00 Baptiste bed...@gmail.com:
Hi Matt,
You have to use HAProxy 1.5.
You can load redirects from a map file.
Map file content, 2 columns, with on the left the reference (what
you're looking from in the client request) and on the right the
response to send back.
domain2.com subdomain.domain1.com
Then, in your frontend, simply add:
http-request redirect code 302 prefix
http://%[req.hdr(host),map_str(map_redirects.lst)] if {
req.hdr(Host),map_str(map_redirects.lst) -m found }
Content of map_redirects.lst:
domain2.com subdomain.domain1.com
If the domain is not listed, then HAProxy will return a 503.
Here are some results:
GET http://127.0.0.1:8080/ -H Host: domain2.com
HTTP/1.1 302 Found
Cache-Control: no-cache
Content-length: 0
Location: http://subdomain.domain1.com/
Connection: close
GET http://127.0.0.1:8080/blah -H Host: domain2.com
HTTP/1.1 302 Found
Cache-Control: no-cache
Content-length: 0
Location: http://subdomain.domain1.com/blah
Connection: close
GET http://127.0.0.1:8080/ -H Host: domain1.com
HTTP/1.0 503 Service Unavailable
Cache-Control: no-cache
Connection: close
Content-Type: text/html
The content of the map can be updated through the HAProxy socket
or
though HTTP headers.
Read the manual to know how.
Bear in mind HAProxy will reset its memory with the content of
the
file when reloading. So it's up to you to sync the memory of
HAProxy
and the content of the file.
Baptiste
On Thu, May 22, 2014 at 11:08 PM, Matt . yamakasi@gmail.com
wrote:
Babtiste,
I'm not able to find any solution to add such rewrites, am I
looking
wrong ?
Cheers,
Matt
2014-05-22 16:37 GMT+02:00 Matt . yamakasi@gmail.com:
Hi,
That is nice, is that in the development version ? I didn't
see
it
in
1.4
as I'm right.
I need to forward domain2.com to subdomain.domain1.com
and subdomain.domain1.com may be a various of webservers that
serve
that
content.
Thanks!
Matt
Re: Error 408 with Chrome
Hi Willy, same problem here with Chrome version 35.0.1916.114 m and : HA-Proxy version 1.4.22 2012/08/09 (Debian 6) Kernel 3.8.13-OVH HA-Proxy version 1.5-dev24-8860dcd 2014/04/26 (Debian GNU/Linux 7.5) Kernel 3.10.13-OVH htmlbodyh1408 Request Time-out/h1 Your browser didn't send a complete request in time. /body/html Timing : Blocking 2ms / Receiving : 1ms Response header: HTTP/1.0 408 Request Time-out Cache-Control: no-cache Connection: close Content-Type: text/html Haproxy cfg: defaults mode http logglobal option dontlognull option redispatch retries3 timeout connect5s timeout client 20s timeout server 20s timeout http-request 5s timeout http-keep-alive 5s timeout check 4s timeout queue 15s option abortonclose option httplog option http-keep-alive option forwardfor except 127.0.0.0/8 Haproxy 1.5 : Didn't have time to setup log for now, will provide asap. Haproxy 1.4 : nothing in log (maybe due to dontlognull ?) If i bypass Haproxy no more 408. Thanks. Arnaud. Le 23/05/2014 16:08, Willy Tarreau a écrit : Hi Kevin, [guys, please could you stop top-posting, it's a total mess to try to respond to this thread, I cannot easily take out the useless parts, thanks]. On Fri, May 23, 2014 at 02:35:21PM +0200, Kevin Maziere wrote: 2014-05-23 14:34 GMT+02:00 Baptiste bed...@gmail.com: Kevin, Do you (still) see 408 errors printed in the browser??? Baptiste On Fri, May 23, 2014 at 2:17 PM, Kevin Maziere ke...@kbrwadventure.com wrote: Hi I've just applied the first patch, here are the debug log : In the logs : 2014-05-23T12:03:20+00:00 images-access haproxy[13409]: 127.0.0.1:56596 [23/May/2014:12:03:17.972] ipv4-yyy-443~ ipv4-yyy-443/NOSRV -1/-1/-1/-1/2041 408 212 - - cR-- 9/3/0/0/0 0/0 BADREQ Well, here I'm seeing a standard 408 after 2 seconds which should match a timeout http-request of 2 seconds. Can you check if you don't have one ? Also, this observation from the logs doesn't seem consistent with your first claim that the 408 is immediate, here it's only after 2 seconds. Or again we are facing this bogus preconnect feature of Chrome. People complain all the time that not only it connects before you want to go to the site, but above all it displays the error that it receives without checking that it got an error prior to using the connection :-( In the debug log, correspond lines: 2014-05-23T12:03:20+00:00 servername haproxy[13409]: Timeout detected: fe=ipv4-yyy-443 s-flags=0080 txn-flags= req-flags=00c88000 msg-flags= now_ms=687261517 req-analyse_exp=687261515 (-2) At least that's good, it's the first request of the connection and nothing except the regular request timeout occurred. There was an interesting thread here about the nasty behaviour of chrome : https://code.google.com/p/chromium/issues/detail?id=85229#c33 Some people suggest closing without ever emitting the 408. You can do that this way : errorfile 408 /dev/null Note that this fantastic browser breaks HTTP by preventing any server from using the well-defined HTTP status code indicating a timeout occurred. Kévin, I think the reason why you have the issue only on one OS is not related to the OS but to your browsing history on that system. The browser doesn't pre-connect there and you don't have the trouble. Regards, Willy
Re: Error 408 with Chrome
2014-05-26 11:56 GMT+02:00 Arnall arnall2...@gmail.com: Hi Willy, same problem here with Chrome version 35.0.1916.114 m and : HA-Proxy version 1.4.22 2012/08/09 (Debian 6) Kernel 3.8.13-OVH HA-Proxy version 1.5-dev24-8860dcd 2014/04/26 (Debian GNU/Linux 7.5) Kernel 3.10.13-OVH Hello, Just to say that I experience the same issue. Customers reported 408 errors with Chrome, and this error was delivered instantly. No bug with another browser. There were no error a few weeks ago with exactly the same config / same HAProxy binary, that's why I'm pretty sure Chrome changed its behaviour for pre-connect. My timeout parameters are as follow : timeout connect 5s timeout http-keep-alive 5s timeout http-request 10s HAProxy version is 1.5-dev18. I've increased the http-request timeout to 60 seconds and it seems to fix the issue, but it is not a good fix Some people suggest closing without ever emitting the 408. You can do that this way : errorfile 408 /dev/null I'll try this today. Olivier
Re: Error 408 with Chrome
2014-05-26 12:05 GMT+02:00 Olivier webmas...@ajeux.com: 2014-05-26 11:56 GMT+02:00 Arnall arnall2...@gmail.com: Hi Willy, same problem here with Chrome version 35.0.1916.114 m and : HA-Proxy version 1.4.22 2012/08/09 (Debian 6) Kernel 3.8.13-OVH HA-Proxy version 1.5-dev24-8860dcd 2014/04/26 (Debian GNU/Linux 7.5) Kernel 3.10.13-OVH Hello, Just to say that I experience the same issue. Customers reported 408 errors with Chrome, and this error was delivered instantly. No bug with another browser. There were no error a few weeks ago with exactly the same config / same HAProxy binary, that's why I'm pretty sure Chrome changed its behaviour for pre-connect. My timeout parameters are as follow : timeout connect 5s timeout http-keep-alive 5s timeout http-request 10s HAProxy version is 1.5-dev18. I've increased the http-request timeout to 60 seconds and it seems to fix the issue, but it is not a good fix Some people suggest closing without ever emitting the 408. You can do that this way : errorfile 408 /dev/null I'll try this today. I continu to see 408 in logs but no more in browser with this errorfile set to /dev/null... for the moment it fix the problem for me. Olivier
Re: Configuring HAProxy to send X_FORWARDED_FOR and X_REAL_IP at the same time.
Hi, On 26.05.2014 12:16, Daniel Todorov wrote: Hello Baptiste, can i extract the info from other header, because we using cloudflare infront of HAProxy? You can also do things like, -- http-request add-header X-Orig-IP %[req.hdr(X-Forwarded-For)] -- this would add header X-Orig-IP with the values from X-Forwarded-For Best Regards, On Mon, May 26, 2014 at 12:15 PM, Baptiste bed...@gmail.com mailto:bed...@gmail.com wrote: On Mon, May 26, 2014 at 10:03 AM, Daniel Todorov leinad...@gmail.com mailto:leinad...@gmail.com wrote: Hello, I'm working for company which have software based on both headers, and if one of them is missing, the software is not working properly. I find a way to configure HAProxy to send each of them but separated. I need to find solution which will make HAProxy to send both. Can I use reqadd or http-request add-header/set-header to set a the second header? Best Regards, Daniel Todorov Hi Daniel Yes, you can use http-request add-header to add headers. You can extract source IP address using the acl 'src'. Baptiste
Re: Error 408 with Chrome
Some people suggest closing without ever emitting the 408. You can do that this way : errorfile 408 /dev/null I'll try this today. I continu to see 408 in logs but no more in browser with this errorfile set to /dev/null... for the moment it fix the problem for me. Excellent This is normal that HAProxy keeps on logging the error. Baptiste
Re: [BUG] Buffer overrun in exp_replace()
On Sat, May 24, 2014 at 10:37 PM, Sasha Pachev sa...@asksasha.com wrote:
Currently exp_replace() (which is used in reqrep/reqirep) is
vulnerable to a buffer overrun. I have been able to reproduce it using
the attached configuration file and issuing the following command:
wget -O - -S -q http://localhost:8000/`perl -e 'print ax4000'`/cookie.php
The other attachment contains the proposed fix. Since I was fixing up
exp_replace() I also added two improvements/fixes:
- str was being checked only in in while (str) and it was possible to
read past that when more than one character was being accessed in the
loop
- I need exp_replace() to support str not necessarily being
NULL-terminated for the replace-header/modify-header feature, so I
added str_len argument which can be set to 0, in which case it is
determined with a call to strlen()
Attached is an improved patch. The following errors are corrected:
- not properly checking for buffer overrun before memcpy() in ext_replace
- when the buffer overrun was detected, the filtering of the headers
continued normally. The patch terminates the filtering by returning -1
from apply_filter_* functions
- the original patch did not distinguish between replacing with an
empty string and a buffer overrun
--
Sasha Pachev
Fast Running Blog.
http://fastrunningblog.com
Run. Blog. Improve. Repeat.
diff --git a/include/common/regex.h b/include/common/regex.h
index 9789ec3..89e6506 100644
--- a/include/common/regex.h
+++ b/include/common/regex.h
@@ -79,7 +79,9 @@ extern regmatch_t pmatch[MAX_MATCH];
* The function return 1 is succes case, else return 0 and err is filled.
*/
int regex_comp(const char *str, struct my_regex *regex, int cs, int cap, char **err);
-int exp_replace(char *dst, char *src, const char *str, const regmatch_t *matches);
+int exp_replace(char *dst, uint dst_size, char *src, const char *str, uint str_len,
+ const regmatch_t *matches);
+
const char *check_replace_string(const char *str);
const char *chain_regex(struct hdr_exp **head, const regex_t *preg,
int action, const char *replace, void *cond);
diff --git a/src/proto_http.c b/src/proto_http.c
index bd6d024..7e6e79f 100644
--- a/src/proto_http.c
+++ b/src/proto_http.c
@@ -235,6 +235,10 @@ struct chunk http_err_chunks[HTTP_ERR_SIZE];
/* this struct is used between calls to smp_fetch_hdr() or smp_fetch_cookie() */
static struct hdr_ctx static_hdr_ctx;
+#define CHECK_ACT_REPLACE if (trash.len == -1) {\
+ Alert(Buffer overrun or invalid expr processing ACT_REPLACE '%s', exp-replace);\
+ return -1; }
+
#define FD_SETS_ARE_BITFIELDS
#ifdef FD_SETS_ARE_BITFIELDS
/*
@@ -6817,7 +6821,8 @@ int apply_filter_to_req_headers(struct session *s, struct channel *req, struct h
break;
case ACT_REPLACE:
-trash.len = exp_replace(trash.str, cur_ptr, exp-replace, pmatch);
+trash.len = exp_replace(trash.str, trash.size, cur_ptr, exp-replace, 0, pmatch);
+CHECK_ACT_REPLACE;
delta = buffer_replace2(req-buf, cur_ptr, cur_end, trash.str, trash.len);
/* FIXME: if the user adds a newline in the replacement, the
* index will not be recalculated for now, and the new line
@@ -6927,7 +6932,8 @@ int apply_filter_to_req_line(struct session *s, struct channel *req, struct hdr_
case ACT_REPLACE:
*cur_end = term; /* restore the string terminator */
- trash.len = exp_replace(trash.str, cur_ptr, exp-replace, pmatch);
+ trash.len = exp_replace(trash.str, trash.size, cur_ptr, exp-replace, 0, pmatch);
+ CHECK_ACT_REPLACE;
delta = buffer_replace2(req-buf, cur_ptr, cur_end, trash.str, trash.len);
/* FIXME: if the user adds a newline in the replacement, the
* index will not be recalculated for now, and the new line
@@ -7676,7 +7682,8 @@ int apply_filter_to_resp_headers(struct session *s, struct channel *rtr, struct
break;
case ACT_REPLACE:
-trash.len = exp_replace(trash.str, cur_ptr, exp-replace, pmatch);
+trash.len = exp_replace(trash.str, trash.size, cur_ptr, exp-replace, 0, pmatch);
+CHECK_ACT_REPLACE;
delta = buffer_replace2(rtr-buf, cur_ptr, cur_end, trash.str, trash.len);
/* FIXME: if the user adds a newline in the replacement, the
* index will not be recalculated for now, and the new line
@@ -7766,7 +7773,8 @@ int apply_filter_to_sts_line(struct session *s, struct channel *rtr, struct hdr_
case ACT_REPLACE:
*cur_end = term; /* restore the string terminator */
- trash.len = exp_replace(trash.str, cur_ptr, exp-replace, pmatch);
+ trash.len = exp_replace(trash.str, trash.size, cur_ptr, exp-replace, 0, pmatch);
+ CHECK_ACT_REPLACE;
delta = buffer_replace2(rtr-buf, cur_ptr, cur_end, trash.str, trash.len);
/* FIXME: if the user adds a newline in the replacement, the
* index will not be recalculated for now, and the new line
@@ -7847,7 +7855,8 @@ int apply_filters_to_response(struct session *s, struct channel *rtr, struct pro
/* The filter did not match the response, it can be
Re: Error 408 with Chrome
Hi Arnall,
On Mon, May 26, 2014 at 11:56:52AM +0200, Arnall wrote:
Hi Willy,
same problem here with Chrome version 35.0.1916.114 m and :
HA-Proxy version 1.4.22 2012/08/09 (Debian 6) Kernel 3.8.13-OVH
HA-Proxy version 1.5-dev24-8860dcd 2014/04/26 (Debian GNU/Linux 7.5)
Kernel 3.10.13-OVH
htmlbodyh1408 Request Time-out/h1
Your browser didn't send a complete request in time.
/body/html
Timing : Blocking 2ms / Receiving : 1ms
Where are you measuring this ? I suspect on the browser, right ? In
this case it confirms the malfunction of the preconnect. You should
take a network capture which will be usable as a reliable basis for
debugging. I'm pretty sure that what you'll see in fact is the following
sequence :
browser haproxy
--- connect --
... long pause ...
408 + FIN ---
... long pause ...
--- send request -
RST -
And you see the error in the browser immediately. The issue is then
caused by the browser not respecting this specific rule :
http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-26#section-6.5
A client or server that wishes to time-out SHOULD issue a graceful
close on the connection. Implementations SHOULD constantly monitor
open connections for a received closure signal and respond to it as
appropriate, since prompt closure of both sides of a connection
enables allocated system resources to be reclaimed.
...
A client sending a message body SHOULD monitor the network connection
for an error response while it is transmitting the request. If the
client sees a response that indicates the server does not wish to
receive the message body and is closing the connection, the client
SHOULD immediately cease transmitting the body and close its side of
the connection.
Anyway, from the various reports we get, it seems like sending an empty
408 message is enough to workaround this abnormal Chrome behaviour. For
this you can proceed like this :
errorfile 408 /dev/null
Note however that it breaks HTTP in that it prevents client from knowing
whether the request was processed or not. The 408 message provides *exactly*
this information :
http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-26#section-6.5.7
The 408 (Request Timeout) status code indicates that the server did
not receive a complete request message within the time that it was
prepared to wait. A server SHOULD send the close connection option
(Section 6.1 of [Part1]) in the response, since 408 implies that the
server has decided to close the connection rather than continue
waiting. If the client has an outstanding request in transit, the
client MAY repeat that request on a new connection.
With only a silent close (as Chrome seems to expect it), the client cannot
reasonably retry without violating a strict HTTP rule :
http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-26#section-6.3.1
A user agent MUST NOT automatically retry a request with a non-
idempotent method unless it has some means to know that the request
semantics are actually idempotent, regardless of the method, or some
means to detect that the original request was never applied.
Regards,
Willy
Rewrite domain.com to other domain.com/dir/subdir
Hi All, In order to my earlier topic about redirecting a domainname I actually want to rewrite one too. Let's says I have domainname2.com and I want to show domainname.com/dir/subdir under that domain, can this be done with reqrep ? It seems that this is the way, but I cannot find any example that does so. Do I also need the forward option ? Thanks! Matt
Re: What is hrsp_5xx for a frontend?
On Sat, May 24, 2014 at 08:40:35AM -0400, Dan Crosta wrote: I'm a little confused about what exactly creates a 5xx response code from HAProxy. I think that if the backend generates a 5xx response, this will show up as a frontend_5xx, and I expect that the value of the hrsp_5xx stat for the frontend should equal the sum of the hrsp_5xx values from the backends. However, this doesn't jive with what we actually see in the statistics output: $ curl -s http://10.1.99.106:8080/haproxy?stats;csv;norefresh; | tr , | cut -f 1,2,44 | head -n 19 # pxname svnamehrsp_5xx myfrontendFRONTEND 10797124 mybackend host001 24364 mybackend host002 17260 mybackend host003 25250 mybackend host004 15135 mybackend host005 17364 mybackend host006 24541 mybackend host007 11422 mybackend host008 14199 mybackend host009 13274 mybackend host010 12797 mybackend host011 24532 mybackend host012 23599 mybackend host013 31728 mybackend host014 24607 mybackend host015 14851 mybackend host016 13937 mybackend BACKEND 10797124 The sum of the hrsp_5xx's for each of the individual backends is 308860, while both the FRONTEND and BACKEND numbers are about 30 times as much. Am I missing something obvious? Does HAProxy ever generate 5xx responses itself, either in the backend or frontend? Is there some more detailed logging we should enable to track this down? Yes it can generate 5xx when it cannot deliver the request somewhere. For example if you're running with many use_backend rules and no default_backend, it's possible that a number of requests en up going nowhere and are rejected as 503. In your case since we're seeing the same number in the frontend and in the backend and you have much less errors on the servers themselves, that can be explained by 503 when the queue is overflown (requests that are never served because of too low a server maxconn value, too short queue timeouts, or too long server response times). Hoping this helps, Willy
Re: Some thoughts about redispatch
On 28 нояб. 2012 г., at 18:10, Dmitry Sivachenko trtrmi...@gmail.com wrote: Hello! If haproxy can't send a request to the backend server, it will retry the same backend 'retries' times waiting 1 second between retries, and if 'option redispatch' is used, the last retry will go to another backend. There is (I think very common) usage scenario when 1) all requests are independent of each other and all backends are equal, so there is no need to try to route requests to the same backend (if it failed, we will try dead one again and again while another backend could serve the request right now) 2) there is response time policy for requests and 1 second wait time is just too long (all requests are handled faster than 500ms and client software will not wait any longer). I propose to introduce new parameters in config file: 1) redispatch always: when set, haproxy will always retry different backend after connection to the first one fails. 2) Allow to override 1 second wait time between redispatches in config file (including the value of 0 == immediate). Right now I use the attached patch to overcome these restrictions. It is ugly hack right now, but if you could include it into distribution in better form with tuning via config file I think everyone would benefit from it. Thanks. redispatch.txt On 26 мая 2014 г., at 18:21, Willy Tarreau w...@1wt.eu wrote: I think it definitely makes some sense. Probably not in its exact form but as something to work on. In fact, I think we should only apply the 1s retry delay when remaining on the same server, and avoid as much a possible to remain on the same server. For hashes or when there's a single server, we have no choice, but when doing round robin for example, we can pick another one. This is especially true for static servers or ad servers for example where fastest response time is preferred over sticking to the same server. Yes, that was exactly my point. In many situations it is better to ask another server immediately to get fastest response rather than trying to stick to the same server as much as possible. Thanks, Willy
Re: Some thoughts about redispatch
On Mon, May 26, 2014 at 06:28:33PM +0400, Dmitry Sivachenko wrote: On 28 . 2012 ?., at 18:10, Dmitry Sivachenko trtrmi...@gmail.com wrote: Hello! If haproxy can't send a request to the backend server, it will retry the same backend 'retries' times waiting 1 second between retries, and if 'option redispatch' is used, the last retry will go to another backend. There is (I think very common) usage scenario when 1) all requests are independent of each other and all backends are equal, so there is no need to try to route requests to the same backend (if it failed, we will try dead one again and again while another backend could serve the request right now) 2) there is response time policy for requests and 1 second wait time is just too long (all requests are handled faster than 500ms and client software will not wait any longer). I propose to introduce new parameters in config file: 1) redispatch always: when set, haproxy will always retry different backend after connection to the first one fails. 2) Allow to override 1 second wait time between redispatches in config file (including the value of 0 == immediate). Right now I use the attached patch to overcome these restrictions. It is ugly hack right now, but if you could include it into distribution in better form with tuning via config file I think everyone would benefit from it. Thanks. redispatch.txt On 26 ??? 2014 ?., at 18:21, Willy Tarreau w...@1wt.eu wrote: I think it definitely makes some sense. Probably not in its exact form but as something to work on. In fact, I think we should only apply the 1s retry delay when remaining on the same server, and avoid as much a possible to remain on the same server. For hashes or when there's a single server, we have no choice, but when doing round robin for example, we can pick another one. This is especially true for static servers or ad servers for example where fastest response time is preferred over sticking to the same server. Yes, that was exactly my point. In many situations it is better to ask another server immediately to get fastest response rather than trying to stick to the same server as much as possible. Yes, I think we can reduce the total number of retries this way, it will be divided by #retries on average. It means that the logs will be inaccurate about what server experienced a retry, but they are already inaccurate when a redispatch happens anyway. I don't think anyone has a specific use case relying retries being performed on the same server for non-sticky connections. So I think we could work on improving this. Anyone has an opinion on this ? Thanks, Willy
Stick tables
Hi, I'm implementing something similar to cloud flare IUAM (javascript based client verification engaging under layer7 ddos attack) Is it normal that http table exp counter gets updated even if src address is whitelisted sc1_get_gpc0(backend) 0 ? Is it possible to force expire an entry using an acl ? Is it possible to define multiple stick tables storing gpc0 in a single frontend, now it's using one from the frontend and one from the backend but how to define sc2 without adding another backend ? config follows backend backend stick-table type ip size 1m expire 10m store gpc0 tcp-request content track-sc1 src if !whitelist acl flag_fail sc0_inc_gpc0(http) ge 0 acl flag_ok sc1_inc_gpc0(backend) ge 0 acl rm_black src_clr_gpc0(http) ge 0 acl whitelist sc1_get_gpc0(backend) gt 0 acl blacklist_candidate sc0_get_gpc0(http) gt 0 #send chalanges if session rate 500 acl normal_rate be_sess_rate lt 500 #checks if chalange response is correct acl cauth_ok cookie_auth #add to whitelist if chalange response is correct http-request allow if whitelist or cauth_ok flag_ok rm_black #send javascript chalange http-request cookie_auth if !auth_ok !normal_rate flag_fail http-request cookie_auth if !auth_ok blacklist_candidate flag_fail frontend http bind 0.0.0.0:8080 stick-table type ip size 1m expire 20m store gpc0 acl flag_fail sc0_inc_gpc0(http) ge 0 acl blacklist sc0_get_gpc0(http) gt 500 acl whitelist sc1_get_gpc0(backend) gt 0 tcp-request connection track-sc0 src if ! whitelist tcp-request connection reject if blacklist flag_fail Thanks, Michal Grzedzicki
Re: Rewrite domain.com to other domain.com/dir/subdir
On Mon, May 26, 2014 at 4:15 PM, Matt . yamakasi@gmail.com wrote: Hi All, In order to my earlier topic about redirecting a domainname I actually want to rewrite one too. Let's says I have domainname2.com and I want to show domainname.com/dir/subdir under that domain, can this be done with reqrep ? It seems that this is the way, but I cannot find any example that does so. Do I also need the forward option ? Thanks! Matt Hi Matt, You have to do a couple of reqirep/reqrep. One for the Host header, one for the URL path. Baptiste
Re: Rewrite domain.com to other domain.com/dir/subdir
Hi Baptiste, OK, I also have seen examples (not for domains as I need them) that use ACL's in front. Waht do you think about that and can you give me some example ? It's kinda confusing what I found using google and mailinglists. Cheers, Matt 2014-05-26 17:22 GMT+02:00 Baptiste bed...@gmail.com: On Mon, May 26, 2014 at 4:15 PM, Matt . yamakasi@gmail.com wrote: Hi All, In order to my earlier topic about redirecting a domainname I actually want to rewrite one too. Let's says I have domainname2.com and I want to show domainname.com/dir/subdir under that domain, can this be done with reqrep ? It seems that this is the way, but I cannot find any example that does so. Do I also need the forward option ? Thanks! Matt Hi Matt, You have to do a couple of reqirep/reqrep. One for the Host header, one for the URL path. Baptiste
Sistema de Información Gerencial Integral - BALANCED SCORECARD
Sistema de Información GERENCIAL INTEGRAL - BALANCED SCORECARDBogotá 26 de junio, 2014 Los altos Ejecutivos de las empresas globales dirigen organizaciones de proporciones enormes y utilizan el Balanced Scorecard para planear, evaluar y “balancear” estratégicamente la visión con los objetivos de la empresa, integrando equipos gerenciales capaces de lograr resultados sobresalientes. Esta revolucionaria metodología ayudará a los Directores y Ejecutivos a pensar más ampliamente sobre lo que significa hoy el verdadero liderazgo en los negocios...Para ampliar información y recibir los beneficios de inscripción temprana responda este correo con los siguientes datos:Nombre: Empresa: Ciudad: Teléfono: Email: "Garantizamos total confidencialidad y privacidad de sus datos" Linea Gratuita Nacional: 018000 51 30 51¿Desea dejar de recibir estos emails? Responda con el asunto dejar
Re: Error 408 with Chrome
Le 26/05/2014 16:13, Willy Tarreau a écrit : Hi Arnall, On Mon, May 26, 2014 at 11:56:52AM +0200, Arnall wrote: Hi Willy, same problem here with Chrome version 35.0.1916.114 m and : HA-Proxy version 1.4.22 2012/08/09 (Debian 6) Kernel 3.8.13-OVH HA-Proxy version 1.5-dev24-8860dcd 2014/04/26 (Debian GNU/Linux 7.5) Kernel 3.10.13-OVH htmlbodyh1408 Request Time-out/h1 Your browser didn't send a complete request in time. /body/html Timing : Blocking 2ms / Receiving : 1ms Where are you measuring this ? I suspect on the browser, right ? In this case it confirms the malfunction of the preconnect. You should take a network capture which will be usable as a reliable basis for debugging. I'm pretty sure that what you'll see in fact is the following sequence : browser haproxy --- connect -- ... long pause ... 408 + FIN --- ... long pause ... --- send request - RST - And you see the error in the browser immediately. The issue is then caused by the browser not respecting this specific rule : Yes it was measured on the browser (Chrome network monitor) I 've made a network capture for you.(in attachment) Thanks. Arnaud. chrome_haproxy_error408.pcap Description: Binary data
Re: Error 408 with Chrome
On Mon, May 26, 2014 at 05:52:15PM +0200, Arnall wrote: Le 26/05/2014 16:13, Willy Tarreau a écrit : Hi Arnall, On Mon, May 26, 2014 at 11:56:52AM +0200, Arnall wrote: Hi Willy, same problem here with Chrome version 35.0.1916.114 m and : HA-Proxy version 1.4.22 2012/08/09 (Debian 6) Kernel 3.8.13-OVH HA-Proxy version 1.5-dev24-8860dcd 2014/04/26 (Debian GNU/Linux 7.5) Kernel 3.10.13-OVH htmlbodyh1408 Request Time-out/h1 Your browser didn't send a complete request in time. /body/html Timing : Blocking 2ms / Receiving : 1ms Where are you measuring this ? I suspect on the browser, right ? In this case it confirms the malfunction of the preconnect. You should take a network capture which will be usable as a reliable basis for debugging. I'm pretty sure that what you'll see in fact is the following sequence : browser haproxy --- connect -- ... long pause ... 408 + FIN --- ... long pause ... --- send request - RST - And you see the error in the browser immediately. The issue is then caused by the browser not respecting this specific rule : Yes it was measured on the browser (Chrome network monitor) I 've made a network capture for you.(in attachment) Thank you. If you looked at the connection from port 62691, it's exactly the sequence I described above. So that clearly explains what Chrome is the only one affected! Best regards, Willy
Re: [BUG] Buffer overrun in exp_replace()
Hi Sasha,
On Mon, May 26, 2014 at 07:51:38AM -0600, Sasha Pachev wrote:
On Sat, May 24, 2014 at 10:37 PM, Sasha Pachev sa...@asksasha.com wrote:
Currently exp_replace() (which is used in reqrep/reqirep) is
vulnerable to a buffer overrun. I have been able to reproduce it using
the attached configuration file and issuing the following command:
wget -O - -S -q http://localhost:8000/`perl -e 'print ax4000'`/cookie.php
The other attachment contains the proposed fix. Since I was fixing up
exp_replace() I also added two improvements/fixes:
- str was being checked only in in while (str) and it was possible to
read past that when more than one character was being accessed in the
loop
- I need exp_replace() to support str not necessarily being
NULL-terminated for the replace-header/modify-header feature, so I
added str_len argument which can be set to 0, in which case it is
determined with a call to strlen()
Attached is an improved patch. The following errors are corrected:
- not properly checking for buffer overrun before memcpy() in ext_replace
- when the buffer overrun was detected, the filtering of the headers
continued normally. The patch terminates the filtering by returning -1
from apply_filter_* functions
- the original patch did not distinguish between replacing with an
empty string and a buffer overrun
Thank you. I'm having some comments about the patch itself below :
diff --git a/src/proto_http.c b/src/proto_http.c
index bd6d024..7e6e79f 100644
--- a/src/proto_http.c
+++ b/src/proto_http.c
@@ -235,6 +235,10 @@ struct chunk http_err_chunks[HTTP_ERR_SIZE];
/* this struct is used between calls to smp_fetch_hdr() or smp_fetch_cookie()
*/
static struct hdr_ctx static_hdr_ctx;
+#define CHECK_ACT_REPLACE if (trash.len == -1) {\
+ Alert(Buffer overrun or invalid expr processing ACT_REPLACE '%s',
exp-replace);\
+ return -1; }
+
Please avoid defining macros for such control blocks, especially when
involve implicit local variables and can cause returns, it's always
harder to follow and when checking for unrelated bugs, they tend to
be disturbing. I know we already do it with CHECK_HTTP_MESSAGE_FIRST(),
but it's used a lot more, something like 25 times or so. And even then
it's annoying when you have to single-step through it.
Another point is that nobody will ever see this alert, so in practice better
not even send it and just ensure that the function fails so that the rules
processing is aborted and an error is returned. I guess -1 already grants
this given that you added the control in your patch. So that could simply
result in adding this at the four places where you used CHECK_ACT_REPLACE :
if (trash.len 0)
return -1;
@@ -6817,7 +6821,8 @@ int apply_filter_to_req_headers(struct session *s, struct
channel *req, struct h
break;
case ACT_REPLACE:
- trash.len = exp_replace(trash.str, cur_ptr,
exp-replace, pmatch);
+ trash.len = exp_replace(trash.str, trash.size,
cur_ptr, exp-replace, 0, pmatch);
+ CHECK_ACT_REPLACE;
delta = buffer_replace2(req-buf, cur_ptr,
cur_end, trash.str, trash.len);
/* FIXME: if the user adds a newline in the
replacement, the
* index will not be recalculated for now, and
the new line
(...)
diff --git a/src/regex.c b/src/regex.c
index 7a76940..b93c61d 100644
--- a/src/regex.c
+++ b/src/regex.c
@@ -22,14 +22,26 @@
/* regex trash buffer used by various regex tests */
regmatch_t pmatch[MAX_MATCH]; /* rm_so, rm_eo for regular expressions */
+#define STR_CHECK if (str = str_end) return -1
+#define DST_CHECK if (dst = dst_end) return -1
+#define DST_LEN_CHECK(l) if (dst + l = dst_end) return -1
Same here, please put these statements directly, it's really hard to follow
what test is being done on them when reading the code. Also, such constructs
with a hidden if are really dangerous because they can change the meaning
of a following else. For example, let's consider this totally made up example :
if (dst)
DST_CHECK;
else
dst = src;
It does not do what it seems, in fact it does this :
if (dst)
if (dst = dst_end)
return -1;
else
dst = src;
That's why we usually employ the do { } while (0) construct in macros.
But here it's really not justified.
Another point concerning the code's efficiency, for the source I believe
you should stick to the *str test instead of str str_end for 3 reasons :
- everywhere it's tested, the following instruction is a fetch of *str,
so the same register will be reused ;
- on machines with low number of registers (eg: x86), it will avoid
moving variables back and forth to the stack.
- it
Re: [BUG] Buffer overrun in exp_replace()
Please avoid defining macros for such control blocks, especially when involve implicit local variables and can cause returns, it's always harder to follow and when checking for unrelated bugs, they tend to be disturbing. I know we already do it with CHECK_HTTP_MESSAGE_FIRST(), but it's used a lot more, something like 25 times or so. And even then it's annoying when you have to single-step through it. Another point is that nobody will ever see this alert, so in practice better not even send it and just ensure that the function fails so that the rules processing is aborted and an error is returned. I guess -1 already grants this given that you added the control in your patch. So that could simply result in adding this at the four places where you used CHECK_ACT_REPLACE : if (trash.len 0) return -1; Another point concerning the code's efficiency, for the source I believe you should stick to the *str test instead of str str_end for 3 reasons : - everywhere it's tested, the following instruction is a fetch of *str, so the same register will be reused ; - on machines with low number of registers (eg: x86), it will avoid moving variables back and forth to the stack. - it avoids having to run over the whole input string twice (once for strlen() and a second time for the actual work). Willy: I am attaching a patch that incorporates your revisions. -- Sasha Pachev Fast Running Blog. http://fastrunningblog.com Run. Blog. Improve. Repeat. diff --git a/include/common/regex.h b/include/common/regex.h index 9789ec3..63689af 100644 --- a/include/common/regex.h +++ b/include/common/regex.h @@ -79,7 +79,7 @@ extern regmatch_t pmatch[MAX_MATCH]; * The function return 1 is succes case, else return 0 and err is filled. */ int regex_comp(const char *str, struct my_regex *regex, int cs, int cap, char **err); -int exp_replace(char *dst, char *src, const char *str, const regmatch_t *matches); +int exp_replace(char *dst, uint dst_size, char *src, const char *str, const regmatch_t *matches); const char *check_replace_string(const char *str); const char *chain_regex(struct hdr_exp **head, const regex_t *preg, int action, const char *replace, void *cond); diff --git a/src/proto_http.c b/src/proto_http.c index bd6d024..88e27e2 100644 --- a/src/proto_http.c +++ b/src/proto_http.c @@ -6817,7 +6817,11 @@ int apply_filter_to_req_headers(struct session *s, struct channel *req, struct h break; case ACT_REPLACE: -trash.len = exp_replace(trash.str, cur_ptr, exp-replace, pmatch); +trash.len = exp_replace(trash.str, trash.size, cur_ptr, exp-replace, pmatch); + +if (trash.len 0) + return -1; + delta = buffer_replace2(req-buf, cur_ptr, cur_end, trash.str, trash.len); /* FIXME: if the user adds a newline in the replacement, the * index will not be recalculated for now, and the new line @@ -6927,7 +6931,11 @@ int apply_filter_to_req_line(struct session *s, struct channel *req, struct hdr_ case ACT_REPLACE: *cur_end = term; /* restore the string terminator */ - trash.len = exp_replace(trash.str, cur_ptr, exp-replace, pmatch); + trash.len = exp_replace(trash.str, trash.size, cur_ptr, exp-replace, pmatch); + + if (trash.len 0) +return -1; + delta = buffer_replace2(req-buf, cur_ptr, cur_end, trash.str, trash.len); /* FIXME: if the user adds a newline in the replacement, the * index will not be recalculated for now, and the new line @@ -7676,7 +7684,11 @@ int apply_filter_to_resp_headers(struct session *s, struct channel *rtr, struct break; case ACT_REPLACE: -trash.len = exp_replace(trash.str, cur_ptr, exp-replace, pmatch); +trash.len = exp_replace(trash.str, trash.size, cur_ptr, exp-replace, pmatch); + +if (trash.len 0) + return -1; + delta = buffer_replace2(rtr-buf, cur_ptr, cur_end, trash.str, trash.len); /* FIXME: if the user adds a newline in the replacement, the * index will not be recalculated for now, and the new line @@ -7766,7 +7778,11 @@ int apply_filter_to_sts_line(struct session *s, struct channel *rtr, struct hdr_ case ACT_REPLACE: *cur_end = term; /* restore the string terminator */ - trash.len = exp_replace(trash.str, cur_ptr, exp-replace, pmatch); + trash.len = exp_replace(trash.str, trash.size, cur_ptr, exp-replace, pmatch); + + if (trash.len 0) +return -1; + delta = buffer_replace2(rtr-buf, cur_ptr, cur_end, trash.str, trash.len); /* FIXME: if the user adds a newline in the replacement, the * index will not be recalculated for now, and the new line @@ -7847,7 +7863,8 @@ int apply_filters_to_response(struct session *s, struct channel *rtr, struct pro /* The filter did not match the response, it can be * iterated through all headers. */ - apply_filter_to_resp_headers(s, rtr, exp); + if (unlikely(apply_filter_to_resp_headers(s, rtr, exp) 0)) +return -1; } } return 0;
Re: Error 408 with Chrome
On Mon, May 26, 2014 at 6:07 PM, Willy Tarreau w...@1wt.eu wrote: On Mon, May 26, 2014 at 05:52:15PM +0200, Arnall wrote: Le 26/05/2014 16:13, Willy Tarreau a écrit : Hi Arnall, On Mon, May 26, 2014 at 11:56:52AM +0200, Arnall wrote: Hi Willy, same problem here with Chrome version 35.0.1916.114 m and : HA-Proxy version 1.4.22 2012/08/09 (Debian 6) Kernel 3.8.13-OVH HA-Proxy version 1.5-dev24-8860dcd 2014/04/26 (Debian GNU/Linux 7.5) Kernel 3.10.13-OVH htmlbodyh1408 Request Time-out/h1 Your browser didn't send a complete request in time. /body/html Timing : Blocking 2ms / Receiving : 1ms Where are you measuring this ? I suspect on the browser, right ? In this case it confirms the malfunction of the preconnect. You should take a network capture which will be usable as a reliable basis for debugging. I'm pretty sure that what you'll see in fact is the following sequence : browser haproxy --- connect -- ... long pause ... 408 + FIN --- ... long pause ... --- send request - RST - And you see the error in the browser immediately. The issue is then caused by the browser not respecting this specific rule : Yes it was measured on the browser (Chrome network monitor) I 've made a network capture for you.(in attachment) Thank you. If you looked at the connection from port 62691, it's exactly the sequence I described above. So that clearly explains what Chrome is the only one affected! Best regards, Willy A short blog article about: http://blog.haproxy.com/2014/05/26/haproxy-and-http-errors-408-in-chrome/ Bapitste
Re: Error 408 with Chrome
*From: *Willy Tarreau w...@1wt.eu *Sent: * 2014-05-26 12:07:09 EDT *To: *Arnall arnall2...@gmail.com *CC: *haproxy@formilux.org *Subject: *Re: Error 408 with Chrome On Mon, May 26, 2014 at 05:52:15PM +0200, Arnall wrote: Le 26/05/2014 16:13, Willy Tarreau a écrit : Hi Arnall, On Mon, May 26, 2014 at 11:56:52AM +0200, Arnall wrote: Hi Willy, same problem here with Chrome version 35.0.1916.114 m and : HA-Proxy version 1.4.22 2012/08/09 (Debian 6) Kernel 3.8.13-OVH HA-Proxy version 1.5-dev24-8860dcd 2014/04/26 (Debian GNU/Linux 7.5) Kernel 3.10.13-OVH htmlbodyh1408 Request Time-out/h1 Your browser didn't send a complete request in time. /body/html Timing : Blocking 2ms / Receiving : 1ms Where are you measuring this ? I suspect on the browser, right ? In this case it confirms the malfunction of the preconnect. You should take a network capture which will be usable as a reliable basis for debugging. I'm pretty sure that what you'll see in fact is the following sequence : browser haproxy --- connect -- ... long pause ... 408 + FIN --- ... long pause ... --- send request - RST - And you see the error in the browser immediately. The issue is then caused by the browser not respecting this specific rule : Yes it was measured on the browser (Chrome network monitor) I 've made a network capture for you.(in attachment) Thank you. If you looked at the connection from port 62691, it's exactly the sequence I described above. So that clearly explains what Chrome is the only one affected! Best regards, Willy Has anyone opened a bug against Chrome for this behavior (did a brief search and didn't see one)? I'd be interested in following it as this behavior will likely have an impact on an upcoming project I've got. -Patrick
Re: What is hrsp_5xx for a frontend?
Thanks, Willy, that makes sense. What settings should we look at tuning? We already have backlog set to 32k in the defaults, but with fairly low timeouts for connect, queue, and server. Should we try setting those timeouts somewhat higher? Or would you recommend something else? (I can also post the haproxy.cfg if that will help) MAGNE+IC Dan Crosta | Director, Engineering On Mon, May 26, 2014 at 10:17 AM, Willy Tarreau w...@1wt.eu wrote: On Sat, May 24, 2014 at 08:40:35AM -0400, Dan Crosta wrote: I'm a little confused about what exactly creates a 5xx response code from HAProxy. I think that if the backend generates a 5xx response, this will show up as a frontend_5xx, and I expect that the value of the hrsp_5xx stat for the frontend should equal the sum of the hrsp_5xx values from the backends. However, this doesn't jive with what we actually see in the statistics output: $ curl -s http://10.1.99.106:8080/haproxy?stats;csv;norefresh; | tr , | cut -f 1,2,44 | head -n 19 # pxname svnamehrsp_5xx myfrontendFRONTEND 10797124 mybackend host001 24364 mybackend host002 17260 mybackend host003 25250 mybackend host004 15135 mybackend host005 17364 mybackend host006 24541 mybackend host007 11422 mybackend host008 14199 mybackend host009 13274 mybackend host010 12797 mybackend host011 24532 mybackend host012 23599 mybackend host013 31728 mybackend host014 24607 mybackend host015 14851 mybackend host016 13937 mybackend BACKEND 10797124 The sum of the hrsp_5xx's for each of the individual backends is 308860, while both the FRONTEND and BACKEND numbers are about 30 times as much. Am I missing something obvious? Does HAProxy ever generate 5xx responses itself, either in the backend or frontend? Is there some more detailed logging we should enable to track this down? Yes it can generate 5xx when it cannot deliver the request somewhere. For example if you're running with many use_backend rules and no default_backend, it's possible that a number of requests en up going nowhere and are rejected as 503. In your case since we're seeing the same number in the frontend and in the backend and you have much less errors on the servers themselves, that can be explained by 503 when the queue is overflown (requests that are never served because of too low a server maxconn value, too short queue timeouts, or too long server response times). Hoping this helps, Willy
Sac Golf Lamborghini- Momentus Outils d'Entrainement
Si ce message ne s'affiche pas correctement consultez-le en ligne -15% sur les outils d'entrainement MOMENTUS MOMENTUS Speed Whoosh 84€ au lieu de 99€ Pour l'achat d'un Momentus Speed Whoosh stick offert. MOMENTUS XL Iron 84€ au lieu de 99€ MOMENTUS PLANE SWING SYSTEM 84€ au lieu de 99€ MOMENTUS Power Hitter 84€ au lieu de 99€ MOMENTUS Power Hitter Iron 84€ au lieu de 99€ Deane Beman's Aim-Check 8,45€ au lieu de 9,95€ Training Grip 9,95€ au lieu de 11,70€ Indoor Driver 84€ au lieu de 99€ Power X 16.95€ au lieu de 19,95€ Stick d'alignement 17€ au lieu de 20€ Sac de Golf LAMBORGHINI à -30% Sac trépied 159€ au lieu de 229€ -30% Sac Chariot 159€ au lieu de 229€ -30% Recevez nos Newsletter Suivez-nous sur Facebook Se désinscrire de cette newsletter
Joint Venture
Chen Wei, Director,Assistant President CNOOC China National Offshore Oil Corp.,(CNOOC) No.25,Chaoyangmenbei Dajie,Dongcheng District, Beijing 100010 P. R.China. Joint Venture, I am approaching for investment partnership with you and or /your company under your committal assistance. Let me know if there are investments potentials in your country also if you are interested to discuss the possibility of entering into a joint venture . I am Mr Chen Wei Director, Assistant President of CNOOC, Executive Vice President of CNOOC Limited, and President of CNOOC Research Institute. Website: http://en.cnooc.com.cn/data/html/english/channel_199.html Optimistically, I am interested to discuss about Joint Venture investment with you if you find it worthwhile to work with a high profile Chinese towards establishing a good business relationship. Kindly let me know if you are interested in this proposal so I shall provide you with the relevant details for the investment funds and our procedures in sequence.I also demand for transparent and professional business cooperation in the future. Expect your response. Respectfully, Chen Wei, Director,Assistant President CNOOC China National Offshore Oil Corp.,(CNOOC) No.25,Chaoyangmenbei Dajie,Dongcheng District, Beijing 100010 P. R.China.
