Documentation

Check Types

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. 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 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. Set how often you want the check to run in the Check Frequency field.
  3. 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
  4. 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.
  5. Select the HTTP method - GET is the default.
  6. If you want the check to follow redirects and evaluate the redirect URL change the 'Redirects:' drop down to "Follow redirects".
  7. 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.
  8. 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.
  9. 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.
  10. If you'd like to verify that a particular string is being returned, type the string into the optional 'Content String' field and set it to either 'Contains' or 'Does not contain'. The HTTP content returned is not inspected if this field is left blank.
  11. Set a time out. The default 5 seconds works fine for most situations.
  12. 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.
  13. Set the notifications you want for this check.

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 withe 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]/