(v3 regression?) request matching location block with both `proxy_cache_purge` and `if` will return 404 when any of those `if` is triggered

[asdfzdfj]

after upgrading this module to v3+, the previously working proxy config using proxy_cache_purge will sometimes return 404 and terminates rather than forwarding request to the upstream servers

this appears to happen when incoming request matched a location block with proxy_cache_purge configured inside, alongside if directives, and will trigger when any of those if is triggered

location / {
	#set $dummy "0";
	### if this is true then it'll 404 instead of proxy_pass up, it doesn't even need to do anything
	if ($arg_x_trigger_if) {
		#set $dummy "1";
	}

	# usual proxy_pass configs
	proxy_pass http://up_origin;
	proxy_cache_purge PURGE from 127.0.0.1 ::1;
	# ...snipped
}

this seem to be present since the first 3.0.0 up to the current master commit (6147443 as of writing), v2 (tested up to 2.5.6) doesn't exhibit this problem

I only found this in proxy context, not sure if it also applies to other contexts that this module supports

(sure, if inside location block is evil and whatnot, but in real config that I first found this bug only sets some variable which is supposedly safe action to be done in such block, and this bug will still happen even if the if block doesn't do anything at all)

---

reproduction setup: https://gist.github.com/asdfzdfj/22fa2b68e0d4829ba17d4e2638750e77

test with curl -vL 'http://localhost:(7080|8080)/test?x_trigger_if=(0|1)
proxy-ok / port 8080 will return 200 and test content regardless of x_trigger_if values
proxy-faulty / port 7080 will fault with 404 when x_trigger_if is nonzero/not empty

[denji]

Please verify that the latest commit in the master branch includes the fix.

[asdfzdfj]

sorry for late reply but unfortunately the problem still persists with latest master commit 2e37e64, in both the repro setup and real deployment