#SharePointProblems | Koskila.net

Solutions are worthless unless shared! Antti K. Koskela's Personal Professional Blog

How to fix an Azure Function failing with error "The resource you are looking for has been removed, had its name changed, or is temporarily unavailable."

koskila
Reading Time 4 min
Word Count 678 words
Comments 2 comments
Rating 4.5 (2 votes)
View

This post describes one way to resolve a problem, where you receive an error like "The resource you are looking for has been removed, had its name changed, or is temporarily unavailable." when calling your Azure Functions.

Problem

Another day, another simple, yet kind of weird issue to solve! I was developing a simple Azure Function to access Microsoft Graph API this time. This particular issue was kind of bugging me since the error message actually had nothing to do with the actual issue and gave no pointers as to how to fix the issue!

I was just developing a function, and suddenly it stopped working, and the only error message I got was this:

The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.

In client-side code, if called with $.get([URL]), it looks somewhat like this (see below):

"The resource you are looking for has been removed, had its name changed, or is temporarily unavailable." leads to a 404 error in jQuery.

"The resource you are looking for has been removed, had its name changed, or is temporarily unavailable." leads to a 404 error in jQuery.

So, what did I do to cause this - and how to fix this?

Steps to reproduce:

For me, this is the way I caused the error.

  1. Create an Azure Function that takes in GET argument(s) using the beta version of the CLI (2.1, in my case)

  2. Call the function from any other source, passing arguments of varying length

  3. Suddenly you notice, with quite a few different arguments, you only get this error from the Azure function: "The resource you are looking for has been removed, had its name changed, or is temporarily unavailable." It doesn't happen with all arguments, though!

  4. When the issue is underway, even if you attach the remote debugger to your Azure Function, it won't fire, at all - so debugging is rather difficult!

But what on Earth causes this?

PostMan "The resource you are looking for has been removed, had its name changed, or is temporarily unavailable."

Postman is no help, either. "The resource you are looking for has been removed, had its name changed, or is temporarily unavailable."

Reason: IIS hosting your Azure Function can't handle your parameters

Weirdly enough, the reason for this issue is actually a bug (or a feature) of Azure functions CLI, or how they use IIS. Long query strings will mess it up. In IIS the default maximum length of the query string is 2048 characters (see References for more info). There was a bug report about this on GitHub (see references)

It looks like it was fixed for v1 of Azure Functions CLI, but not for v2 (beta), so I opened a new issue for v2: https://github.com/Azure/azure-functions-host/issues/3023

  • Update 01.07.2018 - it's now classified as bug, so that's good!

  • Update 01.08.2018 - this is now fixed (I guess in Release 28 of Azure Functions 2.x)! If you're running the latest CLI version, you should be good with longer parameters too :)

However, if you're using v1 of the Azure Functions runtime, or a post-GA version of v2 runtime (anything after Release 28 - so anything released in late 2018 or later), you shouldn't run into this issue anymore.

But what if you do? Well, the same solution still applies, so see below:

Solution (or at least a workaround!)

The fix is simple - move the query parameters from your URL to the request body. This involves possibly changing your primary request type from GET to POST. Since this issue is caused by IIS configuration, the "fix" (I guess it's more of a workaround) applies to both Azure Functions hosted on IIS and actual IIS sites.

So basically, from this:

$.get([url?parameter_1=A lot of information&parameter_2=Waaaay more information...]);

to

$.post([url], { paramater_1: "A lot of information", parameter_2: "Waaaay more information..." } );

Should work after that!

...Or you could just use shorter query variable values. Long query strings cause issues in some browsers, too (well, in IE, that is)... So it might be a good idea to steer clear from them anyways!

References

Comments

Interactive comments not implemented yet. Showing legacy comments migrated from WordPress.
michelle
2020-08-26 09:53:13)
Hi there! wondering if you'd be able to comment on this. We have a customer experience portal that used the url of www.my181williamand550bourke.com.au. We switched the portal provider to a supplier that uses umbraco and azure. When we switched the portals over to the new supplier, we kept the SAME URL, and it should only take maximum 24 hours for a DNS switch. However we are still having issues with customers clicking on the link to the portal and receiving the message The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.” For those customers that have reached out for help, we have instructed them to clear their cache. However this only works if you clear it in advanced settings and set the time range to 'all time'. Do you think this is an issue with the coding in Azure?
Antti K. Koskela
2020-08-26 23:12:59
Hi Michelle, Thanks for your question! Sounds like an interesting case, but rather than an issue in Azure, it sounds like something going wrong with IIS serving some content that the browser is expecting to find with the hostname (hence, the issue started after the switch but clearing the cache helps). I suppose a workaround would be to host the new portal from a new address, but redirect the old requests to the new address (so that people can still access it from the old address). A more proper fix would be to extract the logs from the app service, and investigate what the actual resources are that are being requested and then throw IIS off like that.
Whitewater Magpie Ltd.
© 2025
Static Site Generation timestamp: 2025-08-12T07:18:35Z