LTM VS padding payload response with whitespaces and asterisk

Forums Technical Forums
, ,
1

I have an application that talks to an old OpenVMS system, which was problematic in permanently closing TCP connections. To resolve this issue, I have put a BIG-IP Virtual Server in between them, so the message flow is now:

webMethods --> BIG-IP LTM --> OpenVMS server

This has resolved the TCP connection issue, and I thought everything was good.

However, the application sends XML, and the VMS system responds with the XML payload.

For some reason, BIG-IP is padding the response with lots whitespaces and one asterisk *

The webMethods server does not expect the * in the response and fails to process the response to the client (who originally sent the XML).

So why is BIG-IP adding the * to the response payload?

I’ve included a WireShark trace image, which shows the BIG-IP VS 10.1.4.170 responding to the webMethods server 10.1.4.225, with the payload, including lots of HEX 20 (whitespace) and one * at the end.

My VS configuration uses Type Standard with all the defaults, except, of course, that I’ve configured the Destination Address and Service Port (3012) and added a Pool.

The closes F5 article I have found is this one:

K44201501: BIG-IP is padding HTTP response with additional whitespaces

However, I don’t have Analytics configured on this VS, and I don’t have Application Visibility and Reporting (AVR) provisioned. So, this doesn’t apply, but it’s a similar issue.

2

do you have http profile assigned into the vserver?

and change decoding to HTTP in tcpdump so we can see the http headers and payload.

3

Hi zamroni777

Thanks for your reply.

My post took a few days to publish, and I was trying to find a way to delete my post.

A Developer informed me of this issue (padding with many whitespaces and one asterisk ), and I could see the behaviour in the TCPdump. However, when doing a TCPdump on the OpenVMS server and bypassing BIG-IP, I saw the same behaviour, so BIG-IP is not adding this asterisk; it’s always been there. I compared the traces, and they were the same, so I was misinformed by the Developer.

Thanks for taking the time to respond.