Re: Returning 200 status from my handler

That actually does clear it up for me. Now that you point it out, this is
actually in keeping with established unix conventions. On the shell, a 0
return code has always indicated success while non-zero values indicate an
error. That didn't occur to me(though it probably should have) because I
was building REST endpoints(which are all about HTTP) instead of a shell
script. Your answer does, however, make me feel justified in having
filtered my handler's return code through a hash which maps the HTTP status
code to the appropriate instance of Apache2::Const. That way I can use
numeric statuses without falling out of sync with the defined constants.

Thanks!
John


On Tue, Jan 14, 2014 at 10:34 PM, Perrin Harkins <[email protected]> wrote:

> Hi John,
>
> > I notice, in the getting started documentation, that I am supposed to
> return
> > Apache2::Const::OK to indicate an HTTP 200 success status
>
> Actually, that's not about sending a HTTP 200 success status.  You
> return Apache2::Const::OK to tell httpd that your handler ran
> correctly.
>
> > When I print out other values of
> > constants from the same package they seem to have numeric values which
> > directly correspond to their respective HTTP status codes.
>
> True, but it's just due to a lack of imagination on the part of the
> httpd developers.  The only constants that intentionally contain valid
> HTTP status codes are the Apache2::Const::HTTP_* ones.
>
> > However, it strikes me as a extremely bizarre,
> > especially when returning Apache2::Const::HTTP_OK, which does evaluate to
> > 200, causes Apache2 to response with a canned error response page
>
> Right because you returned something other than HTTP::Const::OK,
> meaning your handler failed and httpd should sound the alarm.
>
> I hope that clears it up for you.  This is a common confusion, so
> nothing to feel bad about.
>
> - Perrin
>