[erlang-questions] mod_esi should return 400 status for missing function

[Paul Fisher]

On Fri, 2008-05-09 at 23:35 -0400, Steve Vinoski wrote:
> On 5/9/08, Paul Fisher <pfisher@REDACTED> wrote:
> > If a Module/Function request matching an erl_script_alias registration
> >  does not exist as a function in the module registered, the current
> >  implementation returns a "500 Internal Server Error", rather than a more
> >  appropriate "400 Bad Request".
> 
> Sorry, but 400 is definitely not the right status code for this. The
> HTTP spec defines 400 as follows:
> 
> "10.4.1 400 Bad Request
> 
> The request could not be understood by the server due to malformed
> syntax. The client SHOULD NOT repeat the request without
> modifications."
>
> In other words, 400 means the request from the client is syntactically
> malformed, which does not apply in this case.

Sorry, but with respect I have to disagree.  I'll admit 404 is probably
a more precise 4xx series response, but it is definitely a *client*
error and and not a *server* error,  The client sent a request for an
invalid resource -- a function not being available in the module
responding to this resource path.  This is exactly the same as a request
for a file that is not available in the filesystem directory. 
Therefore a 4xx and not a 5xx.

404 is doc'd as:

   The server has not found anything matching the Request-URI. No
   indication is given of whether the condition is temporary or
   permanent. The 410 (Gone) status code SHOULD be used if the server
   knows, through some internally configurable mechanism, that an old
   resource is permanently unavailable and has no forwarding address.
   This status code is commonly used when the server does not wish to
   reveal exactly why the request has been refused, or when no other
   response is applicable.

Which is the entirely appropriate response (especially the part about
not revealing why the request was refused.)


> 500 is the correct error to return for this case. The client is
> apparently requesting a known and valid resource, but the server, due
> to an incorrect configuration or implementation, is unable to fulfill
> the request. The 500 HTTP status code is defined as follows:
> 
> "10.5.1 500 Internal Server Error
> 
> The server encountered an unexpected condition which prevented it from
> fulfilling the request."
> 
> which is perfect and exactly right for this scenario.

The client is not requesting a "known and valid resource", that is for
the server-side to define, which in the case of mod_esi implementations
is the functions exported from the module(s) registered.  If a valid
mod_esi implementation is registered for a resource path, then by
definition its public methods defined the resource space... since
nothing else possibly could.

It would possible for a 500 to be returned in the case that the module
was registered and did not exist, but that should really be detected
when mod_esi interprets the configuration and checks if the module(s)
named exist.


-- 
paul