Subject: Should I implement response to "HEAD" request?

From: "Alexey Tal" <[email-masked]>
Date: Mon, 17 Nov 2003 13:23:49 +0300

Hello,

I'm writing client-server application that should communicate through HTTP
protocol. It is not a web-server. My application just use HTTP as a
transport.
I never send HEAD request myself. So I don't implement any response for it.
Should I do it?

1. Can some proxy server on the way between my client and server use this
request for some optimization purposes?

2. Is it actual without caching? I use "Pragma: no-cache", "Cache-Control:
no-cache" in every requests.

SY, Alexey.

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 17 Nov 2003 09:26:37 -0700 (MST)

Alexey,

	From compliance point of view, RFC 2616 says that "the methods
GET and HEAD MUST be supported by all general-purpose servers". It is
up to the implementor, I guess, to define "general-purpose". Thus, you
can support GET only (or some extension methods only) and be
compliant.

	From practical point of view, it is possible that a proxy or a
web crawler would send your server "unexpected" requests such as HEAD.
It is also possible, though even less likely, that a proxy would fail
to handle the actual transaction if your response to HEAD does not
match proxy expectations. Given the number of server implementations
with a broken HEAD, it is not likely that a decent proxy would rely on
or require HEAD support, especially in a no-caching scenario. And you
probably do not care about crawlers and such. Thus, you will be
"safer" supporting HEAD, but the probability of breaking things you
care about without HEAD support is very low.

	Finally, if your server is exposed on the Internet and your
requests may go through proxies outside of your control, you can be
certain there will be unexpected requests sent to your server. Some of
those requests may be malicious. Please make sure that the server can
handle _any_ input, including garbage, unsupported request methods,
and supported request methods with malicious intent.

	N.B. no-cache in a request does not mean "do not cache".
	It means "do not use a cached copy when responding".
	no-cache in a response does not mean "do not cache" either.
	It means "revalidate on every request". You may want to
	use stronger cache-control directives in addition to
	no-cache.

HTH,

Alex.

-- 
Protocol performance, functionality, and reliability testing.
Tools, services, and know-how.
http://www.measurement-factory.com/