httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <>
Subject Re: bogus methods return 500 not 501
Date Thu, 13 Jun 2002 07:19:13 GMT
On Wed, Jun 12, 2002 at 09:09:29PM -0400, Cliff Woolley wrote:
> And what's with this?
> root@deepthought:/root# telnet 80
> Trying
> Connected to
> Escape character is '^]'.
> GRRR / HTTP/1.0
> Host:
> HTTP/1.1 500 Internal Server Error

It's due to the fact that icarus doesn't have a DirectoryIndex file
for /.  Therefore, the handler for the request is mod_autoindex.
This is why when I ran it on my host with a DirectoryIndex file, it
returned 501 because it goes to the default_handler function.

default_handler has this code (server/core.c:3283):

    if (r->method_number == M_INVALID) {
        ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
                      "Invalid method in request %s", r->the_request);
        return HTTP_NOT_IMPLEMENTED;

This code needs to land in mod_autoindex and probably most of
the other modules.  My wonder is WTF do we not abort a method
with M_INVALID well before it runs the handlers?  This seems
like something that the core could easily catch.  If no module
registered an acceptance for that method, this seems bogus to
try to even handle.

However, what would happen if I ask for COPY /.  We implement it,
but it isn't allowable here.  That sounds like a 405.


And, indeed, that's what default_handler does.  So, how do we get
this logic to all modules?  One approach may be to have this code in
ap_invoke_handler() - if all handlers returned DECLINED, then we
should check the method for its correctness.  Or better yet, we could
catch the 501 *before* calling the handlers and catch the 405 *after*
the handlers are run iff DECLINED is returned.  This would ease the
modules' handling of methods - default_handler shouldn't be making
these determinations - IMHO, the core should.  -- justin

View raw message