X-Note: Gateway Ack

[#1]

We have an Endpoint that is setup with our customer and upon their request for a payload we are getting an ACK that we are not expecting:

< HTTP/1.1 100 Continue

< X-Note: Gateway Ack

< HTTP/1.1 200 OK

This is causing us to resend the payload as we think we are not receiving the 200 OK. We normally see the below which processes fine:

< HTTP/1.1 100 Continue

< HTTP/1.1 200 OK

Does anyone know what we are seeing: < X-Note: Gateway Ack. Thanks for reviewing.

,

Anyone know what this Ack is for. We are seeing this from an endpoint where the log is show the response as:

< HTTP/1.1 100 Continue

< X-Note: Gateway Ack

< HTTP/1.1 200 OK

The problem is the source endpoint is expecting the 200 not the X-Note as follows:

< HTTP/1.1 100 Continue

< HTTP/1.1 200 OK

Anyone have an idea if this is coming from Apigee or if this is configurable? The <X-Note: Gateway Ack is causing our app to resend the transmission and we need to figure out if we can turn this off.

[DChiesa]

Hi, Vincent

I guess you're using "curl -v" or some other client that verbosely logs its operation when sending HTTP Requests.

I am not familiar with the X-Note header. I do know that there was a time when the IETF encouraged people who designed APIs to use an X- prefix on any custom header. That recommendation has since been rescinded. Even so, there are plenty of systems and services out there that followed the initial advice and still use headers of the form X-xxxxx .

According to my reading of the relevant part of the HTTP standard, The response should include a Status line followed by zero or more response headers. There is a special status "100 Continue", which is permitted, before the final status. That interim status can include optional headers. The key is that the response must include \r\n\r\n after the final header, or after the 100 Continue status line if there are no headers.

In other words, this is allowed:

HTTP/1.1 100 Continue
X-Note: Gateway Ack

HTTP/1.1 200 OK
... 

I googled around and the only examples of X-Note: with "Gateway Ack" were related to Datapower gateways. I could not find a definitive statement within the Datapower documentation that says "Datapower often sends the X-Note header". But lots of posts of request traces on the internet, that include the X-Note header, all have Datapower in common. Do you have datapower in your environment? If so, that may be the agent that is adding the header. It's not coming from Apigee.

OK, having said all that, you wrote, "This is causing us to resend the payload...." I think that is incorrect behavior. I think "us" (whoever that is) ought to not re-send anything. The HTTP client ought to be able to correctly handle Headers following the 100 Continue. It seems like the ideal mitigation here is to correct the client, or the client's HTTP library, so that it doesn't re-send.

Next question - you indicated that you'd like to find some way to "turn it off". If your APIs are flowing through an Apigee Edge gateway, it's easy to insert an AssignMessage policy that will remove the undesired header.

<AssignMessage name='AM-CleanXNote'>
  <Remove>
    <Headers>
      <Header name='X-Note'/>
    </Headers>
  </Remove>
  <AssignTo createNew='false' transport='http' type='response'/>
</AssignMessage>

You would need to insert that on the response flow, somewhere. That ought to suppress the header.