No support for wildcards in purge URLs from Expire module

Seems to apply fine when I applied it on simplytest.me - I haven't gotten to test this in a live environment, but looks like a good extension to allow for this use of the Expire module.

I'm trying to do something along these lines, but I'm wondering the best way to handle a different case. If "node/1234" needs to be cleared, I would also like to clear "node/1234?test=1", but I don't want to clear "node/12345". This patch would clear both, but since the expire module only sends over a boolean value for the wildcard, there isn't much that can be done on the varnish module side.

The patch no longer applies cleanly to 7.x-1.x-dev, here's an updated patch that does.

Patch in #4 worked for me.

@frankkessler, to purge urls along with all the ones that have query strings, I strip out the query string in the varnish vcl (sub vcl_fetch):

# For the purposes of banning, let's ignore the query string part
set beresp.http.x-url = regsub(beresp.http.x-url, "\?.*$", "");

Note, that I am using the Ban Lurker ban type, where ban rules are based off beresp.http.x-url and beresp.http.x-host.

I've changed the patch so that it works the way #3 mentioned, which I believe is more closely aligned with the way expire.module expects the wildcard to work. When a wildcard path comes in to varnish_expire_cache(), it adds two new versions of the path to the list, which have '/(.*)' and '?(.*)' added to it. Thus, the original path, all paths beneath it, and all query arguments are expired by specifying one wildcard path.

Patch in #6 looks buggy. The ? needs to be escaped. Best to combine both into a single regex:
$paths[$path . '[/?](.*)'] = $path . '[/?](.*)';

Oh, right.

Could you please redo the patch, it does not apply anymore.

Sure.

The patch is readable, well-formed, and effective. I've been using this in production for a couple sites.

Patch from #10 works. Thanks

Committed to latest dev (will be in beta5)

Correction - will be in 7-x.1.1