opensta-devel — OpenSTA developer discussions

[OpenSTA-devel] [ opensta-Bugs-1773940 ] empty parameters cause other parameters to become empty

[SourceForge.net <no...@so...>]

Bugs item #1773940, was opened at 2007-08-14 10:20
Message generated for change (Comment added) made by velivis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1773940&group_id=10857

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Script Language
Group: Behavioral
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: steve2k (steve2k)
Assigned to: Nobody/Anonymous (nobody)
Summary: empty parameters cause other parameters to become empty

Initial Comment:
With the Modeler that ships with OpenSTA 1.4.3.20, if you pass an empty string, i.e. "" as a parameter to a subroutine, all following parameters are ignored.

There is an example script below.
The first time CHECKRESPONSE is called with all 3 parameters populated, it works fine. 

The second time CHECKRESPONSE is called with the first parameter set to "", it ignores all the parameters and uses the parameters passed the first time.

Problem has been confirmed by Bernie Velivis:
"I tried a simple subroutine with 4 string args. As soon as one (counting from left to right) is set to "", then all remaining arguments are set to "" or 0 if numeric. Looks like the code that parses arguments passed to subroutines quits when it see's a null. I would definitely report it on sourceforge."


============ EXAMPLE SCRIPT ==================
!Browser:IE5
!Date : 14/08/2007
Environment
Description ""
Mode HTTP
Wait UNIT MILLISECONDS

Definitions
! Standard Defines
Include "RESPONSE_CODES.INC"
Include "GLOBAL_VARIABLES.INC"

CHARACTER*512 USER_AGENT
Integer USE_PAGE_TIMERS
CHARACTER*256 MESSAGE

CHARACTER*256 p1
CHARACTER*256 p2
CHARACTER*256 p3

Timer T_QQQQ

CONSTANT DEFAULT_HEADERS = ""

Code
 !Read in the default browser user agent field
 Entry[USER_AGENT,USE_PAGE_TIMERS]

 Start Timer T_QQQQ

 CALL CHECKRESPONSE["1param1","1param2","1param3"]

 CALL CHECKRESPONSE["","2param2","2param3"]

 SYNCHRONIZE REQUESTS

 End Timer T_QQQQ

 SUBROUTINE CHECKRESPONSE[p1,p2,p3]
 Log "Parameter 1:", p1
 Log "Parameter 2:", p2
 Log "Parameter 3:", p3
 END SUBROUTINE

 Exit

 ERR_LABEL:

 If (MESSAGE <> "") Then
 Report MESSAGE
 Endif

 Exit


----------------------------------------------------------------------

>Comment By: Bernie Velivis (velivis)
Date: 2007-10-15 10:46

Message:
Logged In: YES 
user_id=1868094
Originator: NO

Work around:  If only one of your parameters may be empty, then make it
the last in list of parameters. If more then one parameter may be empty,
don't use parameters but instead pass the values in local variables.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1773940&group_id=10857

[OpenSTA-devel] [ opensta-Bugs-1622218 ] Time Limit donot run correctly when setup time overcome 24h

[SourceForge.net <no...@so...>]

Bugs item #1622218, was opened at 2006-12-26 00:06
Message generated for change (Comment added) made by velivis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1622218&group_id=10857

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Architecture
Group: Serious
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: justin (justinhungthai)
Assigned to: Nobody/Anonymous (nobody)
Summary: Time Limit donot run correctly when setup time overcome 24h

Initial Comment:
Hi all,

I setup time of "After fixed time" of Stop stask group is 36h. If I return back GUI to check it, its value is 12:00:00 and the OpenSTA will run test in 12h.

Any people meet the above problem as me, please help me.

Thank you in advance 

----------------------------------------------------------------------

>Comment By: Bernie Velivis (velivis)
Date: 2007-10-15 10:32

Message:
Logged In: YES 
user_id=1868094
Originator: NO

I encounter this problem frequently. Using a single task group, I run a
one hour test where I introduce users in batches of N/4 users with ramp up
time of 5 minutes and time between batches of 10 minutes. At the end of one
hour, most of the VUs are stopped, but very often I seen from 1 to 3 VUs
"stuck" which prevents the test from ending properly. Stopping the test
manually (black square button in Commander) terminates the test, but half
the time the HTTP* reports (e.g. HTTP monitored bytes/sec) graphs do not
appear in the test results.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1622218&group_id=10857

Re: [OpenSTA-devel] Joining in...

[Daniel S. <da...@Op...>]

Hi Barak, good to hear from you again.

Barak Sober wrote:
> I used to work with OSTA a couple of years ago and lately decided to
> catch up ...
> I saw that nothing new happened and realized that you are trying to
> issue a bug fix release.
> Well, I haven't got a lot of spare time... but from time to time I
> guess I can help a bit.
> I can write in C++, C# and a bit of Python.
> let me know how can I help

Best thing that you, or anyone, can do right now is to check through
the bug list on SourceForge:
 - find a bug that interests you, or you feel should be fixed.
 - post here to say that you'd like to look into it and ask if
   anyone has more info or hints that aren't in the bug report.
 - investigate it to the point that you know the actual cause of
   the bug and can reproduce it at will, then document these facts
   in the bug reporting system (in case you get run down by a bus)
 - attempt to fix the code in as minimalist way as possible - there
   should be no changes to default behavior and as little chance of
   introducing instability as possible.  If this isn't possible then
   we are still interested, it's just the fix will go to the 1.5
   branch rather than into the 1.4 releases.
 - when you are happy with a fix, post here to say you have one and
   I'll post back with info on how we can get it into CVS.

Cheers
/dan
-- 
Daniel Sutcliffe <Da...@Op...>
  OpenSTA part-time caretaker - http://OpenSTA.org/

[OpenSTA-devel] [ opensta-Bugs-1013510 ] Result files may become corrupted due to bad test closedown

[SourceForge.net <no...@so...>]

Bugs item #1013510, was opened at 2004-08-21 15:44
Message generated for change (Comment added) made by dansut
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1013510&group_id=10857

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Results Analysis
Group: Fatal Error
Status: Open
Resolution: Accepted
Priority: 6
Private: No
Submitted By: Daniel Sutcliffe (dansut)
Assigned to: Daniel Sutcliffe (dansut)
>Summary: Result files may become corrupted due to bad test closedown

Initial Comment:
A large result set from a test may cause issues when
trying to view graphs (the results analysis phase). 
When this happens the results graphs are empty or an
"Out of memory" can be shown.  This issue seems to
occur more with the graphs that are "v Elapsed Time"
but not exclusively so.  All reports have been with
large result sets.

The issues also may not occur the first time you view
your results but once it has happened it will not go
away on its own.  Deleting the HttpStats.cache and
Combined_HTTPDataFile.dat will cause your results to be
analysed again and may help avoid the problem in your
specific instance.

This problem seems to happen more if your test did not
finish cleanly, either through another problem or
through user aborting during the run.  Monitoring
results whilst the test is running also seems to
increase the chance of this happening.

A sure sign that you have a problem is the TestPlugin
process using up large amounts of memory or CPU.  If an
"Out of memory" condition is reported it will come from
this TestPlugin process.

Please add any more useful information to this bug
report.  We are specifically interested in a simple
consistent way of reproducing this error and/or small
resultsets which are known to cause the error.

----------------------------------------------------------------------

>Comment By: Daniel Sutcliffe (dansut)
Date: 2007-08-22 19:33

Message:
Logged In: YES 
user_id=19748
Originator: YES

Jerome's workaround patch, which abandons result file parsing if
corruption
found, has been committed into CVS to be included in the 1.4.4 general
release.

HttpResultsDLL.dll: 1.4.4.2
OpenSTA: 1.4.4.11

This bug will not be closed or marked fixed though - it will serve as a 
marker in the hope we can fix/improve the source of the file corruption
in the future.

----------------------------------------------------------------------

Comment By: Jerome Delamarche (trickyjer)
Date: 2006-12-12 03:17

Message:
Logged In: YES 
user_id=681140
Originator: NO

I released on small tool (ostarepair.exe) that can be used in batch mode
to fix corrupted result files. A patch has been provided to fix the data
automatically in the Commander.

ostarepair.exe is available at http://www.trickytools.com/php/opensta.php

----------------------------------------------------------------------

Comment By: Jerome Delamarche (trickyjer)
Date: 2006-10-04 17:18

Message:
Logged In: YES 
user_id=681140

The "out of memory" message can be generated by a 
corrupted data file when the running test has 
been "killed" instead of being "stopped".

This can be easily fixed:
- either with a batch command soon available on my site 
http://www.trickytools.com)
- either by fixing the bug in OpenSTA itself. But to do 
so, I need some information: is there some documentation 
about OpenSTA design ?

Jerome

----------------------------------------------------------------------

Comment By: Danny Faught (faught)
Date: 2006-04-28 19:02

Message:
Logged In: YES 
user_id=576825

I can easily reproduce this error in v. 1.4.3.20 by
corrupting the contents of HttpStats.cache.

1. I captured a single web page hit, and built a test with
the resulting script and a cpu utilization collector for the
local host.
2. I ran the test.
3. In the results directory, I chopped the last byte off of
the HttpStats.cache file.  It doesn't matter if the
Commander is running when I do this.
4. In the Results tab for the test, as soon as I try to
expand the tree for the test run, I get a non-fatal "Out of
memory" error dialog from TestPlugin.  I don't know if it's
actually out of memory - the error is coming very quickly,
so it may be just a wild integer value asking for an
unreasonably large single block of memory.

Whether the HttpStats.cache file is really getting corrupted
by something is another matter, but this proves that the
tool is not robust against unexpected contents in the test
results.

I also have a reproducible crash that seems related to this
where I didn't intentionally corrupt the HttpStats.cache
file.  I've had three different real-world test runs that
produced results directories that give me a fatal crash
every time I try to expand the results in the tree. 
Removing HttpStats.cache fixes the problem.  I can try to
scrub the file sufficiently for my client to allow me to
send it in if that would help.

----------------------------------------------------------------------

Comment By: chris mead (chrisrmead)
Date: 2005-08-25 12:29

Message:
Logged In: YES 
user_id=1335128

For me, there is no clear correlation between large result sets 
and the crash.  I get the crash repeatedly with a test that only 
has 1060 rows in the Data List, but I get no crash with a test 
that has 50,856 rows, for instance.  

I have a ZIP to attach, but I don't see how to do it yet, maybe 
a comment is required first?

----------------------------------------------------------------------

Comment By: Daniel Sutcliffe (dansut)
Date: 2005-06-09 11:51

Message:
Logged In: YES 
user_id=19748

>From deleted bug#1216593 by javier_dba:
Out of memory error appears while trying to show
"HTTP Responses v Elapsed time".
Test was done successfully ramping 400 vusers along 1
hour.
Attached a zip file ResultsAnalysisCrash.zip containing:
- picture with the error.
- test file
- script file
- output from dir command of Repository folder
- zipped Scripts folder from Repository
- zipped ObjectCode folder from Repository
- zipped ArchMgr folder from Repository
- zipped Profiles folder from Repository

Ten computers generating load, sharing the repository, one
commanding the load. Used OpenSTA 1.4.2 and 1.4.3. Both
versions have the same behaviour "out of memory".

----------------------------------------------------------------------

Comment By: Daniel Sutcliffe (dansut)
Date: 2004-12-13 07:48

Message:
Logged In: YES 
user_id=19748

The results analysis phase has multiple problems -
especially when
dealing with large result sets.  Instead of filing multiple
bug reports
please add any useful and concrete information here that may
help
us get to the bottom of this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1013510&group_id=10857

[OpenSTA-devel] Joining in...

[Barak S. <bar...@gm...>]

Hey there people,
I used to work with OSTA a couple of years ago and lately decided to
catch up ...
I saw that nothing new happened and realized that you are trying to
issue a bug fix release.
Well, I haven't got a lot of spare time... but from time to time I
guess I can help a bit.
I can write in C++, C# and a bit of Python.
let me know how can I help
cheers
Barakino

[OpenSTA-devel] [ opensta-Bugs-1752735 ] Load of Cookies with same name on same request wrong

[SourceForge.net <no...@so...>]

Bugs item #1752735, was opened at 2007-07-12 16:12
Message generated for change (Comment added) made by steve2k
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1752735&group_id=10857

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: HTTP Replay
Group: Behavioral
Status: Open
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Daniel Sutcliffe (dansut)
Assigned to: Daniel Sutcliffe (dansut)
Summary: Load of Cookies with same name on same request wrong

Initial Comment:
If you have a HTTP request that does a Set-Cookie for a Cookie with the same name multiple times then it is impossible to retrieve these different values using the:
 LOAD RESPONSE_INFO HEADER ON <conid> INTO <cookievar>, WITH "Set-Cookie,<cookiename>"
syntax - you will always just get the value from the first occurrence of the Set-Cookie.  This behavior is especially bad because the latest instance in the HTTP headers should override the earlier ones according to the original Netscape spec and the way all tested browsers work.

The only current workaround is to not use the ',WITH "Set-Cookie,<cookiename>"' clause and therefore load all the HTTP headers into a variable that you can parse yourself.

You might also want to talk to your Web application authors about the reasoning for setting the same Cookie multiple times - occasionally it makes sense, mostly it doesn't.

Code should definitely be changed so latest instance is picked up rather than first, but a full solution would require expanding the ',WITH "Set-Cookie,<cookiename>"' clause syntax so that you can further specify which Set Cookie header you are interested in bearing in mind order, path, etc.

----------------------------------------------------------------------

Comment By: steve2k (steve2k)
Date: 2007-08-14 15:27

Message:
Logged In: YES 
user_id=1867232
Originator: NO

I came across this problem and did some research a couple of months ago.

RFC 2109 says
"If a user agent receives a Set-Cookie response header whose NAME is
   the same as a pre-existing cookie, and whose Domain and Path
   attribute values exactly (string) match those of a pre-existing
   cookie, the new cookie supersedes the old."

So it sounds like your first solution would be in line with the RFC.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1752735&group_id=10857

[OpenSTA-devel] [ opensta-Bugs-1773940 ] empty parameters cause other parameters to become empty

[SourceForge.net <no...@so...>]

Bugs item #1773940, was opened at 2007-08-14 15:20
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1773940&group_id=10857

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Script Language
Group: Behavioral
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: steve2k (steve2k)
Assigned to: Nobody/Anonymous (nobody)
Summary: empty parameters cause other parameters to become empty

Initial Comment:
With the Modeler that ships with OpenSTA 1.4.3.20, if you pass an empty string, i.e. "" as a parameter to a subroutine, all following parameters are ignored.

There is an example script below.
The first time CHECKRESPONSE is called with all 3 parameters populated, it works fine. 

The second time CHECKRESPONSE is called with the first parameter set to "", it ignores all the parameters and uses the parameters passed the first time.

Problem has been confirmed by Bernie Velivis:
"I tried a simple subroutine with 4 string args. As soon as one (counting from left to right) is set to "", then all remaining arguments are set to "" or 0 if numeric. Looks like the code that parses arguments passed to subroutines quits when it see's a null. I would definitely report it on sourceforge."


============ EXAMPLE SCRIPT ==================
!Browser:IE5
!Date : 14/08/2007
Environment
Description ""
Mode HTTP
Wait UNIT MILLISECONDS

Definitions
! Standard Defines
Include "RESPONSE_CODES.INC"
Include "GLOBAL_VARIABLES.INC"

CHARACTER*512 USER_AGENT
Integer USE_PAGE_TIMERS
CHARACTER*256 MESSAGE

CHARACTER*256 p1
CHARACTER*256 p2
CHARACTER*256 p3

Timer T_QQQQ

CONSTANT DEFAULT_HEADERS = ""

Code
 !Read in the default browser user agent field
 Entry[USER_AGENT,USE_PAGE_TIMERS]

 Start Timer T_QQQQ

 CALL CHECKRESPONSE["1param1","1param2","1param3"]

 CALL CHECKRESPONSE["","2param2","2param3"]

 SYNCHRONIZE REQUESTS

 End Timer T_QQQQ

 SUBROUTINE CHECKRESPONSE[p1,p2,p3]
 Log "Parameter 1:", p1
 Log "Parameter 2:", p2
 Log "Parameter 3:", p3
 END SUBROUTINE

 Exit

 ERR_LABEL:

 If (MESSAGE <> "") Then
 Report MESSAGE
 Endif

 Exit


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1773940&group_id=10857

[OpenSTA-devel] [ opensta-Bugs-1545996 ] HTTP Capture : No primary URI / Timer set with some browser

[SourceForge.net <no...@so...>]

Bugs item #1545996, was opened at 2006-08-24 10:18
Message generated for change (Comment added) made by dansut
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1545996&group_id=10857

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: HTTP Capture
Group: Inconvenience
Status: Open
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: duominike (duominike)
>Assigned to: Daniel Sutcliffe (dansut)
Summary: HTTP Capture : No primary URI / Timer set with some browser

Initial Comment:
Environnment : Windows XP SP2
Internet Explorer : 6.0.2800.1106.xpsp2.0530301-1526
Patchs : SP1; Q867801; Q903235

Capture mode : Gateway (Local) / No proxy used / Page
timers is on

1) Script Record via Script Modeler->Capture->Record

2) In the HTP result file, there is no URI with the
PRIMARY keyword and timers 

If I do the same actions by using Internet Explorer 5.5
or Firefox 1.5.0.4, no problem. I can obtain PRIMARY
URI et timers.

After investigating the problem,  I realize that
browsers send different HTTP headers request and that
the value of field "Accept" in HTTP header seems to be
very important for HTTP recorder module in order to
choose PRIMARY URI.

With IE 6.0, the value of ACCEPT is always the
following ("*/*") for all kinds of URI (primary
[servlet], normal [images]) and so, the recorder can't
find the PRIMARY URI and position the TIMERS.

Moreover, when you use the "BView" add-on  to replay
the capture, no screen is displayed 

Is is possible for recorder module (and probably
"BWiew" add-on) to use another HTTP header field to
determine PRIMARY URI ("Referer" could be a good
candidate) without depending on "Accept" field whom
value depends on your favourite browser ? 
 



----------------------------------------------------------------------

>Comment By: Daniel Sutcliffe (dansut)
Date: 2007-07-18 19:23

Message:
Logged In: YES 
user_id=19748
Originator: NO

The code does use the Accept header to decide whether a
request is PRIMARY or not - a request with only '*/*' in
the 'Accept:' header is seen as not a PRIMARY request,
everything else is a PRIMARY.

This theory obviously breaks whenever a HTTP client
decides to do something different - the content of the
'Accept:' header is not a great thing to base the
decision on.  However, the PRIMARY keyword has no real
functional meaning - the only potential problem is if
you want to rely on the optional automatically recorded
'Page Timers' which will be in the wrong place.

The 'Referer:' header would seem to be a good choice to
base the decision on - but the Referer of the 2nd primary
is the same as that of secondaries to the 1st primary, 
etc.  Maybe the only ways to truly identify primary
requests are:
- actually see the user clicks and only label the
  requests that come from these as being.
- post process the recording and label as a primary just
  the requests that are mentioned in a Referer field -
  but this means you'd miss primary pages with no sub
  content.

Neither of these are ideal or practical solutions so it
will probably be left as it is until a better idea can
be thought of, or a strong reason for changing it
arrives.

The comments about BView do not belong in this bug
report - BView is an add-on to the OpenSTA toolset and
not part of the project, plus I'm not sure how the
problem is related.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1545996&group_id=10857

[OpenSTA-devel] [ opensta-Bugs-1240930 ] Compiler crashes when bad var SET to array var that isn't

[SourceForge.net <no...@so...>]

Bugs item #1240930, was opened at 2005-07-19 11:41
Message generated for change (Comment added) made by dansut
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1240930&group_id=10857

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Script Language
Group: Crash
Status: Open
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Daniel Sutcliffe (dansut)
Assigned to: Daniel Sutcliffe (dansut)
Summary: Compiler crashes when bad var SET to array var that isn't

Initial Comment:
This SCL script illustrates the problem:
  Environment
    Description "This causes the compiler to crash"
  Definitions
    CHARACTER ChrNotArray
  Code
    SET NotVar = ChrNotArray[1]
  Exit
It should produce a compliation error because NotVar
doesn't exist and and ChrNotArray is not an array - but
it actually crashes the compiler.  If ChrNotArray is an
INTEGER the compiler doesn't crash and produces the
correct error message.

----------------------------------------------------------------------

>Comment By: Daniel Sutcliffe (dansut)
Date: 2007-07-17 17:10

Message:
Logged In: YES 
user_id=19748
Originator: YES

A fix for this issue has been merged into the CVS HEAD.  It
will become generally available in the OpenSTA 1.4.4 release.

scl.exe: 1.4.4.3
OpenSTA: 1.4.4.10

This problem was not exactly as originally reported, it was
a little more widespread.  You 'simply' had to use an array
indexed var that wasn't an array or the same type as the
destination of the SET.  Undefined variables on the left
side of the set are assumed to be integers for the purpose
of further parsing.

All these caused the compiler to crash:
SET ChrVar = IntNotArray[1]
SET ChrConst = IntNotArray[1]
SET IntVar = ChrNotArray[1]
SET IntConst = ChrNotArray[1]
SET NotVar = ChrNotArray[1]
etc.

Fixed the parser to assume the rest of the command was
garbage when it hit an array index that didn't belong -
something in the parsing after that point was getting
messed up and it was easiest to just do no more parsing.

As a bonus along with this fix I removed the rubbish
index information from the SET VARIABLE trace message
output in the Modeler when running a script. ;)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1240930&group_id=10857

[OpenSTA-devel] [ opensta-Bugs-1752735 ] Load of Cookies with same name on same request wrong

[SourceForge.net <no...@so...>]

Bugs item #1752735, was opened at 2007-07-12 12:12
Message generated for change (Settings changed) made by dansut
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1752735&group_id=10857

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: HTTP Replay
Group: Behavioral
Status: Open
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Daniel Sutcliffe (dansut)
Assigned to: Daniel Sutcliffe (dansut)
>Summary: Load of Cookies with same name on same request wrong

Initial Comment:
If you have a HTTP request that does a Set-Cookie for a Cookie with the same name multiple times then it is impossible to retrieve these different values using the:
 LOAD RESPONSE_INFO HEADER ON <conid> INTO <cookievar>, WITH "Set-Cookie,<cookiename>"
syntax - you will always just get the value from the first occurrence of the Set-Cookie.  This behavior is especially bad because the latest instance in the HTTP headers should override the earlier ones according to the original Netscape spec and the way all tested browsers work.

The only current workaround is to not use the ',WITH "Set-Cookie,<cookiename>"' clause and therefore load all the HTTP headers into a variable that you can parse yourself.

You might also want to talk to your Web application authors about the reasoning for setting the same Cookie multiple times - occasionally it makes sense, mostly it doesn't.

Code should definitely be changed so latest instance is picked up rather than first, but a full solution would require expanding the ',WITH "Set-Cookie,<cookiename>"' clause syntax so that you can further specify which Set Cookie header you are interested in bearing in mind order, path, etc.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1752735&group_id=10857

[OpenSTA-devel] [ opensta-Bugs-1752655 ] Cookies repeatedly set by Web app use different variables

[SourceForge.net <no...@so...>]

Bugs item #1752655, was opened at 2007-07-12 09:57
Message generated for change (Comment added) made by dansut
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1752655&group_id=10857

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: HTTP Capture
Group: Inconvenience
Status: Open
>Resolution: Fixed
Priority: 3
Private: No
Submitted By: Daniel Sutcliffe (dansut)
Assigned to: Daniel Sutcliffe (dansut)
Summary: Cookies repeatedly set by Web app use different variables

Initial Comment:
When a Web application repeatedly sets a Cookie (it doesn't matter if it is to the same value or a different value) then the created SCL will use a new defined SCL variable for each Set-Cookie.

Although the created code works fine it makes the scripts longer, overcomplicated and wastes the memory associated with the SCL Cookie variables.  It would be much better for the generated code to realize a previously set Cookie is being reset and simply use the old variable to store the new Cookie value.

----------------------------------------------------------------------

>Comment By: Daniel Sutcliffe (dansut)
Date: 2007-07-17 11:47

Message:
Logged In: YES 
user_id=19748
Originator: YES

A fix for this issue has been merged into the CVS HEAD.  It
will become generally available in the OpenSTA 1.4.4 release.

gwhttp.dll: 1.4.4.7
OpenSTA: 1.4.4.9

The fix involved checking to see if the same named Cookie
had been set before and if so reusing that variable rather
than creating and declaring a new one during TOF generation
in the Gateway.

Static/CONSTANT Cookies will still always use a new
variable for every time they change - although if they are
changing that means they are changing using some other
method than a HTTP Set-Cookie header ...

See this FAQ for more information:
http://portal.opensta.org/faq.php?topic=RecordingCookies


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1752655&group_id=10857

[OpenSTA-devel] [ opensta-Bugs-1523074 ] Created Cookie code uses CONSTANTs where dynamic expected

[SourceForge.net <no...@so...>]

Bugs item #1523074, was opened at 2006-07-15 10:20
Message generated for change (Comment added) made by dansut
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1523074&group_id=10857

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: HTTP Capture
Group: Behavioral
Status: Open
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Daniel Sutcliffe (dansut)
Assigned to: Daniel Sutcliffe (dansut)
Summary: Created Cookie code uses CONSTANTs where dynamic expected

Initial Comment:
The code created to handle the dynamic nature of
Cookies occasionally uses a CONSTANT 'static' Cookie
when it is expected that one retrieved dynamically from
a Set-Cookie HTTP header through use of the of the
'LOAD RESPONSE_INFO HEADER' command would be expected.

It is currently unknown what exact conditions cause the
above problem, but it should be noted that it doesn't
happen for all Web applications and you should be sure
that you are clearing your browsers Cookie Cache for
the domains you are recording before assuming that you
are seeing this problem.

Workaround: hand code the dynamic Cookie SCL where the
problem occurs.

More information and workarounds should be available at
this FAQ location:
http://portal.opensta.org/faq.php?topic=RecordingCookies

----------------------------------------------------------------------

>Comment By: Daniel Sutcliffe (dansut)
Date: 2007-07-17 11:29

Message:
Logged In: YES 
user_id=19748
Originator: YES

A fix for this issue has been merged into the CVS HEAD.  It
will become generally available in the OpenSTA 1.4.4 release.

gwhttp.dll: 1.4.4.6
OpenSTA: 1.4.4.8

Most valid occurrences of this problem turned out to be when
a Cookie contains a space character - although it is
'recommended' that spaces be encoded in Cookies that doesn't
stop badly behaved Web apps not doing this.  The Gateway code
was updated to only see the ';' as a Cookie seperator char
and now even badly behaved apps can have their Cookies
recorded correctly.

There are still many times that you may see 'static' CONSTANT
Cookies when you expect dynamic ones, but the Gateway cannot
ever record most of these cases now - they are when the
Gateway can never see a 'Set-Cookie' header because it does
not occur in the HTTP, eg. Cookie set using JavaScript.  See
the FAQ URL in the first entry of this bug for more
information, examples, and workarounds for these occasions.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1523074&group_id=10857

[OpenSTA-devel] [ opensta-Bugs-1752657 ] Consecutive ~s in recording cause bad SCL or Modeler hang

[SourceForge.net <no...@so...>]

Bugs item #1752657, was opened at 2007-07-12 10:07
Message generated for change (Comment added) made by dansut
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1752657&group_id=10857

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: HTTP Capture
Group: Behavioral
Status: Open
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Daniel Sutcliffe (dansut)
Assigned to: Daniel Sutcliffe (dansut)
Summary: Consecutive ~s in recording cause bad SCL or Modeler hang

Initial Comment:
The symptoms here are that the Modeler will just hang after a recorder is finished (using 100% CPU) or the created script will be missing bits, typically it won't have any of the required variables defined in the Definition section.

The problem is that the Gateway creates a badly formed intermediate recording (TOF) file if the content contains multiple consecutive ~ characters.  This was first noted with a Cookie containing a '~~' sequence, which when encoded for SCL becomes '~~~~', but it is possible that consecutive ~s in many parts of the recorded HTTP stream can cause the same problem.

The same problem can be artificially created by using the Modeler Comment button whilst recording and typing in a string of more than 3 ~s.

----------------------------------------------------------------------

>Comment By: Daniel Sutcliffe (dansut)
Date: 2007-07-17 11:01

Message:
Logged In: YES 
user_id=19748
Originator: YES

A fix for this issue has been merged into the CVS HEAD.  It
will become generally available in the OpenSTA 1.4.4 release.

gwhttp.dll: 1.4.4.5
OpenSTA: 1.4.4.7

This problem was fixed by avoiding the use of the '~~' string
to represent a single '~' when encoding SCL strings.  Instead
the hex representation of ~<7E> is used.  For the issue with
comments the problem strings are simply truncated to the
shortest sequence that does not cause a problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1752657&group_id=10857

[OpenSTA-devel] [ opensta-Bugs-1752735 ] Load of Cookies with same name on same connection wrong

[SourceForge.net <no...@so...>]

Bugs item #1752735, was opened at 2007-07-12 12:12
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1752735&group_id=10857

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: HTTP Replay
Group: Behavioral
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Daniel Sutcliffe (dansut)
Assigned to: Daniel Sutcliffe (dansut)
Summary: Load of Cookies with same name on same connection wrong

Initial Comment:
If you have a HTTP request that does a Set-Cookie for a Cookie with the same name multiple times then it is impossible to retrieve these different values using the:
 LOAD RESPONSE_INFO HEADER ON <conid> INTO <cookievar>, WITH "Set-Cookie,<cookiename>"
syntax - you will always just get the value from the first occurrence of the Set-Cookie.  This behavior is especially bad because the latest instance in the HTTP headers should override the earlier ones according to the original Netscape spec and the way all tested browsers work.

The only current workaround is to not use the ',WITH "Set-Cookie,<cookiename>"' clause and therefore load all the HTTP headers into a variable that you can parse yourself.

You might also want to talk to your Web application authors about the reasoning for setting the same Cookie multiple times - occasionally it makes sense, mostly it doesn't.

Code should definitely be changed so latest instance is picked up rather than first, but a full solution would require expanding the ',WITH "Set-Cookie,<cookiename>"' clause syntax so that you can further specify which Set Cookie header you are interested in bearing in mind order, path, etc.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1752735&group_id=10857

[OpenSTA-devel] [ opensta-Bugs-1752657 ] Consecutive ~s in recording cause bad SCL or Modeler hang

[SourceForge.net <no...@so...>]

Bugs item #1752657, was opened at 2007-07-12 10:07
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1752657&group_id=10857

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: HTTP Capture
Group: Behavioral
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Daniel Sutcliffe (dansut)
Assigned to: Daniel Sutcliffe (dansut)
Summary: Consecutive ~s in recording cause bad SCL or Modeler hang

Initial Comment:
The symptoms here are that the Modeler will just hang after a recorder is finished (using 100% CPU) or the created script will be missing bits, typically it won't have any of the required variables defined in the Definition section.

The problem is that the Gateway creates a badly formed intermediate recording (TOF) file if the content contains multiple consecutive ~ characters.  This was first noted with a Cookie containing a '~~' sequence, which when encoded for SCL becomes '~~~~', but it is possible that consecutive ~s in many parts of the recorded HTTP stream can cause the same problem.

The same problem can be artificially created by using the Modeler Comment button whilst recording and typing in a string of more than 3 ~s.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1752657&group_id=10857

[OpenSTA-devel] [ opensta-Bugs-1752655 ] Cookies repeatedly set by Web app use different variables

[SourceForge.net <no...@so...>]

Bugs item #1752655, was opened at 2007-07-12 09:57
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1752655&group_id=10857

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: HTTP Capture
Group: Inconvenience
Status: Open
Resolution: None
Priority: 3
Private: No
Submitted By: Daniel Sutcliffe (dansut)
Assigned to: Daniel Sutcliffe (dansut)
Summary: Cookies repeatedly set by Web app use different variables

Initial Comment:
When a Web application repeatedly sets a Cookie (it doesn't matter if it is to the same value or a different value) then the created SCL will use a new defined SCL variable for each Set-Cookie.

Although the created code works fine it makes the scripts longer, overcomplicated and wastes the memory associated with the SCL Cookie variables.  It would be much better for the generated code to realize a previously set Cookie is being reset and simply use the old variable to store the new Cookie value.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1752655&group_id=10857

[OpenSTA-devel] [ opensta-Bugs-1389081 ] Gateway does not munge HTTPS URLs in CSS content

[SourceForge.net <no...@so...>]

Bugs item #1389081, was opened at 2005-12-23 13:56
Message generated for change (Comment added) made by dansut
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1389081&group_id=10857

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: HTTP Capture
Group: Behavioral
Status: Open
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Daniel Sutcliffe (dansut)
Assigned to: Daniel Sutcliffe (dansut)
Summary: Gateway does not munge HTTPS URLs in CSS content

Initial Comment:
While recording HTTPS traffic the gateway must
translate all HTTPS URLs in the content returned to the
client being recorded to be http://{ - this is to stop
the client attempting to make SSL/TLS connections to
the Gateway which cannot be recorded and will stop the
halt the gateway.  You can see this happen if you have
a "Unsupported protocol ..." comment in your created
script and your recording browser stops being able to
access any site.

In the OpenSTA 1.4.3 release and earlier the only
content they had this munging done was HTML and
javascript.  The most obvious other type of content
that may need munging is CSS ... but there may be others.

----------------------------------------------------------------------

>Comment By: Daniel Sutcliffe (dansut)
Date: 2007-07-03 16:25

Message:
Logged In: YES 
user_id=19748
Originator: YES

A fix for this issue has been merged into the CVS HEAD.  It
will become generally available in the OpenSTA 1.4.4 release.
gwhttp.dll: 1.4.4.4
OpenSTA: 1.4.4.6

This fix specifically adds checking of CSS to the list of content
types that are checked and munged for HTTPS.  A better solution
would be to allow the list of content-types that are checked and
munged to be user specifiable ... but given the apparent longevity
of the Gateway HTTPS recording solution, it seems pointless to put
any more effort in than this hard coded solution.  The code was
reworked to make it easier to add compiled in content-types though. 

----------------------------------------------------------------------

Comment By: Daniel Sutcliffe (dansut)
Date: 2005-12-23 14:42

Message:
Logged In: YES 
user_id=19748

A possible workaround for this problem is to use the
Remote(manual) recording method and not specify any proxy
for HTTPS content.  This obviously means that the failure
case requests will not be recorded but it may at least allow
some people to make partial recordings of their sites, to
which they can add the problem requests later.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1389081&group_id=10857

[OpenSTA-devel] [ opensta-Bugs-897856 ] Recording HTTPS through Gateway fails in newer browsers

[SourceForge.net <no...@so...>]

Bugs item #897856, was opened at 2004-02-16 02:43
Message generated for change (Settings changed) made by dansut
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=897856&group_id=10857

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: HTTP Capture
Group: Serious
>Status: Open
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Alain Ribault (ribault)
Assigned to: Daniel Sutcliffe (dansut)
>Summary: Recording HTTPS through Gateway fails in newer browsers

Initial Comment:
HTTPS recording :
With my browser (IE6, latest patches), when the opensta
receives an http page with https links, it transforms
the link like http://{ ..., which is correct by opensta
implementation. The problem is that IE escapes '{' by
'%7D' and the gateway does not understand http://%7D,
so the capture stops by 'page not found'.

Hisashi Iwashimizu wrote that it is after applying
MS04-004 
 security patch to IE6. 

I did some tests with Mozilla and it worked fine
(because no escape code). 

----------------------------------------------------------------------

>Comment By: Daniel Sutcliffe (dansut)
Date: 2007-07-03 16:14

Message:
Logged In: YES 
user_id=19748
Originator: NO

I am re-opening this bug with the possibility that it will never be closed
in the future!

Nearly all of the newer browsers (IE7, Firefox 2, Opera 9) fail recording
HTTPS for various reasons.  In IE it seems that the curly bracket gets
multiply URL encoded and Firefox/Opera refuse to even attempt to attempt a
HTTP connection to URLS whose hostname contain this 'invalid' character. 
Instead of attempting to apply bodge after bodge to keep this mechanism
working I am proposing that no more work is done on the Gateway mechanism
for recording HTTPS because it is really too much of a headache and any fix
is liable to be broken again (for valid reasons) by any updated browser
releases - instead I propose that any effort in this area instead be put
into other mechanisms for recording HTTPS traffic.

I am commiting to the CVS HEAD a fix that has been mentioned on the Users
list a few times (patching %7b to %7B) because it does help certain
situations where IE6 gets confused - but I will state again that this is
NOT because the gateway was doing a case dependent comparison but more
because IE was relying on the case to be in upper case.  This might break
things again in future versions but it helps the situation for a small
amount of users now.  This workaround will become generally available in
the OpenSTA 1.4.4 release.
gwhttp.dll: 1.4.4.3
OpenSTA: 1.4.4.5

More info on this whole area in the FAQ here:
http://portal.opensta.org/faq.php?topic=RecordingHttps

If you want to discuss this whole area then please do so by posting to the
OpenSTA Users Mailing List:
http://portal.opensta.org/faq.php?topic=UserMailingList - and not by
posting more info to this bug report.

----------------------------------------------------------------------

Comment By: Daniel Sutcliffe (dansut)
Date: 2005-12-18 13:54

Message:
Logged In: YES 
user_id=19748

This problem had NOTHING to do with script playback - it was
entirely a recording issue.  This fact does not matter
anyway, as the problem is fixed in the current release of
OpenSTA (1.4.3).

Also, please do not use this bug database as a type of
support forum - this just clutters up bug reports and makes
them more confusing.

----------------------------------------------------------------------

Comment By: kikibug (kikibug)
Date: 2005-12-07 04:42

Message:
Logged In: YES 
user_id=1314392

Should recording the script OK with '%7D' instead of '{'
affect playback? I have a problem that I do not know for
sure to be a bug, I have entered it in the mailing lists - I
cannot play back HTTPS script (which was recorded OK and
shows https:// in the requests) when going from the second
to the third HTTPS page in a row. So I am wondering if this
occurence with IE6 may affect playback in any way?

----------------------------------------------------------------------

Comment By: Lance (stampy)
Date: 2005-10-19 14:16

Message:
Logged In: YES 
user_id=1137295

hm, i too also get the %7B when using IE6. Im gathering from 
your previous response that its a problem in IE. Any other 
ideas?

im using osta 1.4.3.20

----------------------------------------------------------------------

Comment By: Daniel Sutcliffe (dansut)
Date: 2005-06-15 12:18

Message:
Logged In: YES 
user_id=19748

mvemers wrote:
> This problem seems to have re-occurred - IE is showing %7B
> in the location bar again:

This actually doesn't mean that this bug has re-occurred,
the fix to this problem was to allow the gateway to
understand the urlencoded form of the { character as well. 
It is only a problem if you cannot record HTTPS because of
this...

----------------------------------------------------------------------

Comment By: Mark Vevers (mvevers)
Date: 2005-06-15 11:26

Message:
Logged In: YES 
user_id=13500

This problem seems to have re-occurred - IE is showing %7B
in the location bar again:

gwhttp.dll: 1.4.3.6 
IE Version:  6.0.2900.2180.xpsp_sp2_gdr.050301-1519

Any suggestions?

Thanks


----------------------------------------------------------------------

Comment By: Daniel Sutcliffe (dansut)
Date: 2005-01-24 13:37

Message:
Logged In: YES 
user_id=19748

And addendum to this fix has been merged into the CVS HEAD.
The case were a Location: header was specified from the root
during a HTTPS redirect was not dealt with.  Thanks to Thierry
for spotting this.  This will be included in the OpenSTA 1.4.3
release.

gwhttp.dll: 1.4.3.5
OpenSTA: 1.4.3.18

----------------------------------------------------------------------

Comment By: Daniel Sutcliffe (dansut)
Date: 2004-12-20 17:29

Message:
Logged In: YES 
user_id=19748

The most recently mentioned fix has been merged into the CVS
HEAD.  It will become generally available in the OpenSTA 1.4.3
release.

gwhttp.dll: 1.4.3.4
OpenSTA: 1.4.3.13

----------------------------------------------------------------------

Comment By: Daniel Sutcliffe (dansut)
Date: 2004-12-20 14:33

Message:
Logged In: YES 
user_id=19748

I now have a "proper" fix for this that treats the URL encoded
version of { (which is %7b not %7d as Alain initially reported)
as equivilant to the {.

The fix had to be extended with a little fudge because it
uncovered and issue with IE and redirects.  This is best shown
by an example:  If I go to record https://osta.lan/mail/ I'll 
get http://{osta.lan/mail/ which the new "fixed" IE will rewrite
to http://%7Bosta.lan/mail/ - this will work fine, but if the
Web server then returns with a HTTP 302 and "Location:
src/login.php" then IE will get confused and try to redirect to
http://%7Bosta.lanan/mail/src/login.php - obviously the extra
2 chars and the domain name changing length confuse IE.  It
is unlikely that anyone in the "real world" will find this IE
buglet so I worked around it by having the gateway rewrite
the "Location:" header so that it is always fully specified for
SSL recordings (the recording .all gets the original value).

I was convinced this was something the gateway was doing
wrong for a long while but hours spent with a sniffer and
tests with other browsers showed that it was IE.

The fix also "enhances" the console and trace output from
the gateway.

This gateway code is ugly...

----------------------------------------------------------------------

Comment By: John L (johnleij)
Date: 2004-09-21 13:34

Message:
Logged In: YES 
user_id=999135

Hi all,

As I wasn't able to build OpenSTA due to lack of access to 
required third party tools, I binary patched the product. I'm 
not sure whether the license gives me the rights to distribute 
the patch, but I gather that it is for everybodys' best if I at 
least inform you of what I did.

I binary patched gwhttp.dll to make it work with SSL even 
after security patch MS04-004 on Internet Explorer 6.

The idea is to replace the ordinary "http://{" sequence 
with "http://-" so that IE doesn't destroy the URL when it is 
UrlEncoded. Note that this quick and dirty fix will make 
OpenSTA stop working with sites that begin with '-' (not very 
common though).

In gwhttp.dll I patched:
- Changed "http://{" to "http://-" (address ~00029380h)
- Changed "{" to "-" (address ~00029c40h)

I could write a long disclaimer here to inform you that I can't 
guarantee that the patch works, but I think you already know 
that. The patch surely seems to work for me.


----------------------------------------------------------------------

Comment By: jmrwnd (jmrwnd)
Date: 2004-09-21 09:23

Message:
Logged In: YES 
user_id=1125756

Has johnleij's fix been implemented anywhere, and is there 
any way to get this alternate version of the code?  I am 
unable to alter and build the source code myself and need a 
workaround for this problem ASAP.  I absolutely must test 
with IE6 or Netscape 6, but both escape the '{' character.

If all else fails, is there another similar tool that could record 
https traffic with these browsers that could run off of a 
laptop?  Any help is greatly appreciated.  Thanks.

----------------------------------------------------------------------

Comment By: John L (johnleij)
Date: 2004-03-16 09:28

Message:
Logged In: YES 
user_id=999135

A possible quick-fix could be to change the implementation of 
OpenSTA so that instead of using "http://{" to identify SSL, 
we could use "http://-". The latter isn't common on the 
internet and is not tampered with by MSIE.

A search through the source code gave me the idea to chage 
the value of constants CYRANO_SSL_URL and 
CYRANO_SSL_STR in HttpGateway\gwhttp\context.hpp to 
reflect this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=897856&group_id=10857

[OpenSTA-devel] [ opensta-Bugs-1747224 ] Cookies with double quote char in, badly translated to SCL

[SourceForge.net <no...@so...>]

Bugs item #1747224, was opened at 2007-07-03 12:40
Message generated for change (Comment added) made by dansut
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1747224&group_id=10857

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: HTTP Capture
Group: Behavioral
Status: Open
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Daniel Sutcliffe (dansut)
Assigned to: Daniel Sutcliffe (dansut)
Summary: Cookies with double quote char in, badly translated  to SCL

Initial Comment:
Cookies that contain the double quote character are badly translated into SCL strings.

This problem actually affects more than just Cookies - it can occur in many strings taken from the HTTP and then appearing as strings in the created SCL.  It is most easily reproduced using Cookies that already exist (static) in the browser though.

The created strings may be uncompilable or may just not be the string that the browser sent - indexing gets mixed up the translation and ~<22> effectively gets put in the wrong place in the created string.

----------------------------------------------------------------------

>Comment By: Daniel Sutcliffe (dansut)
Date: 2007-07-03 13:52

Message:
Logged In: YES 
user_id=19748
Originator: YES

A fix for this issue has been merged into the CVS HEAD.  It
will become generally available in the OpenSTA 1.4.4 release.

gwhttp.dll: 1.4.4.2
OpenSTA: 1.4.4.4

----------------------------------------------------------------------

Comment By: Daniel Sutcliffe (dansut)
Date: 2007-07-03 12:48

Message:
Logged In: YES 
user_id=19748
Originator: YES

I have recoded the modifyStringAsScl routine so that it doesn't "get
confused".  The new algorithm should be considerably more efficient
(doesn't copy strings around so much and works in a single pass), works (it
fixes this bug), and also encodes the single quote character to ~<27> for
completeness and to avoid any potential future issues.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1747224&group_id=10857

[OpenSTA-devel] [ opensta-Bugs-1747224 ] Cookies with double quote char in, badly translated to SCL

[SourceForge.net <no...@so...>]

Bugs item #1747224, was opened at 2007-07-03 12:40
Message generated for change (Comment added) made by dansut
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1747224&group_id=10857

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: HTTP Capture
Group: Behavioral
Status: Open
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Daniel Sutcliffe (dansut)
Assigned to: Daniel Sutcliffe (dansut)
>Summary: Cookies with double quote char in, badly translated  to SCL

Initial Comment:
Cookies that contain the double quote character are badly translated into SCL strings.

This problem actually affects more than just Cookies - it can occur in many strings taken from the HTTP and then appearing as strings in the created SCL.  It is most easily reproduced using Cookies that already exist (static) in the browser though.

The created strings may be uncompilable or may just not be the string that the browser sent - indexing gets mixed up the translation and ~<22> effectively gets put in the wrong place in the created string.

----------------------------------------------------------------------

>Comment By: Daniel Sutcliffe (dansut)
Date: 2007-07-03 12:48

Message:
Logged In: YES 
user_id=19748
Originator: YES

I have recoded the modifyStringAsScl routine so that it doesn't "get
confused".  The new algorithm should be considerably more efficient
(doesn't copy strings around so much and works in a single pass), works (it
fixes this bug), and also encodes the single quote character to ~<27> for
completeness and to avoid any potential future issues.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1747224&group_id=10857

[OpenSTA-devel] [ opensta-Bugs-1747224 ] Cookies with double quote char in badly translated to SCL

[SourceForge.net <no...@so...>]

Bugs item #1747224, was opened at 2007-07-03 12:40
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1747224&group_id=10857

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: HTTP Capture
Group: Behavioral
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Daniel Sutcliffe (dansut)
Assigned to: Daniel Sutcliffe (dansut)
Summary: Cookies with double quote char in badly translated  to SCL

Initial Comment:
Cookies that contain the double quote character are badly translated into SCL strings.

This problem actually affects more than just Cookies - it can occur in many strings taken from the HTTP and then appearing as strings in the created SCL.  It is most easily reproduced using Cookies that already exist (static) in the browser though.

The created strings may be uncompilable or may just not be the string that the browser sent - indexing gets mixed up the translation and ~<22> effectively gets put in the wrong place in the created string.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1747224&group_id=10857

[OpenSTA-devel] Compiling without STLport and increasing char variable limits

[Daniel S. <da...@Op...>]

It's been a while but I've at last found some time to get some things
commited into the CVS HEAD today:

- Some simple changes that allow building the code cleanly without
  any version of the STLport installed - using M$'s included STL.
  Experience has taught me that although this builds without errors
  there are still fixes required as test execution stability is not
  as good as with the recommended STLport.

- Changes that were originally provided by Thierry to make the SCL
  compiler accept larger character arrays.  I made extra changes here
  so that only one line needs to be updated in scl_limits.h and the
  other related buffers, etc. increase in size proportionally.
  Testing has shown this works well and requires no changes to the
  runtime (only to the compiler) a number of people are running 256K
  variables with no downsides - except for more memory usage, duh!

I've been encouraged to get some of this stuff out there by Bernie of
Perfomax who's been providing invaluable testing, feedback, and not
forgetting funding, to find and fix some long standing bugs in the
area of Cookie recording.  Huge thanks to him.  I'll be getting these
commited, after some more testing, in the next week or so.

Cheers
/dan
-- 
Daniel Sutcliffe <Da...@Op...>
  OpenSTA part-time caretaker - http://OpenSTA.org/

[OpenSTA-devel] [ opensta-Bugs-1718678 ] Got an error while using OpenSTA

[SourceForge.net <no...@so...>]

Bugs item #1718678, was opened at 2007-05-14 09:45
Message generated for change (Comment added) made by dansut
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1718678&group_id=10857

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build Mechanism
>Group: None
>Status: Deleted
>Resolution: Rejected
Priority: 5
Private: No
Submitted By: Hiten Dhruv (hitendhruv)
Assigned to: Nobody/Anonymous (nobody)
Summary: Got an error while using OpenSTA

Initial Comment:
Got the error while trying to run project with OpenSTA.. Error as follows.. i need proper solution for this

"fT1Dy74%2Bm8M%2BfBfg%3D"
			                         
C:\Program Files\OpenSTA\Repository\Scripts\SHOWALL.HTP(1864) : error (maxstrlen), Maximum String Length Limit Exceeded
scl: info (endnoobj), C:\Program Files\OpenSTA\Repository\Scripts\SHOWALL.HTP Completed with 1 Diagnostic - Object Deleted


----------------------------------------------------------------------

>Comment By: Daniel Sutcliffe (dansut)
Date: 2007-05-14 11:50

Message:
Logged In: YES 
user_id=19748
Originator: NO

This is not a bug - it is an SCL syntax error.

Please use support forums and check FAQ before reporting bugs - the form
where you submit bugs asks you to do this, perhaps you have a problem
reading ...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1718678&group_id=10857

[OpenSTA-devel] [ opensta-Bugs-1718678 ] Got an error while using OpenSTA

[SourceForge.net <no...@so...>]

Bugs item #1718678, was opened at 2007-05-14 13:45
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1718678&group_id=10857

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build Mechanism
Group: Serious
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Hiten Dhruv (hitendhruv)
Assigned to: Nobody/Anonymous (nobody)
Summary: Got an error while using OpenSTA

Initial Comment:
Got the error while trying to run project with OpenSTA.. Error as follows.. i need proper solution for this

"fT1Dy74%2Bm8M%2BfBfg%3D"
			                         
C:\Program Files\OpenSTA\Repository\Scripts\SHOWALL.HTP(1864) : error (maxstrlen), Maximum String Length Limit Exceeded
scl: info (endnoobj), C:\Program Files\OpenSTA\Repository\Scripts\SHOWALL.HTP Completed with 1 Diagnostic - Object Deleted


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1718678&group_id=10857

[OpenSTA-devel] [ opensta-Bugs-1439936 ] texecuter_htp.exe crash

[SourceForge.net <no...@so...>]

Bugs item #1439936, was opened at 2006-02-27 22:58
Message generated for change (Comment added) made by kieselhorst
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1439936&group_id=10857

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: HTTP Replay
Group: Crash
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: kenmoon (kenmoon)
Assigned to: Nobody/Anonymous (nobody)
Summary: texecuter_htp.exe crash

Initial Comment:
(There is an old bug from 2001 -- 438946 -- that was
closed without resolution for an earlier version of
OpenSTA; I am experiencing a similar problem with 1.4.3.2.)

Running a load test using OpenSTA, after getting
through Task 1 (<40 VUs), both Commander and NameServer
crash with a TExecuter_htp.exe error.  Memory looked
fine across the board.

Software:
OpenSTA version 1.4.3.2
(TExecuter_htp.exe version 1.4.3.3)

Commander & NameServer running on:
Windows XP (Pro) SP 1
Pentium 4, 1GB RAM

Server on which load test is being performed:
Windows Server 2003 (Standard)
Pentium III, 2GB RAM

I am uploading a zip with TExecuter_htp_ipaddress log
file and the .htp scripts if that helps.

Thanks in advance for any insight.
Regards,
Ken.

----------------------------------------------------------------------

Comment By: Dennis Kieselhorst (kieselhorst)
Date: 2007-05-08 11:56

Message:
Logged In: YES 
user_id=1223774
Originator: NO

I'm experiencing the same problem. I'm using Windows XP Pro SP2. The
following is from windows debug log (appcompat):

<?xml version="1.0" encoding="UTF-16"?>
<DATABASE>
<EXE NAME="TExecuter_HTP.exe" FILTER="GRABMI_FILTER_PRIVACY">
    <MATCHING_FILE NAME="Msglib.dll" SIZE="65536" CHECKSUM="0xAAA05FB3"
MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0"
LINK_DATE="05/12/2005 02:25:43" UPTO_LINK_DATE="05/12/2005 02:25:43" />
    <MATCHING_FILE NAME="scl.exe" SIZE="438272" CHECKSUM="0x4C8AAF09"
BIN_FILE_VERSION="1.4.3.2" BIN_PRODUCT_VERSION="1.4.3.20"
PRODUCT_VERSION="1.4.3 Release" FILE_DESCRIPTION="SCL Compiler"
COMPANY_NAME="OpenSTA Open Source Team" PRODUCT_NAME="OpenSTA"
FILE_VERSION="1.4.3.2" ORIGINAL_FILENAME="scl.exe" INTERNAL_NAME="scl"
LEGAL_COPYRIGHT="Copyrighted on an Individual File Basis"
VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x40004"
VERFILETYPE="0x1" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0"
LINKER_VERSION="0x0" UPTO_BIN_FILE_VERSION="1.4.3.2"
UPTO_BIN_PRODUCT_VERSION="1.4.3.20" LINK_DATE="05/12/2005 09:39:59"
UPTO_LINK_DATE="05/12/2005 09:39:59" VER_LANGUAGE="Sprachneutral [0x0]" />
    <MATCHING_FILE NAME="TestInit.exe" SIZE="53248" CHECKSUM="0x64FE0EB3"
BIN_FILE_VERSION="1.4.3.2" BIN_PRODUCT_VERSION="1.4.3.20"
PRODUCT_VERSION="1.4.3 Release" FILE_DESCRIPTION="Test Initiator Utility"
COMPANY_NAME="OpenSTA Open Source Team" PRODUCT_NAME="OpenSTA"
FILE_VERSION="1.4.3.2" ORIGINAL_FILENAME="TestInit.exe"
INTERNAL_NAME="TestInit" LEGAL_COPYRIGHT="Copyrighted on an Individual File
Basis" VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x40004"
VERFILETYPE="0x1" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0"
LINKER_VERSION="0x0" UPTO_BIN_FILE_VERSION="1.4.3.2"
UPTO_BIN_PRODUCT_VERSION="1.4.3.20" LINK_DATE="05/12/2005 02:44:09"
UPTO_LINK_DATE="05/12/2005 02:44:09" VER_LANGUAGE="Sprachneutral [0x0]" />
    <MATCHING_FILE NAME="TestManager.exe" SIZE="208896"
CHECKSUM="0x65A00CE2" BIN_FILE_VERSION="1.4.3.2"
BIN_PRODUCT_VERSION="1.4.3.20" PRODUCT_VERSION="1.4.3 Release"
FILE_DESCRIPTION="Test Manager" COMPANY_NAME="OpenSTA Open Source Team"
PRODUCT_NAME="OpenSTA" FILE_VERSION="1.4.3.2"
ORIGINAL_FILENAME="TestManager.exe" INTERNAL_NAME="TestManager"
LEGAL_COPYRIGHT="Copyrighted on an Individual File Basis"
VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x40004"
VERFILETYPE="0x7" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0"
LINKER_VERSION="0x0" UPTO_BIN_FILE_VERSION="1.4.3.2"
UPTO_BIN_PRODUCT_VERSION="1.4.3.20" LINK_DATE="05/12/2005 02:11:25"
UPTO_LINK_DATE="05/12/2005 02:11:25" VER_LANGUAGE="Sprachneutral [0x0]" />
    <MATCHING_FILE NAME="TExecuter_htp.exe" SIZE="1163264"
CHECKSUM="0x1CD009ED" BIN_FILE_VERSION="1.4.3.3"
BIN_PRODUCT_VERSION="1.4.3.20" PRODUCT_VERSION="1.4.3 Release"
FILE_DESCRIPTION="HTTP Test Executer(TP)" COMPANY_NAME="OpenSTA Open Source
Team" PRODUCT_NAME="OpenSTA" FILE_VERSION="1.4.3.3"
ORIGINAL_FILENAME="TExecuter_htp.exe" INTERNAL_NAME="TExecuter_htp"
LEGAL_COPYRIGHT="Copyrighted on an Individual File Basis"
VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x40004"
VERFILETYPE="0x1" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0"
LINKER_VERSION="0x0" UPTO_BIN_FILE_VERSION="1.4.3.3"
UPTO_BIN_PRODUCT_VERSION="1.4.3.20" LINK_DATE="05/12/2005 02:55:50"
UPTO_LINK_DATE="05/12/2005 02:55:50" VER_LANGUAGE="Sprachneutral [0x0]" />
    <MATCHING_FILE NAME="TExecuter_ntp.exe" SIZE="98304"
CHECKSUM="0xC205ECC8" BIN_FILE_VERSION="1.4.3.2"
BIN_PRODUCT_VERSION="1.4.3.20" PRODUCT_VERSION="1.4.3 Release"
FILE_DESCRIPTION="NT Performance Test Executer" COMPANY_NAME="OpenSTA Open
Source Team" PRODUCT_NAME="OpenSTA" FILE_VERSION="1.4.3.2"
ORIGINAL_FILENAME="TExecuter_ntp.exe" INTERNAL_NAME="TExecuter_ntp"
LEGAL_COPYRIGHT="Copyrighted on an Individual File Basis"
VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x40004"
VERFILETYPE="0x1" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0"
LINKER_VERSION="0x0" UPTO_BIN_FILE_VERSION="1.4.3.2"
UPTO_BIN_PRODUCT_VERSION="1.4.3.20" LINK_DATE="05/12/2005 02:34:28"
UPTO_LINK_DATE="05/12/2005 02:34:28" VER_LANGUAGE="Sprachneutral [0x0]" />
    <MATCHING_FILE NAME="TExecuter_smp.exe" SIZE="98304"
CHECKSUM="0x46FAC045" BIN_FILE_VERSION="1.4.3.1"
BIN_PRODUCT_VERSION="1.4.3.20" PRODUCT_VERSION="1.4.3 Release"
FILE_DESCRIPTION="SNMP Test Executer" COMPANY_NAME="OpenSTA Open Source
Team" PRODUCT_NAME="OpenSTA" FILE_VERSION="1.4.3.1"
ORIGINAL_FILENAME="TExecuter_smp.exe" INTERNAL_NAME="SNMP"
LEGAL_COPYRIGHT="Copyrighted on an Individual File Basis"
VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x40004"
VERFILETYPE="0x1" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0"
LINKER_VERSION="0x0" UPTO_BIN_FILE_VERSION="1.4.3.1"
UPTO_BIN_PRODUCT_VERSION="1.4.3.20" LINK_DATE="05/12/2005 02:40:08"
UPTO_LINK_DATE="05/12/2005 02:40:08" VER_LANGUAGE="Sprachneutral [0x0]" />
    <MATCHING_FILE NAME="TofOptimizer.exe" SIZE="24576"
CHECKSUM="0x981AF5BA" BIN_FILE_VERSION="1.4.3.1"
BIN_PRODUCT_VERSION="1.4.3.20" PRODUCT_VERSION="1.4.3 Release"
FILE_DESCRIPTION="TOF Optimization Utility" COMPANY_NAME="OpenSTA Open
Source Team" PRODUCT_NAME="OpenSTA" FILE_VERSION="1,4,3,1"
ORIGINAL_FILENAME="TofOptimizer.exe" INTERNAL_NAME="TofOptimizer"
LEGAL_COPYRIGHT="Copyrighted on an Individual File Basis"
VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x40004"
VERFILETYPE="0x1" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0"
LINKER_VERSION="0x0" UPTO_BIN_FILE_VERSION="1.4.3.1"
UPTO_BIN_PRODUCT_VERSION="1.4.3.20" LINK_DATE="05/12/2005 03:04:40"
UPTO_LINK_DATE="05/12/2005 03:04:40" VER_LANGUAGE="Sprachneutral [0x0]" />
    <MATCHING_FILE NAME="Web\Modeller\CaptureBHO.dll" SIZE="32768"
CHECKSUM="0xD275C9B7" BIN_FILE_VERSION="1.4.3.1"
BIN_PRODUCT_VERSION="1.4.3.20" PRODUCT_VERSION="1.4.3 Release"
FILE_DESCRIPTION="CaptureBHO" COMPANY_NAME="OpenSTA Open Source Team"
PRODUCT_NAME="OpenSTA" FILE_VERSION="1.4.3.1"
ORIGINAL_FILENAME="CaptureBHO.Dll" INTERNAL_NAME="CaptureBHO"
LEGAL_COPYRIGHT="Copyrighted on an Individual File Basis"
VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x4" VERFILETYPE="0x2"
MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0"
UPTO_BIN_FILE_VERSION="1.4.3.1" UPTO_BIN_PRODUCT_VERSION="1.4.3.20"
LINK_DATE="05/12/2005 09:38:22" UPTO_LINK_DATE="05/12/2005 09:38:22"
VER_LANGUAGE="Sprachneutral [0x0]" />
    <MATCHING_FILE NAME="Web\Modeller\gateway.exe" SIZE="180224"
CHECKSUM="0x80784B00" BIN_FILE_VERSION="1.4.3.1"
BIN_PRODUCT_VERSION="1.4.3.20" PRODUCT_VERSION="1.4.3 Release"
FILE_DESCRIPTION="HTTP Gateway" COMPANY_NAME="OpenSTA Open Source Team"
PRODUCT_NAME="OpenSTA" FILE_VERSION="1.4.3.1"
ORIGINAL_FILENAME="gateway.exe" INTERNAL_NAME="gateway"
LEGAL_COPYRIGHT="Copyrighted on an Individual File Basis"
VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x40004"
VERFILETYPE="0x1" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0"
LINKER_VERSION="0x0" UPTO_BIN_FILE_VERSION="1.4.3.1"
UPTO_BIN_PRODUCT_VERSION="1.4.3.20" LINK_DATE="05/12/2005 03:08:52"
UPTO_LINK_DATE="05/12/2005 03:08:52" VER_LANGUAGE="Sprachneutral [0x0]" />
    <MATCHING_FILE NAME="Web\Modeller\gwconscmd.dll" SIZE="94208"
CHECKSUM="0xA6EFC07F" BIN_FILE_VERSION="1.4.3.1"
BIN_PRODUCT_VERSION="1.4.3.20" PRODUCT_VERSION="1.4.3 Release"
FILE_DESCRIPTION="Gateway Console DLL" COMPANY_NAME="OpenSTA Open Source
Team" PRODUCT_NAME="OpenSTA" FILE_VERSION="1.4.3.1"
ORIGINAL_FILENAME="gwconscmd.dll" INTERNAL_NAME="gwconscmd"
LEGAL_COPYRIGHT="Copyrighted on an Individual File Basis"
VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x40004"
VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0"
LINKER_VERSION="0x0" UPTO_BIN_FILE_VERSION="1.4.3.1"
UPTO_BIN_PRODUCT_VERSION="1.4.3.20" LINK_DATE="05/12/2005 03:09:06"
UPTO_LINK_DATE="05/12/2005 03:09:06" VER_LANGUAGE="Sprachneutral [0x0]" />
    <MATCHING_FILE NAME="Web\Modeller\GWConsole.exe" SIZE="94208"
CHECKSUM="0xEC50CB32" BIN_FILE_VERSION="1.4.3.1"
BIN_PRODUCT_VERSION="1.4.3.20" PRODUCT_VERSION="1.4.3 Release"
FILE_DESCRIPTION="Gateway Console Command" COMPANY_NAME="OpenSTA Open
Source Team" PRODUCT_NAME="OpenSTA" FILE_VERSION="1.4.3.1"
ORIGINAL_FILENAME="GWConsole.exe" INTERNAL_NAME="GWConsole"
LEGAL_COPYRIGHT="Copyrighted on an Individual File Basis"
VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x40004"
VERFILETYPE="0x1" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0"
LINKER_VERSION="0x0" UPTO_BIN_FILE_VERSION="1.4.3.1"
UPTO_BIN_PRODUCT_VERSION="1.4.3.20" LINK_DATE="05/12/2005 02:21:45"
UPTO_LINK_DATE="05/12/2005 02:21:45" VER_LANGUAGE="Sprachneutral [0x0]" />
    <MATCHING_FILE NAME="Web\Modeller\gwhttp.dll" SIZE="225280"
CHECKSUM="0xB557D92E" BIN_FILE_VERSION="1.4.3.6"
BIN_PRODUCT_VERSION="1.4.3.20" PRODUCT_VERSION="1.4.3 Release"
FILE_DESCRIPTION="HTTP recording DLL" COMPANY_NAME="OpenSTA Open Source
Team" PRODUCT_NAME="OpenSTA" FILE_VERSION="1.4.3.6"
ORIGINAL_FILENAME="gwhttp.dll" INTERNAL_NAME="gwhttp"
LEGAL_COPYRIGHT="Copyrighted on an Individual File Basis"
VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x40004"
VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0"
LINKER_VERSION="0x0" UPTO_BIN_FILE_VERSION="1.4.3.6"
UPTO_BIN_PRODUCT_VERSION="1.4.3.20" LINK_DATE="05/12/2005 03:10:18"
UPTO_LINK_DATE="05/12/2005 03:10:18" VER_LANGUAGE="Sprachneutral [0x0]" />
    <MATCHING_FILE NAME="Web\Modeller\HttpCaptureCmd.dll" SIZE="90112"
CHECKSUM="0x3A8C7107" BIN_FILE_VERSION="1.4.3.1"
BIN_PRODUCT_VERSION="1.4.3.20" PRODUCT_VERSION="1.4.3 Release"
FILE_DESCRIPTION="HTTP Command Capture DLL" COMPANY_NAME="OpenSTA Open
Source Team" PRODUCT_NAME="OpenSTA" FILE_VERSION="1.4.3.1"
ORIGINAL_FILENAME="HTTPCaptureCmd.Dll" INTERNAL_NAME="HTTPCaptureCmd"
LEGAL_COPYRIGHT="Copyrighted on an Individual File Basis"
VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x4" VERFILETYPE="0x2"
MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0"
UPTO_BIN_FILE_VERSION="1.4.3.1" UPTO_BIN_PRODUCT_VERSION="1.4.3.20"
LINK_DATE="05/12/2005 02:25:15" UPTO_LINK_DATE="05/12/2005 02:25:15"
VER_LANGUAGE="Sprachneutral [0x0]" />
    <MATCHING_FILE NAME="Web\Modeller\Recoverer.exe" SIZE="81920"
CHECKSUM="0xE37C9EF7" BIN_FILE_VERSION="1.4.3.1"
BIN_PRODUCT_VERSION="1.4.3.20" PRODUCT_VERSION="1.4.3 Release"
FILE_DESCRIPTION="Browser Config Recoverer" COMPANY_NAME="OpenSTA Open
Source Team" PRODUCT_NAME="OpenSTA" FILE_VERSION="1,4,3,1"
ORIGINAL_FILENAME="Recoverer.exe" INTERNAL_NAME="Recoverer"
LEGAL_COPYRIGHT="Copyrighted on an Individual File Basis"
VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x40004"
VERFILETYPE="0x1" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0"
LINKER_VERSION="0x0" UPTO_BIN_FILE_VERSION="1.4.3.1"
UPTO_BIN_PRODUCT_VERSION="1.4.3.20" LINK_DATE="05/12/2005 09:39:12"
UPTO_LINK_DATE="05/12/2005 09:39:12" VER_LANGUAGE="Sprachneutral [0x0]" />
    <MATCHING_FILE NAME="Web\Modeller\stlport_vc6.dll" SIZE="720896"
CHECKSUM="0xAFE44791" BIN_FILE_VERSION="4.0.2000.707"
BIN_PRODUCT_VERSION="4.0.2000.707" PRODUCT_VERSION="4.0.2000.0707"
FILE_DESCRIPTION="STLport" COMPANY_NAME="STLport Consulting, Inc."
PRODUCT_NAME="STLport Standard ANSI C++ Libarary"
FILE_VERSION="4.0.2000.0707" ORIGINAL_FILENAME="STLPORT_VC6BUILD.DLL"
INTERNAL_NAME="stlport.dll" LEGAL_COPYRIGHT="Copyright (C) Boris Fomitchev"
VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x4" VERFILETYPE="0x2"
MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0"
UPTO_BIN_FILE_VERSION="4.0.2000.707"
UPTO_BIN_PRODUCT_VERSION="4.0.2000.707" LINK_DATE="02/09/2003 19:27:56"
UPTO_LINK_DATE="02/09/2003 19:27:56" VER_LANGUAGE="Englisch (USA) [0x409]"
/>
    <MATCHING_FILE NAME="Web\Modeller\TEHttpLib.dll" SIZE="1089536"
CHECKSUM="0x4B512159" BIN_FILE_VERSION="1.4.3.3"
BIN_PRODUCT_VERSION="1.4.3.20" PRODUCT_VERSION="1.4.3 Release"
FILE_DESCRIPTION="HTTP Test Executer DLL" COMPANY_NAME="OpenSTA Open Source
Team" PRODUCT_NAME="OpenSTA" FILE_VERSION="1.4.3.3"
ORIGINAL_FILENAME="TEHTTPlib.Dll" INTERNAL_NAME="ThreadPoolSALib"
LEGAL_COPYRIGHT="Copyrighted on an Individual File Basis"
VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x4" VERFILETYPE="0x2"
MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0"
UPTO_BIN_FILE_VERSION="1.4.3.3" UPTO_BIN_PRODUCT_VERSION="1.4.3.20"
LINK_DATE="05/12/2005 03:04:07" UPTO_LINK_DATE="05/12/2005 03:04:07"
VER_LANGUAGE="Sprachneutral [0x0]" />
    <MATCHING_FILE NAME="Web\Modeller\TModeller_Web.exe" SIZE="655360"
CHECKSUM="0xCC150E2C" BIN_FILE_VERSION="1.4.3.5"
BIN_PRODUCT_VERSION="1.4.3.20" PRODUCT_VERSION="1.4.3 Release"
FILE_DESCRIPTION="SCL Modeler" COMPANY_NAME="OpenSTA Open Source Team"
PRODUCT_NAME="OpenSTA" FILE_VERSION="1.4.3.5"
ORIGINAL_FILENAME="TModeller_web.EXE" INTERNAL_NAME="Modeler"
LEGAL_COPYRIGHT="Copyrighted on an Individual File Basis"
VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x4" VERFILETYPE="0x1"
MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0"
UPTO_BIN_FILE_VERSION="1.4.3.5" UPTO_BIN_PRODUCT_VERSION="1.4.3.20"
LINK_DATE="05/12/2005 09:38:52" UPTO_LINK_DATE="05/12/2005 09:38:52"
VER_LANGUAGE="Sprachneutral [0x0]" />
    <MATCHING_FILE NAME="Web\Modeller\Tof2Scl.dll" SIZE="49152"
CHECKSUM="0x7FA6BCFC" BIN_FILE_VERSION="1.4.3.2"
BIN_PRODUCT_VERSION="1.4.3.20" PRODUCT_VERSION="1.4.3 Release"
FILE_DESCRIPTION="TOF to SCL conversion DLL" COMPANY_NAME="OpenSTA Open
Source Team" PRODUCT_NAME="OpenSTA" FILE_VERSION="1.4.3.2"
ORIGINAL_FILENAME="Tof2Scl.Dll" INTERNAL_NAME="Tof2Scl"
LEGAL_COPYRIGHT="Copyrighted on an Individual File Basis"
VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x4" VERFILETYPE="0x2"
MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0"
UPTO_BIN_FILE_VERSION="1.4.3.2" UPTO_BIN_PRODUCT_VERSION="1.4.3.20"
LINK_DATE="05/12/2005 02:26:26" UPTO_LINK_DATE="05/12/2005 02:26:26"
VER_LANGUAGE="Sprachneutral [0x0]" />
</EXE>
<EXE NAME="kernel32.dll" FILTER="GRABMI_FILTER_THISFILEONLY">
    <MATCHING_FILE NAME="kernel32.dll" SIZE="1057792"
CHECKSUM="0x5001E0C0" BIN_FILE_VERSION="5.1.2600.2945"
BIN_PRODUCT_VERSION="5.1.2600.2945" PRODUCT_VERSION="5.1.2600.2945"
FILE_DESCRIPTION="Client-DLL für Windows NT-Basis-API"
COMPANY_NAME="Microsoft Corporation" PRODUCT_NAME="Betriebssystem
Microsoft® Windows®" FILE_VERSION="5.1.2600.2945
(xpsp_sp2_gdr.060704-2349)" ORIGINAL_FILENAME="kernel32"
INTERNAL_NAME="kernel32" LEGAL_COPYRIGHT="© Microsoft Corporation. Alle
Rechte vorbehalten." VERFILEDATEHI="0x0" VERFILEDATELO="0x0"
VERFILEOS="0x40004" VERFILETYPE="0x2" MODULE_TYPE="WIN32"
PE_CHECKSUM="0x10FA82" LINKER_VERSION="0x50001"
UPTO_BIN_FILE_VERSION="5.1.2600.2945"
UPTO_BIN_PRODUCT_VERSION="5.1.2600.2945" LINK_DATE="07/05/2006 10:55:21"
UPTO_LINK_DATE="07/05/2006 10:55:21" VER_LANGUAGE="Deutsch (Deutschland)
[0x407]" />
</EXE>
</DATABASE>

The commander detects the crash and sets the status back to enabled.

----------------------------------------------------------------------

Comment By: kenmoon (kenmoon)
Date: 2006-02-28 00:15

Message:
Logged In: YES 
user_id=1463183

Adding .htp scripts

----------------------------------------------------------------------

Comment By: kenmoon (kenmoon)
Date: 2006-02-27 23:01

Message:
Logged In: YES 
user_id=1463183

Adding .htp scripts

----------------------------------------------------------------------

Comment By: kenmoon (kenmoon)
Date: 2006-02-27 23:00

Message:
Logged In: YES 
user_id=1463183

Adding second part of TExecuter_htp log....

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1439936&group_id=10857