Re: how to serve inline flash policy
I have not tried this conf, but I would be keen to know if it helped you :) Thanks a lot! Just made a copy of default backend, put that copy and frontend in tcp mode and it worked. Am testing stickiness (i use cookie based one). This example should go to haproxy ./examples --Vladimir
Re: how to serve inline flash policy
If you send cookies with your XML requests, then this is doable too :) But with the 1.5-dev branch only which is able to learn the cookie string and to store it into a stick table. I see. That way you learn the cookie from the HTTP backend and you keep stickiness on it in the XML backend. Well, I don't need stickiness in XML backend. The whole play with tcp mode is too let _raw_ TCP requests pass to the same backend as HTTP requests go... Pity, I loose forwardfor option is frontend -- this is really needed. Is there ever a way to analyze raw content of request buffer in http mode? What I need is to route requests starting with policy-file-request/NULL to the default backend.
Re: how to serve inline flash policy
since your request is not RFC compliant, HAProxy will drop it. You may give a try with the option accept-invalid-http-request on the frontend definition. cheers On Fri, Sep 16, 2011 at 10:42 AM, Vladimir Dronnikov dronni...@gmail.com wrote: If you send cookies with your XML requests, then this is doable too :) But with the 1.5-dev branch only which is able to learn the cookie string and to store it into a stick table. I see. That way you learn the cookie from the HTTP backend and you keep stickiness on it in the XML backend. Well, I don't need stickiness in XML backend. The whole play with tcp mode is too let _raw_ TCP requests pass to the same backend as HTTP requests go... Pity, I loose forwardfor option is frontend -- this is really needed. Is there ever a way to analyze raw content of request buffer in http mode? What I need is to route requests starting with policy-file-request/NULL to the default backend.
Re: how to serve inline flash policy
might be patchable :) I'll look at it and let you know. On Fri, Sep 16, 2011 at 10:51 AM, Vladimir Dronnikov dronni...@gmail.com wrote: since your request is not RFC compliant, HAProxy will drop it. You may give a try with the option accept-invalid-http-request on the frontend definition. Gave, with no success so far... :) Consider req_ssl_ver pattern -- it snoops into request buffer and finds the match. I need the same looking for policy.../ pattern.
Re: how to serve inline flash policy
have you turned on the proxy to mode http ? this macro might be available only in http mode. On Fri, Sep 16, 2011 at 10:51 AM, Vladimir Dronnikov dronni...@gmail.com wrote: since your request is not RFC compliant, HAProxy will drop it. You may give a try with the option accept-invalid-http-request on the frontend definition. Gave, with no success so far... :) Consider req_ssl_ver pattern -- it snoops into request buffer and finds the match. I need the same looking for policy.../ pattern.
Re: how to serve inline flash policy
i use defaults mode http Also started https://github.com/dvv/farm/blob/master/flash/acl.c -- grep for DVV tags to navigate to changes -- this may explain what i mean better
Re: [PATCH] Adding the client's IP address to the existing X-Forwarded-For header
Hi Matthieu, On Thu, Sep 15, 2011 at 01:55:22PM +0200, matthieu.lochegn...@altissemiconductor.com wrote: Hi, I'm facing a problem with the 'X-Forwarded-For' header. Although the HTTP RFC (2616) allows multiple occurences of the same header field, and describes how the values must be merged together, this is not correctly implemented by some servers. Especially JBoss or gSOAP only give one of the occurences to the target service, which cannot get nor build the whole 'X-Forwarded-For' comma separated list. Then why not raise bug reports to those products ? In some circumstances, it can even cause important security issues. Try to send them a POST with two content-length headers, one large then one small. If it is accepted it's possible that you can perform HTTP smugling attacks on them. So I have added a 'concat' keyword to the 'forwardfor' option, to have HAProxy append the client's IP address to the existing 'X-Forwarded-For' header, like traditional Squid proxies do. I am not sure of the correct behaviour this keyword should have together with the 'header' keyword. With the patches below, the 'X-Forwarded-For' header values are moved to the specified header, and the client's IP address is appended to the list.The old header is removed, the new one is added at the end of the header list. I strongly disagree about such a change for two reasons : - first, we can't have options to workaround all known products bugs, or configs will become quite awful and unmtainainable. - second, the way it is done makes the issue even worse as it now allows a client to hide its address : just send two xff headers, the first one will be modified by haproxy and the last one will remain. A sane product will consult the last one and see the address forged by the client. Oh and you can't simply change the logics to adjust the last header instead as it will not work with your buggy servers : haproxy would then change the last occurrence which will be ignored by the buggy servers, so they will still use only the client's information. So this is the wrong way of working around a dangerous server bug in my opinion and I really refuse to introduce nasty security issues that are hard to debug just because some products don't minimally follow protocols. The solution to your issues with those products is to remove the XFF header and let haproxy put its own version. As long as you let your clients send more than one header with those servers, you're screwed anyway. So basically you'd have this : reqidel ^x-forwarded-for option forwardfor Note: there are people who prefer to rename the old header instead of removing it. It's just a matter of taste. Regards, Willy
Haproxy cluster?
Hi, Currently we have a hardware load balancer device with our hosting provider. The benefit of this device (for us) is that it can handle a much higher bandwidth of traffic than the can manage running haproxy on an individual machine/instance with our hosting provider. I was wondering if there's a way to load balance traffic over a number of lower-bandwidth haproxy machines? I've used heartbeat to handle active-passive failover with haproxy before, I guess what I'm really asking if there's a way to do active-active load balancing over a bunch of haproxy machines, with the capability to add more machines to the pool easily, if required? Thanks, Guy
Re: Haproxy cluster?
Hi, I was wondering if there's a way to load balance traffic over a number of lower-bandwidth haproxy machines? I've used heartbeat to handle active-passive failover with haproxy before, I guess what I'm really asking if there's a way to do active-active load balancing over a bunch of haproxy machines, with the capability to add more machines to the pool easily, if required? You might want to have a look at the iptables CLUSTERIP target. I haven't tested it much, though. Best regards, - craig
Re: Haproxy cluster?
Hi Guy, On Fri, Sep 16, 2011 at 11:44:12PM +0200, Craig wrote: I was wondering if there's a way to load balance traffic over a number of lower-bandwidth haproxy machines? I've used heartbeat to handle active-passive failover with haproxy before, I guess what I'm really asking if there's a way to do active-active load balancing over a bunch of haproxy machines, with the capability to add more machines to the pool easily, if required? You might want to have a look at the iptables CLUSTERIP target. I haven't tested it much, though. Also, it depends on the level of load you're trying to achieve. Most sites are more than comfortable with only an active-passive setup, and if you only needa few LBs, sometimes just announcing a few IPs with your DNS and having them bound to VRRP addresses can be enough. You can also use LVS in direct routing mode in front of your farm of haproxy LBs, but for this you'll have to either install 2 more machines to run LVS, or apply the localnode patch to be able to load balance between the LVS node and other ones. This can be very cheap and very scalable though. I also know other people who simply make use of their border routers for the load balancing : they declare multiple routes and the router hashes the IPs to load balance them across multiple LBs. Simple and efficient ! Such a setup implies that you almost never stop your LBs otherwise you'll have painful changes to enter into the routers. Just a few thoughs ;-) Cheers, Willy
Bâches imprimées, moins chères, plus vite
Vos bâches imprimées sur mesure à partir de 9,92 €/m² (HT) Recevez vos bâches en 2 à 5 jours ouvrables Impression HD Encres résistantes aux UV 4 Supports d'impression au choix 8 Finitions (œillets, renforts du bord, etc.) Upload immédiat de vos fichiers ou transfert par FTP Rollup 85 x 20049 eur HT 100 x 20069 eur HT 120 x 200 89 eur HT Délais : Départ usine: J+2 Livraison Express: J+3 Livraison Eco: J+5 Caractéristiques : Impression HD Résistant aux UV Imprimé et monté en Belgique Pop Up Stand parapluie Pop Up 3 x 3 (2,6 x 2,2m) 690 eur HT Pop Up 4 x 3 (3,3 x 2,2m) 790 eur HT Délais : Départ usine: J+4 Livraison Express: J+5 Livraison Eco: J+7 Caractéristiques : Impression HD Résistant aux UV Imprimé et monté en Belgique VEDI express © 2002-2011 - Spécialiste Rollup et Pop Up Achat de Rollup, Pop Up, bâches, stand parapluie au meilleur prix et dans les meilleurs délais. Powered by VEDI Si vous souhaitez ne plus recevoir nos messages Fichiers acceptés Taille des images : Pour Pop Up 3x3m : - Image 337,5x222cm : fichier 337,5x222cm Pour Pop Up 4x3m : - Image 405x222cm : fichier 405x222cm Résolutions conseillées: PDF: 80 dpi avec typo vectorisée TIFF ou JPEG: 120 dpi Format des fichiers acceptés : PDF HD, EPS (avec polices et images incorporées et vectorisées), TIFF, JPEG Respect des couleurs : De préférence, fournir les fichiers en CMYK (noir quadri: C70 M70 Y70 K100). Les fichiers RGB seront convertis. Garanties de qualité Qualité d'impression : Impression HD : vos images sont toujours imprimées en haute définition. Couleurs vivantes et respectées : La gestion des couleurs et la garantie de rendu sont assuréespar notre équipe d'infographistes et d'imprimeurs professionnels expérimentés. Encres UV résistantes : Les encres utilisées pour l'impression de votre image sont toujours des encres résistantes aux rayons ultra violets. Ces encres de qualité garantissent une bonne longévité aux couleurs de votre visuel, pour une image toujours vive. Supports de qualité : Vos images sont imprimées sur support satiné, pour un meilleur rendu des couleurs et des contrastes. D'une épaisseur de 170 µm ou supérieure, nos supports d'impression vous garantissent une image qui ne gondole pas et offrent une protection contre les griffes et les poussières. Résistants aux déchirures et à l'eau, ils peuvent se nettoyer. Images anti-feu : Vos images peuvent être imprimées sur support ignifugé B2 / M1 (en option), idéal et même parfois obligatoire pour les foires et salons. Qualité : Structure solide : éléments construits en acier peint de section 20cm x 20 cm. Simple à monter : assemblage sans outil, montage en 30 minutes à deux personnes. Idéal pour la participation à vos salons grand public ou professionnels. La structure Wave permet de construire des stands d’une multitude de dimensions. Les images murales sont fournies roulées avec une barre de suspension intégré (Veclip). Elles se suspendent au montant horizontal supérieur du stand et se déroulent de haut en bas entre les piliers. Leur largeur est de maximum 2 mètres afin de faciliter le stockage et le transport. Il existe 4 largeurs (50, 100, 150 et 200 cm) et 2 hauteurs (220 cm pour les stands de 2m50 et 290cm pour les stand de 3m20). Mises dos à dos, elles permettent l’affichage recto-verso. Vous choisissez vous-même les différentes largeurs de sorte de combler complètement un côté du stand ou de laisser un passage. La largeur disponible pour l’image est égale à la largeur du stand moins 50 cm. Par exemple: si la largeur du côté du stand à fermer est de 5 mètres, la largeur disponible pour l’image est de 450cm. Pour combler cette largeur, vous pouvez commander 2 images de 200cm et 1 image de 50cm. Si la hauteur de votre stand est de 320 cm, vous choisirez une hauteur d’image de 290 cm. Production et livraison : Livraison express : votre stand livré, prêt à monter en 5 jours ouvrables. Conditions générales de ventes Généralités Seules les présentes conditions de vente sont d’application pour la vente. Ces conditions générales s'appliquent à l’exclusion de toutes autres conditions, même celles reprises sur des bons de commande émanant de l’acheteur. Le vendeur se réserve le droit de modifier à tout moment ces conditions générales. Néanmoins, les commandes en cours restent soumises aux conditions applicables au moment où la vente a été conclue. Les photos, illustrations, couleurs et textes associés aux produits repris sur ce site n’ont pas de caractère contractuel et de ce fait ne sauraient engager la responsabilité du vendeur. Toute commande donnera lieu à une facturation 30 jours après son acceptation dans le cas où la commande ne peut être exécutée en raison d'un retard imputable au client. En cas d'annulation de sa commande, le client sera redevable d'un montant correspondant aux frais déjà exposé, augmenté d'une indemnité de 15 % du montant
