Stas Bekman wrote:
Philippe M. Chiasson wrote:
MP_SAVE_ERRSV(tmpsv)
MP_RESTORE_ERRSV(tmpsv)
Good enough ?
Better MP_FILTER_(SAVE|RESTORE)_ERRSV, as it has filter specific bits.
So noone will attempt to copy them away and use in a different context.
Otherwise your patch that you posted in anoth
Philippe M. Chiasson wrote:
MP_SAVE_ERRSV(tmpsv)
MP_RESTORE_ERRSV(tmpsv)
Good enough ?
Better MP_FILTER_(SAVE|RESTORE)_ERRSV, as it has filter specific bits.
So noone will attempt to copy them away and use in a different context.
Otherwise your patch that you posted in another email +1.
--
__
Here comes a revised patch that's cleaner by using macros.
Stas Bekman wrote:
Philippe M. Chiasson wrote:
Stas Bekman wrote:
Yes, this $@ save/restore logic could be added to filters only. But,
still,
in the case of a failing response handler & filter handler, you'd
lose the
error from the filte
Stas Bekman wrote:
Philippe M. Chiasson wrote:
Stas Bekman wrote:
Yes, this $@ save/restore logic could be added to filters only. But,
still,
in the case of a failing response handler & filter handler, you'd
lose the
error from the filter.
At least, here is a patch that does the same thing, bu
Philippe M. Chiasson wrote:
Stas Bekman wrote:
Yes, this $@ save/restore logic could be added to filters only. But,
still,
in the case of a failing response handler & filter handler, you'd
lose the
error from the filter.
At least, here is a patch that does the same thing, but only for
filters.
Stas Bekman wrote:
Yes, this $@ save/restore logic could be added to filters only. But,
still,
in the case of a failing response handler & filter handler, you'd lose
the
error from the filter.
At least, here is a patch that does the same thing, but only for filters.
The problem with filters is
Yes, this $@ save/restore logic could be added to filters only. But,
still,
in the case of a failing response handler & filter handler, you'd lose
the
error from the filter.
At least, here is a patch that does the same thing, but only for filters.
The problem with filters is that Apache has no
Philippe M. Chiasson wrote:
Stas Bekman wrote:
Philippe M. Chiasson wrote:
Would it be better to localize $@ instead of copying and restoring it?
I wish we could do that, and it was the first thing I attempted.
The problem is that if we do that, even conditionnaly only when $@ is set
on entry, i
Stas Bekman wrote:
Philippe M. Chiasson wrote:
Would it be better to localize $@ instead of copying and restoring it?
I wish we could do that, and it was the first thing I attempted.
The problem is that if we do that, even conditionnaly only when $@ is set
on entry, it means that any _real_ erro
Philippe M. Chiasson wrote:
Would it be better to localize $@ instead of copying and restoring it?
I wish we could do that, and it was the first thing I attempted.
The problem is that if we do that, even conditionnaly only when $@ is set
on entry, it means that any _real_ errors triggered during t
Stas Bekman wrote:
Philippe M. Chiasson wrote:
Stas Bekman wrote:
Philippe M. Chiasson wrote:
Index: lib/Apache/compat.pm
===
RCS file: /home/cvs/modperl-2.0/lib/Apache/compat.pm,v
retrieving revision 1.114
diff -u -I$Id -r1.114 com
Philippe M. Chiasson wrote:
Stas Bekman wrote:
Philippe M. Chiasson wrote:
Index: lib/Apache/compat.pm
===
RCS file: /home/cvs/modperl-2.0/lib/Apache/compat.pm,v
retrieving revision 1.114
diff -u -I$Id -r1.114 compat.pm
--- lib/Apach
Stas Bekman wrote:
Philippe M. Chiasson wrote:
Index: lib/Apache/compat.pm
===
RCS file: /home/cvs/modperl-2.0/lib/Apache/compat.pm,v
retrieving revision 1.114
diff -u -I$Id -r1.114 compat.pm
--- lib/Apache/compat.pm24 Jul 20
Stas Bekman wrote:
Philippe M. Chiasson wrote:
From todo/release:
filters reset $@ generated by eval, see if we can fix that. The TODO
test: TestFilter::out_str_eval presents the case
The description is here:
http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=108639632031457&w=2
The suggested fi
Philippe M. Chiasson wrote:
Index: lib/Apache/compat.pm
===
RCS file: /home/cvs/modperl-2.0/lib/Apache/compat.pm,v
retrieving revision 1.114
diff -u -I$Id -r1.114 compat.pm
--- lib/Apache/compat.pm 24 Jul 2004 07:27:03 - 1.114
++
Stas Bekman wrote:
Philippe M. Chiasson wrote:
ok t_filepath_cmp(canonpath(Apache->server_root_relative),
canonpath($server_root),
'Apache->server_root_relative()');
+
+ok t_filepath_cmp(canonpath(Apache->server_root_relative('/t
Philippe M. Chiasson wrote:
From todo/release:
filters reset $@ generated by eval, see if we can fix that. The TODO
test: TestFilter::out_str_eval presents the case
The description is here:
http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=108639632031457&w=2
The suggested fix handles this p
Stas Bekman wrote:
So back to the compat issue. At the moment lib/Apache/compat.pm has:
sub server_root_relative {
my $class = shift;
File::Spec->catfile(Apache::ServerUtil::server_root, @_);
}
which doesn't cover that special case. I suppose before doing catfile
we need to check whether
Philippe M. Chiasson wrote:
ok t_filepath_cmp(canonpath(Apache->server_root_relative),
canonpath($server_root),
'Apache->server_root_relative()');
+
+ok t_filepath_cmp(canonpath(Apache->server_root_relative('/tmp')),
+
So back to the compat issue. At the moment lib/Apache/compat.pm has:
sub server_root_relative {
my $class = shift;
File::Spec->catfile(Apache::ServerUtil::server_root, @_);
}
which doesn't cover that special case. I suppose before doing catfile
we need to check whether $_[0] is already
Philippe M. Chiasson wrote:
Stas Bekman wrote:
Philippe M. Chiasson wrote:
from todo/release :
* the following methods/functions are using compat implementations in
tests and should use the real 2.0 API: method_register,
server_root_relative
As far as I can see, this is not the case anymore, so s
Stas Bekman wrote:
Philippe M. Chiasson wrote:
from todo/release :
* the following methods/functions are using compat implementations in
tests and should use the real 2.0 API: method_register,
server_root_relative
As far as I can see, this is not the case anymore, so should we remove that
entry
From todo/release:
filters reset $@ generated by eval, see if we can fix that. The TODO
test: TestFilter::out_str_eval presents the case
The description is here:
http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=108639632031457&w=2
The suggested fix handles this problem by saving/restoring th
Philippe M. Chiasson wrote:
from todo/release :
* the following methods/functions are using compat implementations in
tests and should use the real 2.0 API: method_register,
server_root_relative
As far as I can see, this is not the case anymore, so should we remove that
entry ? Or am I missing
Geoffrey Young wrote:
the only apache API we have access to is $r->note_digest_auth_failure,
which
has the job of setting a proper WWW-Authenticate header. the current
tests
only really test this by accident, relying on LWP's Digest
implementation to
handle the header appropriately.
right, that's
Philippe M. Chiasson wrote:
Stas Bekman wrote:
Philippe M. Chiasson wrote:
Stas Bekman wrote:
Philippe M. Chiasson wrote:
More like
DIR
SRV
ALL
ALL -DIR (SRV & HTACCESS)
ALL -HTACCESS (SRV & DIR)
So, I'd suggest this naming
MP_CMD_DIR_...
MP_CMD_SRV_...
MP_CMD_ALL_...
with 2 new macros :
MP_CMD_
>> the only apache API we have access to is $r->note_digest_auth_failure,
>> which
>> has the job of setting a proper WWW-Authenticate header. the current
>> tests
>> only really test this by accident, relying on LWP's Digest
>> implementation to
>> handle the header appropriately.
>
>
> right
Philippe M. Chiasson wrote:
Stas Bekman wrote:
Is anybody familiar with RFC1413?
Sadly, yes, I am.
We provide this API but there is no test. Any takers to write this test?
Writing a test like this one will prove to be near impossible. You need
to be root to run the identd deamon, and I am not su
Geoffrey Young wrote:
[EMAIL PROTECTED] wrote:
stas2004/08/08 10:56:53
Added: t/hooks authen_digest.t
t/hooks/TestHooks authen_digest.pm
Log:
digest auth test
cool! I love that people are becoming as interested in Digest auth as I am :)
I wasn't really getting inte
Philippe M. Chiasson wrote:
Stas Bekman wrote:
Philippe M. Chiasson wrote:
More like
DIR
SRV
ALL
ALL -DIR (SRV & HTACCESS)
ALL -HTACCESS (SRV & DIR)
So, I'd suggest this naming
MP_CMD_DIR_...
MP_CMD_SRV_...
MP_CMD_ALL_...
with 2 new macros :
MP_CMD_NO_DIR
MP_CMD_NO_HTACCESS
To add to the top of
Stas Bekman wrote:
Is anybody familiar with RFC1413?
Sadly, yes, I am.
We provide this API but there is no test. Any takers to write this test?
Writing a test like this one will prove to be near impossible. You need
to be root to run the identd deamon, and I am not sure it would be wise
to get the
[EMAIL PROTECTED] wrote:
> stas2004/08/08 10:56:53
>
> Added: t/hooks authen_digest.t
>t/hooks/TestHooks authen_digest.pm
> Log:
> digest auth test
cool! I love that people are becoming as interested in Digest auth as I am :)
the only comment that I would
Stas Bekman wrote:
Philippe M. Chiasson wrote:
More like
DIR
SRV
ALL
ALL -DIR (SRV & HTACCESS)
ALL -HTACCESS (SRV & DIR)
So, I'd suggest this naming
MP_CMD_DIR_...
MP_CMD_SRV_...
MP_CMD_ALL_...
with 2 new macros :
MP_CMD_NO_DIR
MP_CMD_NO_HTACCESS
To add to the top of a directive handler ?
Yes,
Philippe M. Chiasson wrote:
More like
DIR
SRV
ALL
ALL -DIR (SRV & HTACCESS)
ALL -HTACCESS (SRV & DIR)
So, I'd suggest this naming
MP_CMD_DIR_...
MP_CMD_SRV_...
MP_CMD_ALL_...
with 2 new macros :
MP_CMD_NO_DIR
MP_CMD_NO_HTACCESS
To add to the top of a directive handler ?
Yes, but using those you
from todo/release :
* the following methods/functions are using compat implementations in
tests and should use the real 2.0 API: method_register,
server_root_relative
As far as I can see, this is not the case anymore, so should we remove that
entry ? Or am I missing something ?
--
-
Stas Bekman wrote:
Philippe M. Chiasson wrote:
[...]
If the macro is supposed to suggest the allowed context and PerlModule
is not allowed in DIR, then DIR is not appropriate. I see no problem
with long names if they require no extra source code reading to figure
out what they really do. These
36 matches
Mail list logo
