[SPAM] led hight bay 150w 20151220
Dear Director ,we are an led factory in China .Now our assembly lines are producing led highbay 150w, as attached picture; If YOU have any demand in led highbay, pls send me email and continuing talking.B.RegardsDavidskype:davidwang2686http://mini.wal8.com/img47/534083_20151213102445/thumbnails/145060529022_small.jpg
Ici les voisines disent oui tout de suite !
Title: rencontre-sangouard-19.12.15 Pour visualiser correctement ce message, accédez à la version en ligne Ici les Voisines disent Oui, Direct! 18 Femmes sont encore disponibles deux pas de chez vous pour un RDV sans prise de tête. Pas d'attente: mise en relation et contacts immédiats. 100% Anonyme: confidentialité sécurité. Réponse assurée pour chaque homme qui fait une demande de contact. Tu es dispo ce soir ? C'est le moment de me connecter ! Elles t'attendent pour un plan sans prise de tête. Voir Maintenant Photos Annonces Pour cesser de recevoir nos informations cliquez sur le lien : désabonnez-vous.
RE: haproxy log
Guys, We really need your advice here. From: Cohen Galit Sent: Tuesday, December 15, 2015 10:59 AM To: Cohen Galit; 'haproxy@formilux.org' Subject: RE: haproxy log I'm talking about the prints in logs: Dec 13 10:55:15 localhost.localdomain haproxy[11803]: 10.106.161.146:34747 [13/Dec/2015:10:55:05.698] HAProxy_VVM HAProxy_VVM/cas-au53 1/0/ 966 -- 447/447/447/88/0 0/0 Dec 13 10:55:15 localhost.localdomain haproxy[11803]: 10.106.161.163:63043 [13/Dec/2015:10:55:05.751] HAProxy_VVM HAProxy_VVM/cas-au63 1/0/ 966 -- 445/445/445/89/0 0/0 Dec 13 10:55:15 localhost.localdomain haproxy[11803]: 10.106.161.163:63043 [13/Dec/2015:10:55:05.751] HAProxy_VVM HAProxy_VVM/cas-au63 1/0/ 966 -- 445/445/445/89/0 0/0 Dec 13 10:55:15 localhost.localdomain haproxy[11803]: 10.106.161.166:49649 [13/Dec/2015:10:55:05.807] HAProxy_VVM HAProxy_VVM/cas-au53 1/0/10004 966 -- 443/443/443/88/0 0/0 Dec 13 10:55:15 localhost.localdomain haproxy[11803]: 10.106.161.166:49649 [13/Dec/2015:10:55:05.807] HAProxy_VVM HAProxy_VVM/cas-au53 1/0/10004 966 -- 443/443/443/88/0 0/0 Dec 13 10:55:15 localhost.localdomain haproxy[11803]: 10.106.161.162:14719 [13/Dec/2015:10:55:05.923] HAProxy_VVM HAProxy_VVM/cas-au61 1/0/9998 1239 -- 442/442/442/88/0 0/0 Dec 13 10:55:15 localhost.localdomain haproxy[11803]: 10.106.161.162:14719 [13/Dec/2015:10:55:05.923] HAProxy_VVM HAProxy_VVM/cas-au61 1/0/9998 1239 -- 442/442/442/88/0 0/0 Dec 13 10:55:16 localhost.localdomain haproxy[11803]: 10.106.161.164:17564 [13/Dec/2015:10:55:06.025] HAProxy_VVM HAProxy_VVM/cas-au63 1/0/ 1238 -- 443/443/443/89/0 0/0 Dec 13 10:55:16 localhost.localdomain haproxy[11803]: 10.106.161.164:17564 [13/Dec/2015:10:55:06.025] HAProxy_VVM HAProxy_VVM/cas-au63 1/0/ 1238 -- 443/443/443/89/0 0/0 Dec 13 10:55:16 localhost.localdomain haproxy[11803]: 10.106.161.164:17565 [13/Dec/2015:10:55:06.032] HAProxy_VVM HAProxy_VVM/cas-au132 1/0/ 1239 -- 443/443/443/89/0 0/0 From: Cohen Galit Sent: Monday, December 14, 2015 11:22 AM To: 'haproxy@formilux.org' Subject: FW: haproxy log Hello! Can you examine the logger below? I'm afraid I have a configuration problem in haproxy config, maybe in one of the timeout limits. These lines are printed only after load tests are starting to fail over tcp against 5 imap servers round robin. We are load testing over than 1M create sockets. Here is the configuration: global log 127.0.0.1 local0 debug #emerg alert crit errwarning notice info debug maxconn 90096 tune.ssl.default-dh-param 2048 uid 55301 gid 55301 defaults logglobal modetcp option tcplog option dontlognull retries 3 maxconn 90096 timeout client 60 timeout server 6 timeout connect 5000 listen HAProxy_VVM log global option tcplog mode tcp bind :50143 name VVM_PLAIN bind :50443 name VVM_SSL #bind :50993 name VVM_TLS balance roundrobin #option tcp-check #tcp-check connect port 50443 ssl # USED FOR MIST VVM HEALTH CHECK. DO NOT COMMENT OR CHANGE THIS LINE. #tcp-check expect string *\ OK maxconn 90096 timeout client 60 timeout server 12 timeout connect 5000 #server mips 10.45.92.35 check verify none inter 3 server cas-au53 10.106.75.53 check verify none inter 3 server cas-au61 10.106.75.61 check verify none inter 3 server cas-au62 10.106.75.62 check verify none inter 3 server cas-au63 10.106.75.63 check verify none inter 3 server cas-au132 10.106.138.132 check verify none inter 3 Thanks, Galit From: Kuterman Itzik Sent: Sunday, December 13, 2015 12:09 PM To: Cohen Galit Subject: haproxy log? Dec 13 10:55:15 localhost.localdomain haproxy[11803]: 10.106.161.146:34747 [13/Dec/2015:10:55:05.698] HAProxy_VVM HAProxy_VVM/cas-au53 1/0/ 966 -- 447/447/447/88/0 0/0 Dec 13 10:55:15 localhost.localdomain haproxy[11803]: 10.106.161.163:63043 [13/Dec/2015:10:55:05.751] HAProxy_VVM HAProxy_VVM/cas-au63 1/0/ 966 -- 445/445/445/89/0 0/0 Dec 13 10:55:15 localhost.localdomain haproxy[11803]: 10.106.161.163:63043 [13/Dec/2015:10:55:05.751] HAProxy_VVM HAProxy_VVM/cas-au63 1/0/ 966 -- 445/445/445/89/0 0/0 Dec 13 10:55:15 localhost.localdomain haproxy[11803]: 10.106.161.166:49649 [13/Dec/2015:10:55:05.807] HAProxy_VVM HAProxy_VVM/cas-au53 1/0/10004 966 -- 443/443/443/88/0 0/0 Dec 13 10:55:15 localhost.localdomain haproxy[11803]: 10.106.161.166:49649 [13/Dec/2015:10:55:05.807] HAProxy_VVM HAProxy_VVM/cas-au53 1/0/10004 966 -- 443/443/443/88/0 0/0 Dec 13 10:55:15 localhost.localdomain haproxy[11803]: 10.106.161.162:14719 [13/Dec/2015:10:55:05.923] HAProxy_VVM HAProxy_VVM/cas-au61 1/0/9998 1239 -- 442/442/442/88/0 0/0 Dec 13 10:55:15 localhost.localdomain haproxy[11803]: 10.106.161.162:14719 [13/Dec/2015:10:55:05.923] HAP
Re: haproxy log
Le 20/12/2015 14:06, Cohen Galit a écrit : Guys, We really need your advice here. Without any context, I guess you won't have any advice from anyone. You made some load tests, you have logs... and... well, nothing, no other description. 2 things : - consider adding some maxconn to your "server" lines - ensure your load tests don't exhaust tcp ports. *From:*Cohen Galit *Sent:* Tuesday, December 15, 2015 10:59 AM *To:* Cohen Galit; 'haproxy@formilux.org' *Subject:* RE: haproxy log I'm talking about the prints in logs: Dec 13 10:55:15 localhost.localdomain haproxy[11803]: 10.106.161.146:34747 [13/Dec/2015:10:55:05.698] HAProxy_VVM HAProxy_VVM/cas-au53 1/0/ 966 -- 447/447/447/88/0 0/0 Dec 13 10:55:15 localhost.localdomain haproxy[11803]: 10.106.161.163:63043 [13/Dec/2015:10:55:05.751] HAProxy_VVM HAProxy_VVM/cas-au63 1/0/ 966 -- 445/445/445/89/0 0/0 Dec 13 10:55:15 localhost.localdomain haproxy[11803]: 10.106.161.163:63043 [13/Dec/2015:10:55:05.751] HAProxy_VVM HAProxy_VVM/cas-au63 1/0/ 966 -- 445/445/445/89/0 0/0 Dec 13 10:55:15 localhost.localdomain haproxy[11803]: 10.106.161.166:49649 [13/Dec/2015:10:55:05.807] HAProxy_VVM HAProxy_VVM/cas-au53 1/0/10004 966 -- 443/443/443/88/0 0/0 Dec 13 10:55:15 localhost.localdomain haproxy[11803]: 10.106.161.166:49649 [13/Dec/2015:10:55:05.807] HAProxy_VVM HAProxy_VVM/cas-au53 1/0/10004 966 -- 443/443/443/88/0 0/0 Dec 13 10:55:15 localhost.localdomain haproxy[11803]: 10.106.161.162:14719 [13/Dec/2015:10:55:05.923] HAProxy_VVM HAProxy_VVM/cas-au61 1/0/9998 1239 -- 442/442/442/88/0 0/0 Dec 13 10:55:15 localhost.localdomain haproxy[11803]: 10.106.161.162:14719 [13/Dec/2015:10:55:05.923] HAProxy_VVM HAProxy_VVM/cas-au61 1/0/9998 1239 -- 442/442/442/88/0 0/0 Dec 13 10:55:16 localhost.localdomain haproxy[11803]: 10.106.161.164:17564 [13/Dec/2015:10:55:06.025] HAProxy_VVM HAProxy_VVM/cas-au63 1/0/ 1238 -- 443/443/443/89/0 0/0 Dec 13 10:55:16 localhost.localdomain haproxy[11803]: 10.106.161.164:17564 [13/Dec/2015:10:55:06.025] HAProxy_VVM HAProxy_VVM/cas-au63 1/0/ 1238 -- 443/443/443/89/0 0/0 Dec 13 10:55:16 localhost.localdomain haproxy[11803]: 10.106.161.164:17565 [13/Dec/2015:10:55:06.032] HAProxy_VVM HAProxy_VVM/cas-au132 1/0/ 1239 -- 443/443/443/89/0 0/0 *From:*Cohen Galit *Sent:* Monday, December 14, 2015 11:22 AM *To:* 'haproxy@formilux.org' *Subject:* FW: haproxy log Hello! Can you examine the logger below? I'm afraid I have a configuration problem in haproxy config, maybe in one of the timeout limits. These lines are *printed only after load tests are starting to fail* over tcp against 5 imap servers round robin. We are load testing over than 1M create sockets. Here is the configuration: global log 127.0.0.1 local0 debug #emerg alert crit err warning notice info debug maxconn 90096 tune.ssl.default-dh-param 2048 uid 55301 gid 55301 defaults logglobal modetcp option tcplog option dontlognull retries 3 maxconn 90096 timeout client 60 timeout server 6 timeout connect 5000 listen HAProxy_VVM log global option tcplog mode tcp bind :50143 name VVM_PLAIN bind :50443 name VVM_SSL #bind :50993 name VVM_TLS balance roundrobin #option tcp-check #tcp-check connect port 50443 ssl # USED FOR MIST VVM HEALTH CHECK. DO NOT COMMENT OR CHANGE THIS LINE. #tcp-check expect string *\ OK maxconn 90096 timeout client 60 timeout server 12 timeout connect 5000 #server mips 10.45.92.35 check verify none inter 3 server cas-au53 10.106.75.53 check verify none inter 3 server cas-au61 10.106.75.61 check verify none inter 3 server cas-au62 10.106.75.62 check verify none inter 3 server cas-au63 10.106.75.63 check verify none inter 3 server cas-au132 10.106.138.132 check verify none inter 3 Thanks, Galit *From:*Kuterman Itzik *Sent:* Sunday, December 13, 2015 12:09 PM *To:* Cohen Galit *Subject:* haproxy log? Dec 13 10:55:15 localhost.localdomain haproxy[11803]: 10.106.161.146:34747 [13/Dec/2015:10:55:05.698] HAProxy_VVM HAProxy_VVM/cas-au53 1/0/ 966 -- 447/447/447/88/0 0/0 Dec 13 10:55:15 localhost.localdomain haproxy[11803]: 10.106.161.163:63043 [13/Dec/2015:10:55:05.751] HAProxy_VVM HAProxy_VVM/cas-au63 1/0/ 966 -- 445/445/445/89/0 0/0 Dec 13 10:55:15 localhost.localdomain haproxy[11803]: 10.106.161.163:63043 [13/Dec/2015:10:55:05.751] HAProxy_VVM HAProxy_VVM/cas-au63 1/0/ 966 -- 445/445/445/89/0 0/0 Dec 13 10:55:15 localhost.localdomain haproxy[11803]: 10.106.161.166:49649 [13/Dec/2015:10:55:05.807] HAProxy_VVM HAProxy_VVM/cas-au53 1/0/10004 966 -- 443/443/443/88/0 0/0 Dec 13 10:55:15 localhost.localdomain haproxy[11803]: 10.106.161.1
[SPAM] En exclusivité voici votre nouvelle et unqiue boutique FISKARS, la célèbre marque !
** Vous pourrez exercer vos droits d´accès, annulation, rectification et opposition concernant vos données à caractère personnel, en cliquant * annulation //www.mdirector.com/track/pre-unsubscribe/category/EMAIL/empId/36335/subId/70/listId/10/conId/269/signature/d077cd210da2278c7cd0d0d160ccad8b/conEmail/haproxy@formilux.org/conMovil/-
Re: HAProxy returning 404
Hi Baptiste, On Sat, Dec 19, 2015 at 11:18:36PM +0100, Baptiste wrote: > HAProxy can't return a 404. Your web server may be improperly configured. I'm seeing one possibility (which logs would obviously show), which is that he's using an older version of haproxy which defaults to tunnel mode, and that once the first request is sent to one of the servers, all subsequent ones are send there as well regardless of the content switching rules. Gaurav, please send the output of "haproxy -vv". If your version is older than 1.5 you'll have to add "option http-server-close" or even "option forceclose" in your configuration. The best solution is of course to upgrade it to get one which supports keep-alive. Willy
[ANNOUNCE] haproxy-1.7-dev1
Hi all, the long-awaited 1.7-dev1 is now ready. This also means we managed to tackle the bugs that were plaguing us for some time. I won't repeat here all the bugs that were already backported to 1.6-stable. One of the most interesting change in this version is the addition by Dave Zhu of the ability to present an RSA/DSA/ECDSA certificate depending on what the client supports. Since the discussion gathered a lot of interest (100 mails just on this subject, that's quite rare), it was about time to issue a version with it so that the largest number can test it. In addition, Thierry and I spent 5 hours this afternoon killing the last Lua bugs. It turns out that a few misdesigns were made in the use-service mechanism which should have prevented the applets from relying on sample fetches using http_txn (all the http-enabled ones) since they cannot work (headers have been forwarded). This was the cause behind a number of reports of non-working header fetches made there, and some possible crashes when using POST requests (http_txn are not designed to be fed wrapping buffers). The changes were not easy and some configs which either silently didn't work or even used to cause a crash will properly report an error now. In order to work around the impossibility to use HTTP sample fetches from Lua services, Thierry has added a new headers array that allows applications to still get all their request headers. I tend to expect that we'll see a few more glitches related to the use-service action, because it's quite young, extremely tricky, and powerful (ie: tempting). What matters the most to me is that this cannot bring a process down though. All these Lua fixes will have to be backported to 1.6.3, but I prefer to wait for some feedback on 1.7 first so that if we missed something we avoid to issue too many stable versions that can confuse people. So please beat it hard, and if everything's OK I intend to issue 1.6.3 around next week-end. For the next steps, Baptiste has some DNS fixes, and I intend to merge Christopher's filters work which looks good enough now. Full changelog below : - DOC: specify that stats socket doc (section 9.2) is in management - BUILD: install only relevant and existing documentation - CLEANUP: don't ignore debian/ directory if present - BUG/MINOR: dns: parsing error of some DNS response - BUG/MEDIUM: namespaces: don't fail if no namespace is used - BUG/MAJOR: ssl: free the generated SSL_CTX if the LRU cache is disabled - MEDIUM: dns: Don't use the ANY query type - BUILD: ssl: fix build error introduced in commit 7969a3 with OpenSSL < 1.0.0 - DOC: fix a typo for a "deviceatlas" keyword - FIX: small typo in an example using the "Referer" header - MINOR: cli: ability to set per-server maxconn - DEBUG/MINOR: memory: add a build option to disable memory pools sharing - DEBUG/MEDIUM: memory: optionally protect free data in pools - DEBUG/MEDIUM: memory: add optional control pool memory operations - MEDIUM: memory: add accounting for failed allocations - BUG/MEDIUM: config: count memory limits on 64 bits, not 32 - BUG/MAJOR: dns: first DNS response packet not matching queried hostname may lead to a loop - BUG/MINOR: dns: unable to parse CNAMEs response - BUG/MINOR: examples/haproxy.init: missing brace in quiet_check() - DOC: deviceatlas: more example use cases. - MINOR: config: allow IPv6 bracketed literals - BUG/BUILD: replace haproxy-systemd-wrapper with $(EXTRA) in install-bin. - BUILD: add Haiku as supported target. - BUG/MAJOR: http: don't requeue an idle connection that is already queued - DOC: typo on capture.res.hdr and capture.req.hdr - BUG/MINOR: dns: check for duplicate nameserver id in a resolvers section was missing - CLEANUP: use direction names in place of numeric values - BUG/MEDIUM: lua: sample fetches based on response doesn't work - MINOR: check: add agent-send server parameter - BUG/MINOR: http rule: http capture 'id' rule points to a non existing id - BUG/MINOR: server: check return value of fgets() in apply_server_state() - BUG/MINOR: acl: don't use record layer in req_ssl_ver - BUILD: freebsd: double declaration - BUG/MEDIUM: lua: clean output buffer - BUILD: check for libressl to be able to build against it - DOC: lua-api/index.rst small example fixes, spelling correction. - DOC: lua: architecture and first steps - DOC: relation between timeout http-request and option http-buffer-request - BUILD: Make deviceatlas require PCRE - BUG: http: do not abort keep-alive connections on server timeout - BUG/MEDIUM: http: switch the request channel to no-delay once done. - BUG/MINOR: lua: don't force-sslv3 LUA's SSL socket - BUILD/MINOR: http: proto_http.h needs sample.h - BUG/MEDIUM: http: don't enable auto-close on the response side - BUG/MEDIUM: stream: fix half-closed timeout handling - CLEANUP:
Re: Set the URI
On 12/05/2015 03:42 PM, Brendan Kearney wrote: I am trying to use HAProxy to perform http interception and transparently proxy outbound http traffic. i am having a dog of a time trying to get this working. I need to rewrite the GET line on a request so that the request is for the absolute URL, and not the relative URI. i found this article: http://www.haproxy.com/doc/aloha/7.0/haproxy/http_rewriting.html#rewriting-http-urls and the "Set the URI" section of that page is exactly what i want to do, but i need to do it in the community version of HAProxy, not Aloha. i cant seem to get the process down on how to capture or extract the request URL, and rewrite the GET line to contain that info. Can someone point me in the right direction on what i need to do? thanks in advance, brendan no feedback on how to do this? this would be a really helpful function to have working. any help is appreciated. thanks, brendan
Re: Set the URI
On Sun, Dec 20, 2015 at 09:31:45PM -0500, Brendan Kearney wrote: > On 12/05/2015 03:42 PM, Brendan Kearney wrote: > >I am trying to use HAProxy to perform http interception and > >transparently proxy outbound http traffic. i am having a dog of a > >time trying to get this working. I need to rewrite the GET line on a > >request so that the request is for the absolute URL, and not the > >relative URI. > > > >i found this article: > >http://www.haproxy.com/doc/aloha/7.0/haproxy/http_rewriting.html#rewriting-http-urls > > > > > > > >and the "Set the URI" section of that page is exactly what i want to > >do, but i need to do it in the community version of HAProxy, not Aloha. > > > >i cant seem to get the process down on how to capture or extract the > >request URL, and rewrite the GET line to contain that info. Can > >someone point me in the right direction on what i need to do? > > > >thanks in advance, > > > >brendan > no feedback on how to do this? this would be a really helpful function > to have working. any help is appreciated. Did you try what you pointed above ? What you find for ALOHA will most often work on a recent mainline haproxy since aloha includes haproxy plus some backports. What version are you using ? That just makes me realize that if people are linking to ALOHA docs, we should indicate in the aloha docs what mainline version of haproxy is included in each aloha version. I'll check this with Baptiste. Regards, Willy
Re: HAProxy returning 404
Hi Baptiste / Willy , Same backend server is working with nginx reverse proxy. Below is output of haproxy -vv HA-Proxy version 1.5.11 2015/01/31 Copyright 2000-2015 Willy Tarreau Build options : TARGET = linux2628 CPU = generic CC = gcc CFLAGS = -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -D_FORTIFY_SOURCE=2 OPTIONS = USE_ZLIB=1 USE_OPENSSL=1 USE_PCRE=1 Default settings : maxconn = 2000, bufsize = 16384, maxrewrite = 8192, maxpollevents = 200 Encrypted password support via crypt(3): yes Built with zlib version : 1.2.3.4 Compression algorithms supported : identity, deflate, gzip Built with OpenSSL version : OpenSSL 1.0.1 14 Mar 2012 Running on OpenSSL version : OpenSSL 1.0.1 14 Mar 2012 OpenSSL library supports TLS extensions : yes OpenSSL library supports SNI : yes OpenSSL library supports prefer-server-ciphers : yes Built with PCRE version : 8.12 2011-01-15 PCRE library supports JIT : no (USE_PCRE_JIT not set) Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT IP_FREEBIND Available polling systems : epoll : pref=300, test result OK poll : pref=200, test result OK select : pref=150, test result OK Total: 3 (3 usable), will use epoll. On Mon, Dec 21, 2015 at 3:48 AM, Willy Tarreau wrote: > Hi Baptiste, > > On Sat, Dec 19, 2015 at 11:18:36PM +0100, Baptiste wrote: > > HAProxy can't return a 404. Your web server may be improperly configured. > > I'm seeing one possibility (which logs would obviously show), which is > that he's using an older version of haproxy which defaults to tunnel > mode, and that once the first request is sent to one of the servers, > all subsequent ones are send there as well regardless of the content > switching rules. > > Gaurav, please send the output of "haproxy -vv". If your version is > older than 1.5 you'll have to add "option http-server-close" or even > "option forceclose" in your configuration. The best solution is of > course to upgrade it to get one which supports keep-alive. > > Willy > > -- Regards, Gaurav Sharma, Devops Engineer, Phone No. : 09582232217 Ignite World
通知邮件系统升级haproxy@formilux.org
这是一封 HTML 格式的邮件，请以网页方式查看邮件。
Re: lua: header sample fetch doesn't work in POST requests
Hi Jan,
This will be fiwed in the next 1.6
- some sample fetches which requires a valid haproxy http transaction,
which doesn't exists in Lua land because when the applet start, the
transaction is no longer valid are prohibited.
- in replacement, a new struct in the AppletHTTP class contains
headers and other usefull information.
So, for the header you must access to the Lua structs in place of
sample fetches, for other things like SSL information you can continue
to use the sample fetches (the layer 5 information are available during
the applet time).
Thierry
On Fri, 11 Dec 2015 17:05:58 +0100
Thierry FOURNIER wrote:
> Hello,
>
> Thank you for the bug repport and the method for reproducing it.
>
> You're absolutely right, I reproduce the bug. Unfortunately it's not a
> bug. When we enter in the applet run, the data of the body is received,
> and when the body data is received, HAProxy looses the offset headers.
>
> So, you cannot retrieve the header content when a post is received :(
>
> I wrote a patch which copy the header names and values in an Lua array.
> Its running, but it reveal another bug ;)
>
> I fix all of these and I submit the patch. This patch modify the API,
> so I'm not sure that it will be embed in the 1.6.
>
> Thierry
>
>
>
> On Fri, 11 Dec 2015 11:49:49 +0100
> "Jan A. Bruder" wrote:
>
> > Hi,
> >
> > applet.sf:hdr(name) always returns empty strings in POST requests. It works
> > only in GET requests.
> >
> > To reproduce:
> >
> > haproxy.cfg:
> > global
> > ...
> > lua-load /etc/haproxy/test.lua
> > ...
> >
> > frontend http
> > bind *:8081
> > mode http
> > acl applet_test_url path /applet-test
> > http-request use-service lua.applet-test if applet_test_url
> > default_backend be
> > ...
> >
> > test.lua:
> >
> > -- applet test endpoint
> > core.register_service("applet-test", "http", function(applet)
> > local headerContentType = applet.sf:hdr("Content-Type")
> > core.Info("headerContentType:" .. headerContentType)
> > local headerUserAgent = applet.sf:hdr("User-Agent")
> > core.Info("headerUserAgent:" .. headerUserAgent)
> > local src = applet.sf:src()
> > core.Info("src:" .. src)
> >
> > local response = headerContentType .. " + " .. headerUserAgent .. " + " ..
> > src
> >
> > applet:set_status(200)
> > applet:add_header("content-length", string.len(response))
> > applet:add_header("content-type", "text/plain")
> > applet:start_response()
> > applet:send(response)
> > end)
> >
> > curl -X GET -H "Content-Type: text/plain" http://127.0.0.1:8081/applet-test
> >
> > ==> applet.sf:hdr() returns the correct values
> >
> > curl -X POST -H "Content-Type: application/x-www-form-urlencoded" -d
> > "key=value" http://127.0.0.1:8081/applet-test
> >
> > ==> applet.sf:hdr() returns empty strings
>
Re: SEGFAULT in in buffer_insert_line2
Hi,
The new release of the 1.6 will fix this problem. It was due to an HTTP
analyer called and use after the flush of some http data by the
AppletHTTP Lua things.
Thierry
On Sat, 5 Dec 2015 02:00:50 +0100
Willy Tarreau wrote:
> On Fri, Dec 04, 2015 at 09:18:38AM +0100, Bernd Helm wrote:
> > On 12/03/2015 06:53 PM, Willy Tarreau wrote:
> > >Maybe we're facing a bug where the buffer wraps at the end or something
> > >like this. Bernd, if you still have the core, could you please issue
> > >"print *b" while in buffer_insert_line2() ?
> > yes, i still have the core.
> >
> > (gdb) frame 1
> > #1 0x00413349 in buffer_insert_line2 (b=0x1e47a70,
> > pos=0x1e47acb "ntent-Type: text/html;
> > charset=UTF-8\r\nTransfer-Encoding: chunked\r\n\r\n1b9\r\n > html PUBLIC \"-//W3C//DTD XHTML 1.0 Transitional//EN\"
> >
> > \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\";>\n > str=0x513979 "Connection: close",
> > len=17) at src/buffer.c:126
> > (gdb) print *b
> > $1 = {p = 0x0, size = 822083584, i = 64, o = 2818572288, data = 0x1e47a84
> > "z\344\001"}
> >
> > if you need more information, let me know. thank you.
>
> The buffer was corrupted :-(
> I guess it was corrupted just before doing this buffer_insert_line2(),
> causing it to crash. Buffers are manipulated a lot, so it must have
> been still good a few nanoseconds before calling this. I'll review the
> code in this area in case I can find any hint relevant to your config.
>
> Thanks,
> Willy
>
>
Re: SEGFAULT in in buffer_insert_line2
Nice, thank you! On 12/21/2015 08:37 AM, thierry.fourn...@arpalert.org wrote: Hi, The new release of the 1.6 will fix this problem. It was due to an HTTP analyer called and use after the flush of some http data by the AppletHTTP Lua things. Thierry On Sat, 5 Dec 2015 02:00:50 +0100 Willy Tarreau wrote: On Fri, Dec 04, 2015 at 09:18:38AM +0100, Bernd Helm wrote: On 12/03/2015 06:53 PM, Willy Tarreau wrote: Maybe we're facing a bug where the buffer wraps at the end or something like this. Bernd, if you still have the core, could you please issue "print *b" while in buffer_insert_line2() ? yes, i still have the core. (gdb) frame 1 #1 0x00413349 in buffer_insert_line2 (b=0x1e47a70, pos=0x1e47acb "ntent-Type: text/html; charset=UTF-8\r\nTransfer-Encoding: chunked\r\n\r\n1b9\r\nhttp://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\";>\n The buffer was corrupted :-( I guess it was corrupted just before doing this buffer_insert_line2(), causing it to crash. Buffers are manipulated a lot, so it must have been still good a few nanoseconds before calling this. I'll review the code in this area in case I can find any hint relevant to your config. Thanks, Willy -- Mit freundlichen Grüßen / Best regards, B.Sc. Bernd Michael Helm -- Helm & Walter IT-Solutions GbR Müglitztalstr. 63 D-01809 Dohna Tel.: +49 3529 529129 Fax.: +49 3529 2348140 Mobile: +49 151 21240208 Email: bernd.h...@helmundwalter.de WWW: https://www.helmundwalter.de
