502 Bad Gateway - Response 405 without Allow Header

API Monitoring

To diagnose the error using API Monitoring:

1. Log in to the 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.Response405WithoutAllowHeader as shown below:

   

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

   

8. Click View logs and expand one of the failed requests to view more information.

   
9. From the Logs window, note the following details:
   • Status Code: 502
   • Fault Source: target
   • Fault Code: protocol.http.Response405WithoutAllowHeader.
10. If the Fault Source is target and the Fault Code is protocol.http.Response405WithoutAllowHeader, then that indicates that the backend server responded with 405 Method Not Allowed status code without the Allow header.

Trace tool

To diagnose the error using the Trace tool:

1. Enable the trace session and either
   • Wait for the 502 Bad Gateway error to occur, or
   • If you can reproduce the issue, make the API call to reproduce the issue - 502 Bad Gateway 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 Request sent to target server phase as shown below:

   

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

   The above sample trace shows the error as Received 405 Response without Allow Header. Since the error is raised by Apigee after the request was sent to the backend server, it indicates that the backend server sent the 405 response status code without the Allow header.

7. Navigate to the AX (Analytics Data Recorded) Phase in the trace and click it.

8. Scroll down to the Error / Response Headers section in the Phase Details panel and determine the values of X-Apigee-fault-code and X-Apigee-fault-source as shown below:

   
9. You will see the values of X-Apigee-fault-code and X-Apigee-fault-source as protocol.http.Response405WithoutAllowHeader and targetrespectively, indicating that this error is caused because the backend sent the 405 response status code without the Allow header.

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

NGINX

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 502 errors.

2. Check the NGINX access logs:

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

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

3. Search to see if there are any 502 errors with error code protocol.http.Response405WithoutAllowHeader during a specific duration (if the problem happened in the past) or if there are any requests still failing with 502.

4. If you do find any 502 errors with the X-Apigee-fault-code matching the value of protocol.http.Response405WithoutAllowHeader, then determine the value of the X-Apigee-fault-source.

   Sample 502 error from the 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:

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

Backend server

Option #1: Fix the Backend Server to send 405 status code with the Allow header:

1. Ensure that the backend server always adheres to the specification RFC 7231, section 6.5.5: 405 Method Not Allowed and sends with the 405 status code by including the list of methods that are allowed as part of a Allow header as shown below:

   Allow: HTTP_METHODS

2. For example, if your backend server allows GET, POST and HEAD methods, then you need to ensure that the Allow header contains them as follows:

   Allow: GET, POST, HEAD

Fault handling

Option #2: Use Fault Handling to send 405 status code with the Allow header from your API proxy:

If the backend server returns the 405 status code without the Allow header, you can use fault handling to respond back with the 405 status code and the Allow header from your API proxy as follows:

1. Create a policy such as AssignMessage policy or RaiseFault policy and set the status code to 405 with Allow header and a custom message.

   Sample AssignMessage policy to send 405 with Allow header:

   <AssignMessage async="false" continueOnError="false" enabled="true" name="AM-405WithAllowHeader">
       <DisplayName>AM-405WithAllowHeader</DisplayName>
       <Set>
           <Payload contentType="application/json">{"Specified method is not allowed. Please use one of the methods mentioned in the Allow header."}</Payload>
           <StatusCode>405</StatusCode>
           <ReasonPhrase>Method Not Allowed</ReasonPhrase>
       </Set>
       <Add>
           <Headers>
               <Header name="Allow">GET, POST, HEAD</Header>
           </Headers>
       </Add>
       <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
       <AssignTo createNew="false" transport="http" type="request"/>
   </AssignMessage>

2. Create a FaultRule in the TargetEndpoint, that invokes the policy upon getting the 502 error with the error code protocol.http.Response405WithoutAllowHeader.

   Sample TargetEndpoint configuration showing FaultRule:

   <TargetEndpoint name="default">
   ...
       <FaultRules>
          <FaultRule name="405WithoutAllowHeader">
               <Step>
                   <Name>AM-405WithAllowHeader</Name>
               </Step>
               <Condition>(fault.name = "Response405WithoutAllowHeader")</Condition>
           </FaultRule>
       </FaultRules>

3. Save these changes in a new revision of your API proxy and deploy the revision.
4. Make the API calls and verify that you are getting the 405 status code with the Allow header.

Configure property

Option #3: Configure the property in the Message Processor to prevent Apigee Edge from returning 502 error

1. If you are a Private Cloud user, you can update the property HTTP.ignore.allow_header.for.405 to true to prevent Apigee Edge from raising a 502 error, even if the backend server responds with 405 status code without the Allow header using the How-to guide: Configuring ignore allow header for 405 property in Message Processors.
2. If you are a Public Cloud user, please contact Apigee Edge Support