Ban/purge requests to varnish are malformed.

This looks good to me.

is this already part of the dev version?

This works for me, if I have selected to purge/ban only one url (e.g. the node url).
BUT, if I select to purge/ban more than one url, the patch doesn't seem to work.

I think the replace functionality doesn't work if there are more than one url in the $pattern variable.
It looks something like this:

One url:
PATTERN: ^/http://example.com/my-node-url$

Multiple urls:
PATTERN: ^/http://example.com/$|^/http://example.com/my-node-url$|^/http://example.com/news$|^/http://example.com/arkiv/my-nodes$|^/http://example.com/arkiv/all-nodes$

#1 works fine. Thanks.

patch in #1 only works for single URLS and #6 doesn't work as it is missing the globals declaration. Try this one it works for me.

If you uncheck the "Include base URL in expires" on the Expire module's configuration page, the base URL is not attached in front of the url. Wonder what are the other consequences of this action.
/admin/config/development/performance/expire

This shouldn't require the expire module though, right?

This issue should be able to stand up on it's own.

#9: AFAICT, this functionality is no longer present in the 2.x series of the Expire module: #2113941: hook_expire_cache() should not give absolute URLs but internal Drupal paths.

The patch in #8 works for pages expired by the Expire module, but breaks when I purge pages manually.

Currently, when we update a node, the Expire module handles expiration of all node-related paths, while a few other paths are purged manually.

The Expire module passes the following pattern to varnish_purge() (via varnish_expire_cache()):

'^/http://example.com/$|^/http://example.com/478233$

This results in the following (correct) ban request:

req.url ~ ^/$|^/478233$

Next, we call varnish_purge('example.com', '^/data/ticker')

This results in the following (incorrect) ban request:

req.url ~ ^data/ticker

Maybe we could just remove the $base_root from the pattern and the get rid of any duplicate slashes? (Even though that doesn't seem like a very clean solution.)

What would you expect to be sent if you call :

varnish_purge('example.com', '^/data/ticker')

I can't see what is incorrect in what it is doing?

From the patch, I understand why base_root is being removed but I don't understand base_path. It seems to me that varnish would be keying the cached content off a URL that contains the base_path.

EDIT: Look for evidence in varnish_purge_all_pages, the path to be purged IS the base path, suggests to me that base path should be left alone.

I'm proposing a new patch that does away with the use of global variables and does not strip the base_path from the URL. This patch is based on the most recent code available in git.

So this issue still exists? It explains why the expire module (beta-2) with all its pretty rules integration and other features just doesn't flush nodes.

About the base_path, it is quite clear that it should be left as is, as it defaults to "/" on all sites that are not installed in a subdirectory. In other words, just strip the base_root (hostname).

There are several related issues. The main reason is really that the clear()-implementation of Varnish-module is not fully compatible with how it is implemented in core (or for example memcached).

I'm going to reference the other issues, and marking this as critical, as I know several caching-modules that are broken because of this, especially expire: #2172597: When will the 7.x-2.x branch be the recommended release?

Referencing some of the issues - some of which could be marked duplicates, but someone with authority over the project should decide which is the master-issue. The "7.2 branch"-issue is for expire-module.

This issue should definitely be referenced as well. Basically Expire 2-series is broken, for now:
#2113941: hook_expire_cache() should not give absolute URLs but internal Drupal paths.

I think the remaining issue with this is not malformed URLS but to do with domains. I am trying to roll up domain clearing into a single issue #2208329: Support Multi domain sites

It appears that this was committed.

There's now a related patch at #2340829: Leading slash missing from ban URLs to preserve the base path - which is required for a valid ban request