12

I have an Azure CDN (Verizon, premium) connected to blob storage. I have 2 rules in place based on step 6 in this tutorial. The rules are designed to force the CDN to serve "index.html" when the root of the CDN is called. They may or may not be relevant to the issue, but they are described in Step 6 as follows:

  1. Make sure the dropdown says “IF” and “Always”
  2. click on “+” button next to “Features” twice.
  3. set the two newly-created dropdowns to “URL Rewrite”
  4. set the all the sources and destination dropdowns to the endpoint you created (the value with the endpoint name)
  5. for the first source pattern, set to ((?:[^\?]/)?)($|\?.)
  6. for the first destination pattern, set to $1index.html$2
  7. for the second source pattern, set to ((?:[^\?]/)?[^\?/.]+)($|\?.)
  8. for the second destination pattern, set to $1/index.html$2

I initially uploaded files to blob storage, was able to hit them via the CDN (demonstrating the above rules worked correctly), and then made changes to the local files (debugging) for uploading to blob storage. After updating all files on blob storage and manually purging the CDN endpoint with the "purge all" option checked, I am served the old files by the CDN, and the new files when hitting blob storage directly. This seems to occur for every file (even when hitting the file directly, not just index.html). This still occurs after waiting ~10hrs, clearing browser cache, and trying browsers never before used to access the CDN.

Does anyone know what may be occurring? Is it cached somewhere between my network and the CDN endpoint? I feel like I'm probably missing something very simple...

edit 1: I have another Verizon (non-premium) CDN connected to the same storage container, and it picks up the correct files after a purge; however, even now (24 hrs later) the premium CDN is not serving the updated files.

edit 2: Called Microsoft support for Azure, and they spent about 6 hours investigating to no avail. We eventually tried purging again, and now the updated files are being sent. Still not sure what the issue was.

jpetitte
  • 610
  • 5
  • 18

4 Answers4

14

After working with Microsoft and Verizon Digital Media support for a number of weeks, they finally figured out the solution.

In order to avoid interfering with the purge process, the easiest method is to implement the following "IF" statement before the "Features" portion of your rule:

IF | Request Header Wildcard | Name | User-Agent | Does Not Match | Values | ECPurge/* | Ignore Case (checked)

This if statement will skip this rule altogether for requests made with the purge user agent, allowing the request to hit the CDN as normal.

jpetitte
  • 610
  • 5
  • 18
  • 2
    It would be better if you can edit this and send a screenshot than this. Azure CDN Rules can be complicated with words – Dean Christian Armada Feb 21 '18 at 09:16
  • Not working for me ... :\ Going to fill a case with Microsoft. – Ignacio Soler Garcia Oct 02 '18 at 05:36
  • Many thanks, your info solved it for me as well :). I had a rewrite rule from example.azureedge.net to www.example.com, removing this rule fixed the problem. I also have some rules for non-www to www redirect and http to https which do not seem to interfere. – mhvis Mar 24 '19 at 15:23
  • 4
    It's absolutely amazing how we have to jump through so many complex hoops in order to do something that should just work out of the box, or with minimal basic configuration. I am an AWS guy, but my current client is somewhat tied to Microsoft so I have been forced into this World of misery. It has been one issue after another with Azure and all I can find online is 'dirty' hacks. It seems that every solution is solved by a dirty hack - why can't they actually invest some money into **competent** UX designers and engineers instead of us losing weeks of dev trying to solve these things... (1/2) – Ben Carey Mar 26 '20 at 23:45
  • Thank you very much for coming back and posting this answer - whilst I don't know if it works for me yet (still propagating), judging by what it does, I am fairly confident it will, or at least give me insight on how this works so I can solve it myself. That leads me onto another thing... why on earth do we have to wait up to 4 hours (sometimes longer) for the sodding rules to propogate. They apparently review each rule manually!!!! No joke! If you haven't tried AWS already, I urge you to give it a go - you will never go back... (2/2) – Ben Carey Mar 26 '20 at 23:50
  • This worked for me, but it's worth triple-emphasising that this needs to propagate for quite some team before it works. After adding the rule, I still had purges not working - but next day purges were pretty instant. – oatsoda Aug 06 '20 at 11:54
2

I also found if you purge each file separately, for example, put /css/main.css in 'Content path' when purging instead of 'purge all' it will work

Vic
  • 21
  • 1
  • I also found this, but the accepted answer solved this. I guess the rewrite rule was interfering with purge all, but perhaps not specific file purges. – oatsoda Aug 06 '20 at 11:55
1

10/14/2019 - With this similar setup (Azure CDN/Blob-Static-Site/Verizon), I was having a cache issue too. I happened to have only 1 URL rewrite rule. What solved it for me was to set a subsequent rule regarding the caching/Max-Age.

Here's how I did that: Azure Portal -> CDN profiles -> Click your profile (Overview section)

  1. Click the manage icon in the Overview (in the details section/blade). This should open the craptastic Verizon page.
  2. Hover over "Http Large" and then click Rules Engine
  3. Enter a Name/Description in the textbox. For example: "Force Cache Refresh"
  4. Leave If/Always selected
  5. Click the "+" button next to Features
  6. In the new dropdown that appears choose "Force Internal Max-Age" (leave 200 as the response)
  7. Enter a reasonable* value in the field for seconds. (300 for example)
  8. Click the black Add button

It says it could take 4 hours for this rule to work, for me it was about 2.

Lastly, for this method, the order of the rules should not matter, but for above rewrite rules keep in mind the rules do allow you to move them up and down in priority. For me, i have, Https redirect first, Url rewrite (for "React-routing") 2nd. and lastly Force Cache Refresh last.

*note: This is a balance since purge is not working for me, you want the static (app/site) to update after you publish, but you don't want to have tons of needless traffic to refresh the cache either. For my dev server i settled for 5 minutes. I think production will be 1 hour... haven't decided.

amd3
  • 696
  • 1
  • 6
  • 15
0

is everything working now? I see that your rules are probably more complicated than you need. If the goal is just to have root "/" rewrite to /index.html, this is the only rule you would need:

If always URL Rewrite - Source: "/"; Destination "/index.html"

  • Everything seems to be working, though I haven't had a chance to test a full update to all blobs in the container and then access it via the CDN with the rules in place. I was curious about the complexity of the rules, but I haven't had the time to sit down and work through them to decide if there is a more simple option (although I suspect you are correct based on the documentation I have read). It takes up to 4 hours to alter the rules, so optimizing that part of the puzzle is at the bottom of my list if it is currently functioning properly. – jpetitte Jul 13 '17 at 02:14