I Have an Angular application which is hosted in azure web app. I want to access video file by requesting url like https://something.azurewebsites.net/htmldelivery/assets/videos/test.mp4 But I was not able to served requested video file from web app. It simply return "The resource you are looking for has been removed, had its name changed, or is temporarily unavailable."
App Service Plan :S1 & Location : UK West
This is how it look like my current directory structure in the web app.
When I request the video file directly from browser https://something.azurewebsites.net/htmldelivery/assets/videos/test.mp4 it returns me 404 file not found error.
Does anyone have any idea about this issue ? I was trying to configure Virtual applications and directories in web app configuration but still did not worked for me. I was changing the physical path up to site\wwwroot\htmldelivery\assets\videos\test.mp4 but still no success.
After further investigation I came to the point that Azure web apps need some configuration to configure the mimeType in your web.config to work with video files in Azure Web App. So I have just simply created a web.config file into the root directory and it works well.
<configuration>
<system.webServer>
<staticContent>
<mimeMap fileExtension=".mp4" mimeType="video/mp4"/>
<mimeMap fileExtension=".ogv" mimeType="video/ogg"/>
<mimeMap fileExtension=".webm" mimeType="video/webm"/>
</staticContent>
</system.webServer>
Related
I setup a Sitecore infrastructure on azure (I created the same before and it worked) and when I connect to the web apps directly, they all work. I configured access to two of the apps via Application Gateway - while one works, the other one gives 502 on the health status.
I checked on the application and there it shows me that the error is "ERROR_INTERNET_CONNECTION_ABORTED".
When I completely deactivate Sitecore (rename default.aspx and web.config) and put an index.html page, the application gateway can access it.
As mentioned - I have a running deployment that I did with the same ARM template. I also deleted everything and redeployed - same issue.
As mentioned - direct access to the web app works perfectly.
I have NO network restrictions on the web app yet.
It might be the case for Sitecore initial startup to take ages (more than health probe from service gate).
Considering Service Gate does not receive response from WebApp, it assumes application to be unhealthy, and might cache the 502 code.
What does your web app diagnostics say?
I finally found the issue. It was not the startup time and not an issue with the Application Gateway:
<ipSecurity allowUnlisted="false" denyAction="AbortRequest">
<clear />
<add ipAddress="0.0.0.0" subnetMask="0.0.0.0" allowed="true" />
</ipSecurity>
this is in the web.config for newer Sitecore Versions. No idea why it worked for the other installation - but removing this solved the issue for me.
I'm trying to serve some static content (Jekyll if that's relevant) out of an Azure web app. Said web app can also be served out of an Azure CDN. Both urls (CDN and app) work fine.
A chrome audit complains that the assets of my page are missing cache expiration dates. Fair enough.
But uhhh...how do I set cache expiration for an Azure web app or an Azure CDN endpoint?
Can they be set somewhere in the HTML? Can they be set somewhere in the wilds of the Azure console?
Most google answers (including SO) explain how to set the expiration via a web.config file, but I don't have one of those, because my application is not a .NET app.
The answer to my question turns out to be dead simple. I just needed to add a web.config file to the root of my jekyll app. Like so:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<staticContent>
<clientCache cacheControlMaxAge="365.00:00:00" cacheControlMode="UseMaxAge"/>
</staticContent>
</system.webServer>
</configuration>
Coming from a Linux background, I assumed the web.config was a .NET thing, but nope. It sets the IIS (that is, Azure) configuration.
I am attempting to host multiple websites in a single Azure WebApp rather than having multiple web apps each hosting a site. Each of these sites is rather small, but in order to meet the requirements of the SLA with Azure, we need to have the server scaled with more than one instance for our Production environment, thus the reasoning for combining sites.
After researching this topic, I have got the following setup with our Azure account.
Created the proper CNAME DNS records in our zone manager (complete and works).
Setup the Azure WebApp to respond to the subdomains (complete and works).
Setup a virtual directory for the second web application (complete and works)
At this point, both web applications function correctly and both subdomains are pointing at our Azure instance. We now have the following setup:
both www.mydomain.com and app.mydomain.com bring up the root application that I deployed.
going to www.mydomain.com/app2 and app.mydomain.com/app2 bring up the second application that I deployed to the virtual directory
What I would like to achieve:
Going to app.mydomain.com would bring up the application in the virtual directory.
Going to www.mydomain.com would bring up the application at the root of the azure instance.
However, what I cannot figure out is how to map a subdomain to a specific virtual directory. I have tried to update the Site URL to be the subdomain I want the application to respond to, however, the subdomain still brings up whatever I have in the root of the WebApp deployment.
Should I have some HttpHandler that sits in the site root and directs traffic to the proper virtual directory? Is there a setting in the portal that I am missing? Previously, we did this with Web Roles and tinkering with the ServiceDefinition file, but the tool sets for the Azure Web Apps in regards to publishing, integration with Source Control, etc seem to be a bit further along.
The answer posted by RuslanY will work (with some modifications to the rules slightly) however, after understanding more of the Azure portal and Web App configurations, it is not needed to host multiple sites within a single Web App (Its technically multiple web apps all sharing the resource plan you define, such as 2 instances of Standard Level 0 (S0))*.
As of today's Azure service offerings, the following is true. When you create a new Web App, you pecify the "App Service Plan" that the app falls into. If you have an App Service plan, lets say Standard with 2 instances, any Web App you deploy to that App Service plan shares those resources with other web apps in the same service plan, meaning you are not paying additional costs to host the additional web app if it is in the same App Service plan. I had assumed each web app was its own set of resources (it can be, but doesn't have to be). Given this, to accomplish what I need, I simply create a web app for each sub domain and place them all into the same App Service plan. I now am hosting multiple sites, not paying for 2 servers per site (what I wanted to avoid) and I don't have to use URL rewrites or HTTP Handlers.
I hope this write-up helps others understand the structure of the Azure Web Apps a little bit better. The current online documentation, from what I can tell, doesn't make this exactly clear.
This may be possible to do with URL rewrite rule which takes the hostname of the request and rewrites the request URL to start with the subdomain extracted from the hostname:
<system.webServer>
<rewrite>
<rules>
<rule name="Rewrite Subdomain To Directory">
<match url=".*" />
<conditions>
<add input="{HTTP_HOST}" pattern="^www\.mydomain\.com$" negate="true" />
<add input="{HTTP_HOST}" pattern="^(.+)\.mydomain.\com$" />
</conditions>
<action type="Rewrite" url="{C:1}/{R:0}" />
</rule>
</rules>
</rewrite>
</system.webServer>
To understand the syntax of the rewrite rules you can refer to the IIS.net documentation about URL rewrite module.
We are creating an azure angularjs application. This application is created as a web role in an azure project. After a deploy we get a 403 error:
403 - Forbidden: Access is denied.
You do not have permission to view this directory or page using the credentials that you supplied.
All files are copied automatically from the source project via Gulp. They are not included in the project file.
In the project properties we specified in the publish settings that it should "copy all files in this project folder". The main page is an index.html page that should load up the whole angular application. To get the index.html as default page we added this to the web.config:
<system.webServer>
<modules runAllManagedModulesForAllRequests="true"/>
<defaultDocument>
<files>
<clear/>
<add value="index.html"/>
</files>
</defaultDocument>
Are there other settings we need to adjust?
I may not be able to point out what's wrong with your application but could you please check as following.
Just visit your website with index.html specified. I mean http://your-app.cloudapp.net/index.html. If it works then this could because your web.config setting doesn't work.
If your got a 404 error, please check the website folder via Remote Desktop. This might because your deployment script (or project setting) was incorrect which caused some files were missing.
If it works but got 403 when you clicked some links or buttons to navigated to another angular view, this should because your IIS doesn't support Angular Router. To fix this problem please refer How do I configure IIS for URL Rewriting an AngularJS application in HTML5 mode?
Hope this helps
I have created a web site using the standard ASP.Net MVC 5 template with no authentication. I have added MVCSiteMapProvider from NuGet. On my dev machine the /sitemap.xml endpoint returns the correct sitemap once I add the UrlRoutingModule-4.0 to web.config. If I publish to Azure Web Sites the /sitemap.xml endpoint also works. However if I publish to my local hoster the /sitemap.xml endpoint returns a 404 - File or directory not found.
Any idea what I need to change / add to web.config to get the endpoint working?
Thanks
Tim
As far as I am aware, this configuration is all that is required to make it function in MVC4/MVC5:
<system.webServer>
<modules>
<remove name="UrlRoutingModule-4.0" />
<add name="UrlRoutingModule-4.0" type="System.Web.Routing.UrlRoutingModule" />
</modules>
</system.webServer>
But then, I don't have much of an idea why this line is required, a contributor figured it out and I added the solution to the NuGet package.