Forum Discussion
4 Replies
- Joe_PruittCirrostratus
@rwsalisbury, looks like you omitted the response you were going to add. Not quite sure what could cause the BIG-IP to return a JavaScript validation error. Could it be that something in your application is looking at the user agent passed through with SoapUI? Is there any way to override the User-Agent HTTP header sent from SoapUI? It could be your web framework is blocking the app. You might try setting the User-Agent string to Firefox or Chrome's default values:
Preferences | Working with SOAPUI - http://www.soapui.org/working-with-soapui/reference/preferences-and-settings.htmlHTTP-Settings
FireFox User Agent Strings : http://www.useragentstring.com/pages/Firefox/
-Joe
- rwsalisbury_191NimbostratusDecided not to post the full response received by SoapUI because it is too much detail. What we have found is that even though the SSL Termination is working fine for HTTP GETs, when a client sends an HTTP POST, BigIP redirects the client to the /my.policy page. And we just want BigIP to pass the POST through to the back-end server just like it does the HTTP GETs. The POSTs happen to be SOAP requests for the back-end server to handle, so the server needs to see the entire original request. And the client is a non-browser application, so there is no smart browser or person to deal with the form that BigIP sends back to the client. This redirect by BigIP did not occur before we implemented SSL Termination. So here are our current questions: (1) why does BigIP send a HTTP 301 redirect back to the client when it sees an HTTP POST? (2) How can we stop it from doing that? Thank you for any thoughts or ideas you can share. Richard
- rwsalisbury_191Nimbostratus
This was what was happening and how we resolved it:
The load balancer and the back-end server were not able to agree on a cipher to use for the SSL handshake, so BigIP sent the redirect back to the client.
After we enabled a cipher on the server that BigIP was using, the SSL handshake completed successfully, no redirection occurred, the HTTP POST went through to the server successfully, and a normal response was returned to the client.
- rwsalisbury_191NimbostratusBtw, I used the term "SSL Termination" in this issue, but should have been using the term "SSL Bridging", since we were required to have SSL between the load balancer and the server, as well as between the client and the load balancer.