HTTPd's file callback is unsuited for server-side processing

The reasons are many.

• It indiscriminately registers and serves all of HTTP HEAD, GET and POST methods, without a way for the caller to control this. Server-side processing is likely to be non-idempotent and even non-safe: some people say that even the latter is incompatible with GET.
• It doesn't handle errors: it ignores the return value of the callback, and doesn't provide any mechanism to handle errors in request processing. Server-side processing is more likely to fail, both for technical reasons or due to requests that couldn't be satisfied for an array of reasons. Typically, a callback returning an error will generate a 200 Ok response with an empty body: in any case, I would suggest at least handling this with a 500 server error.
• It doesn't pass the request body to the callback, so POST data isn't supported.
• It doesn't pass HTTP headers which would be relevant for server-side processing.

Yet:

• It is the main callback used for all the server-side processing of the web interface.
• It insists on always running the callback, even with HEAD and discarding its output afterwards. As this is established behavior, I'm not sure that this can be changed though.
• The handler callback, which is much less affected by the above limitations and would be a more suited alternative, doesn't offer the HTTP header handling that the file callback does; and users not only don't want to have to write HTTP themselves, but can't even do it properly because they don't have access to request headers.

One of these should be fixed.