WAS Test

[Rogan Dawes <rogan@dawes.za.net>]

Hi folks,

> 
> I am not sure we ever set the playing field (I am sounding so American
> even as I type, please forgive me) in terms of exactly what we hoped WAS
> would acomplish that VulnXML didn't ie the extensions idea, the ability
> to issue concurrent requests etc.
> 

The major things I was thinking about that we should change from VulnXML 
are:

* Support for a <ThreadGroup> construct

* Definition of some "external" tests that would be implemented by the 
engine, and not explicitly done by WAS-XML. The major one I was thinking 
of was Custom404 handling, which can be handled in a much better way by 
a particular implementation, than by explicitly stating how to test for 
a Custom404 in every WAS test.

<ThreadGroup> I see as being at the same level as a 
<Request><Response><Test> cycle, defining a group of threads that 
execute a number (possibly 1) of <Request><Response><Test> cycles. I'm 
going to abbreviate <Request><Response><Test> as R-R-T in future ;-)

So you might have 1 or more R-R-T cycles, then a ThreadGroup that 
defines 2 or more threads that execute independently, performing 1 or 
more R-R-T cycles in each. The definition of each Thread will allow for 
introduction of delays if necessary, but would default to executing as 
fast as possible. The thread group would also define criteria to 
determine whether to continue, once all the child threads have 
completed. This could again then be followed by 0 or more R-R-T cycles.


The Custom404 issue could be handled by a specific attribute in the 
<Test> element. My thinking is that the engine might start off by 
checking the server to see how it responds to a request for an obviously 
non-existent page. If it gets a 404, fine, this is how the server 
responds to non-existent pages. If it gets a 200, or 302, it needs to 
enable more detailed error handling, which is inappropriate to hard-code 
in the test file itself, to my thinking.

Thoughts?

Rogan