SOAP Response message for http status in header is blank with FQDN URL

[Sajeela]

Hi Team,

 

We have an integration between Clarity application and an external system, WFI. WFI uses Other work write XML to create other works in Clarity upon a work flow approval in WFI. Once they receive response from Clarity, they mark their request status as closed. They use httpConn.getResponseMessage(); parameter from SOAP header to determine the closure of the request. When this integration was in place with Clarity version 13.3, they used to get 'OK' as the response for the mentioned parameter. We upgraded our environment from 13.3 to 15.2 last week. With WFI integration, they are able to create the Other work in Clarity, but they are not getting the response message for that particular parameter. They use Fully Qualified Domain name URL as endpoint URL and with HTTP connection.

For testing purpose, we tried with ip address URL, and we are receiving the message as 'OK', but with fully qualified domain name URL, we don't receive the message (but we receive the Success Message from XOG response though in both the cases). They are challenging on why there is no response for the httpConn.getResponseMessage(); using FQDN URL for 15.2 version. Can you please help me in understanding why there is a difference in response message in header with ip address URL and with FQDN URL?

We also tested this with SOAP UI.

Environment set up details:

- Load Balancer is enabled (Certificate applied) without sticky session.

- 2 application servers are available (No certificate applied)

- Both HTPS and HTTP are enabled

- WFI is using HTTP URL (which is one of the 2 application server URL)

We are able to replicate the same issue in UAT environment, which has 1 application server, HTTPS and HTTP enabled, and no Load Balancer.

[Nick Darlington]

I don't believe PPM will include/exclude the HTTP response header on the basis of the host: header value used.

 

So I would be more inclined to suspect that the device/appliance routing the requests to PPM when that URL is used may also be rewriting the responses on the way back and somehow leaving that off.

 

If you're using HTTP at the PPM end, then setup Wireshark or (if unix) tcpdump and capture the traffic.

 

Then make the requests both using FQDN and the other name, and compare the responses.

 

If you can get this setup inbetween PPM and any load balancers / SSL offloaders / proxies to read the raw output coming from PPM, and you do not see the header being stripped, something else downstream on the way back to the client has to be doing it.

 

If you do see it stripped still, I will be very interested but suggest you raise a support ticket at that point to investigate further if you can.

[Sajeela]

Hi Nick,

 

Thank you for the response. Sorry, couldn't reply on this immediately. 

Actually, in my original request, I need to correct something. Responses from the FQDN and ip address URL are the same. Header information doesn't show the Message 'OK ' in version 15.2 Clarity. But in 13.3, we used to receive this message in Soap header.

 

I checked in Tomcat communities and found that earlier versions of Tomcat used to send the response header message, but newer versions of Tomcat from 8.5.x, Reason Phrase is removed.

 

We've informed this message to concerned team and they are using Code now instead of Message.

 

Thank you so much for responding.

Kind Regars,

Sajeela.