response header whitelisting
Hello
Is it possible to do {response,request} header whitelisting in HAProxy?
Initially I want to allow only certain headers from the backend.
Regards,
Oskar Liljeblad
Re: debian repository http://haproxy.debian.net/
just in case, last update failed: Setting up haproxy (1.5~dev26-1~bpo70+1) ... Starting haproxy: haproxy/usr/sbin/haproxy already running. failed! invoke-rc.d: initscript haproxy, action start failed. dpkg: error processing haproxy (--configure): It depends on what you mean by the haproxy team. They come from the team that maintains the package in Debian itself, that means Debian developers and maintainers and not HAProxy developers. Regards, Apollon
Re: debian repository http://haproxy.debian.net/
On 11:14 Wed 04 Jun , Ghislain wrote: just in case, last update failed: Setting up haproxy (1.5~dev26-1~bpo70+1) ... Starting haproxy: haproxy/usr/sbin/haproxy already running. failed! invoke-rc.d: initscript haproxy, action start failed. dpkg: error processing haproxy (--configure): Ah, that's a bug in the initscript with upgrades from 1.5~dev24+. We'll fix it soon, thanks for the report. Apollon
Re: Error 408 with Chrome
2014-05-26 16:13 GMT+02:00 Willy Tarreau w...@1wt.eu: Hi Arnall, On Mon, May 26, 2014 at 11:56:52AM +0200, Arnall wrote: Hi Willy, same problem here with Chrome version 35.0.1916.114 m and : HA-Proxy version 1.4.22 2012/08/09 (Debian 6) Kernel 3.8.13-OVH HA-Proxy version 1.5-dev24-8860dcd 2014/04/26 (Debian GNU/Linux 7.5) Kernel 3.10.13-OVH htmlbodyh1408 Request Time-out/h1 Your browser didn't send a complete request in time. /body/html Timing : Blocking 2ms / Receiving : 1ms Where are you measuring this ? I suspect on the browser, right ? In this case it confirms the malfunction of the preconnect. You should take a network capture which will be usable as a reliable basis for debugging. I'm pretty sure that what you'll see in fact is the following sequence : browser haproxy --- connect -- ... long pause ... 408 + FIN --- ... long pause ... --- send request - RST - And you see the error in the browser immediately. The issue is then caused by the browser not respecting this specific rule : http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-26#section-6.5 A client or server that wishes to time-out SHOULD issue a graceful close on the connection. Implementations SHOULD constantly monitor open connections for a received closure signal and respond to it as appropriate, since prompt closure of both sides of a connection enables allocated system resources to be reclaimed. ... A client sending a message body SHOULD monitor the network connection for an error response while it is transmitting the request. If the client sees a response that indicates the server does not wish to receive the message body and is closing the connection, the client SHOULD immediately cease transmitting the body and close its side of the connection. Anyway, from the various reports we get, it seems like sending an empty 408 message is enough to workaround this abnormal Chrome behaviour. For this you can proceed like this : errorfile 408 /dev/null After days of tests it appears that 408 error page are still appening, but less frequently. I don't know how but I can see them on my logs and on my browser. Note however that it breaks HTTP in that it prevents client from knowing whether the request was processed or not. The 408 message provides *exactly* this information : http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-26#section-6.5.7 The 408 (Request Timeout) status code indicates that the server did not receive a complete request message within the time that it was prepared to wait. A server SHOULD send the close connection option (Section 6.1 of [Part1]) in the response, since 408 implies that the server has decided to close the connection rather than continue waiting. If the client has an outstanding request in transit, the client MAY repeat that request on a new connection. With only a silent close (as Chrome seems to expect it), the client cannot reasonably retry without violating a strict HTTP rule : http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-26#section-6.3.1 A user agent MUST NOT automatically retry a request with a non- idempotent method unless it has some means to know that the request semantics are actually idempotent, regardless of the method, or some means to detect that the original request was never applied. Regards, Willy
Re: Error 408 with Chrome
On Wed, Jun 04, 2014 at 04:49:53PM +0200, Kevin Maziere wrote: Anyway, from the various reports we get, it seems like sending an empty 408 message is enough to workaround this abnormal Chrome behaviour. For this you can proceed like this : errorfile 408 /dev/null After days of tests it appears that 408 error page are still appening, but less frequently. I don't know how but I can see them on my logs and on my browser. In the logs it's perfectly normal as haproxy reports what has been done, but in the browser, it's really not possible since the error message was replaced with the contents of /dev/null. What might happen is either that some requests go to another haproxy or another server which still emits the error, or that such errors were abusively cached by the client which reports them on closed connection. Regards, Willy
Re: Error 408 with Chrome
Hello Kevin, On 06/04/2014 05:05 PM, Willy Tarreau wrote: On Wed, Jun 04, 2014 at 04:49:53PM +0200, Kevin Maziere wrote: Anyway, from the various reports we get, it seems like sending an empty 408 message is enough to workaround this abnormal Chrome behaviour. For this you can proceed like this : errorfile 408 /dev/null After days of tests it appears that 408 error page are still appening, but less frequently. I don't know how but I can see them on my logs and on my browser. In the logs it's perfectly normal as haproxy reports what has been done, but in the browser, it's really not possible since the error message was replaced with the contents of /dev/null. What might happen is either that some requests go to another haproxy or another server which still emits the error, or that such errors were abusively cached by the client which reports them on closed connection. Regards, Willy Can you post your latest configuration? Regards, -- Nenad Merdanovic | PGP: 0x423edcb2 | Web: http://nimzo.info Linkedin: http://www.linkedin.com/in/nenadmerdanovic
VPrivées : DA ACTIVE-CEINTURES SILICONE-Promo : COMPEX-SIGG-Nouveau:FITSIP-TICKET TO THE MOON
Offres exclusives sur les produits du site Allsportshop.fr Version en ligne | Ajouter Allsportshop à votre carnet d’adresses VENTES PRIVÉES GOURDE SIGG TEXTILE CYCLE HIGH TECH FITNESS OUTDOOR GLISSE URBAINE VENTES PRIVÉES CEINTURES SILICONE: Avec ces ceintures et leurs boucles interchangeables, combinez les couleurs à l'infini. -50% + 1 boucle offerte. CEINTURES FANTAISIE : ALLSPORTSHOP.fr vous propose deux modèles de ceintures aux boucles fantaisie à -50% RÉASSORT DA ACTIVE : -50% sur les vêtements sportifs féminins DA ACTIVE. Jusqu'au Mardi 10 Juin 17 Modèles disponibles Ceintures Silicone Choisissez la couleur de votre boucle supplémentaire offerte 29,90€ 14,95€ ACCÉDER À LA VENTE 8 coloris disponibles Boucles Ceintures Silicone Personalisez votre ceinture avec les différentes couleurs de boucles 9.90€ 4,95€ ACCÉDER À LA VENTE Ceintures Fantaisie Boucles Basket 5 coloris disponibles : Vert, Rouge, Blanc, Noir, Rose 23,90€ 11,95€ ACCÉDER À LA VENTE Ceintures Fantaisie Boucles Drapeau 2 modèles disponibles : USA, Angleterre 23,90€ 11,95€ ACCÉDER À LA VENTE Toute la gamme DA ACTIVE Pantalons, Brassières, Débardeurs, Jupes,Tops, Collants... -50% ACCÉDER À LA VENTE PROMO COMPEX : Électro-stimulateurs musculaires COMPEX surALLSPORTSHOP.fr Pour un produit acheté, recevez 6 électrodes supplémentaires offertes. SIGG : Venez découvrir sur ALLSPORTSHOP.fr les 4 gammes de ces gourdes mythiques. -Active : alu design sportif -Classic : alu design original -Kids : alu décorations ludiques -Viva : la gamme plastique de SIGG Mi-Sport / Mi-Fitness COMPEX Pour un COMPEX acheté, 6 électrodes supplémentaires offertes 849€ 699€749€ 649€ VOIR LE PRODUIT Traveller / Kids SIGG Gourde aluminium de 0,3L (Kids) à 1L (Traveller) -25% VOIR LE PRODUIT NOUVEAU TICKET TO THE MOON : 13 Hamacs de la marque TICKET TO THE MOON sont disponibles sur ALLSPORTSHOP.fr Ces petites merveilles vous attendent pour un repos bien mérité. FITSIP : Boire ou courir, plus besoin de choisir ! Les manchons d'hydratation FITSIP vous permettent de pratiquer votre sport et de vous hydrater sans vous encombrer. Préparer l'été en toute tranquilité sur ALLSPORTSHOP.fr Hamacs TICKET TO THE MOON Simples ou Doubles 13 modèles disponibles 39,95€ VOIR LE PRODUIT Manchon d'hydratation FITSIP 200 ml 6 coloris disponibles 35,00€ VOIR LE PRODUIT ENTREPRISE FRANÇAISE SATISFAIT OU REMBOURSÉ PAIEMENT 100% SÉCURISÉ PAIEMENT PAYPAL PAIEMENT 3D SECURE ALLSPORTSHOP SUR FACEBOOK Consulter la version en ligne Pour être certain de bien recevoir nos messages, ajoutez Allsportshop à votre carnet d’adresses dans votre carnet d’adresses. Se désinscrire de cette newsletter
Re: Error 408 with Chrome
2014-06-04 17:10 GMT+02:00 Nenad Merdanovic ni...@nimzo.info:
Hello Kevin,
On 06/04/2014 05:05 PM, Willy Tarreau wrote:
On Wed, Jun 04, 2014 at 04:49:53PM +0200, Kevin Maziere wrote:
Anyway, from the various reports we get, it seems like sending an empty
408 message is enough to workaround this abnormal Chrome behaviour. For
this you can proceed like this :
errorfile 408 /dev/null
After days of tests it appears that 408 error page are still appening,
but
less frequently.
I don't know how but I can see them on my logs and on my browser.
In the logs it's perfectly normal as haproxy reports what has been done,
but in the browser, it's really not possible since the error message was
replaced with the contents of /dev/null. What might happen is either that
some requests go to another haproxy or another server which still emits
the error, or that such errors were abusively cached by the client which
reports them on closed connection.
Regards,
Willy
Can you post your latest configuration?
Here is my conf :
# Configuration for haproxy1.5
global
log 127.0.0.1 local0
log 127.0.0.1 local1 notice
maxconn 15000
#debug
#quiet
user haproxy
group haproxy
defaults
log global
modehttp
option httplog
#option dontlognull
retries 5
option redispatch
maxconn 15000
option forwardfor
timeout server 30m
timeout connect 5s
timeout client 10s
timeout http-keep-alive 5s
timeout http-request 8s
# Application Frontend
frontend ipv4-127.0.0.1-80
bind 172.16.0.1:80
redirect scheme https code 301 if !{ ssl_fc }
frontend ipv4-127.0.0.1-443
bind 172.16.0.1:443 ssl crt /etc/haproxy/certs/wildcard.pem ciphers
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-RSA-RC4-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES128-SHA:AES256-SHA256:AES256-SHA:RC4-SHA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!EDH
rspadd Strict-Transport-Security:\ max-age=31536000;\ includeSubDomains
reqadd X-Forwarded-Proto:\ https
option http-server-close
default_backend ipv4-80
frontend ipv4-172_16_0_126-80
bind 172.16.0.126:80
redirect scheme https code 301 if !{ ssl_fc }
frontend ipv4-172_16_0_126-443
bind 172.16.0.126:443 ssl crt /etc/haproxy/certs/wildcard.pem ciphers
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-RSA-RC4-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES128-SHA:AES256-SHA256:AES256-SHA:RC4-SHA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!EDH
rspadd Strict-Transport-Security:\ max-age=31536000;\ includeSubDomains
reqadd X-Forwarded-Proto:\ https
option http-server-close
default_backend ipv4-80
frontend ipv6-2000_00_00_00-80
bind 2000:00:00::0:80
redirect scheme https code 301 if !{ ssl_fc }
frontend ipv6-2000_00_00_00-443
bind 2000:00:00::0:443 ssl crt /etc/haproxy/certs/wildcard.pem ciphers
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-RSA-RC4-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES128-SHA:AES256-SHA256:AES256-SHA:RC4-SHA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!EDH
rspadd Strict-Transport-Security:\ max-age=31536000;\ includeSubDomains
reqadd X-Forwarded-Proto:\ https
option http-server-close
default_backend ipv6-80
frontend ipv6-2000_11_11_11-80
bind 2000:11:11::1:80
redirect scheme https code 301 if !{ ssl_fc }
frontend ipv6-2000_11_11_11-443
bind 2000:11:11::1:443 ssl crt /etc/haproxy/certs/wildcard.pem ciphers
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-RSA-RC4-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES128-SHA:AES256-SHA256:AES256-SHA:RC4-SHA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!EDH
rspadd Strict-Transport-Security:\ max-age=31536000;\ includeSubDomains
reqadd X-Forwarded-Proto:\ https
option http-server-close
default_backend ipv6-80
# Application Backend
backend ipv4-80
balance roundrobin
server pubwebsite01 172.16.0.116:80 weight 1 check inter 5000 rise 2
fall 5
server pubwebsite02 172.16.0.123:80 weight 1 check inter 5000 rise 2
fall 5
backend ipv6-80
balance roundrobin
server pubwebsite01 2000:22:22::22:80 weight 1 check inter 5000 rise
2 fall 5
server pubwebsite02 2000:22:22::23:80 weight 1 check inter 5000 rise
2 fall 5
listen admin 172.16.0.126:1234
mode http
stats uri /
# For Chrome : https://code.google.com/p/chromium/issues/detail?id=85229#c33
and ML haproxy
errorfile 408 /dev/null
Regards,
Re: Error 408 with Chrome
On Wed, Jun 4, 2014 at 6:05 PM, Kevin Maziere ke...@kbrwadventure.com wrote:
2014-06-04 17:10 GMT+02:00 Nenad Merdanovic ni...@nimzo.info:
Hello Kevin,
On 06/04/2014 05:05 PM, Willy Tarreau wrote:
On Wed, Jun 04, 2014 at 04:49:53PM +0200, Kevin Maziere wrote:
Anyway, from the various reports we get, it seems like sending an
empty
408 message is enough to workaround this abnormal Chrome behaviour.
For
this you can proceed like this :
errorfile 408 /dev/null
After days of tests it appears that 408 error page are still appening,
but
less frequently.
I don't know how but I can see them on my logs and on my browser.
In the logs it's perfectly normal as haproxy reports what has been done,
but in the browser, it's really not possible since the error message was
replaced with the contents of /dev/null. What might happen is either
that
some requests go to another haproxy or another server which still emits
the error, or that such errors were abusively cached by the client which
reports them on closed connection.
Regards,
Willy
Can you post your latest configuration?
Here is my conf :
# Configuration for haproxy1.5
global
log 127.0.0.1 local0
log 127.0.0.1 local1 notice
maxconn 15000
#debug
#quiet
user haproxy
group haproxy
defaults
log global
modehttp
option httplog
#option dontlognull
retries 5
option redispatch
maxconn 15000
option forwardfor
timeout server 30m
timeout connect 5s
timeout client 10s
timeout http-keep-alive 5s
timeout http-request 8s
# Application Frontend
frontend ipv4-127.0.0.1-80
bind 172.16.0.1:80
redirect scheme https code 301 if !{ ssl_fc }
frontend ipv4-127.0.0.1-443
bind 172.16.0.1:443 ssl crt /etc/haproxy/certs/wildcard.pem ciphers
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-RSA-RC4-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES128-SHA:AES256-SHA256:AES256-SHA:RC4-SHA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!EDH
rspadd Strict-Transport-Security:\ max-age=31536000;\ includeSubDomains
reqadd X-Forwarded-Proto:\ https
option http-server-close
default_backend ipv4-80
frontend ipv4-172_16_0_126-80
bind 172.16.0.126:80
redirect scheme https code 301 if !{ ssl_fc }
frontend ipv4-172_16_0_126-443
bind 172.16.0.126:443 ssl crt /etc/haproxy/certs/wildcard.pem ciphers
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-RSA-RC4-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES128-SHA:AES256-SHA256:AES256-SHA:RC4-SHA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!EDH
rspadd Strict-Transport-Security:\ max-age=31536000;\ includeSubDomains
reqadd X-Forwarded-Proto:\ https
option http-server-close
default_backend ipv4-80
frontend ipv6-2000_00_00_00-80
bind 2000:00:00::0:80
redirect scheme https code 301 if !{ ssl_fc }
frontend ipv6-2000_00_00_00-443
bind 2000:00:00::0:443 ssl crt /etc/haproxy/certs/wildcard.pem ciphers
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-RSA-RC4-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES128-SHA:AES256-SHA256:AES256-SHA:RC4-SHA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!EDH
rspadd Strict-Transport-Security:\ max-age=31536000;\ includeSubDomains
reqadd X-Forwarded-Proto:\ https
option http-server-close
default_backend ipv6-80
frontend ipv6-2000_11_11_11-80
bind 2000:11:11::1:80
redirect scheme https code 301 if !{ ssl_fc }
frontend ipv6-2000_11_11_11-443
bind 2000:11:11::1:443 ssl crt /etc/haproxy/certs/wildcard.pem ciphers
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-RSA-RC4-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES128-SHA:AES256-SHA256:AES256-SHA:RC4-SHA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!EDH
rspadd Strict-Transport-Security:\ max-age=31536000;\ includeSubDomains
reqadd X-Forwarded-Proto:\ https
option http-server-close
default_backend ipv6-80
# Application Backend
backend ipv4-80
balance roundrobin
server pubwebsite01 172.16.0.116:80 weight 1 check inter 5000 rise 2
fall 5
server pubwebsite02 172.16.0.123:80 weight 1 check inter 5000 rise 2
fall 5
backend ipv6-80
balance roundrobin
server pubwebsite01 2000:22:22::22:80 weight 1 check inter 5000 rise 2
fall 5
server pubwebsite02 2000:22:22::23:80 weight 1 check inter 5000 rise 2
fall 5
listen admin
