Documentation

HTTP Advanced Checks

About HTTP Advanced Checks

HTTP Advanced Checks are very similar to HTTP and HTTP Content checks, except that HTTP Advanced checks provide additional features for those who need more granular control of either the request or the response verification. HTTP is the transfer protocol for web pages, as well as being used for some other web based technologies. HTTP is a request-response protocol. The client, in most cases in daily life a browser, sends a request to a server and the server sends a response back, hopefully with the information the user was hoping to get. The response includes a header component and a content component along with an HTTP status code. The content component is the part of the response people see in their browser. It's the part that contains the HTML. The HTTP Advanced check can make all kinds of HTTP requests including: GET, POST, PUT, and DELETE methods. Optionally sign your HTTP request with your own TLS X.509 client certificate. This check allows you to verify the returned HTTP status code. send custom headers, verify received headers, as well as POST data as a form would. You can also specify a content string or regex you expect to find in the content that is returned. This check type supports either positive or negative content string checking, meaning that it can be configured to treat the check as passing if the page includes the content, or it can treat the check as passing if the page does not include the content.

When to use HTTP Advanced Checks

You should use HTTP Advanced checks instead of regular HTTP or HTTP Content checks anytime you need to:

• monitor specific HTTP status codes that are returned
• send specific headers
• verify specific headers are being received
• send PUT, DELETE, HEAD, TRACE, or CONNECT methods
• POST form data or raw content like JSON or XML

Using HTTP Advanced Checks

To set up a HTTP Advanced check,

1. Select HTTP Advanced from the Check type drop down.
2. Give it a friendly label to identify this check in lists and notifications.
3. Enable Automated Diagnostics if you'd like detailed technical info about the failure that may help you troubleshoot a failure.
4. Set how often you want the check to run in the Check Frequency field.
5. Enter the target URL you want to check. It must be a valid URL, starting with either http:// or https://. Any valid URL will work fine, including basic authentication, port numbers, and query strings. If you use the authentication feature for this check, or otherwise include confidential information in your checks, please keep our Terms of Service in mind and limit the access provided by the credentials you use. The following examples are all valid (although these are fictitious, don't actually use these URL's in your checks):
   • http://www.example.com
   • http://couchdb.example.com:5984
   • https://www.example.com/foo/bar.html
   • http://www.example.com/foo/bar.html?this=that&eggs=green
   • https://sam:secret@www.example.com/foo/bar.html?this=that&eggs=green
   • http://[2606:c700:4020:11::53:4a3b]/index.php
6. To force an IPv6 resolution for the FQDN in your URL, change the dropdown from "(Default IP resolution)" to "Force IPv6 resolution". If you're unsure, the default is what you want.
7. Optionally set the HTTP status code you expect from the server in the Status Code field. If you don't enter a code, any status not 200-399 will be considered invalid and the check will fail. If you set this to 0, the response HTTP status code will be ignored.
8. Select the HTTP method - GET is the default.
9. If you want the check to follow redirects and evaluate the redirect URL change the 'Redirects:' drop down to "Follow redirects".
10. Optionally choose to sign your HTTPS request with your own TLS X.509 client cert by choosing it from the 'Client Certificate Auth' drop down. You can upload your client certs and keys in the 'Account Settings' - 'Certs and Keys' tab.
11. Optionally set any headers you'd like to send with your HTTP request in the Request Headers fields. Example: 'User-Agent' in the Header field and 'Chrome' in the Value field. Add as many headers as you need by clicking on the 'add another header' link. More header fields will appear.
12. Optionally set any headers you'd like to verify from the response in the Response Headers fields. Example: 'Content-Type' in the Header field and 'text/html' in the Value field. Add as many headers as you need by clicking on the 'add another header' link. More header fields will appear.
13. If you select the POST HTTP method, you can optionally add POST data to send along with your request. By default the data will be sent as 'application/x-www-form-urlencoded' in the body of the request. Example: 'username' in the Field input and 'joe@example.com' in the value input. Add as much POST data as you need by clicking on the 'add another field' link. More POST data fields will appear. You can also POST arbitrary data like XML or JSON by clicking on the 'Change to data block' link and then putting your raw data in the 'POST Block:' field. You'll likely need to add a Request Header for Content-Type you're sending.
14. If you'd like to verify that particular words appear or do not appear on the webpage being checked, type the words you're checking for into the optional 'Content String' field and set it to either 'Contains' or 'Does not contain'. The website's content is not inspected if this field is left blank.
15. You can use the 'Exact Match'/'Regex' dropdown to have the check treat the 'Content String' field as a regular expression. Exclude the opening and closing slashes, '/' in your regex. Example: '[Ss]ilent' not '/[Ss]ilent/'
16. Set a time out. The default 5 seconds works fine for most situations.
17. Set the Sensitivity. High is usually appropriate. Some web hosts have intermittent periods of time when they don't respond quickly. For a visitor this might not be a big deal if it is intermittent, but it might mean you'll get more "FAIL" responses than you anticipate. In those cases, set the Sensitivity lower.
18. Set the notifications for this check. More information about notifications.

Other considerations

You can use this check to verify your website is returning different content for mobile browsers by sending different headers.

The content returned doesn't have to be HTML - for instance, you can use this check to see if a PDF file is being returned by verifying return header 'Content-Type' is set to value 'application/pdf'.

There is a 3MB limit for this check on the data received from the server. If your URL returns more than 3MB of data, this check will fail.

When following redirects, there is a 4 redirect limit then the check will fail with the following error "Too many redirects".

The threshold timeout applies for all redirect requests and responses, not just the last HTTP request.

IPv6 URLs require the bracket formatting such as http://[2606:c700:4020:11::53:4a3b]/

SSLv3/TLS1.0 are not supported.

To defeat caching services, add an additional query string parameter with the value set to '{{now}}' and we'll put a MS timestamp in there at run time. Example: https://nodeping.com/?cachebusting={{now}}