18W tube lighting
Dear Valued Customer, Good day. LED HIGH BAY LIGHTING 30W led high bay 25$usd each pcs 100W led high bay 45$usd each pcs 150W led high bay only 58$usd each pcs LED FLOOD LIGHTING 10W only 3.3$usd each pcs 50W only 12.5$usd each pcs 80W only 22$usd each pcs We are original producer with technical insight for Led products and we are a professional manufacture in the LED field for several years. Now we are looking for distributors and collaborator. We focus on theLED high bay and if you are interest in these products, then we can give you the very competitive priceand we will have a good cooperation in the future!Tom Huang Sales ManagerShenzhen JIN WANG Optoelectronics Co., Limited
Copying request headers to response header
Hello, I'm using the unique-id-header, and i'm having some difficulty getting it to work how i want it to. First of all, we have a variety of backends, so i'd like if what i'm trying to do could be handled entirely by haproxy. We're trying to implement a header for storing a unique request id (and if possible, making it nested), so it's possible to track the entire chain of requests going through our proxies. Basically that means if a request already contains a X-ReqId header, it should just leave it be, and if there is none, it should tag on it's own. Now i can it to set the header just fine, (not sure about the don't set one if already there part), but i can't seem to figure out how to get this shown in the response (without going outside haproxy). I'm not entirely familar with the haproxy processing pipeline, and what samples are available where. I tried something like this in the frontend (and tried backends as well), to no avail. http-response set-header X-ReqId %[req.fhdr(x-reqid)] Any pointers on how i can achieve my goal?
[SPAM] Zero Bezel Touch Monitor
This is a multi-part message in MIME format. Thismessagecontainsgraphics.Ifyoudonotseethe=graphics,cl=ickheretoview.Zero=BezelTouchMonitorFormoredetailsinformationaboutIP66=monitor,Pleasevisitourwebsite:www.ewinsonic.com88633704789=88633704722sa...@ewinsonic.com
Rencontrez des célibataires même pendant l'été
Si vous ne souhaitez plus recevoir de mails de notre part, utilisez la désinscription en ligne. http://notif.la-rencontre-france.com/unsub?hl=fra=hTlKk3b=3196a219c=1h59d=1767eaabe=bbf5437bemail=haproxy%40formilux.org Merci. [Les mecs s'affichent, les filles choisissent]http://www.mecacroquer.com/a04a3784c815e8afda974b227818ae90.html [Les plus belles rencontres]http://www.mecacroquer.com/a04a3784c815e8afda974b227818ae90.html [Des rencontres pour tous]http://www.mecacroquer.com/a04a3784c815e8afda974b227818ae90.html [Faites des rencontres]http://www.mecacroquer.com/a04a3784c815e8afda974b227818ae90.html [Des rencontres toujours plus belles]http://www.mecacroquer.com/a04a3784c815e8afda974b227818ae90.html [Rejoignez les célibataires]http://www.mecacroquer.com/a04a3784c815e8afda974b227818ae90.html [Un site qui donne le pouvoir de séduction aux femmes]http://www.mecacroquer.com/a04a3784c815e8afda974b227818ae90.html SITE DE RENCONTRE GÉNÉRALISTE OÙ LES FEMMES ONT LE POUVOIR Le printemps approche...Cette période toujours délicate lorsque vous êtes seul ! Osez MecACroquer.Com, un site basé sur le concept du girl power. Les codes de séductions changent, ce sont désormais les femmes qui ont le pouvoir dans le jeu de la séduction. Rejoignez les milliers de célibataires sans plus attendre. Discutez, échangez et rencontrez de nouvelles personnes, qui sait ? Venez rencontrer des célibataires sexy... Inscrivez-vous maintenant sur MecACroquer en moins de 1 minute ! Grâce à MecACroquer, faites les plus belles rencontres ! Laissez vous surprendre par de belles rencontres. Faites toujours plus de rencontres via notre service en ligne. Utilisez et abusez des nombreuses fonctionnalités proposées afin de rencontrer l'amour pour une nuit ou pour la vie. Inscrivez-vous et utilisez notre service de rencontre innovant ! Un problème à l'inscription ? Contactez notre service client : cont...@mecacroquer.com. Vous avez reçu ce mail de notre part car vous avez visité notre site internet récemment. Vous n'avez cependant pas été ajouté à une base de donnée marketing. Veuillez ignorer cet email si vous êtes déjà inscrit.
Resolvers are not applied from default_server line / Incorrect default value for resolve-prefer
Steps to reproduce: 1. Add a resolver section mydns: resolvers mydns nameserver dns1 8.8.8.8:53 nameserver dns2 8.8.4.4:53 2. Add the following line to the backend: default-server inter 1000 weight 13 resolvers mydns 3. Query show stat resolvers mydns from stats socket Expected result: The mydns resolver is used to resolve the server names. Actual result: The mydns resolver is not used at all This configuration does pass a config check haproxy -f haproxy.config -c and there is no error about resolvers keyword being not supported in default-server. The resolve-prefer option on the other hand seems to be set from the default-server. So why not the resolvers as well? Another possible bug: Incorrect default value for resolve-prefer According to the docs, the default value for resolve-prefer should be IPv4. Looking at the source code i am pretty sure this is not the case and instead this option defaults to IPv6: 1.6. Docs: http://cbonte.github.io/haproxy-dconv/snapshot/configuration-1.6.html#5.2-resolve-prefer 1.6 trunk: http://git.haproxy.org/?p=haproxy.git;a=blob;f=src/server.c;h=503d53ab36fc5688454b53dd0d7e88577df6ca46;hb=HEAD#l1037 Regards, Benji
Multi-part message failure during http mode (haproxy 1.5.12)
Hi all, We are getting either ECONNRESET, or sometimes ETIMEDOUT errors when the backend sends a large multi-part message via haproxy. It works for small file sizes of 4K and 8K, but fails for 2 Mb files. Is there any option or setup that will help fix this? Thanks, - Krishna Kumar -- -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Although Flipkart has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments
Re: Resolvers are not applied from default_server line / Incorrect default value for resolve-prefer
On Tue, Aug 4, 2015 at 11:27 PM, BBuhl b_b...@yahoo.de wrote: Baptiste bed...@gmail.com schrieb am 22:21 Dienstag, 4.August 2015: Hi Benji, Thanks a lot for your feedback! First, about the resolve-prefer, I coded it (and documented as well) first for IPv4 as a default. That said, Willy asked me to default it to IPv6. I forgot to update the documentation. I'll send a patch right away to fix the doc. Second, about resolvers in default-server statement. Well, this has never been evoked and has never been coded this way. (note the documentation doesn't mention that resolvers is available for default-server). We did it this way because it allows admins to mix servers with an IP address and servers with a hostname in the same farm. It also allows the admin to choose on which servers you want to enable DNS resolution. If you think this makes sense to have it in the default-server, then we have to find a way to negate it per server. Baptiste Hi Bapiste, thanks for your prompt response. I might be mistaken, but i don't see how allowing resolvers in the default-server statement would prohibit the alternative usage scenarios you were describing (e.g. setting resolvers to different value per server). In that case one would just NOT set resolvers in the default-server statement and instead set them in every server statement, no? not only a different one, the absence of resolvers on a particular server. Some kind of no-resolvers, or resolvers none. I'm not against the idea, we just need to ensure we make it the best way for every one. I just keep in mind your request and will try to address it later. Anyhow, this is nothing big. I can live with setting the resolvers for every server. But it should be documented that resolvers are not supported in default-server. AFAICS, for all the other keywords this is expressively documented with the line Supported in default-server: No. Patch already sent to Willy. I've already been asked to improve the doc about DNS and will do it asap. By the way, if you meet any issue with the DNS resolution itself, please let us know. Baptiste
Re: Resolvers are not applied from default_server line / Incorrect default value for resolve-prefer
Baptiste bed...@gmail.com schrieb am 22:21 Dienstag, 4.August 2015: Hi Benji, Thanks a lot for your feedback! First, about the resolve-prefer, I coded it (and documented as well) first for IPv4 as a default. That said, Willy asked me to default it to IPv6. I forgot to update the documentation. I'll send a patch right away to fix the doc. Second, about resolvers in default-server statement. Well, this has never been evoked and has never been coded this way. (note the documentation doesn't mention that resolvers is available for default-server). We did it this way because it allows admins to mix servers with an IP address and servers with a hostname in the same farm. It also allows the admin to choose on which servers you want to enable DNS resolution. If you think this makes sense to have it in the default-server, then we have to find a way to negate it per server. Baptiste Hi Bapiste, thanks for your prompt response. I might be mistaken, but i don't see how allowing resolvers in the default-server statement would prohibit the alternative usage scenarios you were describing (e.g. setting resolvers to different value per server). In that case one would just NOT set resolvers in the default-server statement and instead set them in every server statement, no? Anyhow, this is nothing big. I can live with setting the resolvers for every server. But it should be documented that resolvers are not supported in default-server. AFAICS, for all the other keywords this is expressively documented with the line Supported in default-server: No. Best, Benji
Re: [PATCH] Add log-format variable %HQ, to log HTTP query strings
On Mon, Aug 3, 2015 at 8:53 AM, Willy Tarreau w...@1wt.eu wrote:
I agree, I found this a bit awkward as well :-)
Regards,
Willy
Hi all -
Thanks for the feedback. I moved the string-scanning bit, but did not
use the find_param_list function. Updated patch is attached.
--
- Andrew Hayworth
From 63b0af8420b22376dba3bfd8d367ff9a12261edf Mon Sep 17 00:00:00 2001
From: Andrew Hayworth andrew.haywo...@getbraintree.com
Date: Fri, 31 Jul 2015 16:14:16 +
Subject: [PATCH] Add log-format variable %HQ, to log HTTP query strings
Since sample fetches are not always available in the response phase,
this patch implements %HQ such that:
GET /foo?bar=baz HTTP/1.0
...would be logged as:
?bar=baz
---
doc/configuration.txt | 1 +
include/types/log.h | 1 +
src/log.c | 36
3 files changed, 38 insertions(+)
diff --git a/doc/configuration.txt b/doc/configuration.txt
index db97cc7..b3ba8a0 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -13987,6 +13987,7 @@ Please refer to the table below for currently
defined variables :
| | %H | hostname | string |
| H | %HM | HTTP method (ex: POST)| string |
| H | %HP | HTTP request URI without query string (path) | string |
+ | H | %HQ | HTTP request URI query string (ex: ?bar=baz) | string |
| H | %HU | HTTP request URI (ex: /foo?bar=baz) | string |
| H | %HV | HTTP version (ex: HTTP/1.0) | string |
| | %ID | unique-id | string |
diff --git a/include/types/log.h b/include/types/log.h
index bbfe020..d0fb966 100644
--- a/include/types/log.h
+++ b/include/types/log.h
@@ -96,6 +96,7 @@ enum {
LOG_FMT_HTTP_METHOD,
LOG_FMT_HTTP_URI,
LOG_FMT_HTTP_PATH,
+ LOG_FMT_HTTP_QUERY,
LOG_FMT_HTTP_VERSION,
LOG_FMT_HOSTNAME,
LOG_FMT_UNIQUEID,
diff --git a/src/log.c b/src/log.c
index ffd8f10..f80de2e 100644
--- a/src/log.c
+++ b/src/log.c
@@ -111,6 +111,7 @@ static const struct logformat_type logformat_keywords[] = {
{ hsl, LOG_FMT_HDRRESPONSLIST, PR_MODE_TCP, LW_RSPHDR, NULL }, /*
header response list */
{ HM, LOG_FMT_HTTP_METHOD, PR_MODE_HTTP, LW_REQ, NULL }, /* HTTP method */
{ HP, LOG_FMT_HTTP_PATH, PR_MODE_HTTP, LW_REQ, NULL }, /* HTTP path */
+ { HQ, LOG_FMT_HTTP_QUERY, PR_MODE_HTTP, LW_REQ, NULL }, /* HTTP query */
{ HU, LOG_FMT_HTTP_URI, PR_MODE_HTTP, LW_REQ, NULL }, /* HTTP full URI */
{ HV, LOG_FMT_HTTP_VERSION, PR_MODE_HTTP, LW_REQ, NULL }, /* HTTP
version */
{ lc, LOG_FMT_LOGCNT, PR_MODE_TCP, LW_INIT, NULL }, /* log counter */
@@ -937,6 +938,7 @@ int build_logline(struct stream *s, char *dst,
size_t maxsize, struct list *list
struct chunk chunk;
char *uri;
char *spc;
+ char *qmark;
char *end;
struct tm tm;
int t_request;
@@ -1578,6 +1580,40 @@ int build_logline(struct stream *s, char *dst,
size_t maxsize, struct list *list
last_isspace = 0;
break;
+ case LOG_FMT_HTTP_QUERY: // %HQ
+ if (tmp-options LOG_OPT_QUOTE)
+ LOGCHAR('');
+
+ if (!txn-uri) {
+ chunk.str = BADREQ;
+ chunk.len = strlen(BADREQ);
+ } else {
+ uri = txn-uri;
+ end = uri + strlen(uri);
+ // look for the first question mark
+ while (uri end *uri != '?')
+ uri++;
+
+ qmark = uri;
+ // look for first space or question mark after url
+ while (uri end !HTTP_IS_SPHT(*uri))
+ uri++;
+
+ chunk.str = qmark;
+ chunk.len = uri - qmark;
+ }
+
+ ret = encode_chunk(tmplog, dst + maxsize, '#', url_encode_map, chunk);
+ if (ret == NULL || *ret != '\0')
+ goto out;
+
+ tmplog = ret;
+ if (tmp-options LOG_OPT_QUOTE)
+ LOGCHAR('');
+
+ last_isspace = 0;
+ break;
+
case LOG_FMT_HTTP_URI: // %HU
uri = txn-uri ? txn-uri : BADREQ;
--
2.1.3
0001-Add-log-format-variable-HQ-to-log-HTTP-query-strings.patch
Description: Binary data
Fwd: request for comment - [PATCH] MEDIUM: mailer: retry sending a mail up to 3 times
bump?
Doorgestuurd bericht
Onderwerp: request for comment - [PATCH] MEDIUM: mailer: retry sending
a mail up to 3 times
Datum: Sun, 26 Jul 2015 21:08:41 +0200
Van:PiBa-NL piba.nl@gmail.com
Aan:HAproxy Mailing Lists haproxy@formilux.org
Hi guys,
Ive created a small patch that will retry sending a mail 3 times if it
fails the first time.
Its seems to work in my limited testing..
HOWEVER.
-i have not checked for memoryleaks, sockets not being closed properly
(i dont know how to..)
-is setting current and last steps to null the proper way to reset the
step of rule evaluation?
-CO_FL_ERROR is set when there is a connection error.. this seems to be
the proper check.
-but check-conn-flags 0xFF is a bit of s guess from observing the
flags when it could connect but the server did not respond properly.. is
there a other better way?
-i used the 'fall' variable to track the number of retries.. should i
have created a separate 'retries' variable?
Thanks for any feedback you can give me.
Best regards,
PiBa-NL
From c5110d981cf0d2c070e88331eede15b0b16e80df Mon Sep 17 00:00:00 2001
From: Pieter Baauw piba.nl@gmail.com
Date: Sun, 26 Jul 2015 20:47:27 +0200
Subject: [PATCH] MEDIUM: mailer: retry sending a mail up to 3 times
Currently only 1 connection attempt (syn packet) was send, this patch increases
that to 3 attempts. This to make it less likely them mail is lost due to a
single lost packet.
---
src/checks.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/src/checks.c b/src/checks.c
index e386bee..cfcb1ee 100644
--- a/src/checks.c
+++ b/src/checks.c
@@ -1408,7 +1408,7 @@ static struct task *server_warmup(struct task *t)
*
* It can return one of :
* - SF_ERR_NONE if everything's OK and tcpcheck_main() was not called
- * - SF_ERR_UP if if everything's OK and tcpcheck_main() was called
+ * - SF_ERR_UP if everything's OK and tcpcheck_main() was called
* - SF_ERR_SRVTO if there are no more servers
* - SF_ERR_SRVCL if the connection was refused by the server
* - SF_ERR_PRXCOND if the connection has been limited by the proxy (maxconn)
@@ -3053,6 +3053,7 @@ static struct task *process_email_alert(struct task *t)
LIST_DEL(alert-list);
check-state |= CHK_ST_ENABLED;
+ check-fall = 0;
}
}
@@ -3060,6 +3061,16 @@ static struct task *process_email_alert(struct task *t)
process_chk(t);
if (!(check-state CHK_ST_INPROGRESS) check-tcpcheck_rules) {
+ if ((check-conn-flags CO_FL_ERROR) || // connection failed,
try again
+ (check-conn-flags 0xFF) // did not reach the
'normal end', try again
+ ) {
+ if (check-fall 3) {
+ check-current_step = NULL;
+ check-last_started_step = NULL;
+ check-fall++;
+ return t;
+ }
+ }
struct email_alert *alert;
alert = container_of(check-tcpcheck_rules, typeof(*alert),
tcpcheck_rules);
--
1.9.5.msysgit.1
Re: Resolvers are not applied from default_server line / Incorrect default value for resolve-prefer
On Tue, Aug 4, 2015 at 5:34 PM, BBuhl b_b...@yahoo.de wrote: Steps to reproduce: 1. Add a resolver section mydns: resolvers mydns nameserver dns1 8.8.8.8:53 nameserver dns2 8.8.4.4:53 2. Add the following line to the backend: default-server inter 1000 weight 13 resolvers mydns 3. Query show stat resolvers mydns from stats socket Expected result: The mydns resolver is used to resolve the server names. Actual result: The mydns resolver is not used at all This configuration does pass a config check haproxy -f haproxy.config -c and there is no error about resolvers keyword being not supported in default-server. The resolve-prefer option on the other hand seems to be set from the default-server. So why not the resolvers as well? Another possible bug: Incorrect default value for resolve-prefer According to the docs, the default value for resolve-prefer should be IPv4. Looking at the source code i am pretty sure this is not the case and instead this option defaults to IPv6: 1.6. Docs: http://cbonte.github.io/haproxy-dconv/snapshot/configuration-1.6.html#5.2-resolve-prefer 1.6 trunk: http://git.haproxy.org/?p=haproxy.git;a=blob;f=src/server.c;h=503d53ab36fc5688454b53dd0d7e88577df6ca46;hb=HEAD#l1037 Regards, Benji Hi Benji, Thanks a lot for your feedback! First, about the resolve-prefer, I coded it (and documented as well) first for IPv4 as a default. That said, Willy asked me to default it to IPv6. I forgot to update the documentation. I'll send a patch right away to fix the doc. Second, about resolvers in default-server statement. Well, this has never been evoked and has never been coded this way. (note the documentation doesn't mention that resolvers is available for default-server). We did it this way because it allows admins to mix servers with an IP address and servers with a hostname in the same farm. It also allows the admin to choose on which servers you want to enable DNS resolution. If you think this makes sense to have it in the default-server, then we have to find a way to negate it per server. Baptiste
Re: Copying request headers to response header
On Tue, Aug 4, 2015 at 10:34 AM, David Reuss shuffle...@gmail.com wrote: Hello, I'm using the unique-id-header, and i'm having some difficulty getting it to work how i want it to. First of all, we have a variety of backends, so i'd like if what i'm trying to do could be handled entirely by haproxy. We're trying to implement a header for storing a unique request id (and if possible, making it nested), so it's possible to track the entire chain of requests going through our proxies. Basically that means if a request already contains a X-ReqId header, it should just leave it be, and if there is none, it should tag on it's own. Now i can it to set the header just fine, (not sure about the don't set one if already there part), but i can't seem to figure out how to get this shown in the response (without going outside haproxy). I'm not entirely familar with the haproxy processing pipeline, and what samples are available where. I tried something like this in the frontend (and tried backends as well), to no avail. http-response set-header X-ReqId %[req.fhdr(x-reqid)] Any pointers on how i can achieve my goal? Hi David, This is not doable in 1.5. In 1.6, you can give a try to the http-request capture statement, to capture at the request time, then inject it back at the time of the response. Baptiste
