502 Bad Gateway - Response 405 without Allow Header

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

Symptom

The client application gets an HTTP status code of 502 Bad Gateway with the error code protocol.http.Response405WithoutAllowHeader as a response for API calls.

Error message

Client application gets the following response code:

HTTP/1.1 502 Bad Gateway

In addition, you may observe the following error message:

{
   "fault":{
      "faultstring":"Received 405 Response without Allow Header",
      "detail":{
         "errorcode":"protocol.http.Response405WithoutAllowHeader"
      }
   }
}

Possible causes

This error occurs if the backend server responds with 405 Method Not Allowed status code without the Allow header.

As per the specification RFC 7231, section 6.5.5: 405 Method Not Allowed, it is expected that the origin server MUST generate and send an Allow header field in a 405 response containing a list of the target resource's currently supported methods. If not, then Apigee responds with 502 Bad Gateway and error code protocol.http.Response405WithoutAllowHeader.

Cause Description Troubleshooting instructions applicable for
405 response without Allow header from backend server The backend server that is processing the API request responds with 405 status code without Allow header. Edge Public and Private Cloud users

Common diagnosis steps

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

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.

    org drop-down list
  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

Cause: 405 response without Allow header from backend server

Diagnosis

  1. Determine the Fault Code and Fault Source for 502 Bad Gateway using API Monitoring, Trace Tool or NGINX access logs as explained in Common diagnosis steps.
  2. If the Fault Code is protocol.http.Response405WithoutAllowHeader and Fault Source has the value target, then this indicates that the backend server has responded with a 405 status code without the Allow header. Therefore, Apigee responds back with 502 Bad Gateway with error code protocol.http.Response405WithoutAllowHeader.

Resolution

Use one of the following methods to resolve the issue:

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

Specification

Apigee expects the 405 Method Not Allowed response from the backend server along with the Allow header as per the following specifications:

Specification
RFC 7231, section 6.5.5: 405 Method Not Allowed
RFC 7231, section 7.4.1: Allow

Key points to note

The recommended solution is to fix the backend server to send the 405 status code with Allow header and adhere to the specification RFC 7231, section 6.5.5: 405 Method Not Allowed.

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 502 Bad Gateway with the error code protocol.http.Response405WithoutAllowHeader
  • 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~ORG.PORT#_access_log

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

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

References

Fault handling in Apigee