CDN origin working for anybody?

Question

I'm trying out the new cdn functionality for css & js files but it doesn't seem to be working.  When requesting the file from the host it always responds with a 301 back to our domain.  The redirect goes to the correct place and serves the correct file which leads me to believe everything is configured properly, just nothing is getting cached.  At first I thought maybe it took some time to propagate but that was last night and still seeing the same behavior today.

Here is a sample: http://az25714.vo.msecnd.net/combine/siteCss/1339386325

Answer 1

Are the caching headers being set appropriately?

For the benefit of others wondering about the new features of the CDN I found the following sample to be helpful and easy to use.

Answer 2

I think they are ok but could be missing something.  The article linked says it must have max-age set and it does, wonder if something else is interfering.

Cache-Control: public, must-revalidate, max-age=2592000
Content-Length: 10967
Content-Type: text/css
Content-Encoding: gzip
Expires: Sat, 16 Apr 2011 16:38:08 GMT
Last-Modified: Thu, 17 Mar 2011 16:38:08 GMT
Etag: "1339386325"
Vary: Accept-Encoding
Server: Microsoft-IIS/7.0
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Thu, 17 Mar 2011 16:38:08 GMT

Answer 3

Hi Leaf.ly,

301 response should ocurred when edge server doesn't cache the requested file. I doubt there are something wrong with your configuration. SteveMarx provide a sample project, you may download and compare with your project

http://blog.smarx.com/posts/using-the-windows-azure-cdn-for-your-web-application

Thanks, 

---

Mog Liang
Please mark the replies as answers if they help or unmark if not.
If you have any feedback about my replies, please contact [e-mail].
Microsoft One Code Framework

Answer 4

These are the headers that are spit out in the sample Marx app:

Server	ASP.NET Development Server/10.0.0.0
Date	Mon, 21 Mar 2011 03:36:25 GMT
X-AspNet-Version	4.0.30319
X-AspNetMvc-Version	3.0
Cache-Control	public, max-age=300
Content-Type	text/css; charset=utf-8
Content-Length	4
Connection	Close

I removed the must-revalidate from my cache-control header but still seeing the same thing.  Could something else like the ETag be causing the edge servers not to cache the files?

Answer 5

Hi Leaf,

Have you run Steve Marx's sample project? To do this, we could first know if your azure account works well.

Thanks,

---

Mog Liang
Please mark the replies as answers if they help or unmark if not.
If you have any feedback about my replies, please contact [e-mail].
Microsoft One Code Framework

Answer 6

I took the code from the sample project and tried it.  The cache headers are set but it still gets redirected:

http://az25714.vo.msecnd.net/index

full source:

  public class CdnController : Controller
  {
    [OutputCache(Duration = 300, Location = System.Web.UI.OutputCacheLocation.Any)]
    public ActionResult Index()
    {
      return File(Server.MapPath("~/public/images/leafly-logo-140ish.png"), "image/png");
    }
  }

 

Answer 7

Hi Leaf.ly,

Thanks for your information, I will involve the senior engineer who familiar to AzureCDN into this issue.

Thanks,

---

Mog Liang
Please mark the replies as answers if they help or unmark if not.
If you have any feedback about my replies, please contact [e-mail].
Microsoft One Code Framework

Answer 8

http://az25714.vo.msecnd.net/combine/siteCss/1339386325 maps to http://leafly.cloudapp.net/cdn/combine/siteCss/1339386325, which does indeed return a 301 redirect to http://www.leafly.com/cdn/combine/siteCss/1339386325. The CDN is just faithfully passing along the request and the response.

My guess is that you have a URL Rewrite rule set up to prevent people from using the leafly.cloudapp.net domain to access the site. This has an undesirable consequence when turning on the CDN.

Answer 9

http://az25714.vo.msecnd.net/combine/siteCss/1339386325 maps to http://leafly.cloudapp.net/cdn/combine/siteCss/1339386325, which does indeed return a 301 redirect to http://www.leafly.com/cdn/combine/siteCss/1339386325. The CDN is just faithfully passing along the request and the response.

My guess is that you have a URL Rewrite rule set up to prevent people from using the leafly.cloudapp.net domain to access the site. This has an undesirable consequence when turning on the CDN.

aha!  Didn't even think about our redirect rule and how it would effect the edge servers.  I will add an exclusion for /cdn.  thanks!