'http-response cache-store icons if { path_beg /icons }' produces crashes and/or random behavior

[PiBa-NL]

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..

- produces core dumps with 1.9-dev4-1ff7633

Using the var(txn.path) instead it succeeds on both versions.

I think its important to 'fix' the article (and perhaps include the
cache section declaration also), and perhaps investigate why haproxy
does seem to try and process the fetch it warns about on startup that it
would/should never match..

Regards,

PiBa-NL (Pieter)

[Willy Tarreau]

Hi Pieter,

Post by PiBa-NL
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..
- 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.

Post by PiBa-NL
- 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.

Post by PiBa-NL
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

[PiBa-NL]

Hi Willy,

Post by Willy Tarreau
Hi Pieter,

Post by PiBa-NL
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..
- 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..

Agreed the configuration is 'wrong', and haproxy says it will 'never'
match, but well results above show it did match in 94% of runs, so it
was all of the following: user-issue, documentation-issue and a
software-issue. Documentation and software are both fixed now, thanks.
And at least the user will get consistent results ;).

Post by Willy Tarreau
*** 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.

Post by PiBa-NL
- 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.

Thanks for the quick fix, with latest 1.9 code the test 'fails'
consistently for the right reason.

Post by Willy Tarreau

Post by PiBa-NL
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

Regards,

PiBa-NL (Pieter)