This is something that could definitely be better documented. I've already
been thrown for a loop by them on several occasions. Sadly, you can't just
return the numeric status codes(which are clearly documented in the HTTP
specifications) because the values of the constants do not match their
corresponding HTTP status codes. Things get even more confusing when you
realize that there are also multiple constants for many of the HTTP status
codes. I actually have a hash in my application that maps numeric HTTP
status codes to the correct constants(I hard coded the constant in my
example because I wanted to test the error with the simplest possible
scenario). Because of this, I actually have a hash in my application that
maps numeric HTTP status codes to the correct constants. That way I can
just use the numeric codes(which ARE clearly document) while also returning
the correct constants, assuming that I've correctly mapped the numeric
codes to the correct constants.
With that said, how can I be sure that I'm using the correct constants? My
existing mappings are as follows:
use constant STATUS_MAP => {
'100' => HTTP_CONTINUE,
'101' => HTTP_SWITCHING_PROTOCOLS,
'200' => OK,
'201' => HTTP_CREATED,
'202' => HTTP_ACCEPTED,
'203' => HTTP_NON_AUTHORITATIVE,
'204' => HTTP_NO_CONTENT,
'205' => HTTP_RESET_CONTENT,
'206' => HTTP_PARTIAL_CONTENT,
'300' => HTTP_MULTIPLE_CHOICES,
'301' => HTTP_MOVED_PERMANENTLY,
'302' => HTTP_MOVED_TEMPORARILY,
'303' => HTTP_SEE_OTHER,
'304' => HTTP_NOT_MODIFIED,
'305' => HTTP_USE_PROXY,
'307' => HTTP_TEMPORARY_REDIRECT,
'400' => HTTP_BAD_REQUEST,
'401' => HTTP_UNAUTHORIZED,
'402' => HTTP_PAYMENT_REQUIRED,
'403' => HTTP_FORBIDDEN,
'404' => HTTP_NOT_FOUND,
'405' => HTTP_METHOD_NOT_ALLOWED,
'406' => HTTP_NOT_ACCEPTABLE,
'407' => HTTP_PROXY_AUTHENTICATION_REQUIRED,
'408' => 408,
'409' => HTTP_CONFLICT,
'410' => HTTP_GONE,
'411' => HTTP_LENGTH_REQUIRED,
'412' => HTTP_PRECONDITION_FAILED,
'413' => HTTP_REQUEST_ENTITY_TOO_LARGE,
'414' => HTTP_REQUEST_URI_TOO_LARGE,
'415' => HTTP_UNSUPPORTED_MEDIA_TYPE,
'416' => HTTP_RANGE_NOT_SATISFIABLE,
'417' => HTTP_EXPECTATION_FAILED,
'500' => HTTP_INTERNAL_SERVER_ERROR,
'501' => HTTP_NOT_IMPLEMENTED,
'502' => HTTP_BAD_GATEWAY,
'503' => HTTP_SERVICE_UNAVAILABLE,
'504' => HTTP_GATEWAY_TIME_OUT,
'505' => 505
};
On Tue, Mar 18, 2014 at 12:33 PM, Adam Prime <adam.pr...@utoronto.ca> wrote:
> I'm pretty sure you should be using Apache2::Const::SERVER_ERROR, not the
> HTTP_* constants. This could probably be documented better. You should
> likely be returning that constant instead of the HTTP_* ones as well.
>
> Adam
>
>
> On 14-03-18 11:59 AM, John Dunlap wrote:
>
>> I recently upgraded my workstation from Debian 6 to Debian 7 and I'm now
>> encountering a problem that I haven't seen before. My apache version
>> is 2.2.22-13+deb7u1. My mod_perl version is 2.0.7-3. I'm guessing that I
>> have an installation problem of some kind but I'm not sure where to look
>> for problems. My application works correctly until I attempt to define a
>> custom response, as follows,
>>
>> sub handler {
>> my $apache = shift;
>> $apache->custom_response(Apache2::Const::HTTP_INTERNAL_SERVER_ERROR, 'hi
>> mom');
>> return Apache2::Const::HTTP_INTERNAL_SERVER_ERROR;
>> }
>>
>> I see a 500 error, which is what I want, when I access the page. However
>> the error page is the default apache 500 error response page and I want
>> to override it. When I look in the logs, I see this:
>>
>> [Tue Mar 18 15:41:32 2014] [error] [client 127.0.0.1] Can't locate
>> object method "custom_response" via package "Apache2::RequestRec" at
>> /usr/local/lariat-trunk/qa-trunk/lib/Lariat/V4/WS/RS/BootstrapHandler.pm
>> line 41.
>>
>> This would imply, at least to me, that this method is not compiled into
>> mod_perl or perhaps into apache itself but I cannot be sure. Any
>> suggestions?
>>
>> Cheers!
>> John
>>
>>
>
