APIGEE : HTTPModifier AssignMessage rules difference

Hi everyone,


What is the difference between AssignMessage and HTTPModifier rule ?
I would like to remove apikey header, both seems to do the job so what is the key to choose between theses 2 options ?

I experienced a strange behavior with assignmessage
(https://cloud.google.com/apigee/docs/api-platform/reference/policies/assign-message-policy)

 

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AssignMessage async="false" continueOnError="false" enabled="true" name="remove-param-apikey">
 <DisplayName>Remove header Param apikey</DisplayName>
 <Remove>
   <HeaderParams>
     <Header name="x-apikey"/>
   </HeaderParams>
 </Remove>
 <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
 <AssignTo createNew="false" transport="http" type="request"/>
</AssignMessage>

 


It removes also all the query string
So I move to the httpmodifier and it works. I keep my querystring (https://cloud.google.com/apigee/docs/api-platform/reference/policies/http-modifier-policy)

 

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<HTTPModifier name="remove-header-apikey">
 <Remove>
   <Headers>
     <Header name="x-apikey"/>
   </Headers>
 </Remove>
 <AssignTo>request</AssignTo>
</HTTPModifier>

 

But I don’t see anything in the docs that explains this behavior and a choice criteria between these 2 rules.

Thanks !

Solved Solved
2 3 150
2 ACCEPTED SOLUTIONS

The HTTPModifier policy is a Standard policy and is meant to address a subset of AssignMessage policy features. Standard policies can be used to create Standard proxies.

Standard artifact types in Apigee are lightweight, therefore they require less infrastructure resources and using them will be generally be less expensive for PAYG and Subscription plans.

View solution in original post

Ruben's answer explains the difference between the step types.

The reason your AssignMessage is removing your querystring, I think, is because the you have Remove/HeaderParams. That HeaderParams element isn't actually valid as a child of Remove . So the result is, Apigee is treating it as just a bare Remove element, which is removing EVERYTHING, all headers, all queryparams, all formparams, etc.

If you want to remove ONLY the header, you need to modify the policy config to use Remove/Headers:

 

<AssignMessage  name="remove-param-apikey">
 <Remove>
   <Headers> <!-- not HeaderParams -->
     <Header name="x-apikey"/>
   </Headers>
 </Remove>
</AssignMessage>

 

Side note: I think it's a bug that Apigee doesn't flag this for you. It should tell you when you're doing something wrong, rather than just silently ignoring it. I've submitted a PR for apigeelint to throw an error when there is an unsupported element like that within AssignMessage. I hope that will be merged soon. Then you could run your proxy through Apigeelint to see a warning about that stuff. Not quite as nice as having the strict validation in the Apigee control plane itself, but. . . still useful.

Also, this line is meaningless, and you can (should) remove it:

 

<AssignTo createNew="false" transport="http" type="request"/>

 

The AssignTo element is effectual only if there is a text value. Something like

 

 <AssignTo>request</AssignTo>

 

But if you have no text value, even if you have a bunch of attributes, then AssignTo does nothing. So, remove it. Or set an explicit text value. (ps: the existing version of Apigeelint warns you about this)

View solution in original post

3 REPLIES 3

The HTTPModifier policy is a Standard policy and is meant to address a subset of AssignMessage policy features. Standard policies can be used to create Standard proxies.

Standard artifact types in Apigee are lightweight, therefore they require less infrastructure resources and using them will be generally be less expensive for PAYG and Subscription plans.

Ruben's answer explains the difference between the step types.

The reason your AssignMessage is removing your querystring, I think, is because the you have Remove/HeaderParams. That HeaderParams element isn't actually valid as a child of Remove . So the result is, Apigee is treating it as just a bare Remove element, which is removing EVERYTHING, all headers, all queryparams, all formparams, etc.

If you want to remove ONLY the header, you need to modify the policy config to use Remove/Headers:

 

<AssignMessage  name="remove-param-apikey">
 <Remove>
   <Headers> <!-- not HeaderParams -->
     <Header name="x-apikey"/>
   </Headers>
 </Remove>
</AssignMessage>

 

Side note: I think it's a bug that Apigee doesn't flag this for you. It should tell you when you're doing something wrong, rather than just silently ignoring it. I've submitted a PR for apigeelint to throw an error when there is an unsupported element like that within AssignMessage. I hope that will be merged soon. Then you could run your proxy through Apigeelint to see a warning about that stuff. Not quite as nice as having the strict validation in the Apigee control plane itself, but. . . still useful.

Also, this line is meaningless, and you can (should) remove it:

 

<AssignTo createNew="false" transport="http" type="request"/>

 

The AssignTo element is effectual only if there is a text value. Something like

 

 <AssignTo>request</AssignTo>

 

But if you have no text value, even if you have a bunch of attributes, then AssignTo does nothing. So, remove it. Or set an explicit text value. (ps: the existing version of Apigeelint warns you about this)

OK Thanks for theses clarifications !