Re: Question about TCPProxy and Correlation

You can spit out all the information the TCPProxy keeps from the HTTP
stream as an XML file. To do this, record with "-http
$GRINDERHOME/etc/httpToXML.xsl".

This will give you XML output. You can later transform this to a script
using

$ java net.grinder.plugin.http.tcpproxyfilter.ProcessRecording blah.xml etc/httpToJythonScriptOldInstrumentation.xsl

The XML format keeps more of the request/response structrure, so it
might just let you figure out the source of the magic values.

- Phil

On 06/06/12 20:55, Lawrence Schapker wrote:
> Hello Ouray:
>
> Thank you so much for the quick response!
>
> The issue is not with the script functionality.  I know the script is wrong as I can see hardcoded
hexadecimal values that should be correlated.  Rerunning my known incorrect script against a proxy won't
help much either.  Example scenario:
>
> The grinder script has a hard coded value of "AAAAFE" (from where it came I have no clue).  When I manually
re-run the exact steps performed in the Grinder script through my local browser, I see the value now is
"AA09DF" (or whatever it may be.  I can see this from Firebug).
>
> I know this value needs to be correlated, but do not know where to get the value (or what logic needs to be
reproduced with the grinder script to recalculate the proper value).  If I could see all the responses that
were sent during the script recording/creation, I could easily "grep" for "AAAAFE" and possibly find the
value within JavaScript somewhere (or if not found, I'd still have to speak with the developer ask more
questions and chances are it's a "framework" thing and I would have to hunt "the needle in the haystack").
>
> Having a viewable "environment" from when the script was recorded would greatly increase the ability to
repair these types of issues.
>
> I don't have a problem trying to change the (TCPProxy) code myself.  If someone could provide a few pointers
to where the change makes the most sense, I'd gladly (try to) add the features (i.e. add a new command line
argument to enable).
>
> Thanks,
>
> Larry
> -----Original Message-----
>
> Message: 1
> Date: Wed, 6 Jun 2012 15:13:44 -0400
> From: Ouray Viney <ouray@...>
> Subject: Re: [Grinder-use] Question about TCPProxy and Correlation
> 	questions.
> To: grinder-use <grinder-use@...>
> Message-ID:
> 	<CAM5wVfhJs8-tTzTkCa_TrkxamY-g_voRG7oexkcizpT0+KXJ8g@...>
> Content-Type: text/plain; charset="windows-1252"
>
> Hi Lawrence:
>
> see my comments inline
>
> On Wed, Jun 6, 2012 at 2:40 PM, Lawrence Schapker
> <lschapker@...>wrote:
>
>> Hello,****
>>
>> ** **
>>
>> I?m using TCPProxy to create a Grinder Jython script.  It appears that 
>> the web pages I?m accessing works in a way where the ?standard? proxy 
>> functionality is failing (i.e. the script is created, but will not 
>> function).
>>
> Can you give an example of what Grinder is doing incorrectly in your sample script?
>
>
>> ****
>>
>> ** **
>>
>> I?m trying to manually correlate the tcpproxy script.  I am having 
>> great difficulty ?seeing? the information being passed back and forth 
>> between the client and the server at the time the script was created.  
>> Attempting to use the ?Echo Filter? seems to work (to a point), but my 
>> server is sending a lot of ?gzipped? text responses (not allowing me 
>> to see the information that is contained).
>>
> Have you tried running your script through a proxy (example Fiddler - great HTTP debugging proxy)?  Keep in
mind that Grinder does do some very nice job of auto-generation dynamic data for you.  I would highly
recommend that you spend some time reviewing the Grinder samples, Grinder web site docs and finally the
Grinder scripting APIs.  When I first started, I had similar questions to you and was pleasantly surprise
how well things were documented.
>
>
>> ****
>>
>> ** **
>>
>> How does one work this issue?
>>
> Honestly, you work through this by knowing the server side code.  Grinder won't be able to get it all right.  I
have dealt with similar issues and the key was understanding the server side code to a degree, such that you
can reverse engineer the script.
>
>
>> ****
>>
>> ** **
>>
>> Other load testing tools I?ve used, store all the server side and 
>> client side responses (in plain test) during a script recording so 
>> that one can go back (if needed) to help properly re-correlate a 
>> troubled script (i.e. when values are actually pulled from within 
>> Javascript.  Grinder hardcodes these values from Javascript.  This 
>> creates a non-functional script when it is actually executed).  
>> Knowing from where these hardcoded values come would make correcting these issues much less a pain.
>>
> Other tools that you are talking about are mostly likely not FREE!  If you have identified something that
Grinder is doing wrong/incorrectly, then IMHO you should log a defect (see source forge project page).
>  Alternatively, you could write the required client side utility code in Java/Python/Jython to service
your testing needs.
>
>
>> ****
>>
>> ** **
>>
>> Any assistance/suggestions would greatly be appreciated.****
>>
>> ** **
>>
>> Larry Schapker ****
>>
>> ** **
>>
>>

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/