How to troubleshoot CORS error in Azure API Management service
In the browser, if you send a request to your Azure API management service, sometimes you might get the CORS error, detailed error message like: Access to XMLHttpRequest at 'https://xxxxx.azure-api.net/123/test' from origin 'https:// xxxxx.developer.azure-api.net' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. This blog is intended to wrap-up the background knowledge and provide a troubleshooting guide for the CORS error in Azure API Management service.
Common causes of SSL/TLS connection issues and solutions
In the TLS connection common causes and troubleshooting guide (microsoft.com) and TLS connection common causes and troubleshooting guide (microsoft.com), the mechanism of establishing SSL/TLS and tools to troubleshoot SSL/TLS connection were introduced. In this article, I would like to introduce 3 common issues that may occur when establishing SSL/TLS connection and corresponding solutions for windows, Linux, .NET and Java. TLS version mismatch Cipher suite mismatch TLS certificate is not trusted TLS version mismatch Before we jump into solutions, let me introduce how TLS version is determined. As the dataflow introduced in the first session(https://techcommunity.microsoft.com/t5/azure-paas-blog/ssl-tls-connection-issue-troubleshooting-guide/ba-p/2108065), TLS connection is always started from client end, so it is client proposes a TLS version and server only finds out if server itself supports the client's TLS version. If the server supports the TLS version, then they can continue the conversation, if server does not support, the conversation is ended. Detection You may test with the tools introduced in this blog(TLS connection common causes and troubleshooting guide (microsoft.com)) to verify if TLS connection issue was caused by TLS version mismatch. If capturing network packet, you can also view TLS version specified in Client Hello. If connection terminated without Server Hello, it could be either TLS version mismatch or Ciphersuite mismatch. Solution Different types of clients have their own mechanism to determine TLS version. For example, Web browsers - IE, Edge, Chrome, Firefox have their own set of TLS versions. Applications have their own library to define TLS version. Operating system level like windows also supports to define TLS version. Web browser In the latest Edge and Chrome, TLS 1.0 and TLS 1.1 are deprecated. TLS 1.2 is the default TLS version for these 2 browsers. Below are the steps of setting TLS version in Internet Explorer and Firefox and are working in Window 10. Internet Explorer Search Internet Options Find the setting in the Advanced tab. Firefox Open Firefox, type about:config in the address bar. Type tls in the search bar, find the setting of security.tls.version.min and security.tls.version.max. The value is the range of supported tls version. 1 is for tls 1.0, 2 is for tls 1.1, 3 is for tls 1.2, 4 is for tls 1.3. Windows System Different windows OS versions have different default TLS versions. The default TLS version can be override by adding/editing DWORD registry values ‘Enabled’ and ‘DisabledByDefault’. These registry values are configured separately for the protocol client and server roles under the registry subkeys named using the following format: <SSL/TLS/DTLS> <major version number>.<minor version number><Client\Server> For example, below is the registry paths with version-specific subkeys: Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client For the details, please refer to Transport Layer Security (TLS) registry settings | Microsoft Learn. Application that running with .NET framework The application uses OS level configuration by default. For a quick test for http requests, you can add the below line to specify the TLS version in your application before TLS connection is established. To be on a safer end, you may define it in the beginning of the project. ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 Above can be used as a quick test to verify the problem, it is always recommended to follow below document for best practices. https://docs.microsoft.com/en-us/dotnet/framework/network-programming/tls Java Application For the Java application which uses Apache HttpClient to communicate with HTTP server, you may check link How to Set TLS Version in Apache HttpClient | Baeldung about how to set TLS version in code. Cipher suite mismatch Like TLS version mismatch, CipherSuite mismatch can also be tested with the tools that introduced in previous article. Detection In the network packet, the connection is terminated after Client Hello, so if you do not see a Server Hello packet, that indicates either TLS version mismatch or ciphersuite mismatch. If server is supported public access, you can also test using SSLLab(https://www.ssllabs.com/ssltest/analyze.html) to detect all supported CipherSuite. Solution From the process of establishing SSL/TLS connections, the server has final decision of choosing which CipherSuite in the communication. Different Windows OS versions support different TLS CipherSuite and priority order. For the supported CipherSuite, please refer to Cipher Suites in TLS/SSL (Schannel SSP) - Win32 apps | Microsoft Learn for details. If a service is hosted in Windows OS. the default order could be override by below group policy to affect the logic of choosing CipherSuite to communicate. The steps are working in the Windows Server 2019. Edit group policy -> Computer Configuration > Administrative Templates > Network > SSL Configuration Settings -> SSL Cipher Suite Order. Enable the configured with the priority list for all cipher suites you want. The CipherSuites can be manipulated by command as well. Please refer to TLS Module | Microsoft Learn for details. TLS certificate is not trusted Detection Access the url from web browser. It does not matter if the page can be loaded or not. Before loading anything from the remote server, web browser tries to establish TLS connection. If you see the error below returned, it means certificate is not trusted on current machine. Solution To resolve this issue, we need to add the CA certificate into client trusted root store. The CA certificate can be got from web browser. Click warning icon -> the warning of ‘isn’t secure’ in the browser. Click ‘show certificate’ button. Export the certificate. Import the exported crt file into client system. Windows Manage computer certificates. Trusted Root Certification Authorities -> Certificates -> All Tasks -> Import. Select the exported crt file with other default setting. Ubuntu Below command is used to check current trust CA information in the system. awk -v cmd='openssl x509 -noout -subject' ' /BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt If you did not see desired CA in the result, the commands below are used to add new CA certificates. $ sudo cp <exported crt file> /usr/local/share/ca-certificates $ sudo update-ca-certificates RedHat/CentOS Below command is used to check current trust CA information in the system. awk -v cmd='openssl x509 -noout -subject' ' /BEGIN/{close(cmd)};{print | cmd}' < /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem If you did not see desired CA in the result, the commands below are used to add new CA certificates. sudo cp <exported crt file> /etc/pki/ca-trust/source/anchors/ sudo update-ca-trust Java The JVM uses a trust store which contains certificates of well-known certification authorities. The trust store on the machine may not contain the new certificates that we recently started using. If this is the case, then the Java application would receive SSL failures when trying to access the storage endpoint. The errors would look like the following: Exception in thread "main" java.lang.RuntimeException: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at org.example.App.main(App.java:54) Caused by: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:130) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:371) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:309) Run the below command to import the crt file to JVM cert store. The command is working in the JDK 19.0.2. keytool -importcert -alias <alias> -keystore "<JAVA_HOME>/lib/security/cacerts" -storepass changeit -file <crt_file> Below command is used to export current certificates information in the JVM cert store. keytool -keystore " <JAVA_HOME>\lib\security\cacerts" -list -storepass changeit > cert.txt The certificate will be displayed in the cert.txt file if it was imported successfully.
Integrating API Management with App Gateway V2
API Management service can be configured in Internal Virtual Network mode which makes it accessible only from within the Virtual Network. Using Application Gateway provides users the ability to protect the API Management service from OWASP vulnerabilities. Application gateway is a reverse proxy service which has a 7-layer load balancer and provides Web Application Firewall (WAF) as one of the services in this use case.
Integrate Azure Front Door with Azure API Management
Azure Front Door is a global, scalable entry-point that uses the Microsoft global edge network to create fast, secure, and widely scalable web applications. This article demonstrates detailed steps to setup Azure Front Door in front of Azure API Management and the steps to restrict APIM accept traffic only from Azure Front Door.
Enhanced API Developer Experience with the Microsoft-Postman partnership
Application Programming Interfaces (APIs) have emerged as the foundational technology powering application modernization. As developers move to modern applications and embrace an API-first world, an easy-to-use API management platform is the need of the hour. At Microsoft, we are on a mission to build a comprehensive and reliable API management platform that’s enabling developers to streamline and secure APIs at scale. Today, at Microsoft Ignite, the Azure API Management team is excited to announce our partnership with Postman, a leading API testing and development platform used by 20M+ developers worldwide. This partnership is aimed at both simplifying API testing and monitoring using the Postman platform for Azure API developers and making the Azure platform readily available to deploy APIs for Postman developers. “This announcement is great news for organizations that recognize APIs as fundamental business assets critical to digital transformation,” said Abhijit Kane, Postman co-founder. “By uniting the world’s top API platform and a leading cloud provider, our two companies have taken a significant step in giving customers the comprehensive set of tools they need for accelerating the API lifecycle.” Boost developer productivity and achieve faster time to market with the Azure API Management and Postman Integrated platform These integrations provide developers all the support they need to test their APIs on Postman and deploying them back on Azure. It takes away unnecessary friction and enables developers to spend more time on writing and shipping software. Let’s take a closer look at how Azure API Management platform and Postman platform integrate to offer developers a fast path to build, test, deploy and iterate on APIs. Test Azure APIs faster with an integrated Postman platform Azure API developers have instant access to the Postman API testing, monitoring, and development platform for rapid iteration on API changes. The integration support includes: Postman-initiated import from Azure API Management with the ability to import OpenAPI definitions from Azure API Management Azure API Management-initiated export of APIs into Postman using “Run in Postman” Accelerate the path to deployment for Postman tested APIs on Azure Once the APIs are designed, tested and ready to go, the integration makes it easy to deploy them on Azure. The integration support includes: Export of OpenAPI definitions from Postman to Azure API Management With over a million APIs published on Azure API Management platform today - it is a battle-hardened, production ready, and highly scaled platform that stretches from on-premises to multi-cloud. Over the past few years, Azure API Management platform has expanded to support every stage of the API lifecycle - enhancing the overall experience for API developers, consumers, operators, and policymakers. Postman partnership is making this even more frictionless, as Smit Patel, head of partnerships at Postman, said, “We’re very proud because this is Postman’s first bidirectional product alliance with a major cloud provider. Aligning with a cloud leader like Microsoft is terrific for our mutual customers and also boosts Postman’s status as the enterprise grade solution for the API-first world.” The Azure API Management team welcomes Postman to the Microsoft partner ecosystem, and together we look forward to enabling our developers embrace an API-first culture to deliver innovations faster, create new revenue streams, and generate value for their end users. Check out Azure integration docs and Postman integration docs for more details. To learn more about this news, read Postman’s press release and Postman’s blog.Troubleshooting 4xx and 5xx Errors with Azure APIM services
Part I - Troubleshooting 4xx Errors Debugging and Troubleshooting Overview The API Management is nothing but a proxy which help to forward the request from client side to destination API service. It has the ability to modify the request or process based on the inputs from the client side before it reaches the destination. In an ideal scenario, APIs configured within an APIM service are expected to return successful responses (mostly 200 OK) along with the accurate data that is expected from the API. In case of failures, you may see an incorrect response code along with a precise error message of what went wrong during the API call. However, there may be scenarios where you may observe API requests failing with generic 4xx or 5xx errors without a detailed error message, and it could be difficult to narrow down or isolate the source of the error. In such cases, the first point is to isolate whether the error code is thrown by APIM or the backend configured by the APIM. This proves to be an important method as most of the error codes are generated by the backend and APIM being a proxy forwards the response (error codes) back to the users who initiated the request. This makes the user think that the error code is thrown from the APIM. Troubleshooting Azure APIM Failed Requests Let's suppose you have initiated an API request to your APIM service and the request eventually fails with a “HTTP 500 – Internal Server Error” message. With generic error messages such as above, it becomes very difficult to isolate the cause or the source of the failed API request since there are several internal and external components that participate during an API invocation process. If responseCode matches backendResponseCode, then there is an issue with the backend and we should troubleshoot the backend configured with the APIM If responseCode does not match backendResponseCode and errorReason is empty, then we should check if their policy logic is returning the error using inspector traces. If errorReason is not empty, it’s a problem in APIM and the troubleshooting of error codes can help to resolve the issue. Inspector Trace If the issue is reproducible on demand, then your best option would be to enable tracing for your APIM API requests. Azure APIM services have the option of enabling the “Ocp-Apim-Trace” for your API requests. This generates a descriptive trace containing detailed information that helps you inspect the request processing step-by-step in detail and gives you a head-start on the source of the error. Reference: https://docs.microsoft.com/en-us/azure/api-management/api-management-howto-api-inspector Diagnostic Logging to Azure Monitor Log Analytics You could also enable diagnostic logging for your APIM services. Diagnostic Logs can be archived to a storage account, streamed to an Event Hub resource, or be sent to Azure Monitor Log Analytics logs which could be further queried as per the scenario and requirement. These logs provide rich information about operations and errors that are important for auditing as well as troubleshooting purposes. The best part about the diagnostic logs is that they provide you with granular level per-request logs for each of your API requests and assist you with further troubleshooting. Reference Article: https://docs.microsoft.com/en-us/azure/api-management/api-management-howto-use-azure-monitor#resource-logs While storage accounts and event hubs work as single targeted destinations for diagnostic log collection/streaming, if you choose to enable APIM diagnostic settings with the destination as Log Analytics Workspace, you would be offered with the below 2 modes of resource log collection: Azure diagnostics - Data is written to the AzureDiagnostics table, which collates diagnostic information from multiple resources of different resource types. Resource specific - Data is written to individual table for each category of the resource. For APIM, the logs would be ported to ApiManagementGatewayLogs table Reference Article: https://docs.microsoft.com/en-us/azure/azure-monitor/platform/resource-logs#send-to-log-analytics-workspace If you want the resource logs to be ported to the ApiManagementGatewayLogs table, you would have to choose the option ‘Resource specific’ as highlighted in the sample screenshot below: Below are the sample diagnostic logs generated on the Log Analytics Workspace. These logs would provide granular level details for your API requests such as the timestamp, request status, api/operation id, time taken values, caller/client IP, method, url invoked, backend url invoked, response code, backend response code, request size, response size, error source, error reason, error message, et cetera. NOTE: Post initial configuration, it may take a couple of hours for the diagnostic logs to be streamed to the destination by the resource provider. Depending on your mode of log collection, here are a few sample queries that could be used for querying the logs pertaining to diagnostic data for your API requests. You can also choose to filter through the logs by fine-tuning the query to retrieve data specific to an API ID or specific to a response code, et cetera. Maneuver to Azure Portal a APIM service a Logs blade under “Diagnostic Settings” section to execute the queries AzureDiagnostics | where TimeGenerated > ago(24h) | where_ResourceId == “apim-service-name” | limit 100 ApiManagementGatewayLogs | where TimeGenerated > ago(24h) | limit 100 Log to Application Insights Another option is to integrate APIM service with Application Insights for generating diagnostic log data. Integration of APIM with Application Insights - https://docs.microsoft.com/en-us/azure/api-management/api-management-howto-app-insights Below is a sample query that can be used for querying the “requests” table that can retrieve the diagnostic data concerned with Azure APIM API requests Maneuver to the respective Application Insights resource a Click on Logs under “Monitoring” section. requests | where timestamp > ago(24h) | limit 100 Alternatively, the error handling in APIM can be carried out using the API management error handling policy - https://docs.microsoft.com/en-us/azure/api-management/api-management-error-handling-policies Now that we have enabled diagnostic logs in order to retrieve details about the different types of errors and errors messages for failed API requests, let’s walk through a couple of commonly observed 4xx and 5xx errors with APIM services. This troubleshooting series focuses on Capturing some of the common 4xx and 5xx errors observed while making API requests using Azure APIM services. Providing guidance to APIM users as to how can they debug or troubleshooting API requests that fail with these errors. Possible solutions for fixing some of the commonly observed 4xx and 5xx errors. Troubleshooting 4xx and 5xx errors with APIM services The very first pivotal step with troubleshooting failed API requests is to investigate the source of the response code that is being returned. If you have enabled diagnostic logging for your APIM service, then the columns “ResponseCode” and “BackendResponseCode” would divulge this primary information. If the 4xx or the 5xx response being returned to the client is primarily being returned by the backend API (review “BackendResponseCode” column), then the issue has to troubleshoot more often from the backend perspective since the APIM service would then forward the same response back to the client without actually contributing to the issue. 4xx Errors: Error code: 400 Scenario 1 Symptoms: The API Management has been working fine during its implementation. It is now throwing a ‘400 Bad Request’ when invoked using the ‘Test’ option under the API Management in Azure portal. While accessing it using a client app or application, the desired result is yielded. Troubleshooting: Now, from the above scenario, we understand that the API is throwing a ‘400 Bad Request’ when invoke only from API Management under the Azure portal. But the other method of invoking is yielding results. The error message clearly states that the endpoint could not be resolved. In case, if it was an issue with the endpoint, then the issue should occur across the invoking methods of the API. Since it is not our case, let us try verifying the endpoint. You can either try to resolve the endpoint from the same machine using command prompt or try a ping test. Resolution: In this kind of scenario’s, it is always recommended to check if the API Management is present within a Virtual Network and also notice that it will be configured in the internal mode. As per the official documentation, “The Test console available on the Azure Portal will not work for Internal VNET deployed service, as the Gateway Url is not registered on the Public DNS. You should instead use the Test Console provided on the Developer portal.” Scenario 2 Symptoms: While invoking the API present under the API Management, we encounter ‘Error: The remote server returned an error: (400) Invalid client certificate’. Troubleshooting: Let us analyze the scenario, This issue occurs when the customer has implemented mutual client certificate authentication, in this case client should pass the valid certificate as per the condition written in the policy <policies> <inbound> <base /> <choose> <when condition="@(context.Request.Certificate == null || !context.Request.Certificate.Verify() || context.Request.Certificate.Issuer.Contains("*.azure-api.net") || !context.Request.Certificate.SubjectName.Name.Contains("*.azure-api.net") || context.Request.Certificate.Thumbprint != "4BB206E17EE41820B36112FD76CAE3E0F7104F36") "> <return-response> <set-status code="403" reason="Invalid client certificate" /> </return-response> </when> </choose> </inbound><backend><base /> </backend><outbound><base /></outbound><on-error> <base /></on-error> </policies> To check whether the certificate is passed or not we can enable the ocp-apim-trace. The below trace shows that no client certificate received. Resolution: Issue resolved after adding the valid client certificate. Similar Scenario’s: Scenario 3 Error Reason: OperationNotFound Error message: Unable to match incoming request to an operation. Error Section: Backend Resolution: Make sure that the operation which is invoked for the API is configured or present in the API Management. If not, add the operation or modify the request accordingly. Scenario 4 Error Reason: ExpressionValueEvaluationFailure Error message: Expression evaluation failed. EXPECTED400: URL cannot contain query parameters. Provide root site url of your project site (Example: https://sampletenant.sharepoint.com/teams/sampleteam ) Error Section: inbound Resolution: Ensure that the URL contains only the query parameter defined in the API according to the configuration in the API Management. Any mismatch might lead to such error messages. For example, if the expected input value is integer and we supply a string, this scenario might lead to the error. Error code: 401 - Unauthorized issues Scenario 1 Symptoms: The Echo API suddenly started throwing HTTP 401 - Unauthorized error while invoking the operations under it. Message- HTTP/1.1 401 Unauthorized { "statusCode": 401, "message": "Access denied due to missing subscription key. Make sure to include subscription key when making requests to an API."} { "statusCode": 401, "message": "Access denied due to invalid subscription key. Make sure to provide a valid key for an active subscription." } Troubleshooting: To get access to the API, developers must first subscribe to a product. When they subscribe, they get a subscription key that is sent as a part of request header that is good for any API in that product. Ocp-Apim-Subscription-Key is the request header sent for the subscription key of the product that is associated with this API. The key is filled in automatically. Regarding error Access denied due to invalid subscription key. Make sure to provide a valid key for an active subscription, it's clear that you are sending a wrong value of Ocp-Apim-Subscription-Key request header while invoking Create resource and Retrieve resource operations. You can check your subscription key for a particular product from APIM Developer portal by navigating to Profile page after sign-in as shown below. Select the Show button to see the subscription keys for respective products you have subscribed to. If you check the headers being sent from Test tab, you notice that the value of Ocp-Apim-Subscription-Key request header is wrong. You might be wondering how come that is possible, because APIM automatically fills this request header with the right subscription key. Let's check the Frontend definition of Create resource and Retrieve resource operations under Design tab. Upon careful inspection, you would notice that these operations got a wrong hard-coded value of Ocp-Apim-Subscription-Key request header added under Headers tab. You can remove it, this should resolve the invalid subscription key problem, but still you would get missing subscription key error. You may get the following error message: HTTP/1.1 401 Unauthorized Content-Length: 152 Content-Type: application/json Date: Sun, 29 Jul 2018 14:29:50 GMT Vary: Origin WWW-Authenticate: AzureApiManagementKey realm="https://pratyay.azure-api.net/echo",name="Ocp-Apim-Subscription-Key",type="header" { "statusCode": 401, "message": "Access denied due to missing subscription key. Make sure to include subscription key when making requests to an API." } Go to the Echo API settings and check if it is associated with any of the available products. If not, then you must associate this API with a product so that you get a subscription key. Resolution: Developers must first subscribe to a product to get access to the API. When they subscribe, they get a subscription key that is good for any API in that product. If you created the APIM instance, you are an administrator already, so you are subscribed to every product by default. Error code: 401 Unauthorized issues Scenario Symptoms: The Echo API has enabled OAuth 2.0 user authorization in the Developer Console. Before calling the API, the Developer Console will obtain an access token on behalf of the user from Authorization header in the Request. Message : Troubleshooting: To troubleshoot the scenario, we would start with checking the APIM inspector trace. We can also find the Ocp-Apim-Trace link from the response. We notice the existence of a “JWT Validation Failed : Claim Mismatched” message in the traces which is unable to decode the header token provided. To check the scope of the “JWT Validation” policy, select the Calculate effective policy button. If you don't see any access restriction policy implemented at any scopes, next validation step should be done at product level, by navigating to the associated product and then click on Policies option. <inbound> <base /> <validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized. Access token is missing or invalid."> <openid-config url="https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration" /> <required-claims> <claim name="aud"> <value>bf795850-70c6-4f22- </value> </claim></required-claims> </validate-jwt> </inbound> Resolution: The claim name provided in the Claim section does not match with the APP registered in the AAD. Provide the Client app registered Application ID in the Claims section to fix the authorization error. After providing the valid app id, the HTTP response results with HTTP/1.1 200 OK. Error code: 403 - Forbidden issues Symptoms: GetSpeakers API operation fetches the details of speakers based on the value provided in the parameter. After few days of using it, The Operation started throwing HTTP 403- Forbidden error whereas the other operations are working fine as expected. Message: HTTP/1.1 403 Forbidden { "statusCode": 403, "message": "Forbidden" } Troubleshooting: To troubleshoot the scenario, we would start with checking the APIM inspector trace. We can also find the Ocp-Apim-Trace link from the response We notice the existence of a “ip-filter” policy that filters(allow/denies) call from specific IP address ranges. To check the scope of the 'ip-filter' policy, select the Calculate effective policy button. If you don't see any access restriction policy implemented at any scopes, next validation step should be done at product level, by navigating to the associated product and then click on Policies option. <inbound> <base /><choose> <when condition="@(context.Operation.Name.Equals("GetSpeakers"))"> <ip-filter action="allow"> <address-range from="13.66.140.128" to="13.66.140.143" /> </ip-filter> </when></choose> </inbound> Resolution: HTTP 403 - Forbidden error can be thrown when there is any access restriction policy implemented. As we can see the IP address is not whitelisted in the error screenshot, we need to allow the IP address in the Policy to make it work. Before: <ip-filter action="allow"> <address-range from="13.66.140.128" to="13.66.140.143" /> </ip-filter> After: <ip-filter action="allow"> <address>13.91.254.72</address> <address-range from="13.66.140.128" to="13.66.140.143" /> </ip-filter> Once we allow the IP address in the IP-Filter Policy we would be able to receive the response. Error code: 404 Symptoms: The Demo API is being invoked by either of the means below, - Developer portal - ‘Test’ option under API Management - Client app like PostMan - Using user code The result of the call is a 404 Not Found error code. Troubleshooting: Make sure that the issue is existing to proceed with the troubleshooting steps. Note: The API Management is not present in any Virtual Network which eliminates the option of Network elements causing the issue. According to the API Management configuration, below are the settings Name of the API – Demo API Web Service URL - http://echoapi.cloudapp.net/api Subscription Required – Yes Below is the error scenario for the 404 error code using the API Management and the PostMan. Postman: API Management portal: Based on the trace file, we can see that the error code is thrown from the forward-request section and we do not obtain much insights from it. The configured web service URL is also reachable, and it displays us a visible content. Web Service URL: Hence, we proceed on collecting the browser trace while replicating the issue in the API Management section in Azure portal. Steps to collect browser trace: - Replicate the issue in the browser (chrome, steps for other browsers might differ slightly) - Press F12 and navigate to the network tab. - Make sure that the actions are recorded. - Right click on any one of the actions and select the last option (Save all as HAR with content). From the trace, we could see the below information which is show in preview state. The Requested URL does not lead to a proper content over the mentioned Web Service URL. This is the reason that though the Web Service URL is reachable, the API was still throwing a 404 Not found error code when it was invoked. Resolution: Make sure that the Web Service URL leads to a valid destination which helps in the issue resolution. The best approach is to create a proper backend structure which hosts the APIs and then map it to the respective API of the API Management and not vice versa. The following pointers are the main reason to encounter a 404 Not found error message from an API Management. You might hit the wrong http Method, (for example, the operation might be POST but you are calling it as GET.) You might be calling a wrong URL (that either has a suffix or wrong operation path). You might be using a wrong protocol (HTTP/HTTPS). In our case, the error is in correspondence with the second point where the configured URL is not pointing to the destination. This has been confirmed by the Browser trace too and hence correcting the URL/path will resolve the issue. Continue Reading 5xx Error Series
