This monitor requests a URL and checks the HTTP response against an expected content. If the response does not return the expected content, the monitor fails. You can use this monitor to ensure that your web pages are available for viewing, to check if a page renders properly on specific browsers, or even to check for the presence/absence of specific content. If the monitor does not find the specified content, the monitor is considered Down. As an example, check a page for a string like "Introducing WhatsUp Gold 2019" after a certain date, and if the monitor doesn't find it, then the monitor fails, and you know to update your web page.
This monitor now supports additional authentication methods for 401 challenge-based authentication. Note, this does not cover form-based authentication where a user would enter a username/password combination into a standard web form. Often internal systems run with self-signed certificates, you can now use this monitor against web pages running self-signed certificates. If you have SSL certificate errors on your webpage, like you may find on internal websites, an actual user may choose to ignore those errors and continue to the page. Previously, this scenario would cause the monitor to halt. Now, the HTTP Content Monitor supports an option to ignore SSL Certificate errors, just as a user may do, so you can monitor web pages behind any of your SSL certificates, regardless of their validity.
Now, you can also choose to have the monitor fail if a specified string is found, which is useful for detecting specific error messages. Lastly, the monitor can be created more generically than in the past, with the use of a %device.hostname variable, so you can create one monitor for use against multiple servers, such as mirrored sites. This monitor continues to support string matching with regular expressions, so you can set up robust search criteria.
Provide a unique name and description for the monitor, then configure the following:
Important: Errors can result when using invalid custom headers or when modifying headers which do not allow modification, such as the HTTP Host header. Click Request URL contents in the monitor configuration interface to test custom headers. If a problem with the header exists, WhatsUp Gold displays an error message. For example, the message "An error occurred with the requested website. Error: The 'Host' header cannot be modified directly. Parameter name: name." indicates the user entered Host:myhost.com as a custom header when the Host header cannot be modified.
Important: Depending on your individual monitor and/or application settings, the HTTP Content active monitor may not recognize HTML tags entered in the Web page content to find field. If you experience this behavior, you can troubleshoot using several methods. First, you can simply remove any HTML tags from your search content. Second, you can launch the WhatsUp Gold admin console and disable FIPS mode as enabling this feature causes WhatsUp Gold to add a space within each HTML tag to ensure a more secure networking environment. Third, you can enable the Use regular expression option.
To check content for the default page of a newly installed IIS server:
http://my-device/iisstart.htm
—where my-device is the hostname or IP address where a fresh instance of IIS is running.
To see how the HTTP Content monitor works, you can test it against one of the example documentation pages hosted by the Internet Assigned Numbers Authority (IANA):
http://www.example.com