Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.The ban URLs are missing the leading slash.
Using module expire 7.x-2.0-rc3 with these settings:
External expiration selected
Include base URL in expires is NOT checked
Varnish settings:
Varnish cache clearing: Selective
Varnish ban type: Ban Lurker
Using: varnishlog|grep ban
0 CLI - Rd ban obj.http.x-host ~ test.example.com && obj.http.x-url ~ ^$|^node/5669/edit$|^node/3880$|^home$|^node/5669$|^products/testing/amazon-redshift$
I believe that the ban should look like this:
0 CLI - Rd ban obj.http.x-host ~ test.example.com && obj.http.x-url ~ ^/$|^/node/5669/edit$|^/node/3880$|^/home$|^/node/5669$|^/products/testing/amazon-redshift$
| Comment | File | Size | Author |
|---|---|---|---|
| #26 | varnish-leave_base_path_in_urls-2340829-26.patch | 544 bytes | natew |
| #5 | varnish-leave_base_path_in_urls-2340829-5-D7.patch | 782 bytes | frankkessler |
Comments
Comment #1
Marshall_Kennard CreditAttribution: Marshall_Kennard commentedThe varnish_purge function removes the base path from the pattern, including the leading slash.
Here is a patch to fix it.
I was not sure if base_path always would begin with a slash. If so, this could be simplified to:
$single_pattern = substr_replace($single_pattern, '', 2, strlen($base_path) - 1);Comment #2
Marshall_Kennard CreditAttribution: Marshall_Kennard commentedHere is the correct patch without the troubleshooting code.
Comment #3
Marshall_Kennard CreditAttribution: Marshall_Kennard commentedComment #4
david.gil CreditAttribution: david.gil commentedpatch in #2 is working for me.
Comment #5
frankkessler CreditAttribution: frankkessler commentedI think we have to think bigger picture here. I don't think the $base_path should be removed at all. That section of code should be removed. Varnish includes the leading slash and any sub-directories in the URL. The $base_path would be included in this. Maybe there's a use case I'm not thinking of, but here's a patch that removes that section of code.
Comment #6
frankkessler CreditAttribution: frankkessler commentedComment #7
mfbThe patch at #5 is working for me. The code in question was added in #2017097: Ban/purge requests to varnish are malformed. if anyone wants to read up on it..
Comment #8
fearlsgroove CreditAttribution: fearlsgroove commented+1 for #5 -- a drupal path without a full base path is useless to varnish as far as I can tell, at least with 3.x and up. Is this sillyness supposed to support old 2.x stuff or something?
Comment #9
basvredeling+1 for #5
Comment #10
blazingarrow CreditAttribution: blazingarrow commentedPatch #5 was faulty. I've added a new patch.Comment #11
basvredelingSorry, but #10 makes no sense at all.
You explode() $patterns, run a loop in which you do absolutely nothing, and implode into $patterns again.
Why was #5 faulty?
Comment #12
blazingarrow CreditAttribution: blazingarrow commentedSorry I was a bit in a rush and overlooked the code completely. I saw a repetitive if statement.
Comment #13
eliosh+1 for #5
I tested it also with Domain Access, and it work very well!
Comment #14
opratr CreditAttribution: opratr commented+1 RBTC for #5
Patch applied cleanly and corrected the problem.
Drupal 7.34
Varnish 7.x-1.0-beta3
Comment #15
cammchugh CreditAttribution: cammchugh commentedI applied this patch and noticed that it surfaces another issue. When selecting the option in the expire module to also expire the home page, the expire module passes '/' as one of the paths to expire. However, when imploding the paths, this module adds the base path ('/' in my case) to each path. This results in the path '//' for the front page, which is clearly incorrect, and the resulting ban fails to invalidate the home page in varnish:
Rd ban req.http.host ~ localhost && req.url ~ ^//$|^/node/61$|^/some/path$
Would this be considered part of this bug, or a separate issue? I'm leaning towards it being a distinct bug, but I could just update the patch for this issue.
As a side note, patch #5 renders the comment "// Modify the patterns to remove base url and base path." somewhat inaccurate, and leaves behind an unreferenced variable $base_path in the varnish_purge function. If I resubmit a patch for the above noted issues, I'll address these as well.
Comment #16
esolitosSame issue there, we donwgraded the module to beta2, I think the priority on this should be quite high, since it basically breaks the possibility to clear the cache!
Comment #17
MiSc CreditAttribution: MiSc commentedSetting this to needs work because of comment #15.
Comment #18
vinmassaro CreditAttribution: vinmassaro commented@cammchugh: can you tell me how to reproduce the double slash issue? With Expire 7.x-2.0-rc4 and this patch added, I don't get this behavior. I set it to clear the front page, and when looking at varnishlog when editing a node, here is the ban I am seeing:
This looks correct to me. It's expiring the home page and node page, as well as all of their aliases.
Comment #19
cammchugh CreditAttribution: cammchugh commented@vinmassaro: I grabbed a clean copy of core, varnish, and expire and also could not reproduce the double slash issue. I went back to the codebase for the project we were working on when I posted #15, and found a couple lines of code tucked away in a custom module added by our team as a partial workaround for this issue. Commented them out and everything functions as expected.
Apologies for the confusion, I believe this can be set back to RBTC.
Comment #20
vinmassaro CreditAttribution: vinmassaro commented@cammchugh: Thanks for checking, moving back to RTBC.
Comment #21
MiSc CreditAttribution: MiSc commentedComment #23
MiSc CreditAttribution: MiSc commentedThanks!
Committed to latest dev - I think this is it for getting a new release out.
Comment #25
pianomansam CreditAttribution: pianomansam commentedWhat's stopping a full release containing this fix? I ran into this issue with beta3 and reluctantly have upgraded to the most recent dev version.
Comment #26
natew CreditAttribution: natew commentedI ran in to the same issue and #5 solved it for me. I needed to rebuild the patch for my build environment, attaching a new version (same changes).