RE: [cache] allow caching of OPTIONS request
Hi there, May I add that, in the CORS implementation, there is a specific header used for the caching duration: Access-Control-Max-Age This header is supported by most of browsers and its specification is available : https://fetch.spec.whatwg.org/#http-access-control-max-age One would think of using this header value instead of the well known Cache-Control header when dealing with CORS and OPTIONS requests. Cheers, Vincent De : Baptiste Envoyé : mercredi 7 août 2019 12:38 À : HAProxy; William Lallemand Objet : [cache] allow caching of OPTIONS request Hi there, Please find in attachement a couple of patches to allow caching responses to OPTIONS requests, used in CORS pattern. In modern API where CORS is applied, there may be a bunch of OPTIONS requests coming in to the API servers, so caching these responses will improve API response time and lower the load on the servers. Given that HAProxy does not yet support the Vary header, this means this feature is useful in a single case, when the server send the following header "set access-control-allow-origin: *". William, can you check if my patches look correct, or if this is totally wrong and then I'll open an issue on github for tracking this one. Baptiste
RE: Use SNI with healthchecks
> It definitely must match in HTTP. However there's nothing making it mandatory > to send HTTP checks, let alone a Host header field (eg: if sending a simple > HTTP/1.0 request). However I'm noting the comment, because once we're able > to more easily configure the HTTP checks, we could imagine that we'd always > use SNI when "sni" is configured on the server line and an http check is in > use. That would be awesome ! > > I'm not even sure that differentiate "Host" header from SNI values is > > possible on softwares like Nginx or Apache. > It should not, that would be a violation of HTTP over TLS. > > We should always use SNI & check-sni as the same value as the "Host" header > > value, > Yes, when we have one :-) > > which in many cases should be the same value as the FQDN from the server > > line. > This is where it's not always the case. Very commonly you'll have the > individual server name (server1, server2, etc) and you need the application > Host header. Yes indeed, that's the point. We use HAProxy mainly to proxy traffic from devices that don't like url/domain changes (like ISP boxes) to CDNs providers so we rewrite a lot of things at HAProxy side (including Host). I totally understand that most HAProxy users need it to forward traffic as it is and therefore to keep SNI and other values from front clients requests. > > I also think SNI should be defaulted when using ssl over server backend. > We could possibly consider making it a default in a future version, indeed, > but only once we have the ability to automatically retrieve correct values. Would definitely be awesome! > > Check-sni should default to the same value as sni but re-writable. > Except that SNI comes from forwarded traffic and there's no forwarded traffic > with the checks to extract the information from. > > CDN providers like CloudFront or Akamai are using more and more SNI > > by blowing up prices on non-sni configurations (CloudFront bills > > 600$/month/vhost to avoid SNI) > I can easily understand why they're doing this. IP addresses are becoming > rare and it's a shame that some sites continue to waste them. With the > rapid growth of SSL over the last few years, I can easily imagine that > many sites have started to request their own IP addresses for no really > valid reason (I believe that MSIE6 was the last browser not to support SNI > but I could be wrong). Absolutely, what for use of default sni also in haproxy would be royal ;) Vincent > Willy
RE: Use SNI with healthchecks
I'll test the "setenv" approach soon. I don't see a case were one would define a different check-sni or sni values from the "Host" header. I'm not even sure that differentiate "Host" header from SNI values is possible on softwares like Nginx or Apache. We should always use SNI & check-sni as the same value as the "Host" header value, which in many cases should be the same value as the FQDN from the server line. I also think SNI should be defaulted when using ssl over server backend. Check-sni should default to the same value as sni but re-writable. CDN providers like CloudFront or Akamai are using more and more SNI by blowing up prices on non-sni configurations (CloudFront bills 600$/month/vhost to avoid SNI) Vincent De : Willy Tarreau <w...@1wt.eu> Envoyé : mercredi 25 avril 2018 09:16 À : Jonathan Matthews Cc : GALLISSOT VINCENT; Lukas Tribus; haproxy@formilux.org Objet : Re: Use SNI with healthchecks On Tue, Apr 24, 2018 at 06:50:13PM +, Jonathan Matthews wrote: > [Top post; fight me] Grrr > You could either read an environment variable inherited from outside the > process, or use "setenv" or "presetenv" as appropriate to DRY your config > out. > > The fine manual describes how you would refer to this envvar in section > 2.3, regardless of which of those options you use to set it. That's indeed a possibility. In Vincent's case I'm seeing that he uses the same name as the FQDN one. That makes me think we could possibly have a special check-sni value to use the FQDN from the server line. That would have the benefit of making it easier to place in a default-server statement. I just don't know how often it happens that the SNI used for checks has to match the FQDN declared in the configuration. Willy
RE: Use SNI with healthchecks
I migrated to 1.8 and sni + check-sni are working fine with the following code: 88 backend cloudfront http-request set-header Host 123456789abcde.cloudfront.net option httpchk HEAD /check HTTP/1.1\r\nHost:\ 123456789abcde.cloudfront.net server applaunch 123456789abcde.cloudfront.net:443 check resolvers mydns no-sslv3 ssl verify required ca-file ca-certificates.crt sni req.hdr(host) check-sni 123456789abcde.cloudfront.net 88 Obviously I cannot use %[req.hdr(host)] for "option httpchk" nor for "check-sni" directives. Do you know how can I define only one time my Host header in the code above ? Thanks, Vincent ____ De : GALLISSOT VINCENT Envoyé : lundi 23 avril 2018 17:33 À : Lukas Tribus Cc : haproxy@formilux.org Objet : RE: Use SNI with healthchecks Thank you very much for your answers, I'll migrate to 1.8 asap to fix this. Vincent De : lu...@ltri.eu <lu...@ltri.eu> de la part de Lukas Tribus <lu...@ltri.eu> Envoyé : lundi 23 avril 2018 17:18 À : GALLISSOT VINCENT Cc : haproxy@formilux.org Objet : Re: Use SNI with healthchecks Hello Vincent, On 23 April 2018 at 16:38, GALLISSOT VINCENT <vincent.gallis...@m6.fr> wrote: > Does anybody know how can I use healthchecks over HTTPS with SNI support ? You need haproxy 1.8 for this, it contains the check-sni directive which allows to set SNI to a specific string for the health check: http://cbonte.github.io/haproxy-dconv/1.8/configuration.html#5.2-check-sni Regards, Lukas
Use SNI with healthchecks
Hi all, I want to use SNI with httpchk on HAProxy 1.7.10 to connect to CloudFront distributions as backend servers. I saw in this mailing-list archives that SNI is not used by default even when using the ssl directive. We don't pay for SNI on that distribution, that means CloudFront doesn't provide a certificate on its default vhost. Because of that, all healthchecks fail with "handshake failure". I temporarily by-passed the issue by adding "port 80" to allow healthchecks over HTTP: option httpchk HEAD /check HTTP/1.1\r\nHost:\ mydistribution.cloudfront.net server mydistribution mydistribution.cloudfront.net:443 check resolvers mydns port 80 cookie no-sslv3 ssl verify required ca-file ca-certificates.crt Does anybody know how can I use healthchecks over HTTPS with SNI support ? Many thanks, Vincent
