Uploaded image for project: 'eZ Publish / Platform'
  1. eZ Publish / Platform
  2. EZP-26087

Cannot purge multiple X-Location-Id content

    Details

    • Type: Bug Bug
    • Status: Backlog
    • Priority: Medium Medium
    • Resolution: Unresolved
    • Affects Version/s: 5.4.5, 1.5.0, 1.6.0
    • Fix Version/s: None
    • Component/s: Caching
    • Labels:
      None

      Description

      The implementation of the resolution of #EZP-24854 is breaking the http purge in case the controllers use several X-Location-Id.

      curl -I http://mysite.com/myaction
       
      HTTP/1.1 200 OK
      Content-Type: text/html; charset=UTF-8
      Cache-Control: public, s-maxage=31536000
      X-Location-Id: 65,6454,7237,12324787
      

      BAN request for 7237:

      X-Location-Id: ^(978687|123|7987|7237)$ 
      

      => The BAN request won't match the content delivered from /myaction.

      I guess the issue raised in #EZP-24854 would be easier to tackle from varnish configuration.

      Is it possible to revert the commit?

        Activity

        Show
        Support Kaliop added a comment - PR: https://github.com/ezsystems/ezstudio/pull/32
        Hide
        Gunnstein Lye added a comment -

        The above PR is closed, moved to Platform: https://github.com/ezsystems/ezplatform/pull/128

        Show
        Gunnstein Lye added a comment - The above PR is closed, moved to Platform: https://github.com/ezsystems/ezplatform/pull/128
        Hide
        Bertrand Dunogier added a comment -

        QA : could you please test this ? I've asked André Rømcke for an extra approval.

        It requires that the related ezpublish-kernel PR is pulled in as well (https://github.com/ezsystems/ezpublish-kernel/pull/1806). [~joao.inacio@ez.no] has knowledge about this.

        Show
        Bertrand Dunogier added a comment - QA : could you please test this ? I've asked André Rømcke for an extra approval. It requires that the related ezpublish-kernel PR is pulled in as well ( https://github.com/ezsystems/ezpublish-kernel/pull/1806 ). [~joao.inacio@ez.no] has knowledge about this.
        Hide
        Miguel das Neves Jacinto (Inactive) added a comment - - edited

        Bertrand Dunogier, André Rømcke, Support Kaliop,

        After many tests I found that 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.

        I used the updated vcl file and the the branch with the revert of the old fix

        Also testing this issue only with the removal of the fix for EZP-24854 yield the same results, so it does not look like it is breaking this, it looks more like it's a separate issue.

        One thing this fix does is works as an alternative to the fix for EZP-24854, I tested and the issue did not manifest.

        Show
        Miguel das Neves Jacinto (Inactive) added a comment - - edited Bertrand Dunogier , André Rømcke , Support Kaliop , After many tests I found that 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. I used the updated vcl file and the the branch with the revert of the old fix Also testing this issue only with the removal of the fix for EZP-24854 yield the same results, so it does not look like it is breaking this, it looks more like it's a separate issue. One thing this fix does is works as an alternative to the fix for EZP-24854 , I tested and the issue did not manifest.
        Hide
        Bertrand Dunogier added a comment -

        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)$
        

        I don't get that. The test-case mentions that you send the request with X-Location-Id: (978687|123|7987|7237). Why would you send it with ^...$ ?

        Show
        Bertrand Dunogier added a comment - 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)$ I don't get that. The test-case mentions that you send the request with X-Location-Id: (978687|123|7987|7237) . Why would you send it with ^...$ ?
        Hide
        Miguel das Neves Jacinto (Inactive) added a comment -

        I only sent the request with ...$ because it is described in the Issue description. Initially I wrote the test case without ...$, however the issue description does mention it.

        Show
        Miguel das Neves Jacinto (Inactive) added a comment - I only sent the request with ...$ because it is described in the Issue description. Initially I wrote the test case without ...$ , however the issue description does mention it.
        Hide
        Bertrand Dunogier added a comment -

        Okay, I think I got it. Thank you [~miguel.jacinto@ez.no].

        Show
        Bertrand Dunogier added a comment - Okay, I think I got it. Thank you [~miguel.jacinto@ez.no] .
        Hide
        Paulo Nunes (Inactive) added a comment -

        Sending back to dev as requested by [~yannick.roger@ez.no], since the contributor hasn't answered the information requested by [~miguel.jacinto@ez.no].

        Show
        Paulo Nunes (Inactive) added a comment - Sending back to dev as requested by [~yannick.roger@ez.no] , since the contributor hasn't answered the information requested by [~miguel.jacinto@ez.no] .

          People

          • Assignee:
            Unassigned
            Reporter:
            Support Kaliop
          • Votes:
            0 Vote for this issue
            Watchers:
            9 Start watching this issue

            Dates

            • Created:
              Updated: