Azure CDN rules engine to add default document EXCEPT for files requested by the site

Question

I am using Azure Verizon CDN to publish my web application (an SPA) from Blob storage. I've successfully set up a custom domain and SSL. I've added a rewrite rule in the CDN to redirect to the default document index.html. Basically, this takes the incoming request and inserts "index.html" between the URL path and any query strings. So mydomain.com/startup goes to mydomain.com/startup/index.html

mydomain.com/homepage goes to mydomain.com/homepage/index.html

and mydomain.com/showuser/?userId=xxxxx goes to mydomain.com/showuser/index.html/?userid=xxxxx

Which all seems to work well.

Existing rule to add default document

The URL in the address bar used by the SPA never requests an actual file, but code in the default document index.html does. And these requests for files are all failing with a 404 because I guess the rewrite rule is acting on these as well.

What I want is some way to not perform the URL rewrite if the URL includes a filename. The rules engine prevents me from adding such a condition when using the URL Rewrite feature - apparently you can't use any match conditions on the URL when trying to use the URL Rewrite feature.

Error when trying to use condition involving URL filename

Answer 1

I was searching for the answer to this as well. I ended up having to engage Azure support.

Unlike App Services and IIS, CDN doesn't have a way to rewrite the URL when a file doesn't exist. However, so long as your SPA's routes don't contain a ., you can create a rewrite rule that only acts on URL paths that don't contain a .. This will have the effect of rewriting naked path requests while leaving file requests alone.

First off, your CDN Profile needs to be the Verizon Premium CDN SKU in Azure. It's the only SKU that supports rewrite rules.

• Go to your CDN Profile in the Azure portal and click the Manage button to bring up the Verizon management portal.
• Select Rules Engine under the HTTP Large menu item.
• Enter whatever name you'd like for the new default document rule.
• The condition should be set to IF Always.
• Click the + next to Features to add a new Feature.
• Select URL Rewrite.
• Note the drop down lists for selecting the CDN endpoint. If you have multiple CDN endpoints in your CDN profile, you will need to add a new Feature for each endpoint.
• For the Pattern, enter [^?.]*(\?.*)?$. This pattern catches URL paths with . in them, but doesn't care whether or not it's in the query string.
• For the Path, enter origin_path/document.ext. This is the tricky part. The Path is relative to the origin root. For instance, if your CDN endpoint's origin path is /origin_path and you want to redirect to index.html, you would enter origin_path/index.html. This will always be the case if your CDN is backed by an Azure Storage Account and the origin points to a container.
• Click Add to add your rule, wait N hours, and you're good to go.

Answer 2

I have an addendum to Justin Gould's answer. With "IF Always" you will break purge requests from Azure. Fortunately, they have a specific User-Agent so you can match on that.

In addition, it will break HTTP → HTTPS redirection if you do that with another rule. Verizon won't let you match on "Request Scheme" to filter out those requests so you have to be sneaky and match on X-Forwarded-Proto.

Instead of "IF" "Always", you'll want to set:

• "IF" → "Request Header Regex" → Name: "User-Agent" → "Does Not Match" → "ECPurge/*" → Ignore Case: checked

• "AND IF" → "Request Header Literal" → Name: "X-Forwarded-Proto" → "Does Not Match" → "http" → Ignore Case: checked

• Then, follow the rest of Justin's instructions.

Reference: https://github.com/Azure/azure-cli/issues/6722

Answer 3

So it seems like your issue is:

these requests for files are all failing with a 404 because I guess the rewrite rule is acting on these as well

And if your assumption is correct, it seems like you would need to request files using their relative path instead of the fully qualified one. Have you tried it?

For example, the resource you are trying to get lives here:

 http://example.com/resource/myresource.pdf

but when you use this path you get redirected to something like:

 http://example.com/resource/index.html/myresource.pdf

...so when referencing the resource if you use a relative path it would look something like this

<a href="/resource/myresource.pdf">my resource</a>

If I misunderstood your question or issue, or this doesnt solve your problem- add the full error you receive in the developer console (F12).. including what the url should be and what its transforming to when you encounter the issue.