You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apreq-dev@httpd.apache.org by Joe Schaefer <jo...@sunstarsys.com> on 2004/06/29 05:14:37 UTC
status and error handling in apreq2
It's time to implement Apache::Request::status,
and looking over the current code, there are
a few shortcomings that we should also address:
1) the status attribute in apreq_value_t is not
useful, and it should be dropped,
2) we need a way of recording and reporting
whether the query_string parse was successful,
so adding an args_status field to apreq_request_t
seems logical,
3) ditto for parsing the "Cookie" headers-
add a status field to cookie_jar_t.
Then we can expose those fields in Perl,
so users have a way to detect such problems.
Also adding a $req->body_status that reports
the active parser's current status would make
a nice implementation of $req->status possible:
sub status {
wantarray ? ($req->args_status, $req->body_status)
: $req->args_status || $req->body_status;
}
Thoughts?
--
Joe Schaefer
Re: status and error handling in apreq2
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> > OK- agreed in principle. However, if a parser fails and the user
> > traps the error, they might also need to know how more details about
> > the failure than can be supplied through $@.
> > Take this for instance:
> > my $req = Apache::Request->new($r);
> > my $data = eval { $req->param("foo") };
> > if ($@) {
> > # user still wants to know if the "foo" param is available,
> > # because it may have been available (through param()!)
> > # prior to the parser entering an error state. How do we
> > # retrieve the "foo" param now?
> > }
>
> give me an example why would you want to continue here at all? How do
> you know that there is no more foo params later on in the input that
> caused the error?
In scalar context param() returns the first "foo" it finds, which may
have come from a valid query-string. Subsequent POST data parsing might
have detected an error in the incoming request body, thus the potential
for an exception in param().
However, depending on how we actually implement the exceptions, we could
ensure the above call would still succeed in this situation.
> How do you that it wasn't just a partial foo?
No partial params ever make it into our tables, not even during uploads.
If a parser error happened during processing of a foo param, that param
will not appear in the output table.
> In any case, mp2 throws object exceptions, apreq can do the same and provide
> its own attributes and overloads. so by default $@ will be stringified
> to give a general error message, but let the user to access individual
> attrbutes of that error object. so you could set some attribute
> telling the user whether the initial quest has succeeded.
+1. Better still would be to provide the current req->args and req->body
tables (as exception attributes), so the user can examine them if necessary.
--
Joe Schaefer
Re: status and error handling in apreq2
Posted by Stas Bekman <st...@stason.org>.
> OK- agreed in principle. However, if a parser fails and the user
> traps the error, they might also need to know how more details
> about the failure than can be supplied through $@.
>
> Take this for instance:
>
> my $req = Apache::Request->new($r);
> my $data = eval { $req->param("foo") };
>
> if ($@) {
> # user still wants to know if the "foo" param is available,
> # because it may have been available (through param()!)
> # prior to the parser entering an error state. How do we
> # retrieve the "foo" param now?
>
> }
give me an example why would you want to continue here at all? How do you know
that there is no more foo params later on in the input that caused the error?
How do you that it wasn't just a partial foo?
In any case, mp2 throws object exceptions, apreq can do the same and provide
its own attributes and overloads. so by default $@ will be stringified to give
a general error message, but let the user to access individual attrbutes of
that error object. so you could set some attribute telling the user whether
the initial quest has succeeded. Though as I mentioned above, I fail to see
how could you know for sure that the param 'foo' may have been available.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: status and error handling in apreq2
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> Joe Schaefer wrote:
> > Stas Bekman <st...@stason.org> writes:
> >
> >>Joe Schaefer wrote:
> >>
> >>>It's time to implement Apache::Request::status,
> >>>and looking over the current code, there are
> >>>a few shortcomings that we should also address:
> >>> 1) the status attribute in apreq_value_t is not
> >>> useful, and it should be dropped,
> >>> 2) we need a way of recording and reporting whether the query_string
> >>> parse was successful,
> >>> so adding an args_status field to apreq_request_t
> >>> seems logical,
> >>> 3) ditto for parsing the "Cookie" headers-
> >>> add a status field to cookie_jar_t.
> >>>Then we can expose those fields in Perl,
> >>>so users have a way to detect such problems.
> >>>Also adding a $req->body_status that reports
> >>>the active parser's current status would make
> >>>a nice implementation of $req->status possible:
> >>> sub status {
> >>> wantarray ? ($req->args_status, $req->body_status)
> >>> : $req->args_status || $req->body_status;
> >>> }
> >>>Thoughts?
> >>
> >>FWIW, I think it's the best for apreq2 to throw an exception when an
> >>error happens, making the errors trappable, when users want to handle
> >>it (which most users won't do anyway), like mp2 now does.
> > That's a good idea, we might even be able to make that
> > configurable with a "RAISE_ERROR => 1" argument to new().
> > Either way, (1) - (3) are necessary to make this happen,
> > because users have very little control over *when* things
> > happen in apreq2.
>
> Frankly, I don't understand why anyone will want to ignore errors and
> therefore why it has to be configurable.
OK- agreed in principle. However, if a parser fails and the user
traps the error, they might also need to know how more details
about the failure than can be supplied through $@.
Take this for instance:
my $req = Apache::Request->new($r);
my $data = eval { $req->param("foo") };
if ($@) {
# user still wants to know if the "foo" param is available,
# because it may have been available (through param()!)
# prior to the parser entering an error state. How do we
# retrieve the "foo" param now?
}
--
Joe Schaefer
Re: status and error handling in apreq2
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
>
>>Joe Schaefer wrote:
>>
>>>It's time to implement Apache::Request::status,
>>>and looking over the current code, there are
>>>a few shortcomings that we should also address:
>>> 1) the status attribute in apreq_value_t is not
>>> useful, and it should be dropped,
>>> 2) we need a way of recording and reporting
>>> whether the query_string parse was successful,
>>> so adding an args_status field to apreq_request_t
>>> seems logical,
>>> 3) ditto for parsing the "Cookie" headers-
>>> add a status field to cookie_jar_t.
>>>Then we can expose those fields in Perl,
>>>so users have a way to detect such problems.
>>>Also adding a $req->body_status that reports
>>>the active parser's current status would make
>>>a nice implementation of $req->status possible:
>>> sub status {
>>> wantarray ? ($req->args_status, $req->body_status)
>>> : $req->args_status || $req->body_status;
>>> }
>>>Thoughts?
>>
>>FWIW, I think it's the best for apreq2 to throw an exception when an
>>error happens, making the errors trappable, when users want to handle
>>it (which most users won't do anyway), like mp2 now does.
>
>
> That's a good idea, we might even be able to make that
> configurable with a "RAISE_ERROR => 1" argument to new().
> Either way, (1) - (3) are necessary to make this happen,
> because users have very little control over *when* things
> happen in apreq2.
Frankly, I don't understand why anyone will want to ignore errors and
therefore why it has to be configurable. Those who know what they are doing
can use eval {} to trap errors.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: status and error handling in apreq2
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> Joe Schaefer wrote:
> > It's time to implement Apache::Request::status,
> > and looking over the current code, there are
> > a few shortcomings that we should also address:
> > 1) the status attribute in apreq_value_t is not
> > useful, and it should be dropped,
> > 2) we need a way of recording and reporting
> > whether the query_string parse was successful,
> > so adding an args_status field to apreq_request_t
> > seems logical,
> > 3) ditto for parsing the "Cookie" headers-
> > add a status field to cookie_jar_t.
> > Then we can expose those fields in Perl,
> > so users have a way to detect such problems.
> > Also adding a $req->body_status that reports
> > the active parser's current status would make
> > a nice implementation of $req->status possible:
> > sub status {
> > wantarray ? ($req->args_status, $req->body_status)
> > : $req->args_status || $req->body_status;
> > }
> > Thoughts?
>
> FWIW, I think it's the best for apreq2 to throw an exception when an
> error happens, making the errors trappable, when users want to handle
> it (which most users won't do anyway), like mp2 now does.
That's a good idea, we might even be able to make that
configurable with a "RAISE_ERROR => 1" argument to new().
Either way, (1) - (3) are necessary to make this happen,
because users have very little control over *when* things
happen in apreq2.
--
Joe Schaefer
Re: status and error handling in apreq2
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> It's time to implement Apache::Request::status,
> and looking over the current code, there are
> a few shortcomings that we should also address:
>
> 1) the status attribute in apreq_value_t is not
> useful, and it should be dropped,
>
> 2) we need a way of recording and reporting
> whether the query_string parse was successful,
> so adding an args_status field to apreq_request_t
> seems logical,
>
> 3) ditto for parsing the "Cookie" headers-
> add a status field to cookie_jar_t.
>
> Then we can expose those fields in Perl,
> so users have a way to detect such problems.
> Also adding a $req->body_status that reports
> the active parser's current status would make
> a nice implementation of $req->status possible:
>
> sub status {
> wantarray ? ($req->args_status, $req->body_status)
> : $req->args_status || $req->body_status;
> }
>
> Thoughts?
FWIW, I think it's the best for apreq2 to throw an exception when an error
happens, making the errors trappable, when users want to handle it (which most
users won't do anyway), like mp2 now does. See:
http://perl.apache.org/docs/2.0/api/APR/Error.html
and some usages:
http://perl.apache.org/search/swish.cgi?query=APR%3A%3AError&sbm=&submit=search
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com