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

Steve Vinoski vinoski@REDACTED
Sat May 10 21:05:56 CEST 2008


On 5/10/08, Paul Fisher <pfisher@REDACTED> wrote:
> On Sat, 2008-05-10 at 08:57 -0500, Paul Fisher wrote:
>  > 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.

Yes, this explanation makes sense.

> As an example, the Googles gdata API documentation seems to support this
>  interpretation:
>
>  http://code.google.com/apis/gdata/reference.html#http-status-codes
>
>  Specifically this bit:
>
>  "Passing a standard parameter not understood by a given service results
>  in a 403 Forbidden response. Passing an unsupported nonstandard
>  parameter results in a 400 Bad Request response. For information on
>  other status codes..."
>
>  In the mod_esi case we are talking about passing a resource component
>  (e.g. the Function in the resource names ".../Module:Function" or
>  ".../Module/Function") which is an expected component of the resource
>  path that is expected by mod_esi structure, but not understood by the
>  service implementation (i.e. function not defined).  I'm not sure that I
>  agree with their use of 403, since I have always reserved that for
>  authentication/access control issues, but fundamentally we are talking
>  about 4xx series errors.

Actually 403 is correct for their case. 403, according to the spec,
means "the server understood the request but is refusing to fulfill
it." 401 is the more appropriate code for authentication and access
control issues.

>  I stand by my patch with a 404 response code:

Based on your explanation in your previous message and this one, I
fully agree that 404, but definitely not 400, is correct.

--steve


More information about the erlang-questions mailing list