Best practice dictates that static assets such as images should have long expiring cache headers so the client only downloads them once. Typically, when uploading to blog storage, you would specify a Cache-Control of many months or even years but the Azure Blob Storage Provider appears not to set this header. This means much slower sites for our users and much more bandwidth costs for us.
Do you have any thoughts or solutions as to how we can resolve this issue?
uses Etags for cache control. As far as I can see this works fine. I have just tested with current versions of IE, Chrome and Firefox on Windows 7. Data will be load only on first request. Depending on your browser and its configuration the next request to an unchanged blob item will return http status 304 and no content data will be send.
After further research I think I got your point. I will add an optional configuration which allows you to set cache-control by file type. Currently I cannot see how to set this for each media item during upload.
at Umbraco.Core.IO.FileSystemProviderManager.<GetUnderlyingFileSystemProvider>b__1(String s) at System.Collections.Concurrent.ConcurrentDictionary`2.GetOrAdd(TKey key, Func`2 valueFactory) at Umbraco.Core.IO.FileSystemProviderManager.GetUnderlyingFileSystemProvider(String alias) at Umbraco.Core.IO.FileSystemProviderManager.GetFileSystemProvider[TProviderTypeFilter]() at Umbraco.Web.Editors.ImagesController.GetResized(String imagePath, Int32 width, String suffix) at Umbraco.Web.Editors.ImagesController.GetBigThumbnail(String originalImagePath) at lambda_method(Closure , Object , Object[] ) at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ActionExecutor.<>c__DisplayClass10.<GetExecutor>b__9(Object instance, Object[] methodParameters) at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ActionExecutor.Execute(Object instance, Object[] arguments) at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ExecuteAsync(HttpControllerContext controllerContext, IDictionary`2 arguments, CancellationToken cancellationToken) --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult() at System.Web.Http.Controllers.ApiControllerActionInvoker.<InvokeActionAsyncCore>d__0.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult() at System.Web.Http.Filters.ActionFilterAttribute.<CallOnActionExecutedAsync>d__5.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Web.Http.Filters.ActionFilterAttribute.<CallOnActionExecutedAsync>d__5.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult() at System.Web.Http.Filters.ActionFilterAttribute.<ExecuteActionFilterAsyncCore>d__0.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult() at System.Web.Http.Controllers.ActionFilterResult.<ExecuteAsync>d__2.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult() at System.Web.Http.Filters.AuthorizationFilterAttribute.<ExecuteAuthorizationFilterAsyncCore>d__2.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult() at System.Web.Http.Dispatcher.HttpControllerDispatcher.<SendAsync>d__1.MoveNext()
Hm, you are right the nuget package is not updated properly. Please use the package form our. You don't have to install it just extract the idseefeld.de.UmbracoAzure.dll and put it into the bin folder.
Then I try to upload a new file, to download it and check "cache-control" value: Chrome say that it is max-age=0.
There are an issue? I look that x-ms-version is "2009-09-19". Am I using a oldest Blob Storage version?
Update
I changed version to "2015-02-21" but I receive the same result.
Update 2
I apologize.
In its control of Chrome if the resource was marked with the proper value for "cache-control" I checked on the "Request Headers" instead of "Response Headers".
I confirm that "Azure Blob Storage Provider" works correctly.
adding Cache-Control header
Hi
Best practice dictates that static assets such as images should have long expiring cache headers so the client only downloads them once. Typically, when uploading to blog storage, you would specify a Cache-Control of many months or even years but the Azure Blob Storage Provider appears not to set this header. This means much slower sites for our users and much more bandwidth costs for us.
Do you have any thoughts or solutions as to how we can resolve this issue?
Thanks
Hi,
uses Etags for cache control. As far as I can see this works fine.
I have just tested with current versions of IE, Chrome and Firefox on Windows 7.
Data will be load only on first request. Depending on your browser and its configuration the next request to an unchanged blob item will return http status 304 and no content data will be send.
Kind regads
Dirk
After further research I think I got your point.
I will add an optional configuration which allows you to set cache-control by file type.
Currently I cannot see how to set this for each media item during upload.
Dirk
Upgrade to version 1.0.10.1 and configure your desired cache-control. Please read documentation for details.
Dirk
Thanks you for adding this so quickly.
Unfortunately after upgrading I am now getting 500 errors in the media section of umbraco:
Here is an example of one of the calls:
http://localhost:61070/umbraco/backoffice/UmbracoApi/Images/GetBigThumbnail?originalImagePath={blog storage image url}
Update: I am using the NuGet package and it looks as though the 1.10 NuGet package is still using the 1.0.9 dll?
Hm, you are right the nuget package is not updated properly. Please use the package form our. You don't have to install it just extract the idseefeld.de.UmbracoAzure.dll and put it into the bin folder.
Thank you for your report!
Dirk
meanwhile the nuget package v1.0.10.2 should be fine!
Dirk
First: little note
I apply now
cacheControl
parameter in "FileSystemProviders.config". I receive an error while try to upload file:Then I add
mimetypes
parameter: it solve the issue.Second: a question
I was add this row in "config" file:
Then I try to upload a new file, to download it and check "cache-control" value: Chrome say that it is
max-age=0
.There are an issue? I look that
x-ms-version
is "2009-09-19". Am I using a oldest Blob Storage version?Update
I changed version to "2015-02-21" but I receive the same result.
Update 2
I apologize.
In its control of Chrome if the resource was marked with the proper value for "cache-control" I checked on the "Request Headers" instead of "Response Headers".
I confirm that "Azure Blob Storage Provider" works correctly.
Hi, I'm experiencing the same problem as you.. what do you mean when you say
AzureBlobFileSystem
provider requires 5 parameters: containerName, rootUrl, connectionString, mimetypes, cacheControl.This is the official sample:
You can simply add
mimetypes
parameter quit empty value like the sample above.Hi, please check out documentation. On page 3 you see the complete configuration. There you can also see where to put:
Cheers!
is working on a reply...