This post was most recently updated on February 26th, 2023.
3 min read.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!)
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 could 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.
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?
A bit of further googling revealed to me, that the first request (when coming from an 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 behaviour 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:
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 the output directory automatically, so that your CLI actually picks them up when you start debugging.
It was that easy. At least some issues are easily resolved… :)
- M365 Copilot claiming “You have turned off web search in the work mode”? Easy fix! - November 19, 2024
- “Performing cleanup” – Excel is stuck with an old, conflicted file and will never recover. - November 12, 2024
- How to add multiple app URIs for your Entra app registration? - November 5, 2024