Re: checklink: error codes

On Mon, 2004-04-05 at 12:11, Nick Kew wrote:

> OK, the reason for that is that sil.org's webserver is deeply broken and
> doesn't support HTTP.  Specifically, it returns inconsistent responses to
> HEAD and GET requests, in violation of every HTTP specification.

Warning: longish nitpickery, my .02¤ and some questions follows.

FWIW, that is how I would like to (and sort of, like I believe most of
the world, do :) interpret RFC 2616.  However, section 5.1.1 contains
the magic phrase:

  The methods GET and HEAD MUST be supported by all general-purpose
  servers.

But AFAICS the spec does not really define "general-purpose" nor whether
a non-general-purpose server can be HTTP/1.1 compliant or not.  Maybe
it's just a thinko, and "general-purpose" actually should have been
omitted or replaced with "HTTP/1.1 compliant"?

The sil.org case seems to be that it responds 403 to (most) HEAD
requests while the corresponding GETs receive a 200; I agree that seems
to be sort of against the spec (sections 5.1.1 and 9.4, and if HEAD is a
MUST).  However, that server also seems to grok the meaning of HEAD:
requests using the LF (no CR) line endings seem to result in a 400 no
matter if it's GET or HEAD, and the HEAD seems to be exactly the same as
the GET one, only with the response body omitted.

So, given the above reverse-engineering and the RFC 2616 quote, can the
sil.org server actually be HTTP/1.1 compliant?  Would it be compliant or
even unconditionally compliant (as far as this particular small subset
of the spec is concerned) if it would respond with 405 or 501 to the
HEAD request in this case instead of 403?  Can a server which does not
implement GET or HEAD be HTTP/1.1 compliant?  Did I miss something?

> As regards explanations, you have a good point.  The text under What
> to do for 403 is woefully inadequate.  The difficulty is that to do it
> justice calls for rather more than could fit in the space.

Agreed.  I think the explanations and "what to do"s (including link
checker specific information and pointers to more info) should be in a
separate document, and the current ones in the results page replaced
with links to this new doc.

Received on Monday, 5 April 2004 12:27:59 UTC