On Fri, 19 Jan 2001, Daniel Stenberg wrote:

> First, what is netsaint and why do you/we need to add hard-coded netsaint-
> specific code in curl?

Netsaint is a monitoring tool for Linux. It can run plugins on hosts. We
run curl from netsaint to do http diagnostics.

> > -g Netsaint URL check mode. Retrieves URL and returns
> > one line of text describing the event and status 0=ok, 1=warning
> > 2-error
>
> In other words, you have an option to set another option? Most people simply
> use -w/--write-out for this.

-g sets other options true. But it also changes the return codes that
curl produces.

> Normally, when people want to check regexes against the contents of a web
> page, they use curl (or libcurl) to get the page and then another tool or
> package does the regex stuff.

well that would involve:

1. Significant overhead. We run hundreds of curl operations per minute.

2. The native HTTP error code checking in curl does not work if curl
returns the text.

> > -j <http-code> Allows the treatment of an http error code as an OK
> > condition. This is necessary when checking f.e. the presence of a
> > http page that requries authentication (code 404). In that case 404 is
> > evidence that the URL works as designed.
>
> Curl doesn't treat HTTP error codes as error conditions. This patch seems to
> add nothing that isn't already supported. Or what is the rational behind
> this?

Curl does treat http error codes as error conditions. See the -f option.

> All in all, how come you don't just write a perl wrapper around curl that
> does all this stuff you want? Or, if you can come up with a solution that
> doesn't modify libcurl, you can make a clone of the curl client that uses
> libcurl and make a 'netsaintcurl' client that is made purely for that
> purpose, separated from curl the general-purpose client.

We did have a perl wrapper first but we ran into troubles with performance
as well as the problem of getting all the info we needed. We needed to run
curl twice with different options to get all the info. That was not
acceptable.

> Please join the list to make discussions around this easier.

ok.
Received on 2001-01-19