Fix example in expr.xml

[nisbet-hubbard]

The original example doesn’t actually work. This PR replaces it with a functional snippet along the lines of ex. 4 from mod_headers.

[covener]

The original works fine for me and the replacement doesn't use expressions

$ curl -vk http://localhost/special_path.php 2>&1 |grep CustomHeader
< CustomHeader: my-value
$ curl -vk http://localhost/other_path.php 2>&1 |grep CustomHeader
$

[covener]

What I find surprising about the existing example and comment is that delaying the evaluation of REQUEST_URI doesn't really make much sense. it should really check something like the CONTENT_TYPE or REQUEST_STATUS.

[nisbet-hubbard]

The original works fine for me

Yes, sometimes it does. A case where it doesn’t is when an existing header is set by the application which one would like to override

@header( 'Cache-Control: no-cache' );

[covener]

There's a different result from the replacement directives? It seems like the override case is more likely about "onsuccess" vs "always" then about using an expression or an env condition

[nisbet-hubbard]

That was my first thought. So I tested each version with always and implicit onsuccess

Header always set Cache-Control "max-age=604800" "expr=%{REQUEST_URI} =~ m#^/wp\.serviceworker$#"

SetEnvIf Request_URI ^/wp\.serviceworker$ worker
Header always set Cache-Control "max-age=604800" env=worker

Only the second works.

[nisbet-hubbard]

@covener I’ve identified the condition under which REQUEST_URI doesn’t work in expr=.

It’s when the path refers to something that’s not a static file, but dynamically generated by an application. This also applies to <If >. Previously, we observed the same limitation with <FilesMatch >, though I didn’t connect the dots at the time.

If you think this behaviour should be preserved, I suppose we can highlight the rule whenever it applies.