azure-functions-host: CORS broken for Linux consumption plans

Definitely a bug in how we configured the CORS middleware. Opened a PR https://github.com/Azure/azure-functions-host/pull/5215 to fix this.

We should be able get this deployed sometime early next week.

@ericdrobinson @jacobgunnarsson Thanks for the patience and all the help investigating this.

thanks for all the details. investigating this more today and will update here soon.

Fix is deployed on all regions. Please give it a try (might need an app restart if the app has been running non-stop).

Our functions are working again. Not sure if this is falling back to our own CORS implementation or being handled properly by the host (likely the host, at this point). One way or the other, browsers are no longer dropping the responses due to incorrect CORS responses.

@balag0 thanks for the update. it seems like I might be having some other issue then. It is letting OPTIONS requests through, yntil i set an Origin header, then I get “empty headers”

Server: Kestrel
Request-Context: appId=cid-v1:xxxx
Date: Tue, 26 Nov 2019 09:55:42 GMT

Do I need to set anything but leaving all fields blank for CORS in the azure portal for it to work?

@balag0 Our functions still aren’t working properly. We’re about two weeks with broken features now. Is there a useful ETA for a fix deployment that you can share?

Update: The build with the fix is available now, the plan is to include this change with the next scheduled release starting end of the week instead of doing an one off deployment today.

A simple way to get a browser to trigger the Preflight Request is to issue a request (XHR; Fetch) that includes a payload (body). This example (adapted from MDN’s Fetch API documentation) should do the trick:

const url = 'https://[someappname].azurewebsites.net/httptrigger';
const data = { username: 'example' };

try {
  const response = await fetch(url, {
    method: 'POST', // or 'PUT'
    body: JSON.stringify(data), // data can be `string` or {object}!
    headers: {
      'Content-Type': 'application/json'
    }
  });
  const json = await response.json();
  console.log('Success:', JSON.stringify(json));
} catch (error) {
  console.error('Error:', error);
}

Hopefully this is helpful.

@ericdrobinson thanks for looking into this in a bit more detail!

@balag0 thanks for your reply! Yes, the issue still persists. As I wrote before adding allowed origins through Azure CLI (or through the portal) properly adds the Access-Control-Allow-Origin header to the preflight response.

However, the issue is not wether or not the Access-Control-Allow-Origin header is present in the preflight response. The issue is that the rest of the required headers are missing, what about Access-Control-Request-Method or Access-Control-Allow-Headers? (or any of the other Access-Control-* headers, described here)

If the preflight request includes those headers but the response does not, the response is considered unsafe and is rejected by the browser.