Response reason phrase from target response rather than response.reason.phrase

Google Cloud Apigee
1

I have a proxy that does a pass through to the target backend service. When the target service returns a 404 response, it has a customised reason phrase, e.g. Player not found and response body.

However Apigee proxy gives 404 Not found with the same target response body.

How do I achieve preserving the target response status code and reason phase in the response?

So far, I tried using Assign Message in the PostFlow of the TargetEnpoint. The Assign Message policy xml is below but is not working as response.reason.phrase is not being replaced by the text from targetResponse.reason.phrase.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AssignMessage continueOnError="false" enabled="true" name="AM-Preserve404ReasonPhrase">
  <DisplayName>AM-Preserve404ReasonPhrase</DisplayName>
  <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
  <!-- copy backend reason phrase -->
  <AssignVariable>
    <Name>response.reason.phrase</Name>
    <Value>{targetResponse.reason.phrase}</Value>
  </AssignVariable>
  <!-- ensure JSON content-type is preserved -->
  <AssignVariable>
    <Name>response.header.Content-Type</Name>
    <Value>{targetResponse.header.Content-Type}</Value>
  </AssignVariable>
  <Condition>(response.status.code = 404)</Condition>
  <AssignTo createNew="false" transport="http" type="response"/>
</AssignMessage>

Thanks in advance.

2

Hi,

Thank you for asking about this. Apigee X does not support the use of Reason Phrase for http/1.1 calls and support for Reason Phrase has been removed from the http/2 standard. It is possible to pass a custom error message in the payload and of course custom headers can be set to add additional details in the response as needed.

Cheers,

1 Like
3

Hello @Elvina_ART

As a best practice I would recommend wrapping your error handler logic into a set of fault rules, as documented here: Handling faults  |  Apigee  |  Google Cloud

With that said (and assuming you catch your exception via fault rule in the target response) the following assign message policy should work to expectation:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AssignMessage async="false" continueOnError="false" enabled="true" name="resource-not-found">
	<DisplayName>Resource Not Found</DisplayName>
	<Set>
		<Payload contentType="application/json">{response.content}</Payload>
		<StatusCode>404</StatusCode>
	</Set>
	<Add></Add>
	<IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
	<AssignTo createNew="false" transport="http" type="request"/>
</AssignMessage>

Let me know what you think, thanks!

4

Thank you @paul-wright for confirming this. I later read somewhere that it is not supported due to consistency across transport and runtimes.

5

We wanted the same 404 status code but with reason phrase as whats been returned by target service, as we have customised phrases.

6

Basically yes. The http standards committee formalized this originally with http/2 and then retroactively with the updated RFC 9110’s clients should ignore and 9112’s it is no longer defined for new implementations.

Cheers,