SOLVE ALL THE ERRORS!

Azure Functions failing on “OPTIONS” call? Quick fix!

I recently ran into an issue when developing Azure Functions locally. My SPFx webpart was configured to request information from my locally running Azure Function, but suddenly started ending up in error. Browser only showed 404 for the first request (OPTIONS) the SPFx webpart was sending – although I knew the function was up and running! So what to do?

Looking at the Azure Functions CLI, this is what it had to say:

Executed HTTP request: {
 "requestId": "d395260e-b82f-41a7-9744-fb74f1aa1dc1",
 "method": "OPTIONS",
 "uri": "/api/Function1",
 "authorizationLevel": "Anonymous",
 "status": "NotFound"
}

So, it actually did receive the request, but couldn’t handle it. I thought you’d get something like “ERR_CONNECTION_REFUSED” to “OPTIONS” if you failed your configuration. Not “NotFound”, which you usually get when you mess up the name of your functions or start debugging the wrong project (give yourself a pat on the back if you’ve never fallen victim to this one – I have!)

"ERR_CONNECTION_REFUSED" from an Azure Function
The good old “ERR_CONNECTION_REFUSED” from an Azure Function. That’s when you know your function can’t manage whatever you’r throwing at it, and that’s good.

If you don’t want to read the background stuff, just click this to scroll to the solution: Enable CORS on your local.settings.json file

Why you (probably) don’t want to manage “OPTIONS” in your Azure Function

Being the simple guy I am, I wanted to see what I can do about the call if I did receive it. It is saying “NotFound”, so maybe I just need to handle the “OPTIONS” requests just like I handle GET and POST? Let’s try it out!

In Azure Functions v2, this is how you can add “OPTIONS” as a new method your function is able to handle. Then it’s usually easy to capture the request.

Azure Function Run parameters with "OPTIONS" as one method
Azure Function Run parameters with “OPTIONS” as one method

This did not help me. Even if I CAN receive an OPTIONS request in an Azure function, I realized I probably don’t want to. What am I actually going to do about it? What does the requester expect me to do with it?

My Azure Function did catch a request with OPTIONS method! Now what to do with it?
My Azure Function did catch a request with OPTIONS method! Now what to do with it?

A bit of further googling revealed to me, that the first request (when coming from a SPFx webpart in this case) with a method “OPTIONS”, is basically just probing if the request is allowed (through CORS) and someone is responding.

Azure Functions CLI actually takes care of this, and you shouldn’t have to do anything. However, if you do want to specify your own values for “Access-Control-Allow-Credentials” and “Access-Control-Allow-Origin”, you could specify your own behavior for OPTIONS. Kind of like these guys:

In this case, apparently you need to remove all of the CORS entries in the Platform Settings for your Azure Functions in Azure Portal.

Anyway, for me there was no reason why I should be tampering with that request. I’d much rather let the Azure Functions CLI take care of all that. But how to do that, since it’s clearly not working correctly?

Solution: Enable CORS on your local.settings.json file

Finally, this was resolved quite easily. The need to remove all CORS entries in Azure, if you want to implement some sort of handling for OPTIONS made me realize that I did not have any CORS configuration on my dev machine. So, in short, You just need to enable CORS on your local dev machine to make your Azure Functions CLI respond nicely to the OPTIONS probe, after which the next call will be a GET or POST.

Here’s how to do it in your local.settings.json file:

A screenshot of my local.settings.json -file with a working CORS configuration! :)
A screenshot of my local.settings.json -file with a working CORS configuration! :)

To ensure, that your local Azure Functions CLI actually applies these changes, you might want to set your local.settings.json to be copied to output directory automatically, so that your CLI actually picks them up when you start debugging.

Setting your local.settings.json and host.json to be always copied to output directory in your local builds to enable Azure Functions CLI to acces newest values of your configuration
Setting your local.settings.json and host.json to be always copied to output directory in your local builds to enable Azure Functions CLI to acces newest values of your configuration

It was that easy. At least some issues are easily resolved… :)

Follow me

Antti K. Koskela

Antti Koskela is a proud digital native nomadic millenial full stack developer (is that enough funny buzzwords? That's definitely enough funny buzzwords!), who works as a Solutions Architect for Valo Intranet, the product that will make you fall in love with your intranet. Working with the global partner network, he's responsible for the success of Valo deployments happening all around the world.

He's been a developer from 2004 (starting with PHP and Java), and he's been bending and twisting SharePoint into different shapes since MOSS. Nowadays he's not only working on SharePoint, but also on .NET projects, Azure, Office 365 and a lot of other stuff.

This is his personal professional (e.g. professional, but definitely personal) blog.
Follow me

Leave a Reply

avatar
5000
  Subscribe  
Notify of