I have a CSS (WebNS 8.20.5.01) in front of an Apache server which is the front end to Oracle Fusion SOA.
When a web browser connects directly to the Apache server using HTTP on port 41778, and submits a POST for a transaction, the client receves a 200 OK response with the result.
Now, put the CSS in the middle, listening on port 80, and proxying (via a group and a defined destination service) to the Apache server on 41778. No other changes. CSS is configured to use arrowpoint-cookie advanced balancing for persistence since with a browser there are multiple TCP sessions made to authenticate, select the service, and then submit the transaction.
Packet captures on both the input and output of the CSS show:
The POST comes in from the browser to the CSS, and the CSS sends out an identical POST transaction to the webserver. Then the CSS sends out another POST that's slightly different to the server (it's a SOAP message), even though the browser hasn't sent any additional packets. The webserver sends out a 202 to the second POST, and then sends the 200 response to the first POST. Only the 200 response gets sent back to the client.
What I cannot figure out is where this second POST is coming from. It's NOT coming from the browser. It's not coming in response to anything the server sent back. The only thing I can think of is the CSS is reading/processing the first POST and generating the second POST from it. I didn't think the CSS did this sort of thing.
This is indeed strange. If you are 100% sure of your findings then i would suggest collecting all the information and opening a TAC case for further investigation.
What made you take the pcaps? Did you face any issues because of this POST getting generated?
Normally CSS will not generate POST on its own. The second POST it geenrated belonged to same TCP connection as first POST or was different?
We took the captures (using our NAM) because when we run a scenario where we put SSL in the front of it (Browser-HTTPS-CSS-HTTP-Apache) we do get an error message back, and in that case we get the "extra" POST twice.
I am sure of what I saw because it is two separate TCP sessions for the two POSTS on the back end.
It really looks as though the CSS is somehow reading the first POST message from the browser and generating the second POST message on its own after passing the first along.
All open a TAC case as soon as my reseller (who I'm tempted to blacklist here) gets the maintenance contract on the chassis updated.
This sounds like a known issue on this software version , I'll recommend you to open a TAC case to check the captures and the configuration.