Thx Baptiste,

I will go this way so.

Thx for the tip with health check tracking.


Regards,


On Thu, Jul 11, 2013 at 11:33 AM, Baptiste <bed...@gmail.com> wrote:

> Hi Steven,
>
> Interesting case.
>
> I would say you could set gpc0 value, but unfortunately, there is
> currently no way to set its value. You can only increase it using
> sc0_inc_gpc0.
> My purpose would to use gpc0 as a flag.
>
> So the best way for you for now is to use multiple backends.
> (You already might know, but you can track health checking from one
> backend to an other one, to avoid sending too many health checks to a
> single server).
>
> By the way, rspadd will be deprecated in favor of http-response.
>
> Baptiste
>
>
> On Wed, Jul 10, 2013 at 6:44 PM, Steven Le Roux <ste...@le-roux.info>
> wrote:
> > Hi all (first message on list :) ),
> >
> > In the process of migrating from httpd to haproxy for a reverse proxy
> > purpose, I'm facing a dilemma about how to set a response header
> according
> > to request URI.
> >
> > I explain :
> >
> > There are four file types that I want to handle :
> >
> > statics : *.js *.css *.png *.txt ...
> > static_ : *.cache.*
> > nocache : *.nocache.*
> > others...
> >
> > So I've set up some ACLs like this :
> >
> >   acl p-url_statics  path_end -i .html .htm .phpt
> >   acl p-url_statics  path_end -i .jpg .jpeg .gif .png .bmp .tif .tiff
> .eps
> > .ai .nef .ico .swf
> >   acl p-url_statics  path_end -i .css .js
> >   acl p-url_statics  path_end -i .txt .sql .csv .log
> >  ...
> >   acl p-url_static_  path_sub -i _static_ .cache.
> >   acl p-url_private  path_sub -i _private_
> >   acl p-nocache      path_sub -i .nocache.
> >
> > I know I can't directly rspadd based on those ACLs, so I use a
> stick-table
> > with tcp-request inspection :
> >
> >   tcp-request content track-sc0 always_true if p-url_statics !p-nocache
> > !p-url_static_
> >   tcp-request content track-sc1 always_true if p-url_static_ !p-nocache
> >   tcp-request content track-sc2 always_true if p-nocache
> >
> > This way I can :
> >
> >   http-response set-header Cache-Control no-store,no-cache
> >   http-response set-header Cache-Control
> > no-cache="Set-Cookie,Set-Cookie2",max-age=604800 if { sc0_tracked }
> >   http-response set-header Cache-Control
> > no-cache="Set-Cookie,Set-Cookie2",max-age=31536000 if { sc1_tracked }
> >   http-response set-header Cache-Control
> > no-store,no-cache,max-age=0,must-revalidate if { sc2_tracked  }
> >
> > The problem here is I need to use the option httpclose/forceclose to
> break
> > "Connection: keepalive" establishment provided by client browsers, so
> it's
> > potentially slowing down L4 exchanges, needing new handshakes... and
> forbid
> > tcp reuse from the L4 load balancer.
> >
> > The other problem is that I don't have any other sticky counter
> available to
> > match request ACLs with response header manipulation like :
> >
> >   acl h-origin-X-Y  hdr(Origin) -i @url@
> >   rspadd Access-Control-Allow-Origin: @url@ if  h-origin-X-Y  h-host-X
> >
> >
> > The other way I'm considering, is to multiple backends for each of my
> > vhosts... which seem not the best option since I have multiple of them...
> > but it's possible to decline like this :
> >
> > bk_@backendID@
> >   ...
> > bk_@backendID@_statics
> >   ...
> > bk_@backendID@_static_
> >   ...
> > bk_@backendID@_nocache
> >   ...
> >
> > with the same configuration (options, health-check, servers, cookie
> > management,...) but specific "rspadd Cache-Control"...
> >
> > Backends with static handling could be free of cookie/stick-table
> handling
> > anyway.
> >
> > I fear it will create a useless health checks noise... since it will be
> > driven by backend...
> >
> > Many backends for just adding a header seem overkill to me because I have
> > already 6000 backends for 20 frontends and an haproxy.conf sizing 5MB
> which
> > takes few seconds to be loaded.
> >
> > Does someone have a best pratice to deal with this dilemma ? Is there any
> > other way to go that I missed ?
> >
> > Thx !
> >
> > Regards,
> >
> > --
> > Steven Le Roux
> > Jabber-ID : ste...@jabber.fr
> > 0x39494CCB <ste...@le-roux.info>
> > 2FF7 226B 552E 4709 03F0  6281 72D7 A010 3949 4CCB
>



-- 
Steven Le Roux
Jabber-ID : ste...@jabber.fr
0x39494CCB <ste...@le-roux.info>
2FF7 226B 552E 4709 03F0  6281 72D7 A010 3949 4CCB

Reply via email to