500 Internal Server Error - BadPath

You're viewing Apigee Edge documentation.
Go to the Apigee X documentation. info

Symptom

The client application gets an HTTP status code of 500 Internal Server Error with the error code protocol.http.BadPath as a response for API calls.

Error message

Client application gets the following response code:

HTTP/1.1 500 Internal Server Error

In addition, you may observe the following error message:

{
   "fault":{
      "faultstring":"Invalid request path",
      "detail":{
         "errorcode":"protocol.http.BadPath"
      }
   }
}

Possible causes

This error occurs if the request URL of the backend server, represented by the flow variable target.url, contains a path that starts with a question mark (?) instead of a forward slash (/), which is invalid.

As per the specifications RFC 3986, section 3: Syntax Components and RFC 3986, section 3.3: Path:

1. The URI syntax has the following components:

           foo://example.com:8042/over/there?name=ferret#nose
           \_/   \______________/\_________/ \_________/ \__/
            |            |            |            |       |
         scheme      authority       path        query   fragment
   

2. The path component is required and it MUST start with and always have a forward slash (/).

Therefore, if the request URL of the backend server has a path component starting with a question mark (?) instead of a forward slash (/), then Apigee Edge responds with 500 Internal Server Error and error code protocol.http.BadPath.

For example: If the target.url has the value https://www.mocktarget.apigee.net?json, then this error occurs as the path is found to be invalid, since it starts with a question mark (?) instead of a forward slash (/).

Cause	Description	Troubleshooting instructions applicable for
Backend server URL (target.url) has an invalid path	The path component in the backend server URL represented by flow variable target.url starts with a question mark (?) instead of a forward slash (/).	Edge Public and Private Cloud users

Common diagnosis steps

Use one of the following tools/techniques to diagnose this error:

Cause: Backend server URL (target.url) has an invalid path

Diagnosis

1. Determine the Fault Code and Fault Source for 500 Internal Server Error using API Monitoring, Trace Tool or NGINX access logs as explained in Common diagnosis steps.
2. If the Fault Code is protocol.http.BadPath and Fault Source has the value target, then this indicates that the backend server URL has an invalid path.

3. The backend server URL is represented by the flow variable target.url in Apigee Edge. This error typically happens if you try to update the backend server URL (target.url) dynamically using any of the policies (within proxy/shared flow) in the Target request flow, such that it has an invalid path.

4. Determine if the flow variable target.url indeed has an invalid path and the source for its value using one of the following methods:

   Trace

   Using Trace tool

   If you have captured a trace for this error, then use the steps as explained in Using Trace tool and

   1. Verify if target.url has an invalid path, that is if it starts with a question mark (?) instead of a forward slash (/).

   2. If yes, then find out the policy that modified or updated the value of target.url to contain an invalid path.

      Sample trace showing JavaScript policy updated the flow variable target.url

      
   3. In the above sample trace, notice that the JavaScript policy has modified or updated the value of target.url to contain an invalid path.
   4. Note that target.url has the following components:
      • scheme: https
      • authority: mocktarget.apigee.net
      • path: ?json

      The path starts with a question mark (?) instead of a forward slash (/), therefore it is invalid.

   Logs

   Using logs in your log server

   1. If you don’t have a trace for this error (an intermittent issue), then check if you have logged the information about the value of flow variable target.url, using policies such as MessageLogging or ServiceCallout policy to your log server.
   2. If you have the logs, review them and
      1. Verify if target.url has an invalid path, and
      2. See if you can determine the information about which policy modified target.url to contain invalid path

   API proxy

   Reviewing the failing API proxy

   If you don’t have a trace or logs for this error, review the failing API proxy to determine what modified or updated the flow variable target.url to contain an invalid path. Check the following:

   • The policy within API proxy
   • Any shared flows invoked from the proxy

5. Examine the specific policy carefully (For example: AssignMessage or JavaScript) that modifies or updates the flow variable target.url and determine the cause for updating target.url to have an invalid path.

   Here are a few example policies that update the flow variable target.url incorrectly to contain an invalid path leading to this error.

   Sample #1

   Sample #1: JavaScript Policy updating target.url variable

   var url = "https://mocktarget.apigee.net?json"
   context.setVariable("target.url", url);
   

   In the above sample, note that the flow variable target.url is updated with the value https://mocktarget.apigee.net?json contained in another variable url.

   Note that the value of the url has the following components:

   • scheme: https
   • authority: mocktarget.apigee.net
   • path: ?json

   The path starts with a question mark (?) instead of a forward slash (/), which is invalid. Therefore, Apigee Edge returns 500 Internal Server Error with error code protocol.http.BadPath.

   Sample #2

   Sample #2: JavaScript Policy updating target.url variable based on the value in the request header

   var path = context.getVariable("request.header.Path");
   var url = "https://mocktarget.apigee.net" + path
   context.setVariable("target.url", url);
   

   In the above sample, notice that the flow variable target.url is updated by concatenating the value https://mocktarget.apigee.net contained in a variable url and the value of another variable path, whose value is retrieved from request.header.Path.

   If you have access to the actual request or trace, then you can verify the actual value passed to request.header.Path.

   Sample Request made by the user

   curl -v https://HOST_ALIAS/v1/myproxy -H "Authorization: Bearer <token> -H "Path: ?user"
   

   In this example, the header path is not sent as part of the request. Therefore, the value of the variable path in the JavaScript policy is null.

   So:

   • url = https://mocktarget.apigee.net + path
   • url = https://mocktarget.apigee.net + "?user"
   • target.url = https://mocktarget.apigee.net?user

   Note that the value of the target.url, has the following components:

   • scheme: https
   • authority: mocktarget.apigee.net
   • path: ?user

   The path starts with a question mark (?) instead of a forward slash (/), which is invalid. Hence, Apigee Edge returns 500 Internal Server Error with error code protocol.http.BadPath.

   Sample #3

   Sample #3: AssignMessage policy updating target.url variable

   <AssignMessage async="false" continueOnError="false" enabled="true" name="AM-SetTargetURL">
       <DisplayName>AM-SetTargetURL</DisplayName>
       <AssignVariable>
            <Name>target.url</Name>
            <Value>https://mocktarget.apigee.net?echo</Value>
       </AssignVariable>
       <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
       <AssignTo createNew="false" transport="http" type="request"/>
   </AssignMessage>
   

   Note that the value of url, has the following components:

   • scheme: https
   • authority: mocktarget.apigee.net
   • path: ?echo

   Again in this example, the path starts with a question mark (?) instead of a forward slash (/), which is invalid. Therefore, Apigee Edge returns 500 Internal Server Error with error code protocol.http.BadPath.

Resolution

As per the URL specification RFC 3986, section 3: Syntax Components, the path component is required and it MUST always start with "/". So follow the below steps to fix this issue:

1. Ensure that the backend server URL, represented by the flow variable target.url always has a valid path and it always starts with a forward slash (/).
   1. In some cases, you may not have a resource name in the path, then ensure that the path at least has a forward slash (/).
   2. If you use any other variables to determine the value of the flow variable target.url, then ensure that other variables don’t have an invalid path.
   3. If you perform any string operations to determine the value of the flow variable target.url, then ensure that the result or outcome of the string operations doesn’t have an invalid path.

2. In the samples discussed above, you can fix this issue as explained below:

   Sample #1

   Sample #1: JavaScript Policy updating target.url variable

   Use a forward slash (/) instead of a question mark (?) in the variable url to fix this issue as shown below:

   var url = "https://mocktarget.apigee.net/json"
   context.setVariable("target.url", url);
   

   Sample #2

   Sample #2: JavaScript Policy updating target.url variable based on the value in the request header

   var path = context.getVariable("request.header.Path");
   var url = "https://mocktarget.apigee.net" + path
   context.setVariable("target.url", url);
   

   Ensure that you pass a valid path, for example: /user as part of request header Path to fix this issue as shown below:

   Sample Request:

   curl -v https://HOST_ALIAS/v1/myproxy -H "Authorization: Bearer <token> -H "Path: /user"
   

   Sample #3

   Sample #3: AssignMessage Policy updating target.url variable

   Add a valid path in the <Value> element of AssignMessage policy. That is, replace the question mark (?) with a forward slash (/) in the <Value> element and set it to https://mocktarget.apigee.net/echo to fix this issue as shown below:

   <AssignMessage async="false" continueOnError="false" enabled="true" name="AM-SetTargetURL">
       <DisplayName>AM-SetTargetURL</DisplayName>
       <AssignVariable>
            <Name>target.url</Name>
            <Value>https://mocktarget.apigee.net/echo</Value>
       </AssignVariable>
       <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
       <AssignTo createNew="false" transport="http" type="request"/>
   </AssignMessage>
   

   Specification

   Apigee Edge expects that the path component in the backend server URL MUST always start with a forward slash (/) as per the following specifications:

   Specification
   RFC 3986, section 3: Syntax Components
   RFC 3986, section 3.3: Path

   If you still need any assistance from Apigee Support, go to Must gather diagnostic information.

   Must gather diagnostic information

   If the problem persists even after following the above instructions, gather the following diagnostic information, and then contact Apigee Edge Support:

   If you are a Public Cloud user, provide the following information:

   • Organization name
   • Environment name
   • API proxy name
   • Complete curl command used to reproduce the 500 Internal Server Error with the error code protocol.http.BadPath
   • Trace file for the API requests

   If you are a Private Cloud user, provide the following information:

   • Complete error message observed for the failing requests
   • Environment name
   • API proxy bundle
   • Trace file for the API requests

   • NGINX access logs:

     /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

     Where: ORG, ENV and PORT# are replaced with actual values.

   • Message Processor system logs /opt/apigee/var/log/edge-message- processor/logs/system.log

   References

   Flow Variables - target