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 <phark...@gmail.com> 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 >
