Re: [patch] CLEANUP: session: remove event_accept() which was not used anymore
Hi Godbach, On Thu, Jun 20, 2013 at 01:53:43PM +0800, Godbach wrote: > Hi, Willy > > Since event_accept() was not used any more in latest snapshot. There is > a patch in attachment for removing this function for your information. > > The commit log is as follows: > > CLEANUP: session: remove event_accept() which was not used anymore > > Remove event_accept() in include/proto/proto_http.h and use correct > function name in other two files instead of event_accept(). Ah yes good catch. Applied, thank you! Willy
[patch] CLEANUP: session: remove event_accept() which was not used anymore
Hi, Willy
Since event_accept() was not used any more in latest snapshot. There is
a patch in attachment for removing this function for your information.
The commit log is as follows:
CLEANUP: session: remove event_accept() which was not used anymore
Remove event_accept() in include/proto/proto_http.h and use correct
function name in other two files instead of event_accept().
--
Best Regards,
Godbach
From 949b6e22353260b8d36178cb704bb88d4564894a Mon Sep 17 00:00:00 2001
From: Godbach
Date: Thu, 20 Jun 2013 13:28:38 +0800
Subject: [PATCH] CLEANUP: session: remove event_accept() which was not used
anymore
Remove event_accept() in include/proto/proto_http.h and use correct function
name in other two files instead of event_accept().
Signed-off-by: Godbach
---
include/proto/proto_http.h |1 -
include/types/session.h|2 +-
src/peers.c|4 ++--
3 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/include/proto/proto_http.h b/include/proto/proto_http.h
index 24e3581..979219e 100644
--- a/include/proto/proto_http.h
+++ b/include/proto/proto_http.h
@@ -63,7 +63,6 @@ extern char *get_http_auth_buff;
#define HTTP_IS_TOKEN(x) (http_is_token[(unsigned char)(x)])
#define HTTP_IS_VER_TOKEN(x) (http_is_ver_token[(unsigned char)(x)])
-int event_accept(int fd);
int process_cli(struct session *t);
int process_srv_data(struct session *t);
int process_srv_conn(struct session *t);
diff --git a/include/types/session.h b/include/types/session.h
index 00ed4cb..42d37db 100644
--- a/include/types/session.h
+++ b/include/types/session.h
@@ -97,7 +97,7 @@
#define SN_BE_TRACK_ANY 0x00E0 /* union of all SN_BE_TRACK_* above */
-/* WARNING: if new fields are added, they must be initialized in event_accept()
+/* WARNING: if new fields are added, they must be initialized in
session_accept()
* and freed in session_free() !
*/
diff --git a/src/peers.c b/src/peers.c
index 998e61d..83781ba 100644
--- a/src/peers.c
+++ b/src/peers.c
@@ -1094,7 +1094,7 @@ static struct session *peer_session_create(struct peer
*peer, struct peer_sessio
struct task *t;
if ((s = pool_alloc2(pool2_session)) == NULL) { /* disable this proxy
for a while */
- Alert("out of memory in event_accept().\n");
+ Alert("out of memory in peer_session_create().\n");
goto out_close;
}
@@ -1113,7 +1113,7 @@ static struct session *peer_session_create(struct peer
*peer, struct peer_sessio
* it as soon as possible, which means closing it immediately for TCP.
*/
if ((t = task_new()) == NULL) { /* disable this proxy for a while */
- Alert("out of memory in event_accept().\n");
+ Alert("out of memory in peer_session_create().\n");
goto out_free_session;
}
--
1.7.7
Re: Configuring different backends using ACL
Hi Ahmed, small question/clarification request. what happens when you directly browse to the jboss backend? like this http://jbosserver/jboss/ do you get this same "not found" ? So haproxy is then forwarding the request like it should, but what i think you want is that haproxy will forward a request to http://haproxy/jboss/index.html to http://jbossserver/index.html , is that indeed what you want/expect? im not sure thats actually possible.. (also thinking about links send in a response would not point to the subfolder.) greets PiBa-NL Op 19-6-2013 23:26, Lukas Tribus schreef: Hi Ahmed! Any suggestions? Post the complete configuration, inlcuding default, global and all backend sections (checking mode http, httpclose, etc). If that doesn't lead to any conclusion, we will need you to start haproxy in debug mode, capture the request and post it on the list, so we can confront it with the configuration. Regards, Lukas
Re: Debian/Ubuntu packages for HAProxy
❦ 8 juin 2013 00:49 CEST, hapr...@serverphorums.com :
> While it's great to have more Ubuntu packages, especially for the dev
> version, I took a look at the Ubuntu ecosystem and basically all the
> packages are missing the USE_ZLIB to enable gzip compression.
Gzip compression has been added to the latest uploads.
--
panic("huh?\n");
2.2.16 /usr/src/linux/arch/i386/kernel/smp.c
RE: Configuring different backends using ACL
Hi Ahmed! > Any suggestions? Post the complete configuration, inlcuding default, global and all backend sections (checking mode http, httpclose, etc). If that doesn't lead to any conclusion, we will need you to start haproxy in debug mode, capture the request and post it on the list, so we can confront it with the configuration. Regards, Lukas
Re: Configuring different backends using ACL
Hello,
I tried your suggestion and I am still getting a "not found" error in my
browser. It doesn't seem to map "localhost/jboss" to anything for example.
Just to be clear, I do not have any apps of any sort in localhost/jboss, it
is just waht I put in the settings. I assumed that haproxy will still read
that somehow. I think that's where I am stuck, or maybe I missed a step.
Any suggestions?
Note: I did not define a default backend (purposely).
Thanks
On Wed, Jun 19, 2013 at 4:04 PM, Nenad Merdanovic wrote:
> I am obviously missing a slash in the inline ACL example, should be:
>
> use_backend webapp if { path_beg /webapp }
>
> On 06/19/2013 10:01 PM, Nenad Merdanovic wrote:
> > Hello Ahmed,
> >
> > Use path_beg instead of url_beg.
> >
> > Also, naming should be changed as this is very unclear:
> >
> >> frontend http-in
> >> bind localhost:80
> >>
> >> acl is_webapp path_beg /webapp
> >> acl is_jboss path_beg /jboss
> >>
> >> use_backend webapp if is_webapp
> >> use_backend jboss if is_jboss
> >
> > Or even use inline ACLs:
> > use_backend webapp if { path_beg webapp }
> >
> > This is how I usually do it, but it all comes down to a person's
> preference.
> >
> > Regards,
> > Nenad
> >
> > On 06/19/2013 09:46 PM, Ahmed H. wrote:
> >> Hello,
> >>
> >> I found a few examples of this but can't get it to work locally. I have
> >> a local haproxy running on port 80, and I was able to get it to work
> >> with one backend defined. If I open the browser and type "localhost" it
> >> routes me to one of the servers defined in my single backend.
> >>
> >> Now I want to define two backends. Basically I'll have a backend for a
> >> regular web app and one that hosts JBoss apps. How can route the
> >> requests based on the URL I enter? What I tried is the following:
> >>
> >> frontend http-in
> >> bind localhost:80
> >>
> >> acl webapp url_beg /webapp
> >> acl jboss url_beg /jboss
> >>
> >> use_backend webapp if webapp
> >> use_backend jboss if jboss
> >>
> >> Not shown here are the proper backends.
> >>
> >> What I was trying to do was that if i entered "localhost/webapp" in the
> >> browser, it would take me to the webapp backends, and if I entered
> >> "localhost/jboss" it would take me to the jboss backends. That of course
> >> does not work, and I get a "Not found" error.
> >>
> >> How can I achieve what I want to do? Do I have to create something on a
> >> web server? Am I not using the ACL properly?
> >>
> >> Thanks!
> >
>
> --
> Nenad Merdanovic | PGP: 0x423edcb2 | Web: http://nimzo.info
> Linkedin: http://www.linkedin.com/in/nenadmerdanovic
>
Re: Configuring different backends using ACL
I am obviously missing a slash in the inline ACL example, should be:
use_backend webapp if { path_beg /webapp }
On 06/19/2013 10:01 PM, Nenad Merdanovic wrote:
> Hello Ahmed,
>
> Use path_beg instead of url_beg.
>
> Also, naming should be changed as this is very unclear:
>
>> frontend http-in
>> bind localhost:80
>>
>> acl is_webapp path_beg /webapp
>> acl is_jboss path_beg /jboss
>>
>> use_backend webapp if is_webapp
>> use_backend jboss if is_jboss
>
> Or even use inline ACLs:
> use_backend webapp if { path_beg webapp }
>
> This is how I usually do it, but it all comes down to a person's preference.
>
> Regards,
> Nenad
>
> On 06/19/2013 09:46 PM, Ahmed H. wrote:
>> Hello,
>>
>> I found a few examples of this but can't get it to work locally. I have
>> a local haproxy running on port 80, and I was able to get it to work
>> with one backend defined. If I open the browser and type "localhost" it
>> routes me to one of the servers defined in my single backend.
>>
>> Now I want to define two backends. Basically I'll have a backend for a
>> regular web app and one that hosts JBoss apps. How can route the
>> requests based on the URL I enter? What I tried is the following:
>>
>> frontend http-in
>> bind localhost:80
>>
>> acl webapp url_beg /webapp
>> acl jboss url_beg /jboss
>>
>> use_backend webapp if webapp
>> use_backend jboss if jboss
>>
>> Not shown here are the proper backends.
>>
>> What I was trying to do was that if i entered "localhost/webapp" in the
>> browser, it would take me to the webapp backends, and if I entered
>> "localhost/jboss" it would take me to the jboss backends. That of course
>> does not work, and I get a "Not found" error.
>>
>> How can I achieve what I want to do? Do I have to create something on a
>> web server? Am I not using the ACL properly?
>>
>> Thanks!
>
--
Nenad Merdanovic | PGP: 0x423edcb2 | Web: http://nimzo.info
Linkedin: http://www.linkedin.com/in/nenadmerdanovic
Re: Configuring different backends using ACL
Hello Ahmed,
Use path_beg instead of url_beg.
Also, naming should be changed as this is very unclear:
> frontend http-in
> bind localhost:80
>
> acl is_webapp path_beg /webapp
> acl is_jboss path_beg /jboss
>
> use_backend webapp if is_webapp
> use_backend jboss if is_jboss
Or even use inline ACLs:
use_backend webapp if { path_beg webapp }
This is how I usually do it, but it all comes down to a person's preference.
Regards,
Nenad
On 06/19/2013 09:46 PM, Ahmed H. wrote:
> Hello,
>
> I found a few examples of this but can't get it to work locally. I have
> a local haproxy running on port 80, and I was able to get it to work
> with one backend defined. If I open the browser and type "localhost" it
> routes me to one of the servers defined in my single backend.
>
> Now I want to define two backends. Basically I'll have a backend for a
> regular web app and one that hosts JBoss apps. How can route the
> requests based on the URL I enter? What I tried is the following:
>
> frontend http-in
> bind localhost:80
>
> acl webapp url_beg /webapp
> acl jboss url_beg /jboss
>
> use_backend webapp if webapp
> use_backend jboss if jboss
>
> Not shown here are the proper backends.
>
> What I was trying to do was that if i entered "localhost/webapp" in the
> browser, it would take me to the webapp backends, and if I entered
> "localhost/jboss" it would take me to the jboss backends. That of course
> does not work, and I get a "Not found" error.
>
> How can I achieve what I want to do? Do I have to create something on a
> web server? Am I not using the ACL properly?
>
> Thanks!
--
Nenad Merdanovic | PGP: 0x423edcb2 | Web: http://nimzo.info
Linkedin: http://www.linkedin.com/in/nenadmerdanovic
Configuring different backends using ACL
Hello, I found a few examples of this but can't get it to work locally. I have a local haproxy running on port 80, and I was able to get it to work with one backend defined. If I open the browser and type "localhost" it routes me to one of the servers defined in my single backend. Now I want to define two backends. Basically I'll have a backend for a regular web app and one that hosts JBoss apps. How can route the requests based on the URL I enter? What I tried is the following: frontend http-in bind localhost:80 acl webapp url_beg /webapp acl jboss url_beg /jboss use_backend webapp if webapp use_backend jboss if jboss Not shown here are the proper backends. What I was trying to do was that if i entered "localhost/webapp" in the browser, it would take me to the webapp backends, and if I entered "localhost/jboss" it would take me to the jboss backends. That of course does not work, and I get a "Not found" error. How can I achieve what I want to do? Do I have to create something on a web server? Am I not using the ACL properly? Thanks!
Re: 'SSL handshake failure' errors
Thank you Lukas. We will see whether SSLv3 improves things. Best, Merton On Wed, Jun 19, 2013 at 1:15 AM, Lukas Tribus wrote: > Hi Merton! > > > don't forget to CC the mailing-list :) > > > > Out of the 5 possible causes you listed, we probably can't do much > > about the other ones. But we can control the above two from our end. I > > suppose that most 'modern' browsers nowadays should be able to do TLS > > v1.0, and SSLv3 is considered as a weaker choice (But I wonder if it > > will make more compatible for clients to support both TLSv1.0 and > > SSLv3?). The specific ciphers we've chosen is to speed up the SSL but > > it might 'screen out' some clients. > > The issue is probably with embedded, mobile and outdated browsers. > If you have a 5 year old Windows CE phone, chances are it will connect > in SSLv3 only (for example). > > > > > We also see in the log that some clients connected/handshake > > successfully initially on some page, but failed the handshake in > > subsequent requests to other parts of the site. > > Keep in mind that a browsers may open a connection to accelerate a > _possible_ future HTTP transaction - and if the users doesn't request > another page, the connection will just be dropped. > > Those optimizations in browsers can trigger warnings on the server-side. > > > > > Any suggestion on making SSL as much compatible as possible while > > keeping it fast? > > You may enable SSLv3 again and monitor the log. > > > > Regards, > > Lukas
Re: RFC: set-tos followup
Hi Lukas, On Wed, Jun 19, 2013 at 02:46:20PM +0200, Lukas Tribus wrote: > > if you have anything that needs the destination address (logs, > > transparent, ...) then conn_get_to_addr() is called early and > > the address is properly set. > > Oh, ok. Well I use a minimalistic configuration when testing. I tend to reuse existing test configs, which brings all sort of entropy :-) > > It was intentional, as looking at the specs, I really did not feel like > > we could use the same classes nor the same method to set them. > > I will quote RFC3260 for this: > > > Diffserv uses six bits of the IPV4 or IPV6 header to convey the > > Diffserv Codepoint (DSCP), which selects a PHB. RFC 2474 attempts to > > rename the TOS octet of the IPV4 header, and Traffic Class octet of > > the IPV6 header, respectively, to the DS field. > > [...] > > The IPV4 Type-of-Service (TOS) field and the IPV6 traffic class > > field are superseded by the 6 bit DS field and a 2 bit CU field > > [...] > > The two least significant bits of the IPV4 TOS octet and the IPV6 > > Traffic Class octet are not used by Diffserv. > > > > When RFC 2474 is updated, consideration should be given to changing > > the designation "currently unused (CU)" to "explicit congestion > > notification (ECN)" and referencing RFC 3168 (or its successor). > > So basically IPv4's TOS is the exact same thing as IPv6's traffic class, > including the bits for ECN. > > I have "http-response set-tos 0x30" in my frontent and wireshark correctly > indentifies the ipv6 traffic with the correct class, tcpdumps does it as > well (class 0x30): > > 14:21:43.918537 IP6 (class 0x30, hlim 64, next-header TCP (6) payload > length: 1460) fe80::a00:27ff:fe8e:1c44.http> fe80::55c8:982:a13:8f73.50360: > Flags [.], cksum 0x485f (incorrect -> 0x927f), seq 1568:3008, ack 702, win > 1034, length 1440 OK, that seems pretty clear then! > > I don't even know what method we can use to set the flags in this case. > > Maybe using the IPv4 method works? > > I will play around with this, but I suspect we will not be able to cope > with it from userspace. > > > One is a fix (to->from) and can as well include the doc fix. The other > > one is an improvement that will possibly need to be iteratively reworked > > later after some testing. > > Perfect, I will bring them in a commitable form. OK thanks, Willy
RE: RFC: set-tos followup
Hi! > if you have anything that needs the destination address (logs, > transparent, ...) then conn_get_to_addr() is called early and > the address is properly set. Oh, ok. Well I use a minimalistic configuration when testing. > It was intentional, as looking at the specs, I really did not feel like > we could use the same classes nor the same method to set them. I will quote RFC3260 for this: > Diffserv uses six bits of the IPV4 or IPV6 header to convey the > Diffserv Codepoint (DSCP), which selects a PHB. RFC 2474 attempts to > rename the TOS octet of the IPV4 header, and Traffic Class octet of > the IPV6 header, respectively, to the DS field. > [...] > The IPV4 Type-of-Service (TOS) field and the IPV6 traffic class > field are superseded by the 6 bit DS field and a 2 bit CU field > [...] > The two least significant bits of the IPV4 TOS octet and the IPV6 > Traffic Class octet are not used by Diffserv. > > When RFC 2474 is updated, consideration should be given to changing > the designation "currently unused (CU)" to "explicit congestion > notification (ECN)" and referencing RFC 3168 (or its successor). So basically IPv4's TOS is the exact same thing as IPv6's traffic class, including the bits for ECN. I have "http-response set-tos 0x30" in my frontent and wireshark correctly indentifies the ipv6 traffic with the correct class, tcpdumps does it as well (class 0x30): 14:21:43.918537 IP6 (class 0x30, hlim 64, next-header TCP (6) payload length: 1460) fe80::a00:27ff:fe8e:1c44.http> fe80::55c8:982:a13:8f73.50360: Flags [.], cksum 0x485f (incorrect -> 0x927f), seq 1568:3008, ack 702, win 1034, length 1440 > I don't even know what method we can use to set the flags in this case. > Maybe using the IPv4 method works? I will play around with this, but I suspect we will not be able to cope with it from userspace. > One is a fix (to->from) and can as well include the doc fix. The other > one is an improvement that will possibly need to be iteratively reworked > later after some testing. Perfect, I will bring them in a commitable form. Regards, Lukas
Re: HAProxy 1.5-dev18 logs messages twice
Dinko Korunic wrote: > On 18.06.2013 17:36, Chris Fryer wrote: > [...] > >> I notice that each request is logged once, then logged again immediately >> before the next request is logged. If there is no "next" request, the >> request is logged a second time after a pause of between 60 and 70 seconds. >> >> If I comment out the "log global" line from the frontend configuration, >> only one request is logged. >> >> This did not used to happen with HAProxy 1.4 > > Hi, > > This is due to 1.5 supporting several log targets, so in your > configuration that's effectively having same log target twice. I've > reported this and the explanation was that it's known and intended behavior. Thanks. Needless to say, this is not apparent from the documentation, so perhaps that should be updated to reflect this state of affairs. Regards, Chris Please access the attached hyperlink for an important electronic communications disclaimer: http://lse.ac.uk/emailDisclaimer
Re: HAProxy 1.5-dev18 logs messages twice
On 18.06.2013 17:36, Chris Fryer wrote: [...] > I notice that each request is logged once, then logged again immediately > before the next request is logged. If there is no "next" request, the > request is logged a second time after a pause of between 60 and 70 seconds. > > If I comment out the "log global" line from the frontend configuration, > only one request is logged. > > This did not used to happen with HAProxy 1.4 Hi, This is due to 1.5 supporting several log targets, so in your configuration that's effectively having same log target twice. I've reported this and the explanation was that it's known and intended behavior. Kind regards, D. -- Dinko Korunic PGP:0xEA160D0B R&D Department Manager at Reflected
Re: RFC: set-tos followup
Hi Lukas, On Wed, Jun 19, 2013 at 02:03:18AM +0200, Lukas Tribus wrote: > Hi! > > I gave the new set-tos option a try, and I noticed two things: > > - addr.to.ss_family is never AF_INET, addr.from.ss_family is what we are > looking for (after this change, it works for IPv4) I was a bit puzzled wondering why it worked for me, and I found. It only depends on the config, and if you have anything that needs the destination address (logs, transparent, ...) then conn_get_to_addr() is called early and the address is properly set. So I agree with you that it's the from we want here. > - the IPv6 related part is missing (TOS/DSCP has the same meaning in IPv6 > than in IPv4, so if addr.from.ss_family is AF_INET6, we can imho go > ahead and set IPV6_TCLASS from set-tos) It was intentional, as looking at the specs, I really did not feel like we could use the same classes nor the same method to set them. But the DSCP specs are a bit foggy to me so I might have overlooked something. > The attached preliminary diff does those two things (and a small doc fix), > however I need some commentary about: > > - if IPV6_TCLASS is not defined, we abort (even though IP_TOS may be > defined, and IPv4 TOS/DSCP could be set) - is this acceptable? The only > way around this would be a dedicated option for IPv6, but that seems > overkill We sure don't want a dedicated action, but before trying to set the TOS on IPv6, I'd like to be confirmed it uses the same values. > - when haproxy listens on both families with one bind statement, it sees > IPv4 connection in the AF_INET6 family (like :::10.0.0.3 instead of > 10.0.0.3): when this happens, we set IPV6_TCLASS, but it has no effect. > Probably expected kernel behavior and I believe most of the people use > dedicate (per address-family) sockets anyway. Good point, I didn't think about this case either. I don't even know what method we can use to set the flags in this case. Maybe using the IPv4 method works ? > Let me know what you guys think about this. > > Willy, do you prefer such a diff like this to be splitted in 2 or 3 patches > or as-is? It would probably be better to split at least the technical ones > into different commits (so a git-bisect is more meaningful). I'd prefer several patches. One is a fix (to->from) and can as well include the doc fix. The other one is an improvement that will possibly need to be iteratively reworked later after some testing. Best regards, Willy
RE: ACL file encoding/ACE
Hi Daniel, > In Norway our customers can register domains with the norwegian letters > æøå. Does this switch work with haproxy if the norwegian letters are > used? The browser doesn't send the norwegian characters in the HTTP transaction, its masked by the "punycode" [1]. Use the ascii representation (as on the wire) and you will we fine. > If so, what encoding should we use on the txt file? ASCII. No special characters. Read about punycode [1]. > Can we specify the domains in ACE format insted? You mean the compression format? No, you cannot. [1] http://en.wikipedia.org/wiki/Punycode Regards, Lukas
ACL file encoding/ACE
Hi. I love that you can specify to use a file in the acl like this for domain switching: acl is_backend1 hdr(Host) -f /etc/haproxy/backend1.txt In Norway our customers can register domains with the norwegian letters æøå. Does this switch work with haproxy if the norwegian letters are used? If so, what encoding should we use on the txt file? Can we specify the domains in ACE format insted? Thanks Daniel
