You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Issac Goldstand <ma...@beamartyr.net> on 2002/04/23 19:29:14 UTC
Q & A: $r->custom_response
Reposting a question (and the answer) that geoff and I discussed in the
IRC room, as I think it's worthwhile to mention...
I had the following line of code (actually many of the sort):
$r->custom_response(FORBIDDEN=>"File size exceeds quota.");
And kept getting errors like:
[Tue Apr 23 19:46:14 2002] null: Argument "FORBIDDEN" isn't numeric in
subroutine entry at /usr/local/httpd/lib/perl/Mine/Pic/Application.pm
line 1343.
The answer to the problem is that by using '=>' instead of ',', I was
making 'FORBIDDEN' become '"FORBIDDEN"' (string instead of numeric 403).
Moral of the story: don't use => with Apache::Constants!
Hope this helps some of you...
Issac
Re: Q & A: $r->custom_response
Posted by Per Einar Ellefsen <pe...@skynet.be>.
At 22:04 23.04.2002, Perrin Harkins wrote:
>Per Einar Ellefsen wrote:
>>I suppose Apache::Constants could have been extended to return globals if
>>requested... But is there really any gain in that?
>
>Only in that people will not get tripped up by the possible bugs that
>using subroutines as constants causes. I guess Apache::Constants is
>difficult to replace, so everyone will just have to keep an eye out for
>this sort of problem.
Agreed.
I'll add a warning in the docs for Apache::Constants which might help out
in the future.
--
Per Einar Ellefsen
per.einar@skynet.be
Re: Q & A: $r->custom_response
Posted by Perrin Harkins <pe...@elem.com>.
Per Einar Ellefsen wrote:
> I suppose Apache::Constants could have been extended to return globals
> if requested... But is there really any gain in that?
Only in that people will not get tripped up by the possible bugs that
using subroutines as constants causes. I guess Apache::Constants is
difficult to replace, so everyone will just have to keep an eye out for
this sort of problem.
- Perrin
Re: Q & A: $r->custom_response
Posted by Per Einar Ellefsen <pe...@skynet.be>.
At 19:51 23.04.2002, Perrin Harkins wrote:
>Per Einar Ellefsen wrote:
>>Well, this one is exported by Apache::Constants, so if you don't want to do
>>$FORBIDDEN = FORBIDDEN;
>>somewhere at the top of your code, you're bound to continue using
>>constants, right?
>
>That's still safer. I used the constants pragma on a big project and I
>saw people get bitten by $hash{CONSTANT} and "string interp CONSTANT" as
>well as the aforementioned CONSTANT => value problem. It's just asking
>for trouble, in my opinion.
>
>Can anyone tell us if the Apache::Constants all just standard HTTP
>response codes, or are some of them actually Apache-specific?
Apache::Constants gets them from httpd.h. Here is the expert:
#define HTTP_CONTINUE 100
#define HTTP_SWITCHING_PROTOCOLS 101
#define HTTP_PROCESSING 102
#define HTTP_OK 200
#define HTTP_CREATED 201
#define HTTP_ACCEPTED 202
#define HTTP_NON_AUTHORITATIVE 203
#define HTTP_NO_CONTENT 204
#define HTTP_RESET_CONTENT 205
#define HTTP_PARTIAL_CONTENT 206
#define HTTP_MULTI_STATUS 207
#define HTTP_MULTIPLE_CHOICES 300
#define HTTP_MOVED_PERMANENTLY 301
#define HTTP_MOVED_TEMPORARILY 302
#define HTTP_SEE_OTHER 303
#define HTTP_NOT_MODIFIED 304
#define HTTP_USE_PROXY 305
#define HTTP_TEMPORARY_REDIRECT 307
#define HTTP_BAD_REQUEST 400
#define HTTP_UNAUTHORIZED 401
#define HTTP_PAYMENT_REQUIRED 402
#define HTTP_FORBIDDEN 403
#define HTTP_NOT_FOUND 404
#define HTTP_METHOD_NOT_ALLOWED 405
#define HTTP_NOT_ACCEPTABLE 406
#define HTTP_PROXY_AUTHENTICATION_REQUIRED 407
#define HTTP_REQUEST_TIME_OUT 408
#define HTTP_CONFLICT 409
#define HTTP_GONE 410
#define HTTP_LENGTH_REQUIRED 411
#define HTTP_PRECONDITION_FAILED 412
#define HTTP_REQUEST_ENTITY_TOO_LARGE 413
#define HTTP_REQUEST_URI_TOO_LARGE 414
#define HTTP_UNSUPPORTED_MEDIA_TYPE 415
#define HTTP_RANGE_NOT_SATISFIABLE 416
#define HTTP_EXPECTATION_FAILED 417
#define HTTP_UNPROCESSABLE_ENTITY 422
#define HTTP_LOCKED 423
#define HTTP_FAILED_DEPENDENCY 424
#define HTTP_INTERNAL_SERVER_ERROR 500
#define HTTP_NOT_IMPLEMENTED 501
#define HTTP_BAD_GATEWAY 502
#define HTTP_SERVICE_UNAVAILABLE 503
#define HTTP_GATEWAY_TIME_OUT 504
#define HTTP_VERSION_NOT_SUPPORTED 505
#define HTTP_VARIANT_ALSO_VARIES 506
#define HTTP_INSUFFICIENT_STORAGE 507
#define HTTP_NOT_EXTENDED 510
#define DOCUMENT_FOLLOWS HTTP_OK
#define PARTIAL_CONTENT HTTP_PARTIAL_CONTENT
#define MULTIPLE_CHOICES HTTP_MULTIPLE_CHOICES
#define MOVED HTTP_MOVED_PERMANENTLY
#define REDIRECT HTTP_MOVED_TEMPORARILY
#define USE_LOCAL_COPY HTTP_NOT_MODIFIED
#define BAD_REQUEST HTTP_BAD_REQUEST
#define AUTH_REQUIRED HTTP_UNAUTHORIZED
#define FORBIDDEN HTTP_FORBIDDEN
#define NOT_FOUND HTTP_NOT_FOUND
#define METHOD_NOT_ALLOWED HTTP_METHOD_NOT_ALLOWED
#define NOT_ACCEPTABLE HTTP_NOT_ACCEPTABLE
#define LENGTH_REQUIRED HTTP_LENGTH_REQUIRED
#define PRECONDITION_FAILED HTTP_PRECONDITION_FAILED
#define SERVER_ERROR HTTP_INTERNAL_SERVER_ERROR
#define NOT_IMPLEMENTED HTTP_NOT_IMPLEMENTED
#define BAD_GATEWAY HTTP_BAD_GATEWAY
#define VARIANT_ALSO_VARIES HTTP_VARIANT_ALSO_VARIES
So apparently, FORBIDDEN == HTTP_FORBIDDEN == 403.
However, I wouldn't rely on any of this, because that's the reason behind
constants: they hide what they really are!
For example, we have this:
#define DECLINED -1 /* Module declines to handle */
#define DONE -2 /* Module has served the response completely
* - it's safe to die() with no more output
*/
#define OK 0 /* Module has handled this stage. */
OK should therefore not be confused with HTTP_OK (many people seem to bite
the bug and return 200, which isn't supposed to be right).
I suppose Apache::Constants could have been extended to return globals if
requested... But is there really any gain in that?
--
Per Einar Ellefsen
per.einar@skynet.be
Re: Q & A: $r->custom_response
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Can anyone tell us if the Apache::Constants all just standard HTTP
> response codes, or are some of them actually Apache-specific?
>
there are over 90 constants in Apache::Constants, which range from HTTP
constants (like FORBIDDEN for 403) to Apache specific ones (like
DECLINED for -1 and OPT_INCLUDES for 2). there is also stuff like
SERVER_VERSION which is really a runtime call to ap_get_server_version().
--Geoff
Re: Q & A: $r->custom_response
Posted by Perrin Harkins <pe...@elem.com>.
Per Einar Ellefsen wrote:
> Well, this one is exported by Apache::Constants, so if you don't want to do
> $FORBIDDEN = FORBIDDEN;
> somewhere at the top of your code, you're bound to continue using
> constants, right?
That's still safer. I used the constants pragma on a big project and I
saw people get bitten by $hash{CONSTANT} and "string interp CONSTANT" as
well as the aforementioned CONSTANT => value problem. It's just asking
for trouble, in my opinion.
Can anyone tell us if the Apache::Constants all just standard HTTP
response codes, or are some of them actually Apache-specific?
- Perrin
Re: Q & A: $r->custom_response
Posted by Per Einar Ellefsen <pe...@skynet.be>.
At 19:38 23.04.2002, Perrin Harkins wrote:
>Issac Goldstand wrote:
>>Reposting a question (and the answer) that geoff and I discussed in the
>>IRC room, as I think it's worthwhile to mention...
>>I had the following line of code (actually many of the sort):
>>$r->custom_response(FORBIDDEN=>"File size exceeds quota.");
>>And kept getting errors like:
>>[Tue Apr 23 19:46:14 2002] null: Argument "FORBIDDEN" isn't numeric in
>>subroutine entry at /usr/local/httpd/lib/perl/Mine/Pic/Application.pm
>>line 1343.
>>The answer to the problem is that by using '=>' instead of ',', I was
>>making 'FORBIDDEN' become '"FORBIDDEN"' (string instead of numeric 403).
>>Moral of the story: don't use => with Apache::Constants!
>
>In fact, don't use constants at all. At least not the kind created by the
>"use constants" pragma and similar tricks. They have all kinds of
>problems like this. Use package variables instead ($FORBIDDEN). Maybe
>some day Perl will have real constants, but I'm perfectly happy with
>package variables in the meantime.
Well, this one is exported by Apache::Constants, so if you don't want to do
$FORBIDDEN = FORBIDDEN;
somewhere at the top of your code, you're bound to continue using
constants, right?
--
Per Einar Ellefsen
per.einar@skynet.be
Re: Q & A: $r->custom_response
Posted by Perrin Harkins <pe...@elem.com>.
Issac Goldstand wrote:
> Reposting a question (and the answer) that geoff and I discussed in the
> IRC room, as I think it's worthwhile to mention...
>
> I had the following line of code (actually many of the sort):
> $r->custom_response(FORBIDDEN=>"File size exceeds quota.");
>
> And kept getting errors like:
> [Tue Apr 23 19:46:14 2002] null: Argument "FORBIDDEN" isn't numeric in
> subroutine entry at /usr/local/httpd/lib/perl/Mine/Pic/Application.pm
> line 1343.
>
> The answer to the problem is that by using '=>' instead of ',', I was
> making 'FORBIDDEN' become '"FORBIDDEN"' (string instead of numeric 403).
>
> Moral of the story: don't use => with Apache::Constants!
In fact, don't use constants at all. At least not the kind created by
the "use constants" pragma and similar tricks. They have all kinds of
problems like this. Use package variables instead ($FORBIDDEN). Maybe
some day Perl will have real constants, but I'm perfectly happy with
package variables in the meantime.
- Perrin
Re: Q & A: $r->custom_response
Posted by Per Einar Ellefsen <pe...@skynet.be>.
At 19:29 23.04.2002, Issac Goldstand wrote:
>Reposting a question (and the answer) that geoff and I discussed in the
>IRC room, as I think it's worthwhile to mention...
>
>I had the following line of code (actually many of the sort):
>$r->custom_response(FORBIDDEN=>"File size exceeds quota.");
>
>And kept getting errors like:
>[Tue Apr 23 19:46:14 2002] null: Argument "FORBIDDEN" isn't numeric in
>subroutine entry at /usr/local/httpd/lib/perl/Mine/Pic/Application.pm line
>1343.
>
>The answer to the problem is that by using '=>' instead of ',', I was
>making 'FORBIDDEN' become '"FORBIDDEN"' (string instead of numeric 403).
>
>Moral of the story: don't use => with Apache::Constants!
Or you can use &FORBIDDEN or FORBIDDEN() or +FORBIDDEN, which are another
fix if you want to continue using =>.
--
Per Einar Ellefsen
per.einar@skynet.be