We have a yaml file hosted on API Connect which is sending a Post request to a backend (with no body in the request).  If content-type is sent with any value other than blank, we are returned a 415 Unsupported Media Type.  If I try sending a request through API Connect without specifying a content-type header I am also getting a 415.  Is there a way to specify that no content-type header is needed on the request?  The only way this is successful is if I declare the content-type header and set it to a blank value.  

We have a yaml file hosted on API Connect which is sending a Post request to a backend (with no body in the request).  If content-type is sent with any value other than blank, we are returned a 415 Unsupported Media Type.  If I try sending a request through API Connect without specifying a content-type header I am also getting a 415.  Is there a way to specify that no content-type header is needed on the request?  The only way this is successful is if I declare the content-type header and set it to a blank value.  

Hi Jeff,
Assuming your using an API Gateway API, in the API, on the invoke policy, you can specify a "blocklist" where you could specify that the Content-Type header would not be sent to the backend.  If using a v5 compatible Gateway, you'd need to clear message.headers.content-type prior to the invoke policy.
Regards,

Steve Linn

We have a yaml file hosted on API Connect which is sending a Post request to a backend (with no body in the request).  If content-type is sent with any value other than blank, we are returned a 415 Unsupported Media Type.  If I try sending a request through API Connect without specifying a content-type header I am also getting a 415.  Is there a way to specify that no content-type header is needed on the request?  The only way this is successful is if I declare the content-type header and set it to a blank value.  

Thanks Steve.  I tried putting in a blocklist after you suggested this.  So it now throws a 415 whether I include content-type or not.  If I call the backend directly and don't include content-type, I get a 200.  Does API Connect send a content-type header by default?  Even if content-type is included in the blocklist?  

Hi Jeff,
Assuming your using an API Gateway API, in the API, on the invoke policy, you can specify a "blocklist" where you could specify that the Content-Type header would not be sent to the backend.  If using a v5 compatible Gateway, you'd need to clear message.headers.content-type prior to the invoke policy.
Regards,

Steve Linn

We have a yaml file hosted on API Connect which is sending a Post request to a backend (with no body in the request).  If content-type is sent with any value other than blank, we are returned a 415 Unsupported Media Type.  If I try sending a request through API Connect without specifying a content-type header I am also getting a 415.  Is there a way to specify that no content-type header is needed on the request?  The only way this is successful is if I declare the content-type header and set it to a blank value.  

Hi Jeff,
I took a simple API that sends a request to a backend that echos back the request body and headers and then posted a JSON payload with a content-type of application/json to that API.  Without the blocklist on the headers, I see the application/json content-type in my response, but with the blocklist, the content-type header is omitted in my response.  Here's my policy:

  assembly:    execute:      - invoke:          version: 2.0.0          title: invoke          backend-type: detect          header-control:            type: blocklist            values:              - Content-Type          parameter-control:            type: allowlist            values: []          timeout: 60          verb: keep          chunked-uploads: true          persistent-connection: true          target-url: $(target-url)          follow-redirects: false          inject-proxy-headers: true

When you call the backend directly without a Content-Type headers, how are you doing this? curl, postman, soapui?  I've found that these tools tend to inject a content-type request header for you if you don't explicitly provide one. For example curl injects Content-Type: application/x-www-form-urlencoded Are you sure the backend is receiving no content-type header in your direct case?

Best Regards,
Steve Linn

Thanks Steve.  I tried putting in a blocklist after you suggested this.  So it now throws a 415 whether I include content-type or not.  If I call the backend directly and don't include content-type, I get a 200.  Does API Connect send a content-type header by default?  Even if content-type is included in the blocklist?  

Hi Jeff,
Assuming your using an API Gateway API, in the API, on the invoke policy, you can specify a "blocklist" where you could specify that the Content-Type header would not be sent to the backend.  If using a v5 compatible Gateway, you'd need to clear message.headers.content-type prior to the invoke policy.
Regards,

Steve Linn

We have a yaml file hosted on API Connect which is sending a Post request to a backend (with no body in the request).  If content-type is sent with any value other than blank, we are returned a 415 Unsupported Media Type.  If I try sending a request through API Connect without specifying a content-type header I am also getting a 415.  Is there a way to specify that no content-type header is needed on the request?  The only way this is successful is if I declare the content-type header and set it to a blank value.  

Hi Steve.

This is how I have it set:

assembly:
    execute:
    - invoke:
        title: invoke
        version: 2.0.0
        verb: keep
        target-url: $(target-url)/hr-data-contact-center$(api.operation.path)$(request.search)
        follow-redirects: false
        timeout: 60
        parameter-control:
          type: allowlist
          values: []
        header-control:
          type: blocklist
          values:
            - content-type
        inject-proxy-headers: true

I'm testing this via postman requests.  When I switch to the direct backend url.. I am able to remove the content-type header and get a 200 response.  When I do the same via my api connect url I am getting a 415 unsupported media type (also using postman).  

When I have the blocklist piece added, I get a 415 regardless.  When It's not present, I can send content-type with a blank value and it works.  With anything other than blank, I get a 415.  And if I remove it all together, I get a 415.

Hi Jeff,
I took a simple API that sends a request to a backend that echos back the request body and headers and then posted a JSON payload with a content-type of application/json to that API.  Without the blocklist on the headers, I see the application/json content-type in my response, but with the blocklist, the content-type header is omitted in my response.  Here's my policy:

  assembly:    execute:      - invoke:          version: 2.0.0          title: invoke          backend-type: detect          header-control:            type: blocklist            values:              - Content-Type          parameter-control:            type: allowlist            values: []          timeout: 60          verb: keep          chunked-uploads: true          persistent-connection: true          target-url: $(target-url)          follow-redirects: false          inject-proxy-headers: true

When you call the backend directly without a Content-Type headers, how are you doing this? curl, postman, soapui?  I've found that these tools tend to inject a content-type request header for you if you don't explicitly provide one. For example curl injects Content-Type: application/x-www-form-urlencoded Are you sure the backend is receiving no content-type header in your direct case?

Best Regards,
Steve Linn

Thanks Steve.  I tried putting in a blocklist after you suggested this.  So it now throws a 415 whether I include content-type or not.  If I call the backend directly and don't include content-type, I get a 200.  Does API Connect send a content-type header by default?  Even if content-type is included in the blocklist?  

Hi Jeff,
Assuming your using an API Gateway API, in the API, on the invoke policy, you can specify a "blocklist" where you could specify that the Content-Type header would not be sent to the backend.  If using a v5 compatible Gateway, you'd need to clear message.headers.content-type prior to the invoke policy.
Regards,

Steve Linn

We have a yaml file hosted on API Connect which is sending a Post request to a backend (with no body in the request).  If content-type is sent with any value other than blank, we are returned a 415 Unsupported Media Type.  If I try sending a request through API Connect without specifying a content-type header I am also getting a 415.  Is there a way to specify that no content-type header is needed on the request?  The only way this is successful is if I declare the content-type header and set it to a blank value.  

Hi Jeff,
Looking at the definition of a 415

----

The HTTP 415 Unsupported Media Type client error response code indicates that the server refuses to accept the request because the payload format is in an unsupported format.

The format problem might be due to the request's indicated Content-Type or Content-Encoding, or as a result of inspecting the data directly.

----
That makes me suspicious, especially with the second sentence, of inspecting the data directly.  In your case, you do not have a chunked-uploads property on your invoke policy, but if not specified I believe the default gateway behavior is true.  Many backends don't support chunked-uploads and in attempting to read the data get confused with the number of bytes provided in each chunked packet.  Please insert a chunked-uploads: false  in your invoke policy and see if that makes a difference.
Best Regards,

Steve Linn

Hi Steve.

This is how I have it set:

assembly:
    execute:
    - invoke:
        title: invoke
        version: 2.0.0
        verb: keep
        target-url: $(target-url)/hr-data-contact-center$(api.operation.path)$(request.search)
        follow-redirects: false
        timeout: 60
        parameter-control:
          type: allowlist
          values: []
        header-control:
          type: blocklist
          values:
            - content-type
        inject-proxy-headers: true

I'm testing this via postman requests.  When I switch to the direct backend url.. I am able to remove the content-type header and get a 200 response.  When I do the same via my api connect url I am getting a 415 unsupported media type (also using postman).  

When I have the blocklist piece added, I get a 415 regardless.  When It's not present, I can send content-type with a blank value and it works.  With anything other than blank, I get a 415.  And if I remove it all together, I get a 415.

Hi Jeff,
I took a simple API that sends a request to a backend that echos back the request body and headers and then posted a JSON payload with a content-type of application/json to that API.  Without the blocklist on the headers, I see the application/json content-type in my response, but with the blocklist, the content-type header is omitted in my response.  Here's my policy:

  assembly:    execute:      - invoke:          version: 2.0.0          title: invoke          backend-type: detect          header-control:            type: blocklist            values:              - Content-Type          parameter-control:            type: allowlist            values: []          timeout: 60          verb: keep          chunked-uploads: true          persistent-connection: true          target-url: $(target-url)          follow-redirects: false          inject-proxy-headers: true

When you call the backend directly without a Content-Type headers, how are you doing this? curl, postman, soapui?  I've found that these tools tend to inject a content-type request header for you if you don't explicitly provide one. For example curl injects Content-Type: application/x-www-form-urlencoded Are you sure the backend is receiving no content-type header in your direct case?

Best Regards,
Steve Linn

Thanks Steve.  I tried putting in a blocklist after you suggested this.  So it now throws a 415 whether I include content-type or not.  If I call the backend directly and don't include content-type, I get a 200.  Does API Connect send a content-type header by default?  Even if content-type is included in the blocklist?  

Hi Jeff,
Assuming your using an API Gateway API, in the API, on the invoke policy, you can specify a "blocklist" where you could specify that the Content-Type header would not be sent to the backend.  If using a v5 compatible Gateway, you'd need to clear message.headers.content-type prior to the invoke policy.
Regards,

Steve Linn

We have a yaml file hosted on API Connect which is sending a Post request to a backend (with no body in the request).  If content-type is sent with any value other than blank, we are returned a 415 Unsupported Media Type.  If I try sending a request through API Connect without specifying a content-type header I am also getting a 415.  Is there a way to specify that no content-type header is needed on the request?  The only way this is successful is if I declare the content-type header and set it to a blank value.  

Hi Steve.

I tried adding chunked-uploads: false, but still see the same behavior.  If I run the same request directly to the back end using postman as well it works if I uncheck content-type as a header, or if I send content-type with a blank value.  When I go through API Connect, it works if I send content-type with a blank value, but if I attempt to not send it as a header, I still get a 415.  So, I guess the question is, when going through API Connect, does it always send content-type regardless?  

Hi Jeff,
Looking at the definition of a 415

----

The HTTP 415 Unsupported Media Type client error response code indicates that the server refuses to accept the request because the payload format is in an unsupported format.

The format problem might be due to the request's indicated Content-Type or Content-Encoding, or as a result of inspecting the data directly.

----
That makes me suspicious, especially with the second sentence, of inspecting the data directly.  In your case, you do not have a chunked-uploads property on your invoke policy, but if not specified I believe the default gateway behavior is true.  Many backends don't support chunked-uploads and in attempting to read the data get confused with the number of bytes provided in each chunked packet.  Please insert a chunked-uploads: false  in your invoke policy and see if that makes a difference.
Best Regards,

Steve Linn

Hi Steve.

This is how I have it set:

assembly:
    execute:
    - invoke:
        title: invoke
        version: 2.0.0
        verb: keep
        target-url: $(target-url)/hr-data-contact-center$(api.operation.path)$(request.search)
        follow-redirects: false
        timeout: 60
        parameter-control:
          type: allowlist
          values: []
        header-control:
          type: blocklist
          values:
            - content-type
        inject-proxy-headers: true

I'm testing this via postman requests.  When I switch to the direct backend url.. I am able to remove the content-type header and get a 200 response.  When I do the same via my api connect url I am getting a 415 unsupported media type (also using postman).  

When I have the blocklist piece added, I get a 415 regardless.  When It's not present, I can send content-type with a blank value and it works.  With anything other than blank, I get a 415.  And if I remove it all together, I get a 415.

Hi Jeff,
I took a simple API that sends a request to a backend that echos back the request body and headers and then posted a JSON payload with a content-type of application/json to that API.  Without the blocklist on the headers, I see the application/json content-type in my response, but with the blocklist, the content-type header is omitted in my response.  Here's my policy:

  assembly:    execute:      - invoke:          version: 2.0.0          title: invoke          backend-type: detect          header-control:            type: blocklist            values:              - Content-Type          parameter-control:            type: allowlist            values: []          timeout: 60          verb: keep          chunked-uploads: true          persistent-connection: true          target-url: $(target-url)          follow-redirects: false          inject-proxy-headers: true

When you call the backend directly without a Content-Type headers, how are you doing this? curl, postman, soapui?  I've found that these tools tend to inject a content-type request header for you if you don't explicitly provide one. For example curl injects Content-Type: application/x-www-form-urlencoded Are you sure the backend is receiving no content-type header in your direct case?

Best Regards,
Steve Linn

Thanks Steve.  I tried putting in a blocklist after you suggested this.  So it now throws a 415 whether I include content-type or not.  If I call the backend directly and don't include content-type, I get a 200.  Does API Connect send a content-type header by default?  Even if content-type is included in the blocklist?  

Hi Jeff,
Assuming your using an API Gateway API, in the API, on the invoke policy, you can specify a "blocklist" where you could specify that the Content-Type header would not be sent to the backend.  If using a v5 compatible Gateway, you'd need to clear message.headers.content-type prior to the invoke policy.
Regards,

Steve Linn

We have a yaml file hosted on API Connect which is sending a Post request to a backend (with no body in the request).  If content-type is sent with any value other than blank, we are returned a 415 Unsupported Media Type.  If I try sending a request through API Connect without specifying a content-type header I am also getting a 415.  Is there a way to specify that no content-type header is needed on the request?  The only way this is successful is if I declare the content-type header and set it to a blank value.  

Hi Jeff, 
This must not be my day as your issue is another one today where I can't recreate anything with my simple testing that would help shed light on any root cause.  I took your invoke policy that you posted earlier, and added chunked-uploads: false.  I changed the target-url to be my backend server, which is a DataPower service, and enabled the DataPower probe so I can see what is being sent to that service.  For the request headers, my backend is receiving a Content-Length header, which would validate that the chunked uploads is disabled, otherwise I'd have seen the Transfer-Encoding header with a value of chunked.  I also have your header-control with a blocklist of content-type, and when my API receives a POST with content-type, my backend does not receive a content-type header, so to answer your question, no, the content-type header is not being sent regardless.  There has to be something else different from when you send your request from Postman.

As with the other issue I looked at today I'd suggest you open a PMR case on the issue.  You should provide a copy of your API yaml file and DataPower debug logs showing the flow of the transaction.  If you have a physical / virtual DataPower appliance, providing a packet capture in the PMR data of traffic to your backend (filtered by the host IP of the backend server), would be very useful. If you can get the DataPower packet capture, please enable the TLS session keys option as well if your backend url is https so the encrypted traffic can be decrypted and the raw request data can be seen.  If you have a Kubernetes DataPower pod, packet captures are not done from DataPower but from the host machine which I've never done before.  L2 support will be able to assist you in getting these packet captures in the Kubernetes case.

Best Regards,
Steve Linn

Hi Steve.

I tried adding chunked-uploads: false, but still see the same behavior.  If I run the same request directly to the back end using postman as well it works if I uncheck content-type as a header, or if I send content-type with a blank value.  When I go through API Connect, it works if I send content-type with a blank value, but if I attempt to not send it as a header, I still get a 415.  So, I guess the question is, when going through API Connect, does it always send content-type regardless?  

Hi Jeff,
Looking at the definition of a 415

----

The HTTP 415 Unsupported Media Type client error response code indicates that the server refuses to accept the request because the payload format is in an unsupported format.

The format problem might be due to the request's indicated Content-Type or Content-Encoding, or as a result of inspecting the data directly.

----
That makes me suspicious, especially with the second sentence, of inspecting the data directly.  In your case, you do not have a chunked-uploads property on your invoke policy, but if not specified I believe the default gateway behavior is true.  Many backends don't support chunked-uploads and in attempting to read the data get confused with the number of bytes provided in each chunked packet.  Please insert a chunked-uploads: false  in your invoke policy and see if that makes a difference.
Best Regards,

Steve Linn

Hi Steve.

This is how I have it set:

assembly:
    execute:
    - invoke:
        title: invoke
        version: 2.0.0
        verb: keep
        target-url: $(target-url)/hr-data-contact-center$(api.operation.path)$(request.search)
        follow-redirects: false
        timeout: 60
        parameter-control:
          type: allowlist
          values: []
        header-control:
          type: blocklist
          values:
            - content-type
        inject-proxy-headers: true

I'm testing this via postman requests.  When I switch to the direct backend url.. I am able to remove the content-type header and get a 200 response.  When I do the same via my api connect url I am getting a 415 unsupported media type (also using postman).  

When I have the blocklist piece added, I get a 415 regardless.  When It's not present, I can send content-type with a blank value and it works.  With anything other than blank, I get a 415.  And if I remove it all together, I get a 415.

Hi Jeff,
I took a simple API that sends a request to a backend that echos back the request body and headers and then posted a JSON payload with a content-type of application/json to that API.  Without the blocklist on the headers, I see the application/json content-type in my response, but with the blocklist, the content-type header is omitted in my response.  Here's my policy:

  assembly:    execute:      - invoke:          version: 2.0.0          title: invoke          backend-type: detect          header-control:            type: blocklist            values:              - Content-Type          parameter-control:            type: allowlist            values: []          timeout: 60          verb: keep          chunked-uploads: true          persistent-connection: true          target-url: $(target-url)          follow-redirects: false          inject-proxy-headers: true

When you call the backend directly without a Content-Type headers, how are you doing this? curl, postman, soapui?  I've found that these tools tend to inject a content-type request header for you if you don't explicitly provide one. For example curl injects Content-Type: application/x-www-form-urlencoded Are you sure the backend is receiving no content-type header in your direct case?

Best Regards,
Steve Linn

Thanks Steve.  I tried putting in a blocklist after you suggested this.  So it now throws a 415 whether I include content-type or not.  If I call the backend directly and don't include content-type, I get a 200.  Does API Connect send a content-type header by default?  Even if content-type is included in the blocklist?  

Hi Jeff,
Assuming your using an API Gateway API, in the API, on the invoke policy, you can specify a "blocklist" where you could specify that the Content-Type header would not be sent to the backend.  If using a v5 compatible Gateway, you'd need to clear message.headers.content-type prior to the invoke policy.
Regards,

Steve Linn

We have a yaml file hosted on API Connect which is sending a Post request to a backend (with no body in the request).  If content-type is sent with any value other than blank, we are returned a 415 Unsupported Media Type.  If I try sending a request through API Connect without specifying a content-type header I am also getting a 415.  Is there a way to specify that no content-type header is needed on the request?  The only way this is successful is if I declare the content-type header and set it to a blank value.  

Thanks Steve.  The more I thought about it, and how it worked when I sent content-type with a blank header, I ended up adding a gatewayscript to do just that.  Set content-type to a blank value, and that did the trick.  

Hi Jeff, 
This must not be my day as your issue is another one today where I can't recreate anything with my simple testing that would help shed light on any root cause.  I took your invoke policy that you posted earlier, and added chunked-uploads: false.  I changed the target-url to be my backend server, which is a DataPower service, and enabled the DataPower probe so I can see what is being sent to that service.  For the request headers, my backend is receiving a Content-Length header, which would validate that the chunked uploads is disabled, otherwise I'd have seen the Transfer-Encoding header with a value of chunked.  I also have your header-control with a blocklist of content-type, and when my API receives a POST with content-type, my backend does not receive a content-type header, so to answer your question, no, the content-type header is not being sent regardless.  There has to be something else different from when you send your request from Postman.

As with the other issue I looked at today I'd suggest you open a PMR case on the issue.  You should provide a copy of your API yaml file and DataPower debug logs showing the flow of the transaction.  If you have a physical / virtual DataPower appliance, providing a packet capture in the PMR data of traffic to your backend (filtered by the host IP of the backend server), would be very useful. If you can get the DataPower packet capture, please enable the TLS session keys option as well if your backend url is https so the encrypted traffic can be decrypted and the raw request data can be seen.  If you have a Kubernetes DataPower pod, packet captures are not done from DataPower but from the host machine which I've never done before.  L2 support will be able to assist you in getting these packet captures in the Kubernetes case.

Best Regards,
Steve Linn

Hi Steve.

I tried adding chunked-uploads: false, but still see the same behavior.  If I run the same request directly to the back end using postman as well it works if I uncheck content-type as a header, or if I send content-type with a blank value.  When I go through API Connect, it works if I send content-type with a blank value, but if I attempt to not send it as a header, I still get a 415.  So, I guess the question is, when going through API Connect, does it always send content-type regardless?  

Hi Jeff,
Looking at the definition of a 415

----

The HTTP 415 Unsupported Media Type client error response code indicates that the server refuses to accept the request because the payload format is in an unsupported format.

The format problem might be due to the request's indicated Content-Type or Content-Encoding, or as a result of inspecting the data directly.

----
That makes me suspicious, especially with the second sentence, of inspecting the data directly.  In your case, you do not have a chunked-uploads property on your invoke policy, but if not specified I believe the default gateway behavior is true.  Many backends don't support chunked-uploads and in attempting to read the data get confused with the number of bytes provided in each chunked packet.  Please insert a chunked-uploads: false  in your invoke policy and see if that makes a difference.
Best Regards,

Steve Linn

Hi Steve.

This is how I have it set:

assembly:
    execute:
    - invoke:
        title: invoke
        version: 2.0.0
        verb: keep
        target-url: $(target-url)/hr-data-contact-center$(api.operation.path)$(request.search)
        follow-redirects: false
        timeout: 60
        parameter-control:
          type: allowlist
          values: []
        header-control:
          type: blocklist
          values:
            - content-type
        inject-proxy-headers: true

I'm testing this via postman requests.  When I switch to the direct backend url.. I am able to remove the content-type header and get a 200 response.  When I do the same via my api connect url I am getting a 415 unsupported media type (also using postman).  

When I have the blocklist piece added, I get a 415 regardless.  When It's not present, I can send content-type with a blank value and it works.  With anything other than blank, I get a 415.  And if I remove it all together, I get a 415.

Hi Jeff,
I took a simple API that sends a request to a backend that echos back the request body and headers and then posted a JSON payload with a content-type of application/json to that API.  Without the blocklist on the headers, I see the application/json content-type in my response, but with the blocklist, the content-type header is omitted in my response.  Here's my policy:

  assembly:    execute:      - invoke:          version: 2.0.0          title: invoke          backend-type: detect          header-control:            type: blocklist            values:              - Content-Type          parameter-control:            type: allowlist            values: []          timeout: 60          verb: keep          chunked-uploads: true          persistent-connection: true          target-url: $(target-url)          follow-redirects: false          inject-proxy-headers: true

When you call the backend directly without a Content-Type headers, how are you doing this? curl, postman, soapui?  I've found that these tools tend to inject a content-type request header for you if you don't explicitly provide one. For example curl injects Content-Type: application/x-www-form-urlencoded Are you sure the backend is receiving no content-type header in your direct case?

Best Regards,
Steve Linn

Thanks Steve.  I tried putting in a blocklist after you suggested this.  So it now throws a 415 whether I include content-type or not.  If I call the backend directly and don't include content-type, I get a 200.  Does API Connect send a content-type header by default?  Even if content-type is included in the blocklist?  

Hi Jeff,
Assuming your using an API Gateway API, in the API, on the invoke policy, you can specify a "blocklist" where you could specify that the Content-Type header would not be sent to the backend.  If using a v5 compatible Gateway, you'd need to clear message.headers.content-type prior to the invoke policy.
Regards,

Steve Linn

We have a yaml file hosted on API Connect which is sending a Post request to a backend (with no body in the request).  If content-type is sent with any value other than blank, we are returned a 415 Unsupported Media Type.  If I try sending a request through API Connect without specifying a content-type header I am also getting a 415.  Is there a way to specify that no content-type header is needed on the request?  The only way this is successful is if I declare the content-type header and set it to a blank value.  

Hi Jeff,
I'm glad you got this working!  Just for my own education here, you were setting the content-type header to an empty string or to a string with one space character?
Thanks,
Steve Linn

Thanks Steve.  The more I thought about it, and how it worked when I sent content-type with a blank header, I ended up adding a gatewayscript to do just that.  Set content-type to a blank value, and that did the trick.  

Hi Jeff, 
This must not be my day as your issue is another one today where I can't recreate anything with my simple testing that would help shed light on any root cause.  I took your invoke policy that you posted earlier, and added chunked-uploads: false.  I changed the target-url to be my backend server, which is a DataPower service, and enabled the DataPower probe so I can see what is being sent to that service.  For the request headers, my backend is receiving a Content-Length header, which would validate that the chunked uploads is disabled, otherwise I'd have seen the Transfer-Encoding header with a value of chunked.  I also have your header-control with a blocklist of content-type, and when my API receives a POST with content-type, my backend does not receive a content-type header, so to answer your question, no, the content-type header is not being sent regardless.  There has to be something else different from when you send your request from Postman.

As with the other issue I looked at today I'd suggest you open a PMR case on the issue.  You should provide a copy of your API yaml file and DataPower debug logs showing the flow of the transaction.  If you have a physical / virtual DataPower appliance, providing a packet capture in the PMR data of traffic to your backend (filtered by the host IP of the backend server), would be very useful. If you can get the DataPower packet capture, please enable the TLS session keys option as well if your backend url is https so the encrypted traffic can be decrypted and the raw request data can be seen.  If you have a Kubernetes DataPower pod, packet captures are not done from DataPower but from the host machine which I've never done before.  L2 support will be able to assist you in getting these packet captures in the Kubernetes case.

Best Regards,
Steve Linn

Hi Steve.

I tried adding chunked-uploads: false, but still see the same behavior.  If I run the same request directly to the back end using postman as well it works if I uncheck content-type as a header, or if I send content-type with a blank value.  When I go through API Connect, it works if I send content-type with a blank value, but if I attempt to not send it as a header, I still get a 415.  So, I guess the question is, when going through API Connect, does it always send content-type regardless?  

Hi Jeff,
Looking at the definition of a 415

----

The HTTP 415 Unsupported Media Type client error response code indicates that the server refuses to accept the request because the payload format is in an unsupported format.

The format problem might be due to the request's indicated Content-Type or Content-Encoding, or as a result of inspecting the data directly.

----
That makes me suspicious, especially with the second sentence, of inspecting the data directly.  In your case, you do not have a chunked-uploads property on your invoke policy, but if not specified I believe the default gateway behavior is true.  Many backends don't support chunked-uploads and in attempting to read the data get confused with the number of bytes provided in each chunked packet.  Please insert a chunked-uploads: false  in your invoke policy and see if that makes a difference.
Best Regards,

Steve Linn

Hi Steve.

This is how I have it set:

assembly:
    execute:
    - invoke:
        title: invoke
        version: 2.0.0
        verb: keep
        target-url: $(target-url)/hr-data-contact-center$(api.operation.path)$(request.search)
        follow-redirects: false
        timeout: 60
        parameter-control:
          type: allowlist
          values: []
        header-control:
          type: blocklist
          values:
            - content-type
        inject-proxy-headers: true

I'm testing this via postman requests.  When I switch to the direct backend url.. I am able to remove the content-type header and get a 200 response.  When I do the same via my api connect url I am getting a 415 unsupported media type (also using postman).  

When I have the blocklist piece added, I get a 415 regardless.  When It's not present, I can send content-type with a blank value and it works.  With anything other than blank, I get a 415.  And if I remove it all together, I get a 415.

Hi Jeff,
I took a simple API that sends a request to a backend that echos back the request body and headers and then posted a JSON payload with a content-type of application/json to that API.  Without the blocklist on the headers, I see the application/json content-type in my response, but with the blocklist, the content-type header is omitted in my response.  Here's my policy:

  assembly:    execute:      - invoke:          version: 2.0.0          title: invoke          backend-type: detect          header-control:            type: blocklist            values:              - Content-Type          parameter-control:            type: allowlist            values: []          timeout: 60          verb: keep          chunked-uploads: true          persistent-connection: true          target-url: $(target-url)          follow-redirects: false          inject-proxy-headers: true

When you call the backend directly without a Content-Type headers, how are you doing this? curl, postman, soapui?  I've found that these tools tend to inject a content-type request header for you if you don't explicitly provide one. For example curl injects Content-Type: application/x-www-form-urlencoded Are you sure the backend is receiving no content-type header in your direct case?

Best Regards,
Steve Linn

Thanks Steve.  I tried putting in a blocklist after you suggested this.  So it now throws a 415 whether I include content-type or not.  If I call the backend directly and don't include content-type, I get a 200.  Does API Connect send a content-type header by default?  Even if content-type is included in the blocklist?  

Hi Jeff,
Assuming your using an API Gateway API, in the API, on the invoke policy, you can specify a "blocklist" where you could specify that the Content-Type header would not be sent to the backend.  If using a v5 compatible Gateway, you'd need to clear message.headers.content-type prior to the invoke policy.
Regards,

Steve Linn

We have a yaml file hosted on API Connect which is sending a Post request to a backend (with no body in the request).  If content-type is sent with any value other than blank, we are returned a 415 Unsupported Media Type.  If I try sending a request through API Connect without specifying a content-type header I am also getting a 415.  Is there a way to specify that no content-type header is needed on the request?  The only way this is successful is if I declare the content-type header and set it to a blank value.