http-server-close

2013-02-28 Thread Jay Christopherson
I'm brand new to haproxy, having just implemented it this week.  So far,
it's been great.

We are using it in front of a series of Apache web servers using mod_php.
 I've seen some notes around that indicate you can (or should) disable
KeepAlive on your Apache servers and use option http-server-close to do
client side keepalive using HAproxy, which seems like a good idea in our
case.

What I'm wondering is, what is the case for using http-server-close in a
frontend vs. backend, or both?  I have some other front and backends that I
specifically don't want keepalive, so I don't want to set it in defaults.

Thanks!
Jay


Re: a cleaner/correct way to filter by IP/destination?

2013-03-13 Thread Jay Christopherson

or better: (latest haproxy 1.5):
http-request deny if is_stats !is_owner


Awesome, works like a charm.  Thanks!

On Wed, Mar 13, 2013 at 1:55 PM, Baptiste bed...@gmail.com wrote:

 Hi Jay,

 This may work if /stats is not hosted on same servers as application
 servers.
 You should better use something like :
 block if is_stats !is_owner

 or better: (latest haproxy 1.5):
 http-request deny if is_stats !is_owner

 Baptiste


 On Wed, Mar 13, 2013 at 9:22 PM, Jay Christopherson
 jc.listm...@gmail.com wrote:
  I'm playing with filter access to a specific URI by IP, like listed
 below.
  What I want is to have ALL requests for /stats be filtered through a
 list of
  IP's.  If you aren't on the list, no access is provided.
 
  frontend http
mode http
bind *:80
acl is_stats url_beg /stats
acl is_owner_ip 1.2.3.4 5.6.7.0/24
use_backend admin if is stats is_owner
default_backend web
 
  backend admin
... servers ...
 
  backend web
... servers ...
 
  Questions:
 
  1.  Is this going to work like I expect?  I'm questioning whether it
 would
  be possible for a user to hit /stats because I have a default_backend.
  It
  seems like there could be a route past that backend filter.  Maybe a user
  not in the IP filter requests /stats -- wouldn't that use the
  default_backend then?  It seems like it wouldn't match my use_backed
  definition and so would continue on to the default.
  2.  Is there a cleaner way to do this by combining into a single ACL,
  assuming the logic I have here is correct?
 
  Thanks!



hdr_sub / checking for cookie

2013-05-21 Thread Jay Christopherson
I have a use case where I need to setup an acl to simply check for the
existence of a cookie by name.  I don't really care what's in it.  I was
thinking to use hdr_sub for this, but part of the syntax seems to be a
string to look for.  In my case, I either don't care what the string is
or it might be randomized.

acl cookie_is_set hdr_sub(cookie) some_string

Is there an better way to just check for the existence (but not the
contents) of a cookie, by name?

Thanks!


Re: hdr_sub / checking for cookie

2013-05-21 Thread Jay Christopherson
Never mind, seems like hdr_cnt will probably be the best solution here.


On Tue, May 21, 2013 at 2:22 PM, Jay Christopherson
jc.listm...@gmail.comwrote:

 I have a use case where I need to setup an acl to simply check for the
 existence of a cookie by name.  I don't really care what's in it.  I was
 thinking to use hdr_sub for this, but part of the syntax seems to be a
 string to look for.  In my case, I either don't care what the string is
 or it might be randomized.

 acl cookie_is_set hdr_sub(cookie) some_string

 Is there an better way to just check for the existence (but not the
 contents) of a cookie, by name?

 Thanks!



logging specific ACLs?

2014-01-20 Thread Jay Christopherson
Is there a way to log specific acl's?  I have some ACL's that I'm using to
filter specific traffic - something like this:

acl forbidden something something
acl forbidden something_else something_else
acl forbidden this that
acl forbidden and_the other
block if forbidden

On the whole, it seems to work fine.  However, a  few reports are filtering
in that make me suspicious that it might be affecting a very small sub-set
of valid users.  The ACl's are basically doing some header validation
(content-length, etc...).  I'd like to be able to log the blocks being
made on that acl, but I'm not sure if that is possible.  I checked the docs
and didn't see anything like that and my normal logging setup isn't
printing anything useful.  I bumped up to debug and still don't see
anything like what I am looking for.

Thanks!
Jay


compression and q-values?

2014-03-14 Thread Jay Christopherson
It appears that HAproxy is not honoring q-values in the Accept-Encoding
header, when requesting compression.

When I run a curl command with Accept-Encoding:gzip (no q-value), I get
back an expected response:

#curl -svo /dev/null
http://something/js/global-main-7b2ca6b.jshttp://origin.cdn.creativelive.com/js/global-main-7b2ca6b.js
-HAccept-Encoding: gzip

*Date: Fri, 14 Mar 2014 19:20:28 GMT*
*Content-Type: application/x-javascript*
*Last-Modified: Fri, 14 Mar 2014 05:35:33 GMT*
*ETag: 53229525-56f6d*
*Access-Control-Allow-Origin: **
*Access-Control-Allow-Credentials: true*
*Access-Control-Allow-Methods: GET, POST, OPTIONS*
*Access-Control-Allow-Headers:
DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type*
*Accept-Ranges: bytes*
*Transfer-Encoding: chunked*
*Content-Encoding: gzip*

However, if I run a 'curl' command with a q-value on the Accept-Encoding
parameter, I get:

# curl -svo /dev/null
http://something/js/global-main-7b2ca6b.jshttp://origin.cdn.creativelive.com/js/global-main-7b2ca6b.js
-HAccept-Encoding: gzip;q=1.000

*Date: Fri, 14 Mar 2014 19:47:10 GMT*

*Content-Type: application/x-javascript*

*Content-Length: 356205*

*Last-Modified: Fri, 14 Mar 2014 05:35:30 GMT*

*ETag: 53229525-56f6d*
*Access-Control-Allow-Origin: **
*Access-Control-Allow-Credentials: true*
*Access-Control-Allow-Methods: GET, POST, OPTIONS*
*Access-Control-Allow-Headers:
DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type*
*Accept-Ranges: bytes*


On HAproxy, I have this setup on my frontend:

frontend web
mode http
bind *:80
bind *:443 ssl crt /etc/haproxy/certs/web.pem crt
/etc/haproxy/certs/
log-format %ST|%fp|%CC|%Ts|%ci|%r|%hr
capture cookie cc= len 63
option http-server-close
option forwardfor
capture request header User-Agent len 128
capture request header Host len 64
errorloc303 504 /live.html
errorloc303 503 /live.html
errorloc303 502 /live.html
maxconn 5000
*compression algo gzip*
*compression type text/html text/plain text/css text/javascript
application/javascript application/x-javascript*


Am I missing something or does HAproxy not support q-values?


Thanks!

Jay