EZP-24854 EZP-26087 Update varnish configuration to purge required lo…

[benoitvidis]

…cations only

cf https://jira.ez.no/browse/EZP-26087
and ezsystems/ezplatform-ee#3

The current implementation of varnish ban allows only one Location ID to be set in the X-Location-Id Header.

The proposal is to:

1. update default varnish configuration (this PR)
2. revert ezsystems/ezpublish-kernel@12353b4

[andrerom]

ping @joaoinacio @bdunogier

[bdunogier]

So this will work because the comma is considered as a word boundary, making sure every location id is interpreted individually ?

It looks okay to me, but I'd like QA to a) verify that this is indeed failing b) test the patch.

[andrerom]

It looks okay to me, but I'd like QA to a) verify that this is indeed failing b) test the patch.

They will also need to revert @joaoinacio's original kernel patch to test this and test the original issue he solved there.

[bdunogier]

Good point @andrerom. I'll open a PR with the revert.

[gggeek]

To be backported to 5.4.9 as well :-)
Side note for the reader: the regression was introduced apparently in 5.4.5

[joaoinacio]

untested but looks OK afaict, as @bdunogier said should probably go through QA

[dspe]

looks good to me aswell :) +1

[bdunogier]

Code changes approved, can be tested as far as I am concerned.

[bdunogier]

Ping @andrerom can you approve unless you disapprove ?

[andrerom]

Assuming we adapt kernel as well for this, so maybe this is 1.7+ and 5.4 (assuming prior fix that caused this was backported to 5.4) only then.

[gggeek]

Sorry to chime in so late guys, but I am not 100% sure that putting the \b modifier here is the best solution - as it kind of introduces a hard coupling between the VCL and the php code in the purge client (https://github.com/ezsystems/ezpublish-kernel/pull/1806/files).

What if we put the \b modifier directly in the client instead?

• more flexible vcl
• less BC breaks
• same results

[andrerom]

(note, this is not needed for master if #143 goes in, as it replaces X-Location-Id with xkey, 5.x however is still an open topic on this)

[miguelcleverti]

@benoitvidis I posted a comment in EZP-26087 with the tests results of the PR.

I but in short the PR does not seem to solve the issue.

After making a BAN request for multiple X-Location-Id's there is still cache for the controller with multiple X-Location-Id, however for controllers with only one X-Location-Id the BAN request works has intended.

Further more if the BAN request is made using the syntax:
X-Location-Id: (978687|123|7987|7237) Instead of: X-Location-Id: ^(978687|123|7987|7237)$

It seem to have the expected behavior.

[yannickroger]

Could any one help our QA to validate this fix? Or else we will have to close this PR as they can't fix the problem using it.

[andrerom]

Closing this as we in the meantime have moved to xkey, if someone has solution that won't break this, please share on JIRA issue.