Hi Jeavon... I do actually have these settings in .. (my bad... i should have stated that) . I was just truncating my code... full file looks like this:

<?xml version="1.0" encoding="utf-8"?>
<caching currentCache="AzureBlobCache">
  <caches>
    <cache name="DiskCache" type="ImageProcessor.Web.Caching.DiskCache, ImageProcessor.Web" maxDays="365">
      <settings>
        <setting key="VirtualCachePath" value="~/app_data/cache" />
      </settings>
    </cache>
    <cache name="AzureBlobCache" type="ImageProcessor.Web.Plugins.AzureBlobCache.AzureBlobCache, ImageProcessor.Web.Plugins.AzureBlobCache" maxDays="365">
      <settings>
        <setting key="CachedStorageAccount" value="DefaultEndpointsProtocol=https;AccountName=MyStorageAccountName;AccountKey=/Wku0aWumPtG7MUE0/yBNL" />
        <setting key="CachedBlobContainer" value="cache" />
        <setting key="UseCachedContainerInUrl" value="true" />
        <setting key="CachedCDNRoot" value="http://MyEndpoint.vo.msecnd.net/" />
        <setting key="SourceStorageAccount" value="" />
        <setting key="SourceBlobContainer" value="" />
        <setting key="StreamCachedImage" value="false" />
      </settings>
    </cache>
  </caches>
</caching>

I can see the image getting written to the blob cache but I don't get the url serving to me. i can see this is getting uploaded: https://tdreditorials.blob.core.windows.net/cache/8/9/4/4/f/f/8944ffa7b6336130c0f9f08d09630e6fa02f1e37.jpg

...and i have this uploaded: https://tdreditorials.blob.core.windows.net/media/1042/logo.jpg

BUT .. when i run the site: I get 404 on page looking for this: http://localhost:56918/media/1042/logo.jpg?height=65&width=205&bgcolor=000

The site is not taking the /media standard urls and converting them to the cdn.

PS: Thanks so much for getting back to me .. I am on day 3 of trying to get this to work.

PPS: Your Security.Config settings say to disable the LocalFileImageService on line 5 and enable cloudImageService so I did that as well... RemoteImageService is still enabled.

Ok, so FileSystemProvider is work fine.

If you request an image directly from Cdn, e.g. http://MyEndpoint.vo.msecnd.net/media/1042/logo.jpg do you get anything (assuming media and cache are in the same account)

Hi. I get 404 when I try and hit http://endpoint891634.vo.msecnd.net/media/1042/logo.jpg

Should the urls be resolving with that address or should they be resolving as the cached path?

As per your suggestion I switched to the new portal.azure.com and setup a new endpoint using the cdnProfile and its new configuration. I created both a new storage container and endpoint. I updated my keys and ran the site. Right away I got media and cache folders created on the storage containers. At that point I set the media and cache folder permissions to BLOB / Public read access. After doing this I had the same behavior (broken images with querystring and no endpoint). I fussed around a bit more and then suddenly I noticed that things started to speed up. I went back to the home page and noticed that the logo now had a 302 redirect from http://localhost:56918/media/1042/logo.jpg?height=65&width=205&bgcolor=000 to http://umb743.azureedge.net/cache/c/d/0/5/5/0/cd0550ba17e83d032005aa8fab4f33b09dc289ce.jpg WIN!

The other images however like the bacci one on the bottom don't get pushed to cdn for some reason.. I can't explain why http://localhost:56918/media/1046/14386124825d43f359900hcropped.jpg If I add a height querystring onto it then immediately I am redirected to a cached instance http://localhost:56918/media/1046/14386124825d43f359900hcropped.jpg?height=200 302s to http://umb743.azureedge.net/cache/d/d/4/c/a/3/dd4ca3d51c8e0c686beeeb6815f3431217a37b7c.jpg

Is this expected behaviour? I notice the same thing with an image I uploaded into the 3 wide colum. I uploaded a 480X270 tall gif and then stuck into one of the 3 wide columns in fanoe home page. It won't get a 302 either even though it is scaled to 276 wide.

Either way it seems to be working I am just not sure if the anomalies are expected.

Thank you for your help in running this down.
FYI - other pages (http://localhost:56918/explore/our-umbraco/) that have images with qstring are getting pushed to cdn correctly.

Hi James thanks for your reply. I was writing while you were. Please see my response above to Jeavon. It works... but not as I would expect. You guys keep asking if something like this works: original url:

   <img src="/media/1049/9027510123_92a91b5cf4_b_dark.jpg?width=1920&amp;height=700&amp;center=0.340823970037453,0.54&amp;mode=crop">

does 302 redirect to http://umb743.azureedge.net/cache/3/a/1/f/f/b/3a1ffbe5b6ff7a0011f10eefca03f52e4e2d5f5e.jpg but this does not resolve at all. http://umb743.azureedge.net//media/1049/902751012392a91b5cf4b_dark.jpg?width=1920&height=700&center=0.340823970037453,0.54&mode=crop

I was thinking maybe it was because it was existing content but this: http://localhost:56918/media/1053/facepalm.jpg does neither a redirect or create a cache instance or create a cdn endpoint like http://umb743.azureedge.net/media/1046/14386124825d43f359900hcropped.jpg

I am happy to send you guys my setup. It is about 120mb zipped including the dlls.

PS: CDN was setup as storage, permissions on blob are public, UseCachedContainerInUrl = false makes all images 500 that were previously in cache. With false I get server error requesting http://localhost:56918/media/1042/logo.jpg?height=65&width=205&bgcolor=000: The remote server returned an error: (400) Bad Request The logo is just the fanoe/umbraco logo

Hi Mac,

The other images however like the bacci one on the bottom don't get pushed to cdn for some reason.. I can't explain why http://localhost:56918/media/1046/14386124825d43f359900hcropped.jpg If I add a height querystring onto it then immediately I am redirected to a cached instance http://localhost:56918/media/1046/14386124825d43f359900hcropped.jpg?height=200 302s to http://umb743.azureedge.net/cache/d/d/4/c/a/3/dd4ca3d51c8e0c686beeeb6815f3431217a37b7c.jpg

Is this expected behaviour? I notice the same thing with an image I uploaded into the 3 wide colum. I uploaded a 480X270 tall gif and then stuck into one of the 3 wide columns in fanoe home page. It won't get a 302 either even though it is scaled to 276 wide.

There's no anomaly there. ImageProcessor.Web will only intercept requests that have querystring parameters. It would be incredibly expensive process-wise for it to do otherwise.

I think you are having trouble understanding how websites work as much as anything.

Scaling an image in the browser will not change a thing unless you are also changing the image request. A browser will not make additional requests for anything at all unless the requested url changes. Any activity that doesn't make a specific request to the server is client side and is handled purely in the browser.

When you change the url to append querystring parameters you are sending a request to the server. ImageProcessor.Web will attempt to intercept and parse the request. If it is one it recognises only then will it process, cache and redirect the request.

http://umb743.azureedge.net//media/1049/902751012392a91b5cf4b_dark.jpg?width=1920&height=700&center=0.340823970037453,0.54&mode=crop

Will never work. That is as expected. You are making a request to a url outside of your domain and as such there is no way for ImageProcessor.Web to intercept it. You simply cannot intercept a request to an external url.

Hi Mac,

Well yeah?!

Nothing will get served through the CDN unless you specifically tell ImageProcessor.Web to do so by adding querystring parameters. We discussed this above.

The FileSystemProvider and ImageProcessor.Web are two separate entitities. Neither know about each other at all.

You configured your FileSystemProvider to use the blob storage account and it doesn't know about the CDN.

I'm not sure how I can explain it any better.

No worries, really glad I was able to give you any assistance. It's a very complicated system overall so difficult to explain at times.

There might, might, be a way I can help you further though.

There is a setting in the configuration interceptAllRequests that was added in ImageProcessor.Web 4.5.0 that tells the system to intercept all requests.

<!--interceptAllRequests - Added version 4.5.0 to allow intercepting requests with no querystring.-->
<processing preserveExifMetaData="false" interceptAllRequests="true">

http://imageprocessor.org/imageprocessor-web/configuration/#processingconfig

This makes things a little more expensive though as your image will now be processed and encoded by System.Drawing before caching and redirecting to the CDN. That can make images actually larger than they originally were. That would serve all images from the CDN.

Having a look through my FilesystemProvider code though it looks like there is no reason why I could not use the CDN root url rather than the blob container url in the configuration. If I'm right that would ensure that all processed images come from the CDN.

e.g

<?xml version="1.0"?>
<FileSystemProviders>
  <Provider alias="media" type="Our.Umbraco.FileSystemProviders.Azure.AzureBlobFileSystem, Our.Umbraco.FileSystemProviders.Azure">
    <Parameters>
      <add key="containerName" value="media" />
     <!-- Replace the value here -->
      <add key="rootUrl" value="http://umb743.azureedge.net/" />
      <add key="connectionString" value="DefaultEndpointsProtocol=https;AccountName=[myAccountName];AccountKey=[myAccountKey]"/>
      <!--
        Optional configuration value determining the maximum number of days to cache items in the browser.
        Defaults to 365 days.
      -->
      <add key="maxDays" value="365" />
    </Parameters>
  </Provider>
</FileSystemProviders>

I suggests you give both a try to see if that aids you.

Cheers

James

Good news. Forcing all requests through the imageProcessor reduces the image request time almost a whopping 50% after subsequent request.

Full image load times from the storage account ranged around: 573ms,988ms,1760ms

Full image load times from the cdn after processing: 228ms, 339ms, 348ms, 371ms

All of this is with browser caching off. If we compare the two worst times the improvement is roughly 5 times faster. It is worth eating the cost of the processor time loss on the initial request in my opinion.

For what it is worth just changing the rootUrl setting to the cdn didn't work.

Thanks for the setting tip! Golden!