Re: HAProxy and SNI
Forget about it, I found it in the git:
this is a brilliant news :)
req_ssl_sni string
Returns true when data in the request buffer looks like a complete SSL (v3
or superior) client hello message with a Server Name Indication TLS extension
(SNI) matching string. SNI normally contains the name of the host the
client tries to connect to (for recent browsers). SNI is useful for allowing
or denying access to certain hosts when SSL/TLS is used by the client. This
test was designed to be used with TCP request content inspection. If content
switching is needed, it is recommended to first wait for a complete client
hello (type 1), like in the example below.
Examples :
# Wait for a client hello for at most 5 seconds
tcp-request inspect-delay 5s
tcp-request content accept if { req_ssl_hello_type 1 }
use_backend bk_allow if { req_ssl_sni -f allowed_sites }
default_backend bk_sorry_page
On Thu, Mar 29, 2012 at 7:48 PM, Baptiste bed...@gmail.com wrote:
Hey Willy,
I read sooner in January you mentioned that HAProxy is now able to
handle SNI, but I can't find anywhere in the documentation how I can
do it.
(and ebr spoke about it in the office as well).
Can you point me to the right section in the documentation please?
Cheers
Re: Copying a Header before Modifying it
Baptiste wrote: On Thu, Mar 29, 2012 at 11:42 PM, William Lewis m...@wlewis.co.uk wrote: Hi Cyril, Cyril Bont wrote: Hi William, Le 29/03/2012 14:30, William Lewis a crit : Hi, So I use Haproxy to rewrite some URL requests infront of my java webservers, but I also want my java webservers to be able to issue redirects relative to the url that hit haproxy. Specifically I want the developers that have access to application platform but not the haproxy to be able to enforce a resource is only accessible over https without me having to write a rule in the haproxy config. In this case they just need to be able to get the original request and send back a 403 redirect with https:// on the front, of course they don't see the original url so this is a problem. I tried solving it with this rule reqirep ^((HEAD|GET|POST|PUT|DELETE|TRACE|OPTIONS|CONNECT|PATCH)\ ([^\ ]*)\ HTTP/1.[01]) \1\nX-Original-Request:\ \3 run before any of the rewrite rules e.g. reqrep ^([^\ \t]*[\ \t])(.*) \1/tomcatcontext\2 This results in a request to the webserver which looks like GET /tomcatcontext/ HTTP/1.1 X-Original-Request: / Host: example.com Connection: keep-alive ... This all works great until you then try and do some acl matching in the haproxy, because an acl like acl example-com hdr_end(host) -i example.com will no longer match. It should (tested quicky here), can you provide us the version of haproxy you're using ? I remember there was a bug in old 1.4 versions concerning headers manipulation. I was using 1.4.19 but have just updated to 1.4.20 and still having the same problem, complete example config below global daemon quiet maxconn 1024 pidfile /home/haproxyblue/haproxy.pid uid 20003 gid 20003 chroot /home/haproxyblue log 127.0.0.1 local0 log 127.0.0.1 local1 notice defaults log global option httplog balance roundrobin mode http retries 3 option redispatch timeout connect 30 timeout client 30 timeout server 30 frontend http-in bind *:80 reqirep ^((HEAD|GET|POST|PUT|DELETE|TRACE|OPTIONS|CONNECT|PATCH)\ ([^\ ]*)\ HTTP/1.[01]) \1\nX-Original-Request:\ \3 acl test hdr_end(host) -i example.com reqrep ^([^\ \t]*[\ \t])(.*) \1/tomcatcontext\2 if test use_backend echo if test backend echo mode http option http-server-close option forwardfor server echo1 127.0.0.1: Hi, You hould enable http-server-close on the frontend side as well. Or better, put it in the defaults. cheers I've added http-server-close to the defaults and the acl still doesn't match when I write the X-Original-Request header.
Re: Copying a Header before Modifying it
Hi all, Le 30/03/2012 12:27, William Lewis a écrit : Baptiste wrote: (...) You hould enable http-server-close on the frontend side as well. Or better, put it in the defaults. cheers I've added http-server-close to the defaults and the acl still doesn't match when I write the X-Original-Request header. Actually, there's a comment in the code which talks about this issue : /* FIXME: if the user adds a newline in the replacement, the * index will not be recalculated for now, and the new line * will not be counted as a new header. */ As a side effect, headers indexes do not point to the right position. This means that acls do not match anymore, which is what you observe. It appears several times in the code, the one that concerns this issue in the function apply_filter_to_req_line() in src/proto_http.c -- Cyril Bonté
Re: haproxy 1.5dev7 server check failed with IPv6
On 03/29/2012 10:20 PM, Sander Klein wrote: Are you sure it's not an config error on the webserver side? I've been running dev7 for quite some time and do a lot of IPv6 checks. Never had any problems with it. Same here. Best regards, Brane
Re: Copying a Header before Modifying it
Hi again,
Le 30/03/2012 13:24, Cyril Bonté a écrit :
Hi all,
Le 30/03/2012 12:27, William Lewis a écrit :
Baptiste wrote:
(...)
You hould enable http-server-close on the frontend side as well.
Or better, put it in the defaults.
cheers
I've added http-server-close to the defaults and the acl still doesn't
match when I write the X-Original-Request header.
Actually, there's a comment in the code which talks about this issue :
/* FIXME: if the user adds a newline in the replacement, the
* index will not be recalculated for now, and the new line
* will not be counted as a new header.
*/
As a side effect, headers indexes do not point to the right position.
This means that acls do not match anymore, which is what you observe.
It appears several times in the code, the one that concerns this issue
in the function apply_filter_to_req_line() in src/proto_http.c
Please find in attachment a quick and *dirty* fix to realign the headers
indexes for your case (based on haproxy 1.4.20).
Maybe this can help you.
--
Cyril Bonté
--- ./haproxy-1.4.20/src/proto_http.c 2012-03-10 21:06:21.0 +0100
+++ ./haproxy-1.4.20-newline/src/proto_http.c 2012-03-30 15:14:31.127457646 +0200
@@ -5849,12 +5849,20 @@
http_msg_move_end(txn-req, delta);
cur_end += delta;
- cur_end = (char *)http_parse_reqline(txn-req, req-data,
- HTTP_MSG_RQMETH,
- cur_ptr, cur_end + 1,
- NULL, NULL);
- if (unlikely(!cur_end))
-return -1;
+ /* Quick and dirty hack to realign headers indexes if the user adds a newline
+ * in the replacement.
+ */
+ {
+char *cur_end2 = (char *)http_parse_reqline(txn-req, req-data,
+ HTTP_MSG_RQMETH,
+ cur_ptr, cur_end + 1,
+ NULL, NULL);
+if (unlikely(!cur_end2))
+ return -1;
+if (cur_end - cur_end2 0) {
+ txn-req.sl.rq.l += cur_end - cur_end2;
+}
+ }
/* we have a full request and we know that we have either a CR
* or an LF at ptr.
Surge 2012 CFP is Open!
Surge 2012, the scalability conference, September 27-28, Baltimore, MD has opened its CFP. Please visit http://omniti.com/surge/2012/cfp for details. -- Katherine Jeschke Director of Marketing and Creative Services OmniTI Computer Consulting, Inc. 7070 Samuel Morse Drive, Ste.150 Columbia, MD 21046 O: 443-325-1357, 222 F: 410/872-4911 C: 443/643-6140 omniti.com Surge2012: http://omniti.com/surge/2012 PG Corridor Days - DC: http://pgday.bwpug.org/ The information contained in this electronic message and any attached documents is privileged, confidential, and protected from disclosure. If you are not the intended recipient, note that any review, disclosure, copying, distribution, or use of the contents of this electronic message or any attached documents is prohibited. If you have received this communication in error, please destroy it and notify us immediately by telephone (1-443-325-1360) or by electronic mail (i...@omniti.com). Thank you.
Can we perform rsp_add for specified hosts?
Hi, All I need insert Set-Cookie response header for specified request(host) I start with creating following two lines of configuration acl rsptest hdr_beg(host) -i www.google.com rspadd Set-Cookie:\ GOOGLEID=123456 if rsptest But all i got is following warning: acl 'rsptest' involves some volatile request-only criteria which will be ignored. So, do we support rsp_add for specified hosts and how? -- *Fred Hu* *Best Regards*
Re: Can we perform rsp_add for specified hosts?
Hi, You're trying to insert a RESPONSE header if a REQUEST header exists. It may not work, either never match or always match. I mean that your acl has an undetermined state when called. You should match something from the response to be sure it works. regards On Sat, Mar 31, 2012 at 5:51 AM, fred hu frederick...@gmail.com wrote: Hi, All I need insert Set-Cookie response header for specified request(host) I start with creating following two lines of configuration acl rsptest hdr_beg(host) -i www.google.com rspadd Set-Cookie:\ GOOGLEID=123456 if rsptest But all i got is following warning: acl 'rsptest' involves some volatile request-only criteria which will be ignored. So, do we support rsp_add for specified hosts and how? -- Fred Hu Best Regards
