Checking the availability of a server resource

HEAD Method

Preliminaries

This note provides supplementary information about the server's implementation of the standard HTTP HEAD method which is used to check resource availability.

The HEAD method is the nearly-identical twin to the GET method, performing all of the same processing steps, but without actually sending any data in the response payload. Crawlers often issue HEAD requests as a surrogate when checking to see if a resource is available.

Request/response handlers

The server's request/response cycle for HEAD requests is handled by this sequence:

Request Handler Optional Configurable
1 Server Name Indication no no
2 Hosts no yes
3 IP Access yes yes
4 Resource Masks yes yes
5 Raw Path no no
6 Cookies no no
7 Forbidden yes yes
8 Cross Origin yes yes
9 RBAC yes yes
10 User Agent yes yes
11 Accept Types no yes
12 Accept Language yes yes
Dynamic Handler Optional Configurable
13 Router yes yes
Response Handler Optional Configurable
14 File Permissions no no
15 Content Types no yes
16 Etag yes no
17 If Modified Since no no
18 Last Modified no no
19 Cache Control yes yes
20 Range * yes no
21 Content Encoding yes yes
22 Content Length no no
23 Status Codes no yes
* The server adds an accept-ranges header to the response in order to inform the caller that range requests are allowed. † Content encoding is performed with HEAD requests, if necessary, and the compressed file is saved to the encoding-cache for subsequent calls; the content-length header reflects the compressed file size. ‡ The content-length response header is the number of bytes that would be sent if this were a GET request; the response payload itself, in a HEAD request, is always empty.

Checking the availability of a server resource