Manual CORS headers in response message are stripped

[NichUK]

In an HttpTrigger function, I am manually setting CORS headers in the HttpResponseMessage, using C#.

When running in an WebApp, this works perfectly, however when running as a function, my manual CORS headers are stripped and replaced with CORS headers from the function application settings. I need to dynamically set CORS headers as my functions will be access from a variety of domains, and having to continually update the function app to add them in would just not be possible, and the wildcard cannot be used because it is incompatible with the withCredentials: true attribute on the XMLHttpRequest call.

Surely function application headers should only be added when there are no existing headers (which must have been created on purpose), rather than replacing them?

This problem is related to #620, but because I am setting the withCredentials attribute on the call, the workaround to remove all CORS information from the function app, doesn't work. This is therefore a blocker.

Also, the portal complains "Error: CORS is not configured for this function app. Please add https://functions.azure.com to your CORS list."

[christopheranderson]

@ahmelsayed - can you investigate?

[ahmelsayed]

This is a side effect of our CORS implementation in Antares and the fact that the portal depends on CORS to communicate with the runtime.
If you want to handle OPTIONS requests in your functions, you need to disable CORS feature which will mean you can't use the portal.

[NichUK]

It would seem to me that if CORS headers are already present when a response is sent out from a function (i.e. they MUST have been deliberately manually added), then your CORS implementation should respect those and leave them alone. If they are not present, then you should add them as currently.

[ricklove]

@NichUK

The workaround in #620 should work with "withCredentials". If you remove all CORS entries in the portal, the portal will start complaining about it, but the manual CORS entries will work.

However, I discovered, that this is only true if the new Proxies (Preview) is disabled. When I enabled the Proxies, it broke this workaround and the Access-Control-Allow-Origin went back to a wildcard.

When I disabled Proxies, then it allowed the CORS to go through.

---

I agree with NichUK that if CORS has been set manually in an azure function, this should override any other settings.

However, I suspect the implementation problem with this is with the OPTIONS pre-flight request and in order to set CORS headers manually, we would need to handle the OPTIONS request manually also.

[christopheranderson]

I'll follow up with the folks who manage this for App Service.

[DonKarlssonSan]

Do you have any updates regarding this issue?

[masters3d]

Same issue with V1, any plans to address this in V2 or beyond? This is very surprising, I am glad I am not alone.