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:
- The URI syntax has the following components: - foo://example.com:8042/over/there?name=ferret#nose \_/ \______________/\_________/ \_________/ \__/ | | | | | scheme authority path query fragment
- The pathcomponent 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.urlstarts 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:
- Sign in to Apigee Edge UI as a user with an appropriate role.
- Switch to the organization in which you want to investigate the issue.   
- Navigate to the Analyze > API Monitoring > Investigate page.
- Select the specific timeframe in which you observed the errors.
- Plot Fault Code against Time. 
- Select a cell which has the fault code - protocol.http.BadPathas shown below: 
- Information about the fault code - protocol.http.BadPathis displayed as shown below: 
- Click View logs and expand the row for the failed request.   
- From the Logs window, note the following details:
          - Status Code: 500
- Fault Source: target
- Fault Code: protocol.http.BadPath
 
- Status Code: 
- If the Fault Source is targetand the Fault Code isprotocol.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:
- Enable the trace session and either
          - Wait for the 500 Internal Server Errorerror to occur, or
- If you can reproduce the issue, make the API call to reproduce the issue
              500 Internal Server Error
 
- Wait for the 
- Ensure Show all FlowInfos is enabled:  
- Select one of the failing requests and examine the trace.
- Navigate through different phases of the trace and locate where the failure occurred.
- You will find the error typically in a flow after the Target Request Flow Started phase as shown below:  
- 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.
- Examine the section Variables Read and Assigned in each of the flow backwards from the error flow towards Target Request Flow Started phase.
- Determine the policy, where the flow variable target.urlwas 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.urlis updated in a JavaScript policy namedJS- SetTargetURLas follows:target.url : https://mocktarget.apigee.net?json
- Note that the value in target.url, has the following components:- scheme: https
- authority: mocktarget.apigee.net
- path: ?json
 
- scheme: 
- Since the path component starts with a question mark (?) instead of a forward slash (/), you get the errorInvalid request path.
- Navigate to the AX (Analytics Data Recorded) Phase in the trace and click it.
- 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:  
- You will see the values of X-Apigee-fault-code and X-Apigee-fault-source as - protocol.http.BadPathand- targetrespectively, 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:
- 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.
- Check the NGINX access logs: - /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
- Search to see if there are any 500errors with error codeprotocol.http.BadPathduring a specific duration (if the problem happened in the past) or if there are any requests still failing with500.
- If you do find any - 500errors 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.BadPathand- targetrespectively, 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
- Determine the Fault Code and Fault Source for 500 Internal Server Errorusing API Monitoring, Trace Tool or NGINX access logs as explained in Common diagnosis steps.
- If the Fault Code is protocol.http.BadPathand Fault Source has the valuetarget, then this indicates that the backend server URL has an invalid path.
- The backend server URL is represented by the flow variable - target.urlin 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.
- Determine if the flow variable - target.urlindeed 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 - Verify if target.urlhas an invalid path, that is if it starts with a question mark (?) instead of a forward slash (/).
- If yes, then find out the policy that modified or updated the value of - target.urlto contain an invalid path.- Sample trace showing JavaScript policy updated the flow variable - target.url  
- In the above sample trace, notice that the JavaScript policy has modified or updated the value of target.urlto contain an invalid path.
- Note that target.urlhas 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.
- scheme: 
 - Logs- Using logs in your log server - 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.
- If you have the logs, review them and
                - Verify if target.urlhas an invalid path, and
- See if you can determine the information about which policy modified
                    target.urlto contain invalid path
 
- Verify if 
 - 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.urlto contain an invalid path. Check the following:- The policy within API proxy
- Any shared flows invoked from the proxy
 
- Verify if 
- Examine the specific policy carefully (For example: AssignMessage or JavaScript) that modifies or updates the flow variable - target.urland determine the cause for updating- target.urlto have an invalid path.- Here are a few example policies that update the flow variable - target.urlincorrectly to contain an invalid path leading to this error.- Sample #1- Sample #1: JavaScript Policy updating - target.urlvariable- var url = "https://mocktarget.apigee.net?json" context.setVariable("target.url", url); - In the above sample, note that the flow variable - target.urlis updated with the value- https://mocktarget.apigee.net?jsoncontained in another variable- url.- Note that the value of the - urlhas 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 Errorwith error code- protocol.http.BadPath.- Sample #2- Sample #2: JavaScript Policy updating - target.urlvariable 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.urlis updated by concatenating the value- https://mocktarget.apigee.netcontained in a variable- urland 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 - pathin 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 Errorwith error code- protocol.http.BadPath.- Sample #3- Sample #3: AssignMessage policy updating - target.urlvariable- <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 Errorwith error code- protocol.http.BadPath.
- scheme: 
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:
- Ensure that the backend server URL, represented by the flow variable
          target.urlalways has a valid path and it always starts with a forward slash (/).- In some cases, you may not have a resource name in the path, then ensure that the
              path at least has a forward slash (/).
- 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.
- 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.
 
- In some cases, you may not have a resource name in the path, then ensure that the
              path at least has a forward slash (
- In the samples discussed above, you can fix this issue as explained below: - Sample #1- Sample #1: JavaScript Policy updating - target.urlvariable- Use a forward slash ( - /) instead of a question mark (- ?) in the variable- urlto 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.urlvariable 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: - /useras part of request header- Pathto 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.urlvariable- 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/echoto 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 - pathcomponent 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 curlcommand used to reproduce the500 Internal Server Errorwith the error codeprotocol.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