URGENT - How to capture invalid request object if VSM failing at HTTP Listen Step( java.lang.IllegalArgumentException)

[vinit.malhotra]

Hello All,

 

I am facing a challenge in my project. Application is sending request to HTTP service of lisa developed in 7.5 Version. Its a simple service with 1 Request Response pair.

Sometimes application is sending correct request and we are able to respond, sometimes we are getting error at HTTP/Listen step as mentioned below.

 

Application team can see proper XML in their application logs and they are saying its not their fault, there is some fault in lisa service. But We can clearly see that something didnt came proper to lisa thats why we got below mentioned error.

 

Support :- I need to know is there a way i can capture what reached to service? I cant see anything in the LISA server logs. I need to capture what is coming to our service which is causing this failure so that we can proove that their application is not sending correct well formed request object to us. 

 

Since the step is failing at listen step only and then test is aborted, I cant run any filter to capture the request object. Shall i create service on Dev test 9.5, will it help me to capture in some different manner? Not sure what needs to be done here.

============================================================================
| java.lang.IllegalArgumentException: Incoming request is not HTTP.
============================================================================
| Step:        HTTP/S Listen
----------------------------------------------------------------------------
| Message:     Incoming request is not HTTP.
----------------------------------------------------------------------------
| Trapped Exception: Incoming request is not HTTP.
| Trapped Message:   java.lang.IllegalArgumentException: Incoming request is not HTTP.

[vinit.malhotra]

J_NeSmith Can you please advice here. Its kind of urgent. Thanks

[Legacy User]

I do not know if I am going to help to you on this question. If possible, I recommend upgrading to 9.5x and opening a support case. The support team may have access to information and tools that I do not. It is also likely that someone will need to Webex with you to review the error you are seeing in order to provide a better diagnosis.

 

Obviously, the exception indicates that DevTest does not recognize something about a given incoming request as being valid within the context of the HTTP 1.1 specification. I have seen this type of exception when a port scanning tool sends a malformed HTTP request in an attempt to breach an http server. I doubt this is your case though. 

 

This exception is most likely trapped in the transport layer of DevTest. I do not believe that 9.5x is going to provide significantly more information in the logs unless you turn on debug mode. 

 

 

If you are able to recreate the exception, you might explore these options:

1) Set logging.properties to debug mode. However, if you are unable to recreate the exception on demand, turning on debug mode could cause a significant amount of output to fill the logs rather quickly.

 

2) Use a tcp packet capture tool on the server running VSE to review the raw incoming request connection and information at the network boundary before DevTest has a chance to process the HTTP request.  

 

3) Probably a long shot... Run the service in ITR mode on Workstation. Have the consumer send a few requests and see if you can trap any additional information. It might be worth viewing the content of lisa.vse.http.current.transaction, lisa.vse.http.current.transaction.body, lisa.vse.http.current.transaction.raw, although these properties may contain the actual transaction object rather than string data.

 

4) Try setting up a DevTest recorder between the consumer and the virtual service. The idea here is to see if the recorder fails before the service. If it does not fail AND you get a failed response or no response from the VSE, you might be able to diagnose something via the raw traffic file.

 

Perhaps, a colleague can chime in with some better options/ideas.

[Legacy User]

If you can recreate the exception on-demand, try this approach (read all of the steps before executing so you do not generate a lot of 'noise' in the logs).

 

1) Set up a call to the service that you know will throw the exception.

2) If possible stop all of the other transactions from coming into the VSE to help keep the log files as compact as possible. Or, run the service in ITR mode on your localhost:port to isolate the transaction.

2) Edit logging.properties file on VSE (or on your workstation if you running in ITR mode)

3) Change the debug level to TRACE

4) Save logging.properties and immediately send the transaction from step 1)

5) Wait a few seconds for the logger to generate the output print lines, edit logging.properties and set debug level back to INFO then save file. This will help minimize the amount of output as much as possible.

6) Open the vse.log file if the service is running in VSE (workstation.log file if running ITR) and search for the phrase "raw request start"

 

Hopefully, you can see raw request in string format. If you do not see the log messages, it may be that the HTTP transaction is null. See if you can locate the HTTP Request Method (i.e., CONNECT, DELETE, GET, HEAD, OPTIONS, PATCH, POST, PUT, TRACE) and version.  Let us know what you discover or post it in the ticket to help the support team. 

[LawrenceDillard76044264]

@Joel Nesmith

 

We see this error when a developer pings our service with an empty telnet request to check and see if the service is up.  Is there a way to trap for this and simply ignore it or set it to a warning so that when they do this, it does not bring down the service?  I was looking at the model and I was unable to define a process that would trap for this empty telnet ping and handle appropriately, by ignoring and maybe logging a warning.  This only happens when a new build is implemented and the developer wants to make sure the application is responding so they do an empty telnet ping.  Obviously if they do this more than 3 times, which happens, they bring down the service and it does not come back up on its own (by design).  We know we could set the lisa.vse.max.hard.errors to a higher number than 3.  But we would like to be a bit more elegant about it, trap the exception, log a message and set the model back to listening mode, rather than allowing the listener to simply shut down and restart and throw a hard error.  we know what is causing it, we simply want the listener to respond appropriately rather than shutdown and throw an error.  We can create the error at will, by simply connecting to the VS and port via Telnet and hitting the 'enter' key.  Rather than throw error we want to handle it.

[Rick.Brown]

A telnet ping doesn't test that "the" service is up, just that the port is open on the VSE and *something* is listening on it. It could be anything listening on it, so it's a poor test.

 

I just tried this, and the results were interesting:

 

When I just hit <enter>, I get no error. I can hit <enter> as many times as I want, and I never get an error.

 

When there is a base path listed in the service model, and I type something other than just <enter>, I get the default "no match" response, and the telnet session is closed by the virtual service, again with no error.

 

When there is no base path in the service model, and I type something other than just <enter>, the telnet session is closed by the virtual service and I get the error you describe.

 

Are you not using base paths, or are you creating a virtual service with a mixture of base paths (so DevTest is unable to distinguish between services by the abstraction of the base path, and it is only able to use "/" as the base path)? I commonly see base paths used to differentiate between versions of a service, and so a virtual service will be for /v1/, /v1.1/ or /v2/ of a service, and those would be used as base paths to make sure there is never the chance for a virtual service to respond with an incorrect version of a service. In this configuration, I would have three different virtual services for three versions of a real service, all listening on the same port. If this is your case, you could follow this use case, and create an additional TCP virtual service with no base path to respond differently, thereby foiling any "telnet ping" test your developers try, forcing them to send properly-formed requests to test their deployment. I remember once creating a TCP service like this, which responded with lyrics from Rick Astley's "Never Gonna Give You Up", one line every second, rick-rolling the poor developer who would try to misuse my service in this way.

[Rick.Brown]

[LawrenceDillard76044264]

Thank you Rick.