"Do not automatically include Content-Type header in request"-option

[Stefan Klotz]

Hi all,
I'd like to better understand the HTTP-routing option "Do not automatically include Content-Type header in request", especially as we have a strange behavior for one of our policies, where this option solved the problem. But based on my understanding and the official documentation, I can't explain it.
Scenario:

• Backend throughs a 415 error, when there is no Content-Type header available AND if it's not "application/json".
• Once I enable this option, everything is working fine.

Testing:

• I configured a test policy with an unencrypted HTTP-URL to be able to sniffer the outgoing request from the gateway towards the backend.
• option enabled:
  • Any provided Content-Type will be passed 1:1 untouched -> only "application/json" is working, all other types will result in 415 error
  • If I do NOT include a Content-Type, gateway will also NOT include it -> all requests will result in 415 error
• option disbaled (default):
  • Any provided Content-Type will be passed 1:1 untouched -> only "application/json" is working, all other types will result in 415 error
  • If I do NOT include a Content-Type, gateway seems to include always "text/xml" doesn't matter which format the body has -> all requests will result in 415 error

So I do not understand what's going on here and why just enabling this option is solving the issue for this API.
Can you please provide some more information here?
Thank you!

Ciao Stefan :)

[Zhijun He]

Hello Ciao,
The server will reject the request if the content-type is not recognized, or the content-type is not matching the body content.
So,
first of all, ensure the gateway only send/pass the request with the content-type known by the backend server. 
secondly, it depends, if the request is built on gateway, the gateway should ensure the body matches the content-type, if the gateway just passes the request, then the client should ensure a valid request. (actually, the gateway should reject the bad request, same as any http server)

The default option is to just pass the content-type from the request. If you check the option, that means you want to modify/override the content-type, to do so, you should to use the "validate or change content-type" assertion or "Manage Transport Properties/Headers" assertion to set the content-type before route assertion.
Otherwise the outcome could be unexpected/unknown.
ie. this option is not supposed to work alone.

There are examples in product document, please refer to,
https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-enterprise-software/layer7-api-management/api-gateway/10-0/policy-assertions/assertion-palette/message-routing-assertions/route-via-http-s-assertion.html#concept.dita_049ffc6cf73f4e1b368ebb8707b00fe50b5546cc_manipulating

Regards,
Mark

[Stefan Klotz]

Hi Mark,
thanks for the answer.
Some more details from my side:

• As described before, we are currently NOT using any additional assertion for validating/modifying the Content-Type.
• We have just enabled this option and it is working correctly
• The request will be passed from the client
• The body they are sending is just an array, like "[1]" or just an empty array like "[]" (is this really an allowed JSON-format? based on RFC it looks like)

So as you mentioned "Otherwise the outcome could be unexpected/unknown, ie. this option is not supposed to work alone", this is exactly our current setup.
How can I further analyze what is really happening here?
How can I check the Content-Type before and after policy processing (I mean in case the Gateway is somehow adjusting it during policy processing)?
Thank you!

Ciao Stefan :)

[Zhijun He]

Dear Ciao,
In your use case, there is a backend server, and the gateway is supposed to pass the request.
Then we don't have to validate the request on gateway side, if any problem of the request, the backend server will return error response, the gateway just need to pass the response back  to the client.
This is a common implementation (when the gateway is working as "gateway"), and should be a better practice because of the loose coupling.
ie. leave the default setting of the route assertion, and select "Never fail as long as target returns an answer" on the [Other] tab of route assertion properties. That will let the gateway pass the error response to the client.

I don't see any problem if the server returns error for bad request. We don't have to correct it for the client.

Of cause, if you want to, the gateway is able to implement business logic, including tailoring the request/response, but you need to know all the specs of the request from backend. If the specs changed, you need to change on gateway as well.

As I said, if you select "Do not automatically include Content-Type header in request", then you should specify the content type in your policy before routing to backend. This is by design.
The provided document has example on how to do it,

Example 2: Modify the Content-Type header before routing

• Add the Route via HTTP(S) assertion to a policy and select 

  Do not automatically include Content-Type header in request

  .
• Add the Manage Transport Properties/Headers Assertion before the Route via HTTP(S) assertion and set the target message to 'Request'. Configure the properties as follows:
• Type: 

  HTTP Header
• Operation: 

  Add or Replace
• Property/Header Name: 

  Content-Type
• Property/Header Value:

   application/my-content-type

If it's still working without specifying the content-type, it's another issue, but it's not expected to do like that.

Regards,
Mark

[Stefan Klotz]

Hi Mark,
thanks for your answer again, but this is all clear for me.
The intention of my question is just to understand, why we have a use case where the backend is answering with a 415 error code for a specific type of request and as soon as I enable this single HTTP-option, the backend is answering with successful HTTP-Code.
So as a result the gateway MUST do something in the background depending if this option is enabled or not. And maybe this behavior is only related to a specific request-type. If you also don't have a technical explanation for this, the last idea would be to analyze the affected request on the clientside connection of the gateway and on the serverside connection of the gateway, e.g. with tcpdump. But this might be complicated as the traffic is encrypted. So is there any other (easier) possibility to check the request and all its headers with the Policy Manager (Debugger???) on the incoming and outgoing interface?
Again, I just want to understand the current behavior, doesn't matter if it's an issue with the client or on the gateway (or a combination of both).
Thank you!

Ciao Stefan :)