0

My backend server returns HTTP 405 back to Apigee 4.23 (OPDK) for a particular request. However, the backend fails to set the "ALLOW" header that the standard says that a 405 response should include.

Instead of fixing my backend (due to some constraints on touching a long running code base), I would like to handle this scenario in my proxy TargetEndpoint Response flow and add the ALLOW header. However, it looks like Apigee 4.23 (OPK) wouldn't let me do this and it sends the following response back to client:

HTTP/1.1 502 Bad Gateway
Content-Type: application/json
Content-Length: 139

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

I followed the documentation regarding setting the "success.codes" property on the TargetEndpoint:

<HTTPTargetConnection>
        <Properties>
            <Property name="success.codes">405</Property>
        </Properties>
        <URL>https://my.backend.url</URL>
</HTTPTargetConnection>

Still getting same error. How do I solve this ? Am using Apigee 4.23 (On Premises Deployment Kit)

Cheeso
  • 180,104
  • 92
  • 446
  • 681
tsv
  • 1
  • 4
  • I was able to get Apigee ignore the missing ALLOW header for 405's from the backend by setting the property "HTTP.ignore.allow_header.for.405" to true in the files conf/apigee/message-processor/http.properties and conf/apigee/router/http.properties in each Router and Message Processor servers and restarting Apigee servers. Is there an easier way to do this without having to restart the servers ? – tsv Dec 05 '13 at 23:06
  • Are you using the on premises version of Apigee Edge? Alternatively, are you using the legacy 3.8 version? – Mike Malloy Dec 05 '13 at 23:46
  • Apigee 4.23 (OPK) - just updated the post as well – tsv Dec 07 '13 at 05:49

3 Answers3

0

HTTP.ignore.allow_header.for.405 is checked only at system level not for each proxy. Instead of treating 405 as success in the proxy, you can treat that as a fault and handle it in the fault flow.

<FaultRules>
    <FaultRule name="defaultFaultHandling">
        <Step>
            <Name>AssignMessage-1</Name>
        </Step>
</FaultRule>
</FaultRules>

Where in AssignMessage he can add Allow header and return the response to client.

 <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AssignMessage async="false" continueOnError="false" enabled="true" name="AssignMessage-1">
    <DisplayName>AssignMessage-1</DisplayName>
    <FaultRules/>
    <Properties/>

       <Set>
          <Headers> <Header name="Allow">GET, PUT</Header>   </Headers>      

      </Set>

    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
    <AssignTo createNew="true" transport="http" type="response"/>
</AssignMessage>
Mike Malloy
  • 1,300
  • 1
  • 14
  • 19
  • Nope. did not work. Getting the same error. Infact tried all possibilities suggested by http://apigee.com/docs/api-services/content/fault-handling but the fault rule did not trigger at all :( – tsv Jan 08 '14 at 01:35
0

You can use the success codes property in the following way. Also we do not have an equivalent property for HTTP.ignore.allow_header.for.405 for Target Endpoint.

Test

Instead of using the below

        <HTTPTargetConnection>
           <Properties>
             <Property name="success.codes">405</Property>
           </Properties>
         <URL>https://my.backend.url</URL>
        </HTTPTargetConnection>

Use the below and let me know if it works or not:

             <HTTPTargetConnection>
                  <Properties>
                     <Property name="additional.success.codes">405</Property>
                  </Properties>
                <URL>https://my.backend.url</URL>
             </HTTPTargetConnection>
Jagjyot
  • 21
  • 2
0

I could handle this using a flow CatchAll as the last flow in Flows

<Flows>
  <!--
    ...
    -->
  <Flow name="CatchAll">
    <Request>
      <Step>
        <Name>raiseMethodNotAllowedFaultResponse</Name>
      </Step>
    </Request>
    <Response/>
  </Flow>
</Flows>

The correspondig raise fault policy

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RaiseFault async="false" continueOnError="false" enabled="true" name="raiseMethodNotAllowedFaultResponse">
  <DisplayName>raiseMethodNotAllowedFaultResponse</DisplayName>
<Properties/>
<FaultResponse>
    <Set>
      <Headers>
        <Header name="Allow">POST</Header>
      </Headers>
      <Payload contentType="text/plain">Method Not Allowed</Payload>
      <StatusCode>405</StatusCode>
      <ReasonPhrase>Method Not Allowed</ReasonPhrase>
    </Set>
  </FaultResponse>
<IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</RaiseFault>
fcdt
  • 2,151
  • 5
  • 9
  • 24