azure cdn purge not refreshing cached content

Question

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.

Answer 1

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.

Answer 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

Answer 3

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"

Answer 4

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.