Reason Phrase is returned incorrectly for a Response code

[adevegowda]

We want to return the reason phrase as “Upgrade Required” for the response code 426 as shown below:

HTTP/1.1 426 Upgrade Required

To achieve this, we invoke the below RaiseFault policy when a certain condition is met:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RaiseFault async="false" continueOnError="false" enabled="true" name="RaiseFault">
<DisplayName>RaiseFault</DisplayName>
<FaultResponse>
<Set source="response">
<Payload contentType="text/plain"/>
<StatusCode>426</StatusCode>
<ReasonPhrase>Upgrade Required</ReasonPhrase>
</Set>
</FaultResponse>
<IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</RaiseFault>

However, when we get the response from the API request we get it as follows:

HTTP/1.1 426 Unknown

Somehow reason phrase is returned incorrectly.

[adevegowda]

1. Gathered the UI trace for the requests and observed that the correct response code and reason phrase (HTTP/1.1 426 Upgrade Required) was being sent back to the client under the section “Response sent to the client”
2. This indicated that the Message Processor returned the correct information back to the client.
3. Next step was to see if the Routers were returning back the response code and reason phrase as is or was making any modification.
4. For this, used the following two techniques:
   1. Make the direct call from Routers to the API Proxy as documented here.This approach showed that we were getting the correct response code and reason phrase.(Note: This approach can be used only by Private Cloud users.)
   2. Checked the Virtual Hosts and found that we had the apige.net domain host alias -> <orgname>-<envname>.apigee.net. Made the direct call using this virtual host alias. Interestingly got the expected response code and reason phrase.
5. This indicated that the incorrect reason phrase was seen only when the users were using their own custom domain virtual host alias.
6. Ran the dig and nslookup commands on the specific custom domain virtual host alias. (For ex: somename.something.com)
7. Noticed that it was pointing to another hostname before it hit Apigee Edge.
8. This indicated that there was another layer in between the client application and Apigee Edge.
9. With this we were able to prove that the layer between the client application and Apigee Edge was actually modifying the reason phrase from “Upgrade Required” to “Unknown”.

This layer could be anything Akamai, F5 etc. If a similar issue is observed, please do check if there are any other layers exist between the client application and Apigee Edge. Verify if that layer is making any modifications to the reason phrase.