I am using Azure CDN (Ex: https://example-cdn.azureedge.com) to deliver static website from backend-endpoint which is Blob storage. Everything works fine except that Http request for static file(Ex: translation files stored on assets folder location /assets/i18n/en.json) from Angular application (Ex: https://example.com) are failed. As per the document, CORS is automatically set to *.
What I observed is that Angular application while making http request using HttpClient does a preflight request before making actual GET request. Azure CDN seems to be not supporting preflight OPTIONS request. Browser request fails with an error message Response for preflight does not have HTTP ok status.
Here is the snapshot of Rules set on Azure CDN
Question is, how to request files conditionally from Azure CDN using Angular application
If anyone facing the this issue, please make sure your original host is responding to these requests. In my case, Azure Storage Account was the original host. CDN started to respond after enabling CORS settings on Storage account.
Related
I'm trying to get the Azure IoT Remote Monitoring Web UI (https://github.com/Azure/pcs-remote-monitoring-webui) to run on my local machine and connect to a deployed instance of the solution at https://{your solution name}.azurewebsites.net/
I get an error from the server. Can anyone help me?
I'm following this tutorial:
https://learn.microsoft.com/en-us/azure/iot-accelerators/iot-accelerators-remote-monitoring-customize
When I run npm start, I get these messages in the browser console:
Failed to load resource: the server responded with a status of 401 (Unauthorized)
Access to XMLHttpRequest at 'https://{your solution name}.azurewebsites.net//config/v1/solution-settings/theme' from origin 'http://localhost:3000' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.
In the Azure Portal, find the resource for the deployed App Service that you are trying to ping (the *.azurewebsites.net address). Under the options for this App Service (in the left hand pane) there should be a CORS option. Once you’ve opened up the CORS option you should be able to whitelist URLs - enter your full localhost URL including the ports and https://. Save the changes and then reload the page that previously wasn’t working - changes might take a few minutes to apply.
I'm configuring Azure Application Gateway Url based routing for my two back-end pools and it is not working.
My default routing configuration is pointing to b1 end point and it is reachable by blabla.cloudapp.azure.com
When I add additional route path /b1/* I cannot access my back-end pool via blabla.cloudapp.azure.com/b1/. I get 404 page not found response.
Can anyone please help me to understand what is wrong with my configuration?
Azure Application Gateway URL Based routing will route different requests to different groups of servers (backend pools) based upon the URL of the request. Once the request is sent to a VM, it is received and treated like a normal web request. If the URL you are accessing is a Valid web URL for the web server that is receiving the request, then it will return a proper response.
The fact that you are getting a 404 error means that your web servers are receiving the request, but not finding anything at the requested location. One way you can troubleshoot this is to log onto the VM that should be receiving the request and trying the request in a browser replacing blabla.cloudapp.azure.com/with localhost/.
In the example you posted, you would need a folder from within your web directory called "b1" for the URL you specified to be a valid request.
You can use a Path-Based Rule to specify the default backend pool, as well as specific URL paths that should be sent to other backend pools. Here is an example of how to configure a Azure Application Gateway with URL based routing in the Portal.
Having an issue with Azure storage CDN. We have it configured for CORS, basically we allow all headers and origins (*), and GET|HEAD|
OPTIONS. Everything works fine when we are using the storage direct host. When we switch it over to use the CDN host,the OPTIONS request stops returning any of the allow headers and causes cross origin failures. On other gets I do get the allow origin header but nothing else. Anyone seen this or am I overlooking a config option somewhere? Happens locally talking to Azure and on our Azure hosted site.
Azure CDN profiles from Akamai currently do not tunnel OPTIONS requests. There is a patch currently underway to enable OPTIONS requests for cors pre-flight.
If you don't use pre-flight requests, does CORS work?
I believe in the last few days (around 4th Feb 2014), Microsoft announced CORS support for Azure Storage (link here) which is obviously a great idea.
In my case, I just wanted to find some confirmation of using a custom domain to map to azure storage which would solve an issue as follows:
Azure storage has a container with assets (images/docs etc)
I also have css/js assets there in azure storage too
Because at present the azure storage location is something like mystorage.blob.core.windows.net and my actual domain (where pages/services live) is say www.mydomain.com, I get CORS issues loading assets from a different domain of course.
So my question is if I do map a CNAME (for example assets.mydomain.com) to azure storage, will this solve the CORS related issues? Seems to me it should, however I wanted to check if others had a similar experience that they could comment on?
Thanks in advance.
You shouldn't get CORS issues loading assets, if they're just being loaded via link, script and img tags and the like. CORS only applies to AJAX requests made by JavaScript code in browsers.
Also, if the CORS rules are correctly configured on the Azure Storage account Blob service, the domain you use to address the account is irrelevant; it's the domain the current web page was served from (the Origin domain) that must be accepted by the CORS-enabled service.
So for example, if your page is served from yaysite.com, and you try to access a resource on yay.blob.core.windows.net using an XMLHttpRequest, the browser will add an Origin header to the request:
Origin: http://yaysite.com
The server at yay.blob.core.windows.net then needs to return an Access-Control-Allow-Origin header matching that to the response headers:
Access-Control-Allow-Origin: http://yaysite.com
If the browser doesn't see this header in the response, it will discard the data and the XMLHttpRequest object will trigger the error event.
Setting CORS rules on Azure Storage is described in this MSDN blog post.
Has anyone successfully configured Azure CDN for HTTP compression using their hosted web role? We are having trouble compressing HTTP content at the Azure edge servers. The CDN is only caching the uncompressed version of the content.
If we hit our resource link (webresource.axd) from a non-Azure approach it compresses via gzip (using the xxxx.cloudapp.net/cdn/webresource.axd) as expected. However, as soon as we point our resource link to Azure CDN (xxxx.vo.msecnd.net), the content is served up uncompressed, despite the browser telling the Azure CDN it accepts gzip.
I posted this same issue to Azure Forums, but nobody has responded as of yet.
While troubleshooting the problem, it appears that the Azure CDN is stripping out the Accept-Encoding HTTP header. Just curious if others have had this same issue.
Azure CDN Best Practices states...
How does the Windows Azure CDN work with compressed content?
The Windows Azure CDN will not modify (or add) compression to your objects. The Windows Azure CDN respects whatever compression is provided by the origin based on the "Accept-Encoding" header. As of 1.4, Azure Storage does not support compression. If you are using hosted-service object delivery, you can configure IIS to return compressed objects.
What we are seeing is that the CDN is not respecting the origin Accept-Encoding, it's being stripped away.
It was discovered thru trial and error that Azure CDN has a current limitation that it won't pass the Accept-Encoding HTTP header unless it finds a QueryString parameter containing a compressable filename type (.js, .cs) or you are requesting a file by its original name (jquery.js, site.css, etc.).
What this means is that if you are using an AXD resource handler (WebResource.axd, etc.), the HTTP compression will not be performed. The Azure CDN will only pass the Accept-Encoding if you append a QueryString parameter with a .cs or .js extension.
We are using a custom AXD resource handler, so this was easy for us to implement. We just applied &group=core.js and &group=core.css for our combined minified resources and the compression worked as expected. It's unfortunate this doesn't exist in the current Azure CDN documentation.
In short, we had to transform our URIs from this:
https://xxxx.vo.msecnd.net/resourceManager.axd?token=HL80vX5hf3lIAAA
to this:
https://xxxx.vo.msecnd.net/resourceManager.axd?token=HL80vX5hf3lIAAA&group=core.js
Once the Azure CDN sees the .js in the querystring, it will return the compressed version of the resource.
Hope this helps someone else using web resources (AXDs) served up via the Azure CDN.
CDN picks up compression from the origin and Windows Azure Storage does not support compression directly so if you get CDN content from Azure Storage origin, it will not be compressed. So if you have content hosted at Windows Azure Storage you will not be able to have compressed content. To have compressed content, you would need to host the content at hosted service such as web role as origin. As this type of origin would be IIS based, is a supported way to use compression.
Windows Azure CDN supports compressed content over HTTP1.0, and most of the time the problem I have seen are related with having an HTTP 1.0 vs HTTP 1.1 issue. So when you request you CDN object directly from your web role via HTTP 1.0 (using the wget command) you should get compressed content if all is correct. If you get non-compressed content then you know where the problem is. Please be sure you’ve configured your application and IIS itself to deliver compressed content to HTTP 1.0 clients as well as HTTP 1.1 clients.
I have written a detailed blog entry to exactly add HTTP Compression with Azure CDN through Web role:
http://blogs.msdn.com/b/avkashchauhan/archive/2012/03/05/enableing-gzip-compression-with-windows-azure-cdn-through-web-role.aspx
These answers about adding .css/.js extensions don't appear to apply any more with the recent (Q1 2014) updated Azure CDN service back-end.
I ran an isolated test with a new Cloud Service Web Role project today and a new CDN instance.
I placed a /cdn/style-1.css file in my web role (single instance) and accessed it via CDN. It was not compressed. Accessing directly WAS compressed.
The fix for my Web Role serving gzip'd content was to ensure the IIS configuration option noCompressionForProxies is "false" (default is true).
This made the Azure CDN then send me down gzip'd content.
Appending css/js extensions made no difference.
Note that when testing this change, it is a host configuration change so you must restart IIS via IIS Manager (not iisreset) for it to take effect. Lastly, to test the change, be sure to create a new file (eg, style-2.css) and request that via the CDN so it will fetch it from the origin server again.