On 01/06/2016 03:19 μμ, Willy Tarreau wrote: > Hi Pavlos, > > On Tue, May 31, 2016 at 12:06:14PM +0200, Pavlos Parissis wrote: >> >> On 30/05/2016 05:24 ????, Nenad Merdanovic wrote: >>> Hello Bjorn, >>> >>> On 5/30/2016 4:29 PM, Björn Zettergren wrote: >>>> Hi, >>>> >>>> I've been playing around with the ECC+RSA certificate on same IP as >>>> described in the haproxy blog at >>>> http://blog.haproxy.com/2015/07/15/serving-ecc-and-rsa-certificates-on-same-ip-with-haproxy/ >>>> >>>> However, I get unexpected results when testing and I'm thinking that >>>> my problem is with the sample fetching of req.ssl_ec_ext on incoming >>>> requests being inconsistent or haproxy starts processing the request >>>> before enough of the data has been sent. I don't know how to >>>> troubleshoot any further or how to get it working, if it's at all >>>> expected to work "as advertised". >>> >>> Yes, it seems like the case is that the fetch is only called once, when >>> there is not enough data in the buffer. You can work around this like: >>> tcp-request inspect-delay 5s >> >> That option was never clear to me what it does. >> Does it introduce a delay on user's request? >> I think it only delays the inspection of the request from haproxy >> but the actual request isn't delayed. >> >> Am I right? > > That's more or less it. Just to make it very clear, it tells haproxy that > when facing *incomplete* data preventing it from taking a decision, it > should wait this long. What's important to know is that ACLs implement a > three-state match : > - does not match > - does match > - uncertain, need more info > > If you're waiting for a TLS hello and someone sends an HTTP request, > it will immediately not match so there is no delay. If someone sends a > valid TLS hello message that haproxy can fully parse, there's no delay > either. But if the data start like a TLS hello but are incomplete (eg > due to a packet loss causing a retransmission), you want haproxy to > wait a bit. This tells how long to wait. Past this delay, the pattern > doesn't match. > > That's exactly similar to the http-request timeout for HTTP in fact. >
OK now it is very clear to me how it works. Thanks for the explanation, Pavlos
signature.asc
Description: OpenPGP digital signature
