Re: HEAD message

From: Dancer <[email protected]>
Date: Tue, 31 Aug 1999 08:42:19 +1000

"James A. Donald" wrote:
>
> From: dancer [mailto:dancer]On Behalf Of Dancer
> > I'm trepiditious about a number of things that Will Not Work(tm) if
> > I implement the spec exactly as given. (Those damn HEAD requests,
> > revalidation, and servers giving bodies in response to HEAD requests
> > on CGI's...a _very_ common thing - The fix is obvious. Do not do
> > HEAD requests in a persistant connection.

(Exaggerating my Australian accent)

Well, viewers..James Donald wrote in with a list of questions about HEAD
requests.

> How common are head requests?

Good question James. To find out, we visited a real website, and looked
in the logs.
(Frantic abacus work)

Well, according to the logs, HEAD requests account for forty-one percent
of the requests to this server, with GET requests accounting for
virtually all the remainder. That's quite a lot, really.

James also says,
> I cannot seem to provoke IE into
> issuing a HEAD request.

You should be careful when trying to provoke a major browser. They've
been known to turn on the unwary, and can be more dangerous than a cut
snake. Exercise extreme caution before poking one with a stick.

> What functionality to they implement for the
> end user?

Primarily? Object validation. Browsers cache copies of virtually
everything. Proxies often cache things. Every damned thing caches stuff
these days. How to tell if the copy you have is still good, or if it
needs to be changed without fetching the whole thing? Issue a HEAD
request and compare the validators, or in a pinch issue a conditional
GET.

> In short how acceptable is it to misbehave on head requests,
> or to close connection on head requests?

Under HTTP/1.0 it's common to misbehave on HEAD requests...at least to
the point of CGI scripts and some web-servers pretending they don't
exist and that they are really GET requests. Under HTTP/1.1 with the
persistent connection model as the default, you'll break persistency
every time you misbehave on a GET.

> What are the implications of
> such behavior for the end user?

If/When HTTP/1.1 is widely deployed/taken-up everyone will discover that
your site is _so_ much slower than people who are doing it right. So,
speed basically, and possibly (depending on what proxy might be between
you and them) not working at all is concievably possible.

That's all we have time for this week, next week we'll be covering
house-training Border Manager with a leather strap and a rolled-up
newspaper, and pay a visit to a fellow who claims to have the world's
largest collection of NT scrimshaw.

D
Received on Mon Aug 30 1999 - 16:57:27 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:48:08 MST