Re: Sharing configuration between multiple backends
On 9 March 2015 at 00:12, Thrawn shell_layer-git...@yahoo.com.au wrote: Hi, all. Is there a way to share configuration between multiple backends? The use case for this is that we would like to configure different response headers for different parts of our application, based on the request URL, but otherwise route traffic the same way. Specifically, we want to specify 'X-Frame-Options: ALLOW-FROM some site' across most of the application, but just use 'X-Frame-Options: DENY' on the admin area. We could do this, of course, by sending the admin traffic to a different backend, and setting the response header differently in that backend, but then we'd need to repeat our server configuration, hich is otherwise the same. Something like this: frontend foo listen x.x.x.x acl admin url_beg /admin default_backend foo use_backend foo_admin if admin backend foo rspadd X-Frame-Options: ALLOW-FROM some-trusted-server.com potentially complex configuration goes here backend foo_admin rspadd X-Frame-Options: DENY same configuration goes here To reduce the duplication, is it possible to have one backend delegate to another, or specify a named list of servers that can be referenced from different places? I don't know about your specific *question*, but to solve your specific *problem*, you might just use rspadd's conditional form: frontend foo acl admin url_beg /admin rspadd X-Frame-Options: DENY if admin rspadd X-Frame-Options: ALLOW-FROM some-trusted-server.com unless admin default_backend whatever As per https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#rspadd. Dictated but not tested ;-) Jonathan
Re: Sharing configuration between multiple backends
Hi, Jonathan. Thanks for your reply. Unfortunately we can't use a request ACL to perform actions on a response, as per http://marc.info/?l=haproxym=138384425604641w=1 (and our own experience confirms it). The request object is not available any more when the response is being altered. Willy's suggested approach was to use a request ACL to send traffic to a different backend, which can then apply the response action. So, in the case where that backend is almost a duplicate of the first, is there (or should there be) some way to reduce the duplication? Regards Thrawn On 2015-03-09 14:27:09, Jonathan Matthews wrote: I don't know about your specific *question*, but to solve your specific *problem*, you might just use rspadd's conditional form: frontend foo acl admin url_beg /admin rspadd X-Frame-Options: DENY if admin rspadd X-Frame-Options: ALLOW-FROM some-trusted-server.com unless admin default_backend whatever As per https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#rspadd= . Dictated but not tested ;-) Jonathan
Sharing configuration between multiple backends
Hi, again. Looks like I forgot to put a subject header last time I sent this, so I'm guessing it was lost in the spam. Original: Hi, all. Is there a way to share configuration between multiple backends? The use case for this is that we would like to configure different response headers for different parts of our application, based on the request URL, but otherwise route traffic the same way. Specifically, we want to specify 'X-Frame-Options: ALLOW-FROM some site' across most of the application, but just use 'X-Frame-Options: DENY' on the admin area. We could do this, of course, by sending the admin traffic to a different backend, and setting the response header differently in that backend, but then we'd need to repeat our server configuration, hich is otherwise the same. Something like this: frontend foo listen x.x.x.x acl admin url_beg /admin default_backend foo use_backend foo_admin if admin backend foo rspadd X-Frame-Options: ALLOW-FROM some-trusted-server.com potentially complex configuration goes here backend foo_admin rspadd X-Frame-Options: DENY same configuration goes here To reduce the duplication, is it possible to have one backend delegate to another, or specify a named list of servers that can be referenced from different places? Thanks in advance. Thrawn
