Re: generic protocol test [Re: Features...]

[Christian Hopp]

On Sun, 28 Sep 2003, Christian Hopp wrote:

> On Fri, 26 Sep 2003, Jan-Henrik Haukeland wrote:
>
> > Martin Pala <address@hidden> writes:
> >
> > > Christian Hopp wrote:
> > >
> > >>1) Generic protocol test...
> > >>
> > >>   if failed port 1234 [{expect|send} "string" [{expect|send} "string"] 
> > >> ...]
> > >>
> > >>   Actually it is quite self explaining...  for every "send" the
> > >>   "string" is sent through the connection (w/ or w/o ssl), and for
> > >>   every "expect" the return is read and matched against the "string".
> > >>
> > > This seems good :) Maybe only instead of "send" we can use already
> > > present "request" word, which serves for the same purpose in already
> > > implemented protocol tests (such as http).
> >
> > (I think request should only be used for requesting a document entity
> > from a server, while expect|send is more of a protocol test.)
> >
> > Yes, expect|send seems like a good idea, because it's a way to
> > implement a protocol in the configure file, instead of implementing it
> > as a protocol C-module.
> >
> > You will probably need to use the keywords send and expect because not
> > all protocols will send you a greating, e.g. HTTP.
> >
> > if failed port 80 send "HEAD / HTTP/1.0" expect "HTTP/1.1 200"
> >
> > But implementing this will (probably) quickly raise a request for
> > supporting simple reg. exp. in a string for this to really become
> > useful.  Consider the above http test, here the answer from the server
> > could either be "HTTP/1.1 200" or "HTTP/1.0 200" where both are okay,
> > so as a user I would really like to do something like this:
> >
> > if failed port 80 send "HEAD / HTTP/1.0" expect "HTTP/1.[01]{1,1} 200"
> >
> > Maybe the gnu regexp package could be used, but I don't think that we
> > should support regexp in the first version :)
>
> It's no big deal.  I have just played around with libpcre (perl compatible
> REs).  It really easy to use for our purpose.  And pcREs are are most
> comfortable... IHMO the best of perl since ever. (-:  If it's okay I gonna
> do a pcre version (and --without-pcre just with strings).  Okay?

I have moved to POSIX regex... (-:  we don't need any additional libs and
we still have extended regexs.

CHopp

-- 
Christian Hopp                                email: address@hidden
Institut für Elektrische Informationstechnik             fon: +49-5323-72-2113
TU Clausthal, Leibnizstr. 28, 38678 Clausthal-Zellerf.   fax: +49-5323-72-3197
                             pgpkey: https://www.iei.tu-clausthal.de/pgp-keys/