Hi Pieter, On Sun, Oct 28, 2018 at 12:49:44AM +0200, PiBa-NL wrote: > Hello Chad, List, > > Thanks for the nice article > https://www.haproxy.com/blog/introduction-to-haproxy-acls/ > > However one of the examples that shows how to use cache-store seems flawed.. > > Attached ive made a little varnishtest, that: > > - fails to run success-full when repeated 100 times with the path_beg acl on > 1.8.14 (some requests are send twice to the s1 server, which stops listening > after 1..) but its about 6% of runs that fails..
There is a bug in this config, which is reported by an haproxy warning : *** h1 0.0 debug|[WARNING] 300/201711 (22373) : parsing [/tmp/vtc.22366.5fa5c991/h1/cfg:37] : acl 'WeCanSafelyCacheThatFile' will never match because it only involves keywords that are incompatible with 'backend http-response header rule' *** h1 0.0 debug|[WARNING] 300/201711 (22373) : parsing [/tmp/vtc.22366.5fa5c991/h1/cfg:38] : acl 'WeCanSafelyCacheThatFile' will never match because it only involves keywords that are incompatible with 'backend http-response header rule' Indeed, the ACL references the "path" sample fetch function in the response, which is not available. > - produces core dumps with 1.9-dev4-1ff7633 I've just managed to reproduce it and fix it (thanks for your report and the reproducer). I *suspect* 1.8 and older are not safer, but that the way the buffers work there make it dereference a wrong (but existing) memory area, thus it doesn't crash. > Using the var(txn.path) instead it succeeds on both versions. Indeed, it's expected since the path is lost once the request leaves. Thanks! Willy
