[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: generic protocol test [Re: Features...]
From: |
Christian Hopp |
Subject: |
Re: generic protocol test [Re: Features...] |
Date: |
Mon, 29 Sep 2003 17:24:35 +0200 (CEST) |
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/