I am trying to remove unwanted Cache-Control, Pragma and Expires HTTP headers in responses from a Web Api 2 project hosted on an Azure website in Standard mode.
I have tried the following in Global.asax Application_PreSendRequestHeaders:
var headers = ((HttpApplication)sender).Context.Response.Headers;
headers.Remove("Cache-Control");
headers.Remove("Pragma");
headers.Remove("Expires");
This works when debugging in Visual Studio. But on Azure, the headers are only removed for GET requests and not HEAD or POST requests.
Grateful for any suggestions!
Azure Web Sites supports the request filtering module, so you can do this in your web.config:
<system.webServer>
<httpProtocol>
<customHeaders>
<remove name="Cache-Control" />
<remove name="Pragma" />
<remove name="Expires" />
</customHeaders>
</httpProtocol>
</system.webServer>
Disclaimer: I am not condoning the removal of these headers, which are an essential part of the HTTP protocol.
Removing cache headers says to clients "it is entirely up to you to decide how to cache this response", which may result in odd and hard-to-reproduce errors in production. If you want to disable caching, you should set these headers to values which explicitly disable caching:
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Cache-Control" value="no-cache" />
<add name="Pragma" value="no-cache" />
<add name="Expires" value="-1" />
</customHeaders>
</httpProtocol>
</system.webServer>
Related
I have IIS 10 in front of a reverse proxy.
The reverse proxy sends responses with the header X-Frame-Options.
I need to remove this header from the response when another header is set to something:
Condition : CustomHeader is set to CustomValue
I have tried the following code (that doesn't include the condition because I don't know how to do it) but it doesn't work. The response still includes X-Frame-Options header.
<httpProtocol>
<customHeaders>
<add name="X-Frame-Options" value="" />
</customHeaders>
</httpProtocol>
Does anyone know how to solve that please ?
Thanks.
You can try below setting:
<httpProtocol>
<customHeaders>
<remove name="X-Frame-Options" />
</customHeaders>
</httpProtocol>
More information you can refer to this link: https://learn.microsoft.com/en-us/iis/configuration/system.webserver/httpprotocol/customheaders/#attributes.
I'm trying to add/remove certain http headers from responses coming back from a 'pure' web api application (i.e. no MVC) published to Azure.
I added the following web.config to the project in VS2019:
<configuration>
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="X-Content-Type-Options" value="nosniff"/>
<add name="X-Frame-Options" value="SAMEORIGIN"/>
<remove name="X-Powered-By"/>
</customHeaders>
</httpProtocol>
</system.webServer>
</configuration>
This works fine in my dev environment with IISExpress. It also works fine when the app is published to Azure for app services that are not configured for multi-instance scaling. However, when the app service is configured for multi-instance scaling (three instances in my case) then responses from the app contain 'X-Powered-By' and no 'X-Content-Type-Options' or 'X-Frame-Options'.
Publishing creates the following web.config in Out folder on my dev machine:
<configuration>
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="X-Content-Type-Options" value="nosniff" />
<add name="X-Frame-Options" value="SAMEORIGIN" />
<remove name="X-Powered-By" />
</customHeaders>
</httpProtocol>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath=".\<apname>.exe" stdoutLogEnabled="false" stdoutLogFile="\\?\%home%\LogFiles\stdout" hostingModel="inprocess" />
</system.webServer>
</configuration>
I also verified that the above web.config is present in the root of the app service in Azure.
Is there anything else that needs to be done in app service configuration in Azure for this to work with multi-instance scaling?
After testing, you do not need to make any changes. In the code or web.config, your solution is currently possible, provided that it is deployed in a windows-based webapp. If it is deployed under linux, then the web.config file is not effective. The web.config file is only applicable to iis. Under linux, the configuration file that needs to be used should be .htaccess.
Put web.config under the wwwroot path, which is the root directory of the project.
Based on windows azure webapp, the post-deployment effect should be consistent with the local iis effect. After testing, after I deploy, you can see the screenshots, and the effect in your web.config has been achieved.
Note:
Some headers cannot be deleted, but they can be overwritten. They need to be coded in the program. You are not involved in this question yet.
<httpProtocol>
<customHeaders>
<add name="X-Content-Type-Options" value="nosniff" />
<add name="X-Frame-Options" value="SAMEORIGIN" />
<-- replace server vaule -->
<add name="Server" value="N/A" />
<remove name="X-Powered-By" />
</customHeaders>
</httpProtocol>
Test Steps:
Method 1 with web.config
Create a sample project like below.
Deploy to azure, please see my files on scm site.
Method 2 without web.config (workaround, also works in linux)
Add below code in Startup.cs, it also works for me .
app.Use(async (context, next) =>
{
context.Response.Headers.Add("X-Content-Type-Options", "nosniff");
context.Response.Headers.Add("X-Frame-Options", "SAMEORIGIN");
context.Response.Headers.Remove("X-Powered-By");
await next.Invoke();
});
I'm trying to allow CORS over a site, using the IIS CORS module (https://www.iis.net/downloads/microsoft/iis-cors-module), but I'm having troubles.
This is my web.config:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<cors enabled="true" failUnlistedOrigins="true">
<add origin="https://my.site" allowCredentials="false" maxAge="120">
<allowHeaders allowAllRequestedHeaders="true"></allowHeaders>
<allowMethods>
<add method="GET" />
<add method="POST" />
<add method="PUT" />
</allowMethods>
</add>
</cors>
</system.webServer>
</configuration>
with this setup, the OPTIONS (pre-flight) request works fine, but any further request (GET, POST) raise a browser exception because of missing Access-Control-Allow-Origin
I tryed to add the following to web.config:
<httpProtocol>
<customHeaders>
<add name="Access-Control-Allow-Origin" value="https:/my.site" />
</customHeaders>
</httpProtocol>
but in this way the OPTIONS fails because there're 2 instances of Access-Control-Allow-Origin
Using only custom header the pre-flight fails with code 500 (I think IIS doesn't support OPTIONS method without the CORS module).
IIS CORS module documentation is very poor and googling I only find info related to .NET code, but it's not my case. I can't modify code (and it's not .NET), I need to act on IIS.
How can I make IIS respond properly to CORS requests ?
From the code you have posted, it looks like you have not added your origin correctly.
The origin line should contain a (Fully Qualified Domain Name) FQDN or some regex that matches it.
A correct line would look like:
<add origin="https://my.site.com" allowCredentials="false" maxAge="120">
You can allow subdomains of your domain using:
<add origin="https://*.site.com" allowCredentials="false" maxAge="120">
From the sounds of it, you aren't receiving the headers you want back from the web server. This may be due to the webserver Only returning CORS safe headers.
Using the IIS CORS Blog from Microsoft, I've added in config that will expose the headers back in the request.
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<cors enabled="true" failUnlistedOrigins="true">
<add origin="https://my.site" allowCredentials="false" maxAge="120">
<allowHeaders allowAllRequestedHeaders="true">
<add header="DNT" />
<add header="Host" />
<add header="Origin" />
<add header="Referrer" />
<add header="User-Agent" />
</allowHeaders>
<allowMethods>
<add method="GET" />
<add method="POST" />
<add method="PUT" />
</allowMethods>
<exposeHeaders>
<add header="DNT" />
<add header="Host" />
<add header="Origin" />
<add header="Referrer" />
<add header="User-Agent" />
</exposeHeaders>
</add>
</cors>
</system.webServer>
</configuration>
However, according to This CORS documentation OPTIONS requests don't get the Allow Headers or Expose Headers configuration applied to them. Hopefully that's not the issue here though.
Below I've added the most basic CORS request I can think of. If this request works, then it may be a client side problem you are encountering.
fetch('example.com', {
method: 'GET',
mode: 'cors',
credentials: 'include',
headers: { 'Authorization': authString }
}).then(
response => response.json()
); // parses JSON response into native JavaScript objects
The Sonar test suite makes the interesting point that it should be considered bad practice to send the HTTP headers
Content-Security-Policy
X-Content-Security-Policy
X-Frame-Options
X-UA-Compatible
X-WebKit-CSP
X-XSS-Protection
when sending non-HTML resources.
I currently configure my IIS server using web.config, namely
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Content-Security-Policy" value="default-src 'self' ; img-src 'self' data:; script-src 'self' cdnjs.cloudflare.com/ajax/libs/html5shiv/" />
<add name="X-Frame-Options" value="DENY" />
<add name="X-Content-Type-Options" value="nosniff" />
<add name="X-Permitted-Cross-Domain-Policies" value="none" />
<add name="X-UA-Compatible" value="IE=edge" />
<add name="X-Xss-Protection" value="1; mode=block" />
</customHeaders>
</httpProtocol>
</system.webServer>
</configuration>
But that configuration sends those headers no matter the type of the resource send.
How to make IIS selectively add those headers to the right types of files?
You can use the IIS UrlRewrite module (an IIS extension) and add a custom headers only for html resources.
Check this old question.
I was using WebPageTest to test the performance of my Azure Web App (ASP.Net vNext Web API/Angular). I got an F for both "Compress Transfer" and "Cache Static Content".
After searching StackOverflow and Google, I added the following to my web.config:
<urlCompression doStaticCompression="true" doDynamicCompression="true" />
<httpCompression>
<dynamicTypes>
<clear />
<remove mimeType="*/*" />
<add enabled="true" mimeType="text/*"/>
<add enabled="true" mimeType="message/*"/>
<add enabled="true" mimeType="application/x-javascript"/>
<add enabled="true" mimeType="application/javascript"/>
<add enabled="true" mimeType="application/json"/>
<add enabled="false" mimeType="*/*"/>
<add enabled="true" mimeType="application/atom+xml"/>
<add enabled="true" mimeType="application/atom+xml;charset=utf-8"/>
</dynamicTypes>
<staticTypes>
<clear />
<remove mimeType="*/*" />
<add enabled="true" mimeType="text/*"/>
<add enabled="true" mimeType="message/*"/>
<add enabled="true" mimeType="application/javascript"/>
<add enabled="true" mimeType="application/atom+xml"/>
<add enabled="true" mimeType="application/xaml+xml"/>
<add enabled="true" mimeType="application/json"/>
<add enabled="false" mimeType="*/*"/>
</staticTypes>
</httpCompression>
and
<staticContent>
<!-- Set expire headers to 30 days for static content-->
<clientCache cacheControlMode="UseMaxAge" cacheControlMaxAge="30.00:00:00" />
</staticContent>
After redeploying my Web App, I re-ran the test and I am still getting an F for both of them. Even though I have added these settings to web.config, it does not appear that Azure Web App is honoring them.
Also, I found out that some Web App tiers do not allow compression but I am running on an S2 and I verified that it does allow compression.
Any help would be appreciated!
Thanks!
gzip compression is enabled by default for Azure Web Apps. You can see the rules in your sites LocalSiteRoot/Config/applicationhost.config. Looking at the response headers (which can easily be done with developer tools) should confirm that gzip is being used. It is possible that one of the resources that your site loads is not compressed, and this is causing the WebPageTest to fail. I would look at a network capture and the response headers, and see if you can find the offending resources if you're concerned.
To go to the local site root, you can use FTP, or go to your SCM site at https://.scm.azurewebsites.net/DebugConsole and then click the globe icon.
Also I suspect that your 2 javascript files are not getting compressed since the Content-Type header is not getting populated, so the rule is not capturing it because it does not recognize the mimetype.
Just to back up #theadriangreen here - it will be a header problem. I've found adding the types in the web.config to be unreliable.
What you need to do instead is edit the applicationHost.config file stored in the deepest dark part of azure. The easiest way to do this, is to install the IIS Manager extension either in the Azure portal or in Kudu. Kudu can be accessed via .scm.azurewebsites.net.
There you can edit the file, and it'll save a xdt for you - which once you restart the app you should find that the xdt gets applied.
Alternatively, you can just add an applicationHost.xdt to your App root and you are good to go. Here is a sample.
<?xml version="1.0" encoding="utf-8"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<system.webServer>
<httpCompression>
<dynamicTypes>
<add mimeType="application/json;charset=utf-8" enabled="true" xdt:Transform="InsertAfter(/configuration/system.webServer/httpCompression/dynamicTypes/add[(#mimeType='application/json')])" />
</dynamicTypes>
</httpCompression>
</system.webServer>
</configuration>
References:-
https://github.com/projectkudu/kudu/wiki/Xdt-transform-samples
https://blogs.msdn.microsoft.com/benjaminperkins/2015/03/03/making-changes-to-the-applicationhost-config-on-azure-websites/
https://github.com/shibayan/IISManager