content-length is showing less and backend throwing 4XX error

[rajkalgur]

HI,

I have a APIGEE url where it is invoked by different clients. endpoint is working is for all other clients except for tibco(applications are running on Tibco BW)

when i debug, i could see full payload when APIGEE received but content-length is showing wrong. 

any thoughts?

Thanks,

Raj

[dchiesa1]

Hi

I'm sure people would like to help you, but you're not providing enough information on the problem. 

---

@rajkalgur wrote:

when i debug, i could see full payload when APIGEE received but content-length is showing wrong. 

---

received from what?  from the client?  From the upstream?   Apigee receives inbound requests from clients, then proxies to an upstream, and then again receives responses from the upstream.  Which "receive" part are you having trouble with?

If you can use Apigee debug/trace on the requests that succeed, and the ones that fail, you should be able to analyze them and look for differences. What conclusions can you draw? What observations can you share?   

[rajkalgur]

1st image refers, request payload i received from client.

here is the curl command i captured from same debug screen.

I am not seeing any issue with the payload. when a client hits a request, here is the response from target server. 

however, if i run the curl command or hit from the postman with same payload, i am getting the success response from target backend. 

i am stuck here and not sure where is the issue.

[dchiesa1]

If I were looking at this, I would examine the differences between the messages arriving at Apigee, comparing the messages that originate from TIBCO (the ones that fail), with the messages that originate from "elsewhere" (the ones that succeed). Maybe there is a different header, or the payload is different, etc. 

[rajkalgur]

Thanks Dino. I see few differences. Authorization header is added for failed ones. Where as auth header is not added for successful requests. I am not adding any auth headers on apigee side. I am checking further with application teams. 

[dchiesa1]

You can configure Apigee to remove the Authorization header, or any header.

This is common when using Apigee for security mediation.  Maybe the inbound uses an application-layer security token, passed in the Authorization header, while Apigee connects to the upstream using 2-way TLS for authentication + authorization. In that case, the header that the client passes to Apigee should not be relayed to the upstream system.  Normally you'd use a VerifyAccessToken or VerifyAPIKey policy in Apigee on the request flow, and then use AssignMessage with Remove/Headers to remove the inbound Auth header before Apigee proxies to the upstream.

<AssignMessage name='AM-Clean-Auth-Header'>
  <Remove>
    <Headers>
      <Header name='Authorization'/>
    </Headers>
  </Remove>
</AssignMessage>

You might try that. Although, the error message from the upstream system in your case does not suggest "you've passed an Authorization header I was not expecting."  But it's good hygiene anyway.

[rajkalgur]

Thank you. I removed authorization header and it is not passing over to target endpoint.

on both success and failure scenarios, i do not see any difference in payload. somehow request payload which is coming from tibco client is failing with 4XX which means bad payload or not passing payload to target whereas request coming from postman is getting success.

below are the screenshots for success vs failure scenarios

Failure:

Success:

[dchiesa1]

Your'e focusing on the payload, and the payloads appear to be the same. 

To be sure I would want to look at the debugsession file itself, either a JSON or XML download, and compare the payloads as shown in that session file. I learned recently about Unicode U+200B, the so-called "Zero width space".  This is an actual character which , when rendered, is expected to take up no width. By definition, you cannot see it, in a display on a webpage, such as the one showing the debug session.  You can only see this character if you view the encoding of a string which contains it.  The downloaded debugsession file would show it.  If a character like this is embedded in some json, it might cause a JSON parser to fail to parse. Which might result in the error you are seeing: "not enough parameterS" or somehting like that. 

Am I suggesting there is a zero width space in the payload of the request that originates from Tibco? No. I'm suggesting that there may be a difference between the pass and fail scenarios that you cannot perceive just looking at the  UI.  It could be a newline, or some other character in the payload which does not get rendered in the HTML of the debug screen.  So I would check there. 

If I were you I would also look at the other parts of the message - the headers. You already know it's the same verb  (POST). Are the headers different in any way? Again look in the debugsession download - a hidden character would show up there and might not show up in the UI. 

[rajkalgur]

Hi,

I downloaded both success and failure debugging sessions. only difference observed content-length is coming blank with failed scenario. I can see the content but request.header.content-length is showing as blank. please refer screenshots below. I would like highlight, the same APIGEE endpoint is working for all other clients and it is already deployed in production. 

Note: it is working. if tibco uses existing broadcomm layer7 endpoint.

Failure: from Tibco 

Success: from postman