Forum Discussion

Doug_53924's avatar
Doug_53924
Icon for Nimbostratus rankNimbostratus
Mar 31, 2010

JSP code in hidden frame is not working

I am new to F5 so here goes. We are trying to use F5 to load balance JVMs that are configured on WebLogic. It appears that the application (Maximo) has a link to JSP code that is in a hidden field. Using IE watch we discovered that F5 was not processing the following HTTP GET correctly.

 

 

GET /maximo/webclient/common/hiddenframe.jsp?sc=1269969429832 HTTP/1.1

 

 

I am sure there is an iRule that can address this. Is there a way to resolve this problem with a profile setting?

 

 

This a message that IE Watch intercepted was:

 

 

 

 

Error 500--Internal Server Error

 

 

 

 

 

 

 

Error 500--Internal Server Error

 

 

 

From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1: 10.5.1 500 Internal Server Error The server encountered an unexpected condition which prevented it from fulfilling the request.

 

 

 

 

 

config
design

2 Replies

Sort By
  • L4L7_53191's avatar
    L4L7_53191
    Icon for Nimbostratus rankNimbostratus
    Mar 31, 2010
    I'm not sure (based on the info above) that we can definitively say there's an issue here. A 500 error is a valid response, albeit not ideal. Have you run a capture on the 'backside' network as the request is headed to WebLogic? Also, could you post some of the stack trace from the app server logs?

     

     

    The error above looks related to HTTP 1.1 somehow. Without active intervention the LTM won't interfere with this. Also, your GET above does not specify a Host: header, which is usually required for most application containers. That may be a good place to start if you've not done so already.

     

     

    -Matt
  • Jason_Keating's avatar
    Jason_Keating
    Icon for Altostratus rankAltostratus
    Mar 31, 2010
    Yeah, I'd say that WLS is throwing that 500, in your response the " " gives it away.

     

     

    The F5 is not generating the error, simply passing it back to you as it should.

     

     

    Assuming you can point a browser or some other client at WLS (curl, netcat, telnet ...) and do not get this error when sending the request direct to WLS you should compare the request passed by your browser to WLS (when not using the LTM) to the request passed by the LTM to WLS (when using the LTM)

     

     

    If you do get the error when GET'ing from WLS with no LTM - look to WLS.