opensta-devel — OpenSTA developer discussions

[OpenSTA-devel] [ opensta-Feature Requests-1375814 ] Ability to create files

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

Feature Requests item #1375814, was opened at 2005-12-08 00:01
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=360857&aid=1375814&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: None
Status: Open
Priority: 5
Submitted By: Usha (usha_ravi)
Assigned to: Richard Clarke (rclarke)
Summary: Ability to create files

Initial Comment:
I am working on OpenSTA 1.4.3, and many a times in my 
projet I have found the necessity of outputting the 
data retrieved in responses to files so that the next 
test can take it up as input data. Currently OpenSTA 
does not support creation of files/writing into 
files, it would be great if that feature is 
introduced.

Thanks,
Usha

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

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

[OpenSTA-devel] [ opensta-Bugs-1375234 ] https truncation of large requests

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

Bugs item #1375234, was opened at 2005-12-07 12:00
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=1375234&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: Serious
Status: Open
Resolution: None
Priority: 5
Submitted By: Sarah Williams (williams_sarah)
Assigned to: Nobody/Anonymous (nobody)
Summary:  https truncation of large requests

Initial Comment:
Am currently using OpenSTA 1.4.3
Was browsing the forum for a solution to this problem
and found that a few people have reported it too.
 
I'll detail what I've tried here:
-good-
. I've recorded a script to (upload a 10Kb file) in the
Modeler (https).
. The script get recorded correctly. It compiles. I
play it back. It works fine.
. Entire content reaches the server.
-/good-
 
-good-
. I increase the content (by 1KB) to be uploaded within
the script.
. It compiles; play back is fine. Content-length is
correctly sent by OpenSTA.
. Entire content reaches the server.
-/good-
 
-bad-
. I increase the content to around 15.7Kb
. It compiles.
. Content-length is correctly sent by OpenSTA.
. Play back times out on the upload.
. I've printed the content of the request. Only about
15227 bytes get printed.
-/bad-
 
As a side note, this  works on http

Tested on:
1. WEBLOGIC on Intel
2. Oracle 10gAS on Sun Sparc

Any workaround would be appreciated

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

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

[OpenSTA-devel] [ opensta-Bugs-897856 ] Recording HTTPS fails because newer IE escapes URL

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

Bugs item #897856, was opened at 2004-02-16 09:43
Message generated for change (Comment added) made by kikibug
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: Closed
Resolution: Fixed
Priority: 5
Submitted By: Alain Ribault (ribault)
Assigned to: Daniel Sutcliffe (dansut)
Summary: Recording HTTPS fails because newer IE escapes URL

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: kikibug (kikibug)
Date: 2005-12-07 11: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 21: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 19: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 18: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 20: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-21 00: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 21: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 20: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 16: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 16: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-696350 ] OpenSTA limit of 1664 vusers/users ?

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

Bugs item #696350, was opened at 2003-03-03 00:18
Message generated for change (Comment added) made by thefuzzball
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=696350&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
Submitted By: Ranjit Shewale (jcrvs)
Assigned to: Daniel Sutcliffe (dansut)
Summary: OpenSTA limit of 1664 vusers/users ?

Initial Comment:
OpenSTA does not display and message when it 
reaches the user/vuser limit of 1664. 
As the test continues the vusers go on loading to a limit 
of 1664 and donot increase beyond that for the http or 
web scripts. 
This is observed on platform as Windows NT Server 4.0 
with SP6.
The marked observations (reported by perfmon) as the 
1664 user limit are as follows:-
1. Handle count for the TExecutor_htp.exe - it rises 
gradually as the test starts till it reaches the saturation 
point and then remains stable (drops to 0 when the test 
stops). Now the saturation point corresponds to the 
point where cpu utilization starts increasing and later 
reaches 100%.
2. Context switches of system are high in the region 
where the cpu utilization is 100%.
3. Exception dispatches per sec are high in the region 
where the cpu  utilization is 100%.
4. File Control Operations/sec are high in the region 
where the cpu  utilization is 100%

(My conculsion: 
This makes me conclude that the NT machine 'handle 
limit' is probably around 3734 or so and when opensta 
requests more handles to the system the system starts 
returning exceptions, hence the exceptions observed are 
high here as mentioned in point 3 above

The NT help for 'File Control Operations/sec' 
says 'operations usually include file system control 
requests or requests for information about device 
characteristics or status'. This could alos be one of the 
reasons for the problem. Something like opensta is 
internally making calls to get the status of cretain 
threads etc and results into pushing the server queue to 
higher value. This in turn increases the context switches 
amongst threads)

For other non-http scripts with huge delays as 10 
minutes or so, the OpenSTA is able to exceedd the user 
limit of 1664.

There is no documentation that mentions the above 
1664 vuser limit/bug.

The perfmon file is attached for reference. Unzip the file 
and open it using the NT4.0 perfom tool.

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

Comment By: thefuzzball (thefuzzball)
Date: 2005-11-15 16:19

Message:
Logged In: YES 
user_id=1379239

Using opensta 1.4.3.20

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

Comment By: thefuzzball (thefuzzball)
Date: 2005-11-15 16:16

Message:
Logged In: YES 
user_id=1379239

Replicated this on Windows Server 2003 standard edition. 
Dual 3.2 GHZ Xeon w/ 2G ram

CPU load hovered around 97% avg. for both processors.  It
crashed the box within seconds after the 1664 users were met.

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

Comment By: Daniel Sutcliffe (dansut)
Date: 2003-04-29 21:05

Message:
Logged In: YES 
user_id=19748

More info can be added and read at:
http://portal.opensta.org/faq.php?topic=BugsMaxVu

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

Comment By: Ranjit Shewale (jcrvs)
Date: 2003-03-03 00:22

Message:
Logged In: YES 
user_id=721091

Sorry forgot to attach the file

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

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

[OpenSTA-devel] [ opensta-Bugs-696350 ] OpenSTA limit of 1664 vusers/users ?

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

Bugs item #696350, was opened at 2003-03-03 00:18
Message generated for change (Comment added) made by thefuzzball
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=696350&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
Submitted By: Ranjit Shewale (jcrvs)
Assigned to: Daniel Sutcliffe (dansut)
Summary: OpenSTA limit of 1664 vusers/users ?

Initial Comment:
OpenSTA does not display and message when it 
reaches the user/vuser limit of 1664. 
As the test continues the vusers go on loading to a limit 
of 1664 and donot increase beyond that for the http or 
web scripts. 
This is observed on platform as Windows NT Server 4.0 
with SP6.
The marked observations (reported by perfmon) as the 
1664 user limit are as follows:-
1. Handle count for the TExecutor_htp.exe - it rises 
gradually as the test starts till it reaches the saturation 
point and then remains stable (drops to 0 when the test 
stops). Now the saturation point corresponds to the 
point where cpu utilization starts increasing and later 
reaches 100%.
2. Context switches of system are high in the region 
where the cpu utilization is 100%.
3. Exception dispatches per sec are high in the region 
where the cpu  utilization is 100%.
4. File Control Operations/sec are high in the region 
where the cpu  utilization is 100%

(My conculsion: 
This makes me conclude that the NT machine 'handle 
limit' is probably around 3734 or so and when opensta 
requests more handles to the system the system starts 
returning exceptions, hence the exceptions observed are 
high here as mentioned in point 3 above

The NT help for 'File Control Operations/sec' 
says 'operations usually include file system control 
requests or requests for information about device 
characteristics or status'. This could alos be one of the 
reasons for the problem. Something like opensta is 
internally making calls to get the status of cretain 
threads etc and results into pushing the server queue to 
higher value. This in turn increases the context switches 
amongst threads)

For other non-http scripts with huge delays as 10 
minutes or so, the OpenSTA is able to exceedd the user 
limit of 1664.

There is no documentation that mentions the above 
1664 vuser limit/bug.

The perfmon file is attached for reference. Unzip the file 
and open it using the NT4.0 perfom tool.

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

Comment By: thefuzzball (thefuzzball)
Date: 2005-11-15 16:16

Message:
Logged In: YES 
user_id=1379239

Replicated this on Windows Server 2003 standard edition. 
Dual 3.2 GHZ Xeon w/ 2G ram

CPU load hovered around 97% avg. for both processors.  It
crashed the box within seconds after the 1664 users were met.

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

Comment By: Daniel Sutcliffe (dansut)
Date: 2003-04-29 21:05

Message:
Logged In: YES 
user_id=19748

More info can be added and read at:
http://portal.opensta.org/faq.php?topic=BugsMaxVu

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

Comment By: Ranjit Shewale (jcrvs)
Date: 2003-03-03 00:22

Message:
Logged In: YES 
user_id=721091

Sorry forgot to attach the file

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

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

[OpenSTA-devel] about codemax

[shrinivas d. <shr...@gm...>]

Hello All,
                I am trying to build openSTA from source.And for that
I require Codemax (latest version)Could anyone help me in getting
Codemax

Thanks & Regards
Shrinivas Dole

RE: [OpenSTA-devel] Re: Issue in building opensta from source - xmlparser.h errors

[Kamal, S. \(Cognizant\) <Swa...@co...>]

Thanks a lot Dan :)

The error was in the order I was giving the path.Had specified Visual=
 Studio include path above the platform  SDK path.Corrected it.
Also I had not installed the Internet SDK.

That solved the problem.Also i updated to ostaw32-1-4-3.
Its building better now .. hope to get it running by tomorrow.

Thanks again,
Swathy


-----Original Message-----
From: ope...@li...
[mailto:ope...@li...]On Behalf Of Daniel
Sutcliffe
Sent: Wednesday, October 19, 2005 9:35 PM
To: ope...@li...
Subject: [OpenSTA-devel] Re: Issue in building opensta from source -
xmlparser.h errors


Swathy Kamal wrote:
> I am trying to build Opensta from source on windows 2000.  I am
> using ostaw32-1-4-2.

Firstly - Why?
1.4.3 has been released for quite some time and fixes many issues,
including some build problems.  You do yourself no favors trying to
build outdated versions.  Ideally get yourself setup with anonymous
CVS access - but if that isn't possible then at the very least use
the latest source package.

> While trying to build xmlrpc files it gives the following error:
> Compiling...
> CallManager.cpp
> D:\OpenSTA\ostaw32-1-4-2\src\Architecture\XMLRelay\xmlrpc\XMLParser.h(44)=
 : error C2061: syntax error : identifier 'IXMLDOMNode'
> D:\OpenSTA\ostaw32-1-4-2\src\Architecture\XMLRelay\xmlrpc\XMLParser.h(54)=
 : error C2143: syntax error : missing ';' before '*'
> D:\OpenSTA\ostaw32-1-4-2\src\Architecture\XMLRelay\xmlrpc\XMLParser.h(54)=
 : error C2501: 'IXMLDOMNode' : missing storage-class or type specifiers
> D:\OpenSTA\ostaw32-1-4-2\src\Architecture\XMLRelay\xmlrpc\XMLParser.h(54)=
 : error C2501: 'm_pXMLNode' : missing storage-class or type specifiers
> D:\OpenSTA\ostaw32-1-4-2\src\Architecture\XMLRelay\xmlrpc\XMLParser.h(68)=
 : error C2143: syntax error : missing ';' before '*'
> D:\OpenSTA\ostaw32-1-4-2\src\Architecture\XMLRelay\xmlrpc\XMLParser.h(68)=
 : error C2501: 'IXMLDOMDocument' : missing storage-class or type=
 specifiers
> D:\OpenSTA\ostaw32-1-4-2\src\Architecture\XMLRelay\xmlrpc\XMLParser.h(68)=
 : error C2501: 'm_pXMLDoc' : missing storage-class or type specifiers
>=0D
> This error reoccurs wherever "IXMLDOMNode" is being used.  My
> Visual C++ 6.0 editor doesn't have the definition for IXMLDOMNode.
> I ve updated the VC++ with service pack 6 (as recommended in the
> pre-requisites for building OpenSTA).  But this didn't help

IXMLDOMNode is part of the MS XML SDK and not any part of Visual C++.
This points to the fact that you have either a problem with the
Platform SDK you have installed, or some issue with include PATHs.
What is your setup?  Are these the only errors you are getting?

Hope this helps,
/dan
--=0D
Daniel Sutcliffe <Da...@Op...>
  OpenSTA part-time caretaker - http://OpenSTA.org/


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
OpenSTA-devel mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/opensta-devel

This e-mail and any files transmitted with it are for the sole use of the=
 intended recipient(s) and may contain confidential and privileged=
 information.
If you are not the intended recipient, please contact the sender by reply=
 e-mail and destroy all copies of the original message.=0D
Any unauthorised review, use, disclosure, dissemination, forwarding,=
 printing or copying of this email or any action taken in reliance on this=
 e-mail is strictly=0D
prohibited and may be unlawful.

  Visit us at http://www.cognizant.com

[OpenSTA-devel] [ opensta-Bugs-897856 ] Recording HTTPS fails because newer IE escapes URL

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

Bugs item #897856, was opened at 2004-02-16 02:43
Message generated for change (Comment added) made by stampy
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: Closed
Resolution: Fixed
Priority: 5
Submitted By: Alain Ribault (ribault)
Assigned to: Daniel Sutcliffe (dansut)
Summary: Recording HTTPS fails because newer IE escapes URL

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: 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] Re: Issue in building opensta from source - xmlparser.h errors

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

Swathy Kamal wrote:
> I am trying to build Opensta from source on windows 2000.  I am
> using ostaw32-1-4-2.

Firstly - Why?
1.4.3 has been released for quite some time and fixes many issues,
including some build problems.  You do yourself no favors trying to
build outdated versions.  Ideally get yourself setup with anonymous
CVS access - but if that isn't possible then at the very least use
the latest source package.

> While trying to build xmlrpc files it gives the following error:
> Compiling...
> CallManager.cpp
> D:\OpenSTA\ostaw32-1-4-2\src\Architecture\XMLRelay\xmlrpc\XMLParser.h(44) : error C2061: syntax error : identifier 'IXMLDOMNode'
> D:\OpenSTA\ostaw32-1-4-2\src\Architecture\XMLRelay\xmlrpc\XMLParser.h(54) : error C2143: syntax error : missing ';' before '*'
> D:\OpenSTA\ostaw32-1-4-2\src\Architecture\XMLRelay\xmlrpc\XMLParser.h(54) : error C2501: 'IXMLDOMNode' : missing storage-class or type specifiers
> D:\OpenSTA\ostaw32-1-4-2\src\Architecture\XMLRelay\xmlrpc\XMLParser.h(54) : error C2501: 'm_pXMLNode' : missing storage-class or type specifiers
> D:\OpenSTA\ostaw32-1-4-2\src\Architecture\XMLRelay\xmlrpc\XMLParser.h(68) : error C2143: syntax error : missing ';' before '*'
> D:\OpenSTA\ostaw32-1-4-2\src\Architecture\XMLRelay\xmlrpc\XMLParser.h(68) : error C2501: 'IXMLDOMDocument' : missing storage-class or type specifiers
> D:\OpenSTA\ostaw32-1-4-2\src\Architecture\XMLRelay\xmlrpc\XMLParser.h(68) : error C2501: 'm_pXMLDoc' : missing storage-class or type specifiers
> 
> This error reoccurs wherever "IXMLDOMNode" is being used.  My
> Visual C++ 6.0 editor doesn't have the definition for IXMLDOMNode.
> I ve updated the VC++ with service pack 6 (as recommended in the
> pre-requisites for building OpenSTA).  But this didn't help

IXMLDOMNode is part of the MS XML SDK and not any part of Visual C++.
This points to the fact that you have either a problem with the
Platform SDK you have installed, or some issue with include PATHs.
What is your setup?  Are these the only errors you are getting?

Hope this helps,
/dan
-- 
Daniel Sutcliffe <Da...@Op...>
  OpenSTA part-time caretaker - http://OpenSTA.org/

[OpenSTA-devel] Issue in building opensta from source - xmlparser.h errors

[Kamal, S. \(Cognizant\) <Swa...@co...>]

Hi,

      I am trying to build Opensta from source on windows 2000.I am using
ostaw32-1-4-2.While trying to build xmlrpc files it gives the following=
 error:

Compiling...
CallManager.cpp
D:\OpenSTA\ostaw32-1-4-2\src\Architecture\XMLRelay\xmlrpc\XMLParser.h(44) :=
 error C2061: syntax error : identifier 'IXMLDOMNode'
D:\OpenSTA\ostaw32-1-4-2\src\Architecture\XMLRelay\xmlrpc\XMLParser.h(54) :=
 error C2143: syntax error : missing ';' before '*'
D:\OpenSTA\ostaw32-1-4-2\src\Architecture\XMLRelay\xmlrpc\XMLParser.h(54) :=
 error C2501: 'IXMLDOMNode' : missing storage-class or type specifiers
D:\OpenSTA\ostaw32-1-4-2\src\Architecture\XMLRelay\xmlrpc\XMLParser.h(54) :=
 error C2501: 'm_pXMLNode' : missing storage-class or type specifiers
D:\OpenSTA\ostaw32-1-4-2\src\Architecture\XMLRelay\xmlrpc\XMLParser.h(68) :=
 error C2143: syntax error : missing ';' before '*'
D:\OpenSTA\ostaw32-1-4-2\src\Architecture\XMLRelay\xmlrpc\XMLParser.h(68) :=
 error C2501: 'IXMLDOMDocument' : missing storage-class or type specifiers
D:\OpenSTA\ostaw32-1-4-2\src\Architecture\XMLRelay\xmlrpc\XMLParser.h(68) :=
 error C2501: 'm_pXMLDoc' : missing storage-class or type specifiers

This error reoccurs wherever "IXMLDOMNode" is being used.My Visual C++ 6.0=
 editor doesn't have the definition for IXMLDOMNode.I ve updated the VC++=
 with service pack 6 (as recommended in the pre-requisites for building=
 OpenSTA).But this didn't help

Any help regarding this is welcome.

Thanks,
Swathy

This e-mail and any files transmitted with it are for the sole use of the=
 intended recipient(s) and may contain confidential and privileged=
 information.
If you are not the intended recipient, please contact the sender by reply=
 e-mail and destroy all copies of the original message.=0D
Any unauthorised review, use, disclosure, dissemination, forwarding,=
 printing or copying of this email or any action taken in reliance on this=
 e-mail is strictly=0D
prohibited and may be unlawful.

  Visit us at http://www.cognizant.com

[OpenSTA-devel] [ opensta-Bugs-524883 ] Gateway can hang on compressed Response body.

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

Bugs item #524883, was opened at 2002-03-02 13:16
Message generated for change (Comment added) made by dansut
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=524883&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: Crash
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Dan Connelly (dsconnelly)
Assigned to: Daniel Sutcliffe (dansut)
Summary: Gateway can hang on compressed Response body.

Initial Comment:
Most HTTP 1.1 browsers will allow the server to send 
HTTP response bodies with GZIP or "deflate" body text.

However, when the server does so during Script 
Modelling, the gateway will hang.

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

>Comment By: Daniel Sutcliffe (dansut)
Date: 2005-10-08 17:14

Message:
Logged In: YES 
user_id=19748

sayalik: If you had read this problem report you would have
seen that it has little to do with the issues you comment
on.  Your recording issue may be a new occurence of
bug#475128 but it is difficult to tell with the limited
details you provided.

If you had read the FAQ entry about reporting bugs that is
pointed to at the top of the form to submit a new bug you
would have also seen that this is not a support forum and
you are very much not following the suggested bug reporting
protocol!

Finally, the urgency (or not) of your situation is of no
interest in the entries of this bug database for this free
toolset.  If you really have an urgent need to find
solutions for your issues then I can only suggest you take
advantage of some of the fine commercial support available
for this toolset - links are in the FAQ.

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

Comment By: Sayali (sayalik)
Date: 2005-10-06 10:44

Message:
Logged In: YES 
user_id=1354482

Hi,
I am recording scripts using OpenSTA 1.4.3. The gateway 
hangs while recording the script containing a zip file upload. 
Is there a resolution to the problem?
I recorded the scripts after a lot of pains and reinstalls, and 
now on running the tests, I am getting errors : 

Timeout generated for socket 0xf4
IO failed for VU 2-1 on connection 0/27 with error 258: (The 
wait operation timed out.  ).
ERROR 2148074255 while receiving data on a secured 
connection on connection 0/28.

This problem requires urgent resolution, so it will be greatly 
appreciated if you can provide one.
Thanks and regards.

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

Comment By: Daniel Sutcliffe (dansut)
Date: 2005-04-24 21:50

Message:
Logged In: YES 
user_id=19748

Compressed content-encoding HTTP does not presently have any
support in OpenSTA.  This problem should be dealt with in a
cleaner fashion - if full support fro compressed HTTP
implemented then it will be provided under this feature request:
 
http://sourceforge.net/tracker/index.php?func=detail&aid=746432&group_id=10857&atid=360857

The actual symtoms of this problem are varied - the crashing
symtom may be improved by the fix for 475128.  Please add a
comment if you still see this issue in OpenSTA>1.4.3

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

Comment By: Antony Marcano (antonym)
Date: 2003-06-02 04:28

Message:
Logged In: YES 
user_id=403001

Tried this against www.google.com with 1.4.1 and 1.4.2 and
this problem was not reproducible, however, a client was
experiencing  an issue where no page was returned but the
browser believed it was 'done' which appears to be related
(no more detail available at this time).

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

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

[OpenSTA-devel] [ opensta-Bugs-524883 ] Gateway can hang on compressed Response body.

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

Bugs item #524883, was opened at 2002-03-02 18:16
Message generated for change (Comment added) made by sayalik
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=524883&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: Crash
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Dan Connelly (dsconnelly)
Assigned to: Daniel Sutcliffe (dansut)
Summary: Gateway can hang on compressed Response body.

Initial Comment:
Most HTTP 1.1 browsers will allow the server to send 
HTTP response bodies with GZIP or "deflate" body text.

However, when the server does so during Script 
Modelling, the gateway will hang.

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

Comment By: Sayali (sayalik)
Date: 2005-10-06 14:44

Message:
Logged In: YES 
user_id=1354482

Hi,
I am recording scripts using OpenSTA 1.4.3. The gateway 
hangs while recording the script containing a zip file upload. 
Is there a resolution to the problem?
I recorded the scripts after a lot of pains and reinstalls, and 
now on running the tests, I am getting errors : 

Timeout generated for socket 0xf4
IO failed for VU 2-1 on connection 0/27 with error 258: (The 
wait operation timed out.  ).
ERROR 2148074255 while receiving data on a secured 
connection on connection 0/28.

This problem requires urgent resolution, so it will be greatly 
appreciated if you can provide one.
Thanks and regards.

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

Comment By: Daniel Sutcliffe (dansut)
Date: 2005-04-25 01:50

Message:
Logged In: YES 
user_id=19748

Compressed content-encoding HTTP does not presently have any
support in OpenSTA.  This problem should be dealt with in a
cleaner fashion - if full support fro compressed HTTP
implemented then it will be provided under this feature request:
 
http://sourceforge.net/tracker/index.php?func=detail&aid=746432&group_id=10857&atid=360857

The actual symtoms of this problem are varied - the crashing
symtom may be improved by the fix for 475128.  Please add a
comment if you still see this issue in OpenSTA>1.4.3

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

Comment By: Antony Marcano (antonym)
Date: 2003-06-02 08:28

Message:
Logged In: YES 
user_id=403001

Tried this against www.google.com with 1.4.1 and 1.4.2 and
this problem was not reproducible, however, a client was
experiencing  an issue where no page was returned but the
browser believed it was 'done' which appears to be related
(no more detail available at this time).

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

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

[OpenSTA-devel] Re: Possible Issue with applications sending two cookies at once

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

Daniel Sutcliffe wrote:
> It sounds like OpenSTAs SCL always selects the 1st header - I can
> believe this but need to check it - and that the browsers that the
> Princeton guys were using always selected the last header.

I've checked this now and OpenSTA definitely will always select the
1st header when asked to query duplicate headers - this, along with
the fact that every browser I tried will use the last duplicate
header, means that this really is a bit of a bug.  The workaround
for it, parsing headers in SCL, is not pretty either.

> If the defined behavior of a browser is that later HTTP headers
> override earlier ones - need to find RFC and check for this - then
> SCLs behavior is clearly wrong!  If it is not a defined behavior
> but all (most) browsers exhibit the latter HTTP headers override
> behavior then OpenSTAs behavior is "not desirable".

The closest comment I can find with regard to this behavior was in
rfc2616, which in section 4.2 "Message Headers" states:
 'Multiple message-header fields with the same field-name MAY be
  present in a message if and only if the entire field-value for that
  header field is defined as a comma-separated list [i.e., #(values)].
  It MUST be possible to combine the multiple header fields into one
  "field-name: field-value" pair, without changing the semantics of
  the message, by appending each subsequent field-value to the first,
  each separated by a comma.  The order in which header fields with
  the same field-name are received is therefore significant to the
  interpretation of the combined field value, and thus a proxy MUST
  NOT change the order of these field values when a message is
  forwarded.'
This says that:
  Set-Cookie: cook1=A
  Set-Cookie: cook1=B
Should be equivalent to:
  Set-Cookie: cook1=A, cook1=B

This looks promising but doesn't help a great deal because rfc2109,
which defines the COokie mechanism, allows this but doesn't seem to
specifically define what happens when a the same cookie is Set twice
in the same header any more than it does when they are in seperate
headers.  What it does say in Section 4.3.3 "Cookie Management" is:
 '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.  However, if the Set-
  Cookie has a value for Max-Age of zero, the (old and new) cookie is
  discarded.  Otherwise cookies accumulate until they expire
  (resources permitting), at which time they are discarded.'
Which is obviously intended to describe redefinition of Cookies in
seperate HTTP transactions but I guess can be thought to apply to our
case as well.

Does anyone have anything further to comment on this?  If not I'll
create a bug report ...

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

[OpenSTA-devel] Re: Codemax(tested with 2.1.0.24)

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

Swathy Kamal wrote:
> I am trying to build OpenSTA from source.  And for that I require
> Codemax 2.1.0.24.  Could anyone help me in getting Codemax
> 2.1.0.24.

I've helped Swathy to find a copy of this.

Also - this is the last HTML formatted mail that will get through to
this mailing list, measures have been taken to reject any further
multipart emails.

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

[OpenSTA-devel] Codemax(tested with 2.1.0.24)

[swathy k. <swa...@ya...>]

Hi All,
 
  I am trying to build openSTA from source.And for that I require Codemax 2.1.0.24.
Could anyone help me in getting Codemax 2.1.0.24.
 
Thanks in advance,
Swathy

		
---------------------------------
Yahoo! for Good
 Click here to donate to the Hurricane Katrina relief effort. 

Re: [OpenSTA-devel] Help on setting up Bandwidth for the VU in Open STA

[Noelle K. B. <no...@tc...>]

Srinivas:

You wrote:
> Please help me out in setting up bandwidth for the
> Virtual Users in OpenSTA.

You are posting this question on the wrong list.  This is the 
Developer's mailing list - a list for OpenSTA Developer discussions. 
For questions and discussions concerning the use and limited support of 
OpenSTA you should post on the OpenSTA User's mailing list.

Also, you may want to review the FAQ first before posting a question as 
simple as this to the User's list.  The FAQ is located here: 
http://portal.opensta.org/faq.php, and I am sure that if you read 
through this document you will find the help that you need.

-- 
Noelle Kristen Beaudin
OpenSTA docs

[OpenSTA-devel] Help on setting up Bandwidth for the VU in Open STA

[Srinivas N. <sre...@ya...>]

Dear All,

Please help me out in setting up bandwidth for the
Virtual Users in OpenSTA.

Thanks & Regards
Srinivas


		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

[OpenSTA-devel] [ opensta-Bugs-1013510 ] Blank graphs or TestPlugin errors from bad results analysis

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

Bugs item #1013510, was opened at 2004-08-21 19:44
Message generated for change (Comment added) made by chrisrmead
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
Submitted By: Daniel Sutcliffe (dansut)
Assigned to: Daniel Sutcliffe (dansut)
Summary: Blank graphs or TestPlugin errors from bad results analysis

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: chris mead (chrisrmead)
Date: 2005-08-25 16: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 15: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 12: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] Re: Possible Issue with applications sending two cookies at once

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

Olaf Kock wrote:
> I can't say if this really qualifies as tomcat bug, the same may
> occur from any web application and is probably difficult to track
> down.

I don't think it really matters whether it is a tomcat bug or not ...
It is fairly easy to create a Web application that has multiple
Set-Cookie: headers with the same name - job for tomorrow.  Perhaps
this makes a buggy Web application, but then again ...

> Is it worth thinking about handling the situation of two cookies
> of the same name in OpenSTA?

It sounds like OpenSTAs SCL always selects the 1st header - I can
believe this but need to check it - and that the browsers that the
Princeton guys were using always selected the last header.  If the
defined behavior of a browser is that later HTTP headers override
earlier ones - need to find RFC and check for this - then SCLs
behavior is clearly wrong!  If it is not a defined behavior but all
(most) browsers exhibit the latter HTTP headers override behavior
then OpenSTAs behavior is "not desirable".

It probably wouldn't be too difficult to change the LOAD
RESPONSE_INFO HEADER behavior, but ... possibilities of breaking
peoples existing scripts.  Reading the SCL Ref doc:
  http://opensta.org/docs/sclref/load-response_info-header.htm
I think we have to consider the wildcard operation of this command
and also the behavior of specifying "other" HTTP headers which may
also be duplicated ...

Looks to me like this command needs a better identifier syntax just
like its LOAD RESPONSE_INFO BODY sibling.

Thoughts, comments, suggestions?
/dan
-- 
Daniel Sutcliffe <Da...@Op...>
  OpenSTA part-time caretaker - http://OpenSTA.org/

[OpenSTA-devel] Possible Issue with applications sending two cookies at once

[Olaf K. <ok...@ab...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

regarding Joseph Celanos thread "Tomcat 5.0 Session Info Not Maintained"
on the user mailing list I thought it might be good to discuss an
external bug report here - I have not yet tried what they say there but
it seems reasonable:

I can't say if this really qualifies as tomcat bug, the same may occur
from any web application and is probably difficult to track down. Is it
worth thinking about handling the situation of two cookies of the same
name in OpenSTA?

Or do I sound stupid and should rephrase what I wanted to ask?

Cheers,
Olaf


http://jasigch.princeton.edu:9000/jira/browse/UP-819

The text there is:

LoginServlet.java performs the following calls unconditionally:

  request.getSession().invalidate();
  request.getSession(true);

This results in exposing an apparent bug in Tomcat, which will generate
two Set-Cookie headers for JSESSIONID. JSESSIONID is diferent in both,
and the second one represents a valid session. Most browsers will take
the second cookie and will function.

We discovered the problem when running OpenSTA for load-testing, and
OpenSTA, probably erroneously, picks the first cookie, which does not
represent a valid session. Knowing of no easu way to modify OpenSTA, we
have found that changing the above lines of code works around the problem:

    if (request.getSession(false) != null)
      request.getSession().invalidate();
    // Retrieve the user's session
    request.getSession(true);
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFC+3MSrOvgD3EqpS4RAnVhAJ4vZ6YKtb8WBzf5ilZTvDjp00gOQwCfQ2ZO
Jtc9U5DCgn0rR44j0CjPdGg=
=hEyK
-----END PGP SIGNATURE-----

[OpenSTA-devel] Re: CodeMax 2.1.0.24

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

Daniel Sutcliffe wrote:
> > I can make the required Codemax available to you whatever - I just
> > need to know that you are willing to work with us and "share" your
> > ideas and code before I make the effort to help you... :-)

Holger Koch wrote:
> Thanks for your great offer. I fixed it.

That's lovely - except we have no idea what you fixed or how you
fixed it!

For your input to be of some use to the community we need to know
these facts.  I specifically want to know all and *ANY* problems with
the software, and if there are fixes available that it is nice if
they can be publically known so everyone that makes use of OpenSTA
can make use of them - with getting fixes included into released
product being the primary goal.

The only reason OpenSTA is not a better tool than it is now is an
attitude of "take take take" with very little "give back".  That's
not how open source works - and is the main reason OpenSTA releases
don't happen more often with more improvements.

Please tell us what you fixed and how,
/dan
-- 
Daniel Sutcliffe <Da...@Op...>
  OpenSTA part-time caretaker - http://OpenSTA.org/

Re: [OpenSTA-devel] Help about existing tools.

[Olaf K. <ok...@ab...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Guillaume Insa schrieb:
> Good morning everybody,
> 
> I am requiring some help about OpenSTA. Is it able to test the SMTP protocol ? 
> Because I am searching a tool which could realise end-to-end mailing tests and I 
> would be very grateful if you could bring me some help (about the 
> functionalities of this software or advice about other tools that could support 
> mail protocols).

Hi,

you are asking this on the developer mailing list, where you are most
likely not going to get the answers that you asked for.

You can find information about what OpenSTA does in the faq
(http://portal.opensta.org/faq.php), specifically in the very first
question.

Cheers,
Olaf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFC8y+RrOvgD3EqpS4RAvhNAJ93WYuXVZW3V+uDbpRw6DGC+0yZvgCfSy0T
tx9R0gUaWtJTkaMK1WdyWto=
=xYJQ
-----END PGP SIGNATURE-----

[OpenSTA-devel] Help about existing tools.

[Guillaume I. <gu...@ho...>]

<html><div style='background-color:'><FONT size=2>
<P>Good morning everybody, </P>
<P>I am requiring some help about OpenSTA. Is it able to test the SMTP protocol ? Because I am searching a tool which could realise end-to-end mailing tests and I would be very grateful if you could bring me some help (about the functionalities of this software or advice about other tools that could support mail protocols). </P>
<P>Thank you very much in advance.</P></FONT>
<DIV class=RTE></DIV></div></html>

Re: [OpenSTA-devel] Re: CodeMax 2.1.0.24

[Holger K. <ho...@gm...>]

Hi Dan,

Thanks for your great offer. I fixed it.

Regards Holger

On 8/2/05, Daniel Sutcliffe <da...@op...> wrote:
> Holger Koch wrote:
> > > but it looks like it doesn't work with IE6, because MS replaces the
> > > character with %7B which doesn't help much.
>=20
> This problem:
>   http://sourceforge.net/tracker/?group_id=3D10857&atid=3D110857&func=3Dd=
etail&aid=3D897856
> Is supposed to be fixed in 1.4.3.  If you are having an issue then
> please tell us exactly the symtoms and how to reproduce the problem
> and I'll fix it - I know this code pretty well now ;-)
>=20
> Olaf Kock wrote:
> > As far as I understand http://%7B is now equivalent to http://{ and
> > is interpreted by the gateway in the same way. That is: you see
> > http://%7B and the gateway will connect https:// to your server and
> > record https:// urls in your script.
> >
> > Somebody correct me if I'm wrong - it's been a long time since I
> > recorded https traffic.
>=20
> You entirely are correct Olaf.
>=20
> The initial posted workaround for the issue was executable patching
> to replace the '{' with a '-' , I wasn't entirely happy with this
> approach for a real fix so I just made the gateway see '{' and '%7B'
> as equivalent.  It wasn't quite that simple but that was the outcome.
>=20
> Holger: I am interested in your thoughts on a "workaround",
> especially where you need Codemax to rebuild the Modeler... both of
> the previous "fixes" for this issue are not in Modeler code at all.
>=20
> I can make the required Codemax available to you whatever - I just
> need to know that you are willing to work with us and "share" your
> ideas and code before I make the effort to help you... :-)
>=20
> Cheers
> /dan
> --
> Daniel Sutcliffe <Da...@Op...>
>   OpenSTA part-time caretaker - http://OpenSTA.org/
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclic=
k
> _______________________________________________
> OpenSTA-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensta-devel
>

[OpenSTA-devel] Re: New to OpenSTA, need help

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

Please repost this question to the OpenSTA Users List:
  http://lists.sf.net/lists/listinfo/opensta-users

This is the OpenSTA Developers Mailing List - ie. it is for
discussing the building and enhancing of OpenSTA, and not its
general use and problems with this...

I'll answer your issue on the users list; it has nothing to do with
certificates and should be answered by the FAQ...

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