We Keep Coding

How can I control the HTTP response headers added to my ASP.NET core web application when hosted in Azure app service?

we have written an ASP.NET core 2.2 web application which basically exposes a few web api controllers and we have used the ResponseCachingMiddleware in order to implement a server side response cache in our middleware pipeline.
We followed this Microsoft guide and we decided to add the HTTP response header Vary so that each response from our application includes the following header: Vary: Accept-Encoding, Accept-Charset.
Doing so, as explained in the guide linked above, is needed in order for the response cache to honor the client request headers so that the cached responses are used if and only if they are compatible with the client request.
Testing with postman I noticed that, when deploying the app in Azure (we used a standard Azure App Service to do so), the Vary response header is not what I would expect: it seems that Azure itself adds the value Accept-Encoding so that the value for the Vary header is set as Accept-Encoding, Accept-Charset,Accept-Encoding (this is a combination of the value set by our application and the value that, I suppose, is automatically added by Azure).
That said I have a couple of questions:
is the extra value Accept-Encoding really added by the azure host ?
is there a way to customize the HTTP headers added by the Azure host (if any) ?
is the value Accept-Encoding, Accept-Charset,Accept-Encoding a valid value for the Vary header ? is it going to work as expected even if we have a value repeated twice ?

Hosting ASP .NET Core on Azure App Service (a Windows one) still uses IIS as outlined here. So you should be able to control your headers by adding web.config to your project.
Here is an example of what that would look like and the link to the docs,
<configuration>
<system.web>
<httpRuntime enableVersionHeader="false" /> <!-- Removes ASP.NET version header. Not needed for Ghost running in iisnode -->
</system.web>
<system.webServer>
<security>
<requestFiltering removeServerHeader="true" /> <!-- Removes Server header in IIS10 or later and also in Azure Web Apps -->
</security>
<httpProtocol>
<customHeaders>
<clear /> <!-- Gets rid of the other unwanted headers -->
<add name="X-Frame-Options" value="SAMEORIGIN" />
</customHeaders>
<redirectHeaders>
<clear />
</redirectHeaders>
</httpProtocol>

Enable CORS on Specific URL in ASP.NET Web Forms

I'm not a backend developer, so I apologize ahead of time if I do not provide enough information. I am just trying to find some resources that will help my backend developer understand what I am trying to do.
I am trying to make an AJAX GET request to an rss feed inside of web application that was built using ASP.NET Web Forms. However, the request gets blocked because of Cross Origin Security. I want to enable CORS for the route that is associated with our RSS feed (/page/rss/{id}).
I was able to enable CORS in our webconfig using:
<httpProtocol>
<customHeaders>
<add name="Access-Control-Allow-Origin" values="*" />
<add name="Access-Control-Allow-Methods" values="GET" />
<add name="Access-Control-Allow-Headers" values="Content-Type" />
</customHeaders>
</httpProtocol>
But, that enables it for the entire project which is not what I want. Our routes are defined in an XML file like this:
<namespace.routing>
<routings>
<route name="publishedPage" url="page/{PageName}" page="~/Default.aspx" />
</routings>
<defaults>
<default url="http://blog.example.com" domain="example.com" page="page/homepage" />
</defaults>
</namespace.routing>
So, how would one go about enabling CORS on a specific path in ASP.NET Web Forms? If someone could point me in the direction of some resources that would help us that would be great. If you need anymore information I'm happy to provide it. Thanks!

I'm not sure how you are returning your rss endpoint, but if you have access to the HttpContext object, you can use it to supply the CORS headers directly.
HttpContext.Current.Response.AppendHeader("Access-Control-Allow-Origin", "*");
HttpContext.Current.Response.AppendHeader("Access-Control-Allow-Methods", "Get");
HttpContext.Current.Response.AppendHeader("Access-Control-Allow-Headers", "Content-Type");
Depending on how old your app is, you might need to use AddHeader instead of AppendHeader.

RESTful WebService CORS Preflight Channel did not succeed

I created a WebService in C#. All GET methods are working without any problems.
Now I need to provide some POST methods. When calling it via C# it works without any problems. Then I tried to write a small html page with JavaScript to call my methods. But there I get a CORS error ("Preflight channel did not succeed").
I already added the following part to my web.config file:
<customHeaders>
<add name="Access-Control-Allow-Origin" value="*" />
<add name="Access-Control-Allow-Headers" value="*" />
<add name="Access-Control-Allow-Methods" value="*" />
</customHeaders>
Sadly it is still not working. What am I doing wrong?

So what you have here is not really a valid way to handle CORS requests. The problem is that this will add the CORS headers to all responses, but browsers will use an OPTIONS request in order to check for CORS headers. This would work if you also implement OPTIONS requests for all of your API end points.
The better option is to use one of the CORS frameworks, such as this one: Enabling Cross-Origin Requests in ASP.NET Web API 2 for ASP.NET WebAPI 2. This type of framework will intercept the OPTIONS request for you and supply the appropriate response without the need for you to manually create 2 routes per endpoint.

AngularJS, WebAPI, and Windows Authentication: OPTIONS 401 and "Reponse for preflight has invalid HTTP status code 401"

I'm building an internal application for work that uses AngularJS, WebAPI, and Windows Authentication. The Angular client and the WebAPI are different projects, which will run on two seperate ports on my local machine.
I enabled CORS in Web.config of the API project using the following:
<httpProtocol>
...
<customHeaders>
<add name="Access-Control-Allow-Origin" value="http://localhost:#PORTOFCLIENT#" />
<add name="Access-Control-Allow-Headers" value="Content-Type" />
<add name="Access-Control-Allow-Methods" value="GET, POST, PUT, DELETE, OPTIONS" />
<add name="Access-Control-Allow-Credentials" value="true" />
</customHeaders>
</httpProtocol>
I can make GET requests just fine; the problem is when I try to save an object using POST:
function updateFoo(foo) {
return $http.post(baseUrl + "/api/foos", foo, { withCredentials: true })
.then(updateFooComplete)
.catch(updateFooFailed);
...
}
I receive the following errors in Chrome:
OPTIONS http://localhost:#PORTOFWEBAPI#/api/foos
XMLHttpRequest cannot load http://localhost:#PORTOFWEBAPI#/api/foos. Response for preflight has invalid HTTP status code 401
After a little Googling, I found this response mentioning the fact that the OPTIONS request shouldn't be authenticated.
How do I prevent OPTION requests from being authenticated by WebAPI? Am I missing something?

X-Frame-Options bug in ASP.NET MVC (.NET 4.5.1)

Does anyone know why the response returned by an ASP.NET MVC controller contains the X-FRAME-OPTIONS: SAMEORIGIN header so many times? I think this might be a bug in the framework (using version 4.5.1).
It seems as though the header is added once for each form on the page. My work around is to disable the header in MVC and add it in the web.config file instead, like this:
Global.asax.cs:
protected void Application_Start()
{
System.Web.Helpers.AntiForgeryConfig.SuppressXFrameOptionsHeader = true;
}
Web.config:
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="X-Frame-Options" value="SAMEORIGIN" />
</customHeaders>
</httpProtocol>
</system.webServer>

The header is added each time you call #Html.AntiForgeryToken(). Which means if you have multiple forms on your pages and each form includes that call, you'll get duplicate headers.
A comment to the question references this blog: http://daveonsoftware.blogspot.ru/2015_03_01_archive.html. I think that's a good explanation of the problem. In my application, I picked option #3.