Should the manifest file of a hosted Firefox OS app live on the same domain?
I'd like to put it on a CDN together with the rest of the static files.
Yes it should be served from the same origin. That is part of the security model of hosted apps and it is there to prevent abuse of your app. Take a look at manifest page on MDN:
... the paths must be served from the same origin as the app
Related
I am hosting an angular application in azure web app. I want my application should be only accessible on chrome browser. If someone access the site from other browser then user should redirect to browser restriction page. So to achieve this is there any policy available that can be added to web app, instead of writting the code to detect the browser and then redirect?
Rajesh
Azure web app does not have the functionality to restrict access to the browser as you described.
Reason
Azure app service (Windows & Linux) is essentially a webserver running in a sandbox, which is no different from real IIS or Nginx and Apache.
WebServer provides program deployment and access functions, and only receives HttpRequest. As for the information contained in HttpRequest, azure app service does not provide analysis.
For example, adding User-Agent: Chrome is the specific information contained in HttpRequest. This means that we can only determine the source by parsing the HttpRequest through the code.
I have a Azure Linux web app. I can upload files via FTP (for example test.html) but then accessing them (https://mysite.azurewebsites.net/test.html) gives a 404. The files are there, and I can see them in kudu console, but I get 404? I even deleted the "hostingstart" file yet going to https://mysite.azurewebsites.net still returns the hostingstart file content? Do I need to trigger a "redeploy" somehow? The documentation I have read just says "upload the files via ftp to /home/site/wwwroot which is what I have done.
???
I turned on all logging, but was getting nothing meaningful. I raised a support ticket and got a response that explains it. A .Net platform on Linux cannot serve static content;
response from Microsoft:
Analysis:
http://mysite.azurewebsites.net/
Is a Linux web app with the custom image
DOTNETCORE|3.1
Hosted inside a B1 App Service Plan
The requests are served by a single Small web worker.
This type of web app expects .Net Core content not plain HTML. If you want to deploy plain HTML you can use a Windows web app or a Linux web app with PHP, as on a Windows web app there is IIS and on PHP there is Apache as web servers that by default are able to serve static content also.
for static content you can also use only your storage to deploy.
https://learn.microsoft.com/en-us/azure/storage/blobs/storage-blob-static-website
I have an Azure Media Service set up with a Premium subscription. I made an Android app which uses VideoView player and requests the multi-bitrate video files over HTTPS using the following format for asset links:
https://example.streaming.mediaservices.windows.net/c2234567-be1a-123c-ca25-e90bfca246da/1227_e3337f7-35ac-43e0-b55c-223e3333662.ism/QualityLevels(421811)/Manifest(video,format=m3u8-aapl)
Until now, I had CDN integration disabled. This worked fine and I never had issues using HTTPS.
However, now I want to enable CDN integration with default settings. When this feature is enabled, it automatically attaches the media service subdomain as a custom domain under the CDN (in this case example.streaming.mediaservices.windows.net). From what I understand, this means I should be able to continue making requests from my Android app to the same URLs as before, except now it will direct those requests to the CDN instead of the media service.
However, what I'm not sure of is whether or not I'll still be able to call those URLs over HTTPS. I see that Azure has a feature for Custom Domains with HTTPS in the works but it doesn't appear to be available yet.
So does the ability to call media service asset URLs over HTTPS carry over after CDN integration, and especially if I'm using the default media service subdomain as my custom domain?
If not, what will happen to the HTTPS calls? Will they receive no response or will they just bypass the CDN?
you should have no issues using HTTPS on CDN enabled Media Services Endpoints.
The Custom Domain HTTPS primarily refers to vanity urls like "blizz.com", which is not currently supported.
I have a web site hosted on Azure (http://mike-ward.azurewebsites.net/). I set up an Azure CDN from the Azure portal that points to (references?) my web site. According to the articles and docs I've read, content is only served from the /cdn/ folder (http://az667460.vo.msecnd.net/cdn/images/favicon.ico for example). However, it also seems to serve the dynamic web site stuff by simply referencing the root (http://az667460.vo.msecnd.net/).
Has the policy changed with regard to serving content from other than the /cdn/ folder? If not, what's happening here?
Al website content is now available through the CDN, see these new examples:
http://azure.microsoft.com/en-us/documentation/articles/cdn-websites-with-cdn/
In your site you manage the url, so if a resource is referenced with the CDN url: http://az667460.vo.msecnd.net it will be served from the CDN.
the special /cdn folder isn't required anymore
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.