Le 29/11/2014 01:09, Willy Tarreau a écrit :
Hi Charles,
On Fri, Nov 28, 2014 at 03:09:05PM +0100, Charles Bijon wrote:
Hi,
I wonder if when using the header rewrite for CORS if
- we can simplify keeping the origin in a variable on the fly and of
course with a list of acl for accept this domain
or
- that one is forced to use a different backend to each domain.
example:
in the backend using :
rspadd Access-Control-Allow-Origin: $(hdr(origin))
But I do not know if this concept of variable is possible with haproxy.
Today, i am using one backend for each origin domain with different way
of "rspadd Access-Control-Allow-Origin: XXXXX" that will be not funny to
manage.
In 1.5 you have a few tricks to achieve this. The simplest one is
exactly the same principle as to what Baptiste explained to Pavlos
in the other thread. The only variables that haproxy carries right
now during a request/response cycle are :
- track-sc keys (only 3 of them and mostly usable as booleans)
- header captures
- logs (which are in fact captures)
There's an extra possibility consisting in capturing payload while
processing the TCP layer. This payload will take a capture slot
exactly like a header. It's sometimes useful to capture non-header
information.
If you just need to capture a header, you can have this in your
frontend :
capture request header origin len 50
And thanks to this, you'll be able to pick it from the responses
with capture.req.hdr(<id>) where <id> is the index of the capture
(typically 0 if this is your only capture).
In your case I'd suggest :
http-response add-header Access-Control-Allow-Origin
%[capture.req.hdr(0)]
As you can see it's a bit ugly. But it should do the job. As a side effect,
unless you redefine your log format, you'll have this origin header logged
between curly braces.
Regards,
Willy
Hi Willy,
Thanks you for this method, i will try it next update on ours fronts
Regards,
Charles
