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.