Removing X-Forwarded-xx,Accept-Encoding,SOAPAction,User-Agent,Connection,

Hi,

I tried removing the following with Assign Message based on Assign Message Policy documentation.

But After debugging trace looks like it gets added by apigee Router (by "Proxy POST Client" which comes in response flow after Assign message found this behavior when debugging the trace).

ie apigee router is adding this header again before sending back to the client. Please confirm my understanding is correct. ?

I reviewed few posts and believe its and understand Router doing it...

https://community.apigee.com/questions/39785/removing-connection-response-header.html https://community.apigee.com/questions/31685/removing-server-response-header.html

Q1. Is there any ways to remove this permanently thro some configuration in apigee and later enable it from Router if required.

Please indicate the steps. To remove following headers listed. Could not get detailed steps .Do I need to raise ticket with Apigee ? I want all such headers to be removed from response message. My client are unable to process my response if I have following Header information embed with response. Nor they can detect or delete such header. Its unexpected for them

List of Header to be removed are (I just manipulated the value of Header)

1.Connection: keep-alive

2.X-Forwarded-For: 10.XX.55.66

3.X-Forwarded-Port: 5x4

4.X-Forwarded-Proto: ttpp

5.Accept-Encoding: zip,flate

6.SOAPAction: "https://helloworld.com/GetMeHello"

7.User-Agent: Apache-HttpServer/5.x.y (Java/1.7.0_2XX)

8.Host: myhost.apigee.net

Q2 Looks like I cannot remove HOST as well and replace as HOST with Server instead, because its controlled by apigee Router.

Please find the Assign Policy configuration

<AssignMessage name="Assign-Message-2">
  <DisplayName>Assign-POST-response</DisplayName>
  <AssignTo createNew="false" transport="http" type="response"/>
  <Remove>
    <Headers>
      <Header name="Connection"/>
    </Headers>
    <Headers>
      <Header name="X-Forwarded-For"/>
    </Headers>
    <Headers>
      <Header name="X-Forwarded-Port"/>
    </Headers>
    <Headers>
      <Header name="X-Forwarded-Proto"/>
    </Headers>
    <Headers>
      <Header name="SOAPAction"/>
    </Headers>
    <Headers>
      <Header name="User-Agent"/>
    </Headers>
  </Remove>
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</AssignMessage>

Q3. Why does Assign Message Policy did not indicate about such information in documentation indicating that list of apigee router header (listed above)cannot be removed or updated or set ?Let me know if I overlooked the AssignMessage documentation ?

Please suggest.

0 7 1,711
7 REPLIES 7

Are the headers to be removed in the API response or in the request that gets forwarded to a backend server ?

Other than SOAPAction header do you have a reason to remove the other headers as they usually are helpful in HTTP requests.

Header to be removed from response , and this is getting added from Apigee Router from during response as i indicated

I need to remove all indicated Header to simulate the way currently response is expected from required partners.

Please suggest a step to proceed further with the indicated details.

@Dino-at-Google

@Dino

@Anil Sagar @ Google @Anil Sagar

@Abiram Radhakrishnan Got any solution to this. I have to remove this attribute from header in my request as my backend is not support x-forwarded-for attribute in header.

I think yours is a new question.

Normally you use AssignMessage to remove headers.

Remove all headers:

<AssignMessage name='AM-RemoveAllHeaders'>
  <Remove>
    <Headers/>
  </Remove>
</AssignMessage>

Remove specific headers:

<AssignMessage name='AM-RemoveSomeHeaders'>
  <Remove>
    <Headers>
      <Header name='First-Header-to-Remove'/>
      <Header name='Another-Header-to-Remove'/>
    </Headers>
  </Remove>
</AssignMessage>

If this does not answer your question, please ask a new one. In general, rather than asking a question in a comment to a 1-year old thread, if you have a new question, ask a new question.

Don't do this:

<AssignMessage name="Assign-Message-2">
  <DisplayName>Assign-POST-response</DisplayName>
  <AssignTo createNew="false" transport="http" type="response"/>
  <Remove>
    <Headers>
      <Header name="Header1"/>
    </Headers>
    <Headers>
      <Header name="Header2"/>
    </Headers>
    <Headers> ...  </Headers>
  </Remove>
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</AssignMessage>

Do this:

<AssignMessage name="Assign-Message-2">
  <DisplayName>Assign-POST-response</DisplayName>
  <AssignTo createNew="false" transport="http" type="response"/>
  <Remove>
    <Headers>
      <Header name="Header1"/>
      <Header name="Header2"/>
       ...
    </Headers>
  </Remove>
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</AssignMessage>

Unfortunately, the deserialization of XML configuration for Apigee Edge sometimes allows multiple elements when really only a single element is valid. For example, see the multiple Headers elements in the "don't do this" example. This configuration may be silently accepted, but it may not do what you want. This applies to more than just the AssignMessage policy.

In some cases you DO want multiple elements. For example the Header element which is a child of Headers.

Thanks @Dino

I just want to remove X-FORWARDED-FOR attribute and for that I am using

<AssignMessage name="AM-JWKS">
    <AssignTo createNew="true" transport="http" type="request">jwksrequest</AssignTo>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    <Set>
        <Verb>GET</Verb>
        <Headers>
            <Header name="x-some-header">some_value</Header>
        </Headers>
        <Path>/SecureAuth/jwks</Path>
    </Set>
    <Remove>
        <Headers>
            <Header name="X-Forwarded-For"/>
        </Headers>
    </Remove>
    <AssignVariable>
        <Name>target.copy.pathsuffix</Name>
        <Value>false</Value>
    </AssignVariable>
</AssignMessage>

This code does not remove x-forwarded-for from header.

Regards,

Ankita

Yes, ok, thanks for showing the policy. I think you have some misunderstanding.

You have this line in your policy.

<AssignTo createNew="true" transport="http" type="request">jwksrequest</AssignTo>

That means you are creating a new request object inside the message context. You are storing that new request object under the name jwksrequest. If you read the context variable named jwksrequest after this policy executed, you will see a new request object.

People mostly use createNew="true" in order to build a request that will be sent out via ServiceCallout or some other mechanism. (You can create a request in AssignMessage and then send in from within JavaScript, for example).

Because the request is newly instantiated, it contains nothing at first. No path, no verb, no headers, no content. It's empty. Therefore the Remove element has no effect. This element in your policy:

     <Remove>
        <Headers>
            <Header name="X-Forwarded-For"/>
        </Headers>
    </Remove>

...will do nothing, because jwksrequest has been initialized with no headers.

It's possible that you are expecting this AssignMessage policy to affect the ambient "request" object. That won't happen because you use createNew="true" and you've named a new request object (jwksrequest) in the "AssignTo" element. If your desire is to modify the ambient request object, then remove the AssignTo element.

If you want to create a new request (jwksrequest) and ALSO affect the ambient request object, then you will need two distinct AssignMessage policies.

AssignMessage is a workhorse policy. It does lots of things, which is nice. But necessarily it has lots of options, which can be confusing.