My current thoughts on support for getting performance data from the remote page would be to just scrape it from the standard plugin output, which is supported as the body:

PLUGIN OK - Good to go! | time=0.012s;1;10;10;0

I was also thinking about how to add support for receiving as headers, since the other supported aspects of the plugin may be transmitted as headers. My current thoughts are for a header named X-Nagios-Performance which would hold the name=value pair, separated by spaces like the normal plugin and would also allow more than one header with the data to be present:

X-Nagios-Performance: time=0.012s;1;10;10;0
X-Nagios-Performance: count=2;;;50;0 other=4;;;4;0

For Nagios::Plugin::OverHTTP itself, since the remote plugin can provide critical and warning thresholds, I was thinking of allowing for actually changing the status based on that to be made optional by default (because if the remote plugin said the status was OK but yet a performance metric it sent said that it should really be in a WARNING state, by default Nagios would have kept that as OK so I believe that my plugin should honor that as well by default). New options for the plugin would be:

--warning name=threshold
--critical name=threshold
--use-transmitted-thresholds
--override-transmitted-thresholds

The last option --override-transmitted-thresholds would cause the performance data written as the plugin’s output to be changed to match the thresholds given as the plugin’s options. This means a plugin with the given options --override-transmitted-thresholds --critical time=4 would cause the performance data to say time=0.012s;1;4;10;0 instead of time=0.012s;1;10;10;0 (note that this setting does not affect the decision of the final status code).

The goal of Test::Override::UserAgent is to be able to write response overrides easily. The module allows for the author to create a class consisting of only definitions for overrides so the override definitions do not have to be repeated in each test file. An example override class would look like:

package t::CustomUA;
 
use 5.008;
use Test::Override::UserAgent for => 'configuration';
 
# Disable live requests (the default, anyhow)
allow_live(0);
 
override_request
  host => 'localhost',
  path => '/test',
  sub {
    return [200, ['content-type' => 'text/plain'], ['Test response']];
  };
 
1;

This will cause requests that have a host of localhost and a path of /test to get a response back of text/plain with the Test response body. This configuration can then be used in a test file:

#!perl -T
 
use 5.008;
use Test::More tests => 1;
use t::CustomUA;
 
use My::Module; # Your awesome module to test
 
my $object = new_ok 'My::Module';
 
# Your module has a way to set the user agent it uses
t::CustomUA->configuration->install_in_user_agent($object->user_agent);
 
# Perhaps your module has no way to set the user agent
# or there is something down stream that uses a user agent.
my $scope = t::CustomUA->configuration->install_in_scope;
 
# Do tests that make requests by LWP::UserAgent
 
# End the scope override
undef $scope;

This could be used so that when a HEAD request comes from a specified IP address, the page can do some sort of self-check and output the results in the headers and provide back no body. This would allow for a very wide-range of live checks on a web site, giving up-to-date information regarding areas of the website they you would not notice until a user pointed out to you, allowing it to be fixed before anyone even notices.

If the response is multiple lines and it looks like HTML (like has a HTML, BODY, or HEAD tag), then the script will attempt to find the TITLE tag and put the contents as the first line of the message. If there is no TITLE tag, then it will try looking for a H1 tag.

package Node;
 
use Moose 0.89;
 
has child => (
  is  => 'rw',
  isa => 'Node',
  clearer   => 'clear_child',
  predicate => 'has_child',
  trigger   => \&_child_trigger,
);
has parent => (
  is  => 'rw',
  isa => 'Node',
  clearer   => 'clear_parent',
  predicate => 'has_parent',
);
 
before clear_child => sub {
  my ($self) = @_;
 
  # Trigger dissociate the parent from the child about to be cleared
  $self->_child_trigger(undef, $self->child);
 
  return;
};
 
sub _child_trigger {
  my ($self, $child, $previous_child) = @_;
 
  if (defined $previous_child) {
    # Remove this node as the parent of the previous child
    $previous_child->clear_parent();
  }
 
  if (defined $child) {
    # Set this node as the parent of the new child
    $child->parent($self);
  }
 
  return;
}
 
no Moose;
 
1;

I quickly saw the benefit of this new feature for my Authen::CAS::External distribution and incorporated this into the cas_url and the user_agent attributes. Now the associated LWP::UserAgent always has the proper handlers set up and strange issues where browsing to a CAS page with a user agent object formerly associated with Authen::CAS::External triggering the Authen::CAS::External library will no longer occur.