Hi,
I'm working on a modperl site that doesn't presently handle HEAD requests
properly (it returns the entire content). That's definitely a waste
(especially seeing how browsers bang on it with HEAD requests), is not
compliant, and makes telnet debugging a pain.
I know how to detect a HEAD and to return correctly. The problem is that
there are a *lot* of content handlers and that would require patching them all.
>From the discussion we had around it, it seems that there are two
solutions: either put the check in the TransHandler (it knows which urls
map to which content handlers) which would return immediately a 404 or a
200, or put that in the part of the logic that deals with rendering the
content (all content handlers use it) so that it would return only the
headers and skip the actual content.
Choosing between either is hard. The advantage of the TransHandler solution
is that it would avoid potentially costly processing (lots of db requests)
that happens in the content handlers. It's problem is that some of these
content handlers might decide to return 404s themselves, or redirects, or
403s, etc... if certain conditions that require processing are not met.
Thus the TransHandler would return false positives because it only knows
whether there is a registered handler, not what that handler would actually
return. The advantage of putting HEAD checks in the rendering code is that
it would already know the return code for the request as it runs at the end
of the content phase and would thus be able to return correct answers as
well as to add content-length headers, which a certain number of search
engines will probably very much like. However, all the costly processing
will have happened for (next to) nothing, and we wouldn't be saving much.
Does anyone else have experience in dealing with such problems or ideas on
which choice is best ?
-- robin b.
Radioactive cats have 18 half-lives.
