Google is committed to advancing racial equity for Black communities. See how.

500 Internal Server Error - BadPath

You're viewing Apigee Edge documentation.
View Apigee X documentation.

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:

API Monitoring

Procedure #1: Using API Monitoring

To diagnose the error using API Monitoring:

  1. Sign in to Apigee Edge UI as a user with an appropriate role.
  2. Switch to the organization in which you want to investigate the issue.

  3. Navigate to the Analyze > API Monitoring > Investigate page.
  4. Select the specific timeframe in which you observed the errors.
  5. Plot Fault Code against Time.

  6. Select a cell which has the fault code protocol.http.BadPath as shown below:

  7. Information about the fault code protocol.http.BadPath is displayed as shown below:

  8. Click View logs and expand the row for the failed request.

  9. From the Logs window, note the following details:
    • Status Code: 500
    • Fault Source: target
    • Fault Code: protocol.http.BadPath
  10. If the Fault Source is target and the Fault Code is protocol.http.BadPath, then that indicates that the backend server URL has an invalid path.

Trace

Procedure #2: Using Trace tool

To diagnose the error using the Trace tool:

  1. Enable the trace session and either
    • Wait for the 500 Internal Server Error error to occur, or
    • If you can reproduce the issue, make the API call to reproduce the issue 500 Internal Server Error
  2. Ensure Show all FlowInfos is enabled:

  3. Select one of the failing requests and examine the trace.
  4. Navigate through different phases of the trace and locate where the failure occurred.
  5. You will find the error typically in a flow after the Target Request Flow Started phase as shown below:

  6. Note the value of the error from the trace:

    error: Invalid request path

    Since the error is raised by Apigee Edge after the Target Request Flow Started phase, it indicates that the backend server URL has an invalid path. This would most likely happen if the flow variable target.url (which represents the URL for backend server) in Apigee Edge has been possibly updated with an invalid path through one of the policies in the target request flow.

  7. Examine the section Variables Read and Assigned in each of the flow backwards from the error flow towards Target Request Flow Started phase.
  8. Determine the policy, where the flow variable target.url was updated:

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

    In the sample trace shown above, note the value of the flow variable variable target.url is updated in a JavaScript policy named JS- SetTargetURL as follows: target.url : https://mocktarget.apigee.net?json

  9. Note that the value in target.url, has the following components:
    • scheme: https
    • authority: mocktarget.apigee.net
    • path: ?json
  10. Since the path component starts with a question mark (?) instead of a forward slash (/), you get the error Invalid request path.
  11. Navigate to the AX (Analytics Data Recorded) Phase in the trace and click it.
  12. Scroll down to the Phase Details - Error Headers section and determine the values of X-Apigee-fault-code and X-Apigee-fault-source as shown below:

  13. You will see the values of X-Apigee-fault-code and X-Apigee-fault-source as protocol.http.BadPath and target respectively, indicating that this error is caused because the backend server URL has an invalid path.

    Response headers Value
    X-Apigee-fault-code protocol.http.BadPath
    X-Apigee-fault-source target

Nginx

Procedure #3: Using Nginx access logs

To diagnose the error using Nginx access logs:

  1. If you are a Private Cloud user, then you can use Nginx access logs to determine the key information about HTTP 500 Internal Server Error.
  2. Check the Nginx access logs:

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

  3. Search to see if there are any 500 errors with error code protocol.http.BadPath during a specific duration (if the problem happened in the past) or if there are any requests still failing with 500.
  4. If you do find any 500 errors with the X-Apigee-fault-code matching the value of protocol.http.BadPath, then determine the value of the X- Apigee-fault-source.

    Sample 500 error from Nginx access log:

    The above sample entry from Nginx access log has the following values for X-Apigee- fault-code and X-Apigee-fault-source:

    Headers Value
    X-Apigee-fault-code protocol.http.BadPath
    X-Apigee-fault-source target

    Notice that the values of X-Apigee-fault-code and X-Apigee-fault-source are protocol.http.BadPath and target respectively, indicating that this error is caused because the backend server URL has an invalid path.

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 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 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