Re: [ANNOUNCE] Apache::Dispatch-0.03
Roger Espel Llima wrote:
>
> > @{"${class}::ISA"}
>
> Incidentally, does anyone know of a way to do this that works under
> strict? The above requires a "no strict 'refs'" to work.
Something like this we3nt by on p5p a while ago (IIRCC):
@{$main::{"$class\::"}->{ISA}}
but that's a lot more cryptic that
{
no strict 'refs' ;
@{"${class}::ISA"} ;
}
- Barrie
Re: [ANNOUNCE] Apache::Dispatch-0.03
On Tue, 8 Aug 2000, Roger Espel Llima wrote:
> > @{"${class}::ISA"}
>
> Yep, that's one weird bit of syntax. I just needed this recently to
> write a test.pl, and it took quite a bit of testing to get it working. :)
>
> Incidentally, does anyone know of a way to do this that works under
> strict? The above requires a "no strict 'refs'" to work.
No, thats a standard thing that is disabled under strict. Of course you'd
only be doing that in some neat hack, so locally disabling strict isn't a
big deal (strict is a lexical pragma, so it only applies in the current
scope).
--
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org
Re: [ANNOUNCE] Apache::Dispatch-0.03
Geoffrey Young wrote: > > -Original Message- > > From: Roger Espel Llima [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, August 08, 2000 12:52 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [ANNOUNCE] Apache::Dispatch-0.03 > > > [snip] > > > > Yep, that's one weird bit of syntax. I just needed this recently to > > write a test.pl, and it took quite a bit of testing to get it > > working. :) > > this showed up in p5p in late june... > $foo = "bar"; > @$foo = (1,2,3); > $foo->[1] = 4; > print @bar; > > wicked cool... standard symbolic referencing. > > > --Geoff > > > > > Incidentally, does anyone know of a way to do this that works under > > strict? The above requires a "no strict 'refs'" to work. nope. purposely does not work under strict. -- ___cliff [EMAIL PROTECTED]http://www.genwax.com/
RE: [ANNOUNCE] Apache::Dispatch-0.03
> -Original Message- > From: Roger Espel Llima [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, August 08, 2000 12:52 PM > To: [EMAIL PROTECTED] > Subject: Re: [ANNOUNCE] Apache::Dispatch-0.03 > [snip] > > Yep, that's one weird bit of syntax. I just needed this recently to > write a test.pl, and it took quite a bit of testing to get it > working. :) this showed up in p5p in late june... $foo = "bar"; @$foo = (1,2,3); $foo->[1] = 4; print @bar; wicked cool... --Geoff > > Incidentally, does anyone know of a way to do this that works under > strict? The above requires a "no strict 'refs'" to work. > > -- > Roger Espel Llima, [EMAIL PROTECTED] > http://www.iagora.com/~espel/index.html >
Re: [ANNOUNCE] Apache::Dispatch-0.03
Matt Sergeant wrote:
> > I really wanted to have DispatchStat be On, Off, or ISA, where ISA reloaded
> > the asked for module and all it's parents - since given Class->method(),
> > method() might not actually be in Class. Basically, I wasn't able to find a
> > way to get to @Class::ISA where Class is unknown until run-time (that is,
> > it's held in $class). I figured I should be able to use some symbolic
> > referencing or something, but I couldn't get it to work.
>
> @{"${class}::ISA"}
Yep, that's one weird bit of syntax. I just needed this recently to
write a test.pl, and it took quite a bit of testing to get it working. :)
Incidentally, does anyone know of a way to do this that works under
strict? The above requires a "no strict 'refs'" to work.
--
Roger Espel Llima, [EMAIL PROTECTED]
http://www.iagora.com/~espel/index.html
RE: [ANNOUNCE] Apache::Dispatch-0.03
On Mon, 7 Aug 2000, Geoffrey Young wrote:
> ok, here's a pre-PAN
>
> http://morpheus.laserlink.net/~gyoung/modules/Apache-Dispatch-0.04.tar.gz
>
> I borrowed some code from Apache::StatINC to add a single module reload.
>
> Unfortunately, this doesn't cover inherited circumstances, although I don't
> know how important that is going to be to folks.
>
> I really wanted to have DispatchStat be On, Off, or ISA, where ISA reloaded
> the asked for module and all it's parents - since given Class->method(),
> method() might not actually be in Class. Basically, I wasn't able to find a
> way to get to @Class::ISA where Class is unknown until run-time (that is,
> it's held in $class). I figured I should be able to use some symbolic
> referencing or something, but I couldn't get it to work.
@{"${class}::ISA"}
--
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org
RE: [ANNOUNCE] Apache::Dispatch-0.03
ok, here's a pre-PAN http://morpheus.laserlink.net/~gyoung/modules/Apache-Dispatch-0.04.tar.gz I borrowed some code from Apache::StatINC to add a single module reload. Unfortunately, this doesn't cover inherited circumstances, although I don't know how important that is going to be to folks. I really wanted to have DispatchStat be On, Off, or ISA, where ISA reloaded the asked for module and all it's parents - since given Class->method(), method() might not actually be in Class. Basically, I wasn't able to find a way to get to @Class::ISA where Class is unknown until run-time (that is, it's held in $class). I figured I should be able to use some symbolic referencing or something, but I couldn't get it to work. other than that, it seems to work ok... suggestions welcome :) --Geoff
RE: [ANNOUNCE] Apache::Dispatch-0.03
> -Original Message- > From: Matt Sergeant [mailto:[EMAIL PROTECTED]] > Sent: Monday, August 07, 2000 9:45 AM > To: Geoffrey Young > Cc: '[EMAIL PROTECTED]' > Subject: RE: [ANNOUNCE] Apache::Dispatch-0.03 > > > > > so, you are desiring a StatINC like feature within Dispatch > itself? sounds > > like overkill to me - after all, you're in development, so stat()ing > > everything shouldn't be a big deal... > > OK, so take development out of the picture, and put in there > a server that > you can't restart, but would like to be able to tweak your > scripts on... yeah, yeah... :) actually, someone else asked me off the list for the same type of thing - I wasn't so sure about it, but I guess now I'm out numbered... DispatchStat On|Off coming soon to a server near you... --Geoff > > -- > > > Fastnet Software Ltd. High Performance Web Specialists > Providing mod_perl, XML, Sybase and Oracle solutions > Email for training and consultancy availability. > http://sergeant.org | AxKit: http://axkit.org >
RE: [ANNOUNCE] Apache::Dispatch-0.03
On Mon, 7 Aug 2000, Geoffrey Young wrote: > > Assuming you're in a development stage, I might expect > > Dispatch to stat > > the module that it's loading, like StatINC does, to check if it needs > > reloading again. And I'd turn that off for development. This gives you > > the advantage that Apache::Registry has of re-loading new > > scripts (except > > in Dispatch's case, its a module not a script). And it won't > > stat _all_ > > the modules installed on every hit, like StatINC does, so the overhead > > should be reasonable. > > well, I had assumed that for development, one could just install StatINC and > have that work, but I didn't actually try it. until now, that is, and yes, > it works... > > so, you are desiring a StatINC like feature within Dispatch itself? sounds > like overkill to me - after all, you're in development, so stat()ing > everything shouldn't be a big deal... OK, so take development out of the picture, and put in there a server that you can't restart, but would like to be able to tweak your scripts on... -- Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
RE: [ANNOUNCE] Apache::Dispatch-0.03
> -Original Message- > From: Matt Sergeant [mailto:[EMAIL PROTECTED]] > Sent: Monday, August 07, 2000 9:29 AM > To: Geoffrey Young > Cc: '[EMAIL PROTECTED]' > Subject: RE: [ANNOUNCE] Apache::Dispatch-0.03 > > > On Mon, 7 Aug 2000, Geoffrey Young wrote: > > > > Does Dispatch stat() the module on every hit? It might be > useful to > > > provide a switch to turn that off, if so. > > > > which I would guess is just apache doing apache translation > things, right? > > Yes, as the guide says, you could install an Apache::OK trans > handler to > get rid of those. > > > After determining the proper class->method() by parsing the > uri and making > > some assumptions, Dispatch.pm calls class->can(method), > which does magic > > things, of which I know little about the inner workings... > > > > I was interested in somehow trying to cache known methods to avoid > > successive can() calls, but I wasn't quite sure how to go > about that one > > yet... > > > > does that help? > > No, because it's not what I meant :-) oh :) > > Assuming you're in a development stage, I might expect > Dispatch to stat > the module that it's loading, like StatINC does, to check if it needs > reloading again. And I'd turn that off for development. This gives you > the advantage that Apache::Registry has of re-loading new > scripts (except > in Dispatch's case, its a module not a script). And it won't > stat _all_ > the modules installed on every hit, like StatINC does, so the overhead > should be reasonable. well, I had assumed that for development, one could just install StatINC and have that work, but I didn't actually try it. until now, that is, and yes, it works... so, you are desiring a StatINC like feature within Dispatch itself? sounds like overkill to me - after all, you're in development, so stat()ing everything shouldn't be a big deal... --Geoff > > -- > > > Fastnet Software Ltd. High Performance Web Specialists > Providing mod_perl, XML, Sybase and Oracle solutions > Email for training and consultancy availability. > http://sergeant.org | AxKit: http://axkit.org >
RE: [ANNOUNCE] Apache::Dispatch-0.03
On Mon, 7 Aug 2000, Geoffrey Young wrote: > > Does Dispatch stat() the module on every hit? It might be useful to > > provide a switch to turn that off, if so. > > which I would guess is just apache doing apache translation things, right? Yes, as the guide says, you could install an Apache::OK trans handler to get rid of those. > After determining the proper class->method() by parsing the uri and making > some assumptions, Dispatch.pm calls class->can(method), which does magic > things, of which I know little about the inner workings... > > I was interested in somehow trying to cache known methods to avoid > successive can() calls, but I wasn't quite sure how to go about that one > yet... > > does that help? No, because it's not what I meant :-) Assuming you're in a development stage, I might expect Dispatch to stat the module that it's loading, like StatINC does, to check if it needs reloading again. And I'd turn that off for development. This gives you the advantage that Apache::Registry has of re-loading new scripts (except in Dispatch's case, its a module not a script). And it won't stat _all_ the modules installed on every hit, like StatINC does, so the overhead should be reasonable. -- Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
RE: [ANNOUNCE] Apache::Dispatch-0.03
> -Original Message-
> From: Matt Sergeant [mailto:[EMAIL PROTECTED]]
> Sent: Monday, August 07, 2000 8:57 AM
> To: Geoffrey Young
> Cc: '[EMAIL PROTECTED]'
> Subject: RE: [ANNOUNCE] Apache::Dispatch-0.03
>
>
> On Mon, 7 Aug 2000, Geoffrey Young wrote:
>
> > for anyone who is interested (apparently not many :) I ran
> a quick "hello
> > world" LWP::Simple based benchmark using Apache::Registry (with
> > RegistryLoader), a normal PerlHandler, and Apache::Dispatch...
> >
> > Benchmark: timing 5000 iterations of dispatch, handler, registry...
> > dispatch: 108 wallclock secs (24.21 usr + 5.73 sys = 29.94 CPU) @
> > 167.00/s (n=5000)
> >handler: 91 wallclock secs (22.88 usr + 5.71 sys =
> 28.59 CPU) @ 174.89/s
> > (n=5000)
> > registry: 98 wallclock secs (23.77 usr + 5.45 sys =
> 29.22 CPU) @ 171.12/s
> > (n=5000)
>
> Does Dispatch stat() the module on every hit? It might be useful to
> provide a switch to turn that off, if so.
here's the only strace fragment with stat calls (with PerlSendHeaders Off)
read(3, "GET /Dispatch/foo HTTP/1.0\r\nConn"..., 4096) = 854
rt_sigaction(SIGUSR1, {SIG_IGN}, {SIG_IGN}, 8) = 0
time(NULL) = 965653681
gettimeofday({965653681, 395188}, NULL) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [RT_0], 8) = 0
stat("/usr/local/apache/spinnaker/Dispatch/foo", 0xb7cc) = -1 ENOENT (No
such file or directory)
stat("/usr/local/apache/spinnaker/Dispatch", 0xb7cc) = -1 ENOENT (No
such file or directory)
stat("/usr/local/apache/spinnaker", {st_mode=S_IFDIR|0755, st_size=1024,
...}) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [RT_0], 8) = 0
rt_sigaction(SIGALRM, NULL, {0x40099490, [], SA_INTERRUPT|0x400}, 8) = 0
dup2(15, 2) = 2
which I would guess is just apache doing apache translation things, right?
After determining the proper class->method() by parsing the uri and making
some assumptions, Dispatch.pm calls class->can(method), which does magic
things, of which I know little about the inner workings...
I was interested in somehow trying to cache known methods to avoid
successive can() calls, but I wasn't quite sure how to go about that one
yet...
does that help?
--Geoff
>
> --
>
>
> Fastnet Software Ltd. High Performance Web Specialists
> Providing mod_perl, XML, Sybase and Oracle solutions
> Email for training and consultancy availability.
> http://sergeant.org | AxKit: http://axkit.org
>
RE: [ANNOUNCE] Apache::Dispatch-0.03
On Mon, 7 Aug 2000, Geoffrey Young wrote: > for anyone who is interested (apparently not many :) I ran a quick "hello > world" LWP::Simple based benchmark using Apache::Registry (with > RegistryLoader), a normal PerlHandler, and Apache::Dispatch... > > Benchmark: timing 5000 iterations of dispatch, handler, registry... > dispatch: 108 wallclock secs (24.21 usr + 5.73 sys = 29.94 CPU) @ > 167.00/s (n=5000) >handler: 91 wallclock secs (22.88 usr + 5.71 sys = 28.59 CPU) @ 174.89/s > (n=5000) > registry: 98 wallclock secs (23.77 usr + 5.45 sys = 29.22 CPU) @ 171.12/s > (n=5000) Does Dispatch stat() the module on every hit? It might be useful to provide a switch to turn that off, if so. -- Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
RE: [ANNOUNCE] Apache::Dispatch-0.03
for anyone who is interested (apparently not many :) I ran a quick "hello
world" LWP::Simple based benchmark using Apache::Registry (with
RegistryLoader), a normal PerlHandler, and Apache::Dispatch...
Benchmark: timing 5000 iterations of dispatch, handler, registry...
dispatch: 108 wallclock secs (24.21 usr + 5.73 sys = 29.94 CPU) @
167.00/s (n=5000)
handler: 91 wallclock secs (22.88 usr + 5.71 sys = 28.59 CPU) @ 174.89/s
(n=5000)
registry: 98 wallclock secs (23.77 usr + 5.45 sys = 29.22 CPU) @ 171.12/s
(n=5000)
and also uncovered a small bug:
--- Dispatch.pm 2000/08/04 15:36:32 1.8
+++ Dispatch.pm 2000/08/07 12:00:41
@@ -105,9 +105,8 @@
# since the uri is dispatchable, check each of the extras
#-
- my @extras = $dcfg->{_extras} ?
- @{$dcfg->{_extras}} :
- @{$scfg->{_extras}};
+ my @extras = $dcfg->{_extras} ? @{$dcfg->{_extras}} :
+$scfg->{_extras} ? @{$scfg->{_extras}} : undef;
foreach my $extra (@extras) {
if ($extra eq "PRE") {
just FYI...
--Geoff
RE: [ANNOUNCE] Apache::Dispatch-0.02
> > -Original Message-
> > From: Matt Sergeant [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, August 01, 2000 9:46 AM
> > To: Geoffrey Young
> > Cc: '[EMAIL PROTECTED]'
> > Subject: Re: [ANNOUNCE] Apache::Dispatch-0.02
> >
> >
> >
> > You're gonna hate me for this...
> >
> > Can you add pre and post methods for the dispatching? It
> > would be really
> > useful to be able to (for example) save and restore
> $SIG{__DIE__}, and
> > maybe other things like that, rather than having to
> > explicitly remember to
> > call them yourself.
>
> ok, I'll work on adding pre_dispatch() and post_dispatch()
> (and possibly
> dispatch_error) calls to the existing framework and see what
> I can come up
> with...
>
> --Geoff
>
well, I wasn't able to get that functionality into the existing design, but
that's ok because I wasn't too happy with it anyway :)
http://morpheus.laserlink.net/~gyoung/modules/Apache-Dispatch-0.03.tar.gz
is the new version. I haven't uploaded it yet because I wanted to ask
anyone interested whether they are terribly upset that the API will be
changing and Apache::Dispatch won't support per-server handler calling.
Basically, you'll still need at least one , since in
order to get pre and post processing in, we had to move to PerlHandler from
PerlFixupHandler.
anyway, here's the new README. I think the code generally cleaner than what
came before, so I'll upload it later in the week if nobody speaks up and
objects :)
--Geoff
NAME
Apache::Dispatch - call PerlHandlers with the ease of CGI scripts
SYNOPSIS
httpd.conf:
PerlModule Apache::Dispatch
PerlModule Bar
SetHandler perl-script
PerlHandler Apache::Dispatch
DispatchPrefix Bar
DispatchExtras Pre Post Error
DESCRIPTION
Apache::Dispatch translates $r->uri into a class and method and runs
it as a PerlHandler. Basically, this allows you to call PerlHandlers
as you would CGI scripts - directly from the browser - without having
to load your httpd.conf with a slurry of tags.
EXAMPLE
in httpd.conf
PerlModule Apache::Dispatch
PerlModule Bar
SetHandler perl-script
PerlHandler Apache::Dispatch
DispatchPrefix Bar
DispatchExtras Pre Post Error
in browser:
http://localhost/Foo/baz
the results are the same as if your httpd.conf looked like:
SetHandler perl-script
PerlHandler Bar::dispatch_baz
This configuration offers additional security by protecting the
class from the browser and keeping the method name from being
called directly. Because any class under the Bar:: hierarchy can be
called, one directive is able to handle all the methods
of Bar, Bar::Baz, etc...
CONFIGURATION DIRECTIVES
DispatchPrefix
Applies on a per-location basis only. The base class to be
substituted for the $r->location part of the uri.
DispatchExtras
A list of extra processing to enable per-request. They may be
applied on a per-server or per-location basis. If the main
handler is not a valid method call, the request is declined prior
to the execution of any of the extra methods.
Pre - eval()s Foo->pre_dispatch() prior to dispatching the uri
uri. The $@ of the eval is not checked in any way.
Post - eval()s Foo->post_dispatch() prior to dispatching the
uri. The $@ of the eval is not checked.
Error - If the main handler returns other than OK then
Foo->error_dispatch() is called and return status of it
is returned instead. Without this feature, the return
status of your handler is returned.
SPECIAL CODING GUIDELINES
Apache::Dispatch uses object oriented calls behind the scenes. This
means that you either need to account for your handler to be called
as a method handler, such as
sub dispatch_bar {
my $class = shift; # your class
my $r = shift;
}
or get the Apache request object yourself via
sub dispatch_bar {
my $r = Apache->request;
}
NOTES
In addition to the special methods pre_dispatch(), post_dispatch(),
and error_dispatch(), if you define dispatch_index() it will be called
if the method is empty (eg, by /Foo or /Foo/).
There is no require()ing or use()ing of the packages or methods prior
to their use as a PerlHandler. This means that if you try to dispatch
a method without a PerlModule directive or use() entry in your
startup.pl you probably will not meet with much success. This adds a
bit of security and reminds us we should be pre-loading that code in
the parent process anyway...
If the uri can be dispatched but contains anything other than
[a-zA-Z0-9_/-] Apache::Dispatch declines to handle the request.
Like everything in perl, the package names are case sensit
RE: [ANNOUNCE] Apache::Dispatch-0.02
> -Original Message-
> From: Matt Sergeant [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, August 01, 2000 9:46 AM
> To: Geoffrey Young
> Cc: '[EMAIL PROTECTED]'
> Subject: Re: [ANNOUNCE] Apache::Dispatch-0.02
>
>
>
> You're gonna hate me for this...
>
> Can you add pre and post methods for the dispatching? It
> would be really
> useful to be able to (for example) save and restore $SIG{__DIE__}, and
> maybe other things like that, rather than having to
> explicitly remember to
> call them yourself.
ok, I'll work on adding pre_dispatch() and post_dispatch() (and possibly
dispatch_error) calls to the existing framework and see what I can come up
with...
--Geoff
>
> --
>
>
> Fastnet Software Ltd. High Performance Web Specialists
> Providing mod_perl, XML, Sybase and Oracle solutions
> Email for training and consultancy availability.
> http://sergeant.org | AxKit: http://axkit.org
>
Re: [ANNOUNCE] Apache::Dispatch-0.02
On Tue, 1 Aug 2000, Geoffrey Young wrote:
> The URL
>
>
> http://morpheus.laserlink.net/~gyoung/modules/Apache-Dispatch-0.02.tar.gz
>
> has entered CPAN as
>
> file: $CPAN/authors/id/G/GE/GEOFF/Apache-Dispatch-0.02.tar.gz
> size: 6362 bytes
>md5: 922a0064a77148d72aa29d3a9cc5db25
>
> Revision history for Perl extension Apache::Dispatch
>
> 0.01 7.28.2000
> - original version
> - many kudos and thanks to:
> Vivek Khera
> Matt Sergeant
> for the initial ideas and impetus
>
> 0.02 8.1.2000
> - thanks again to Matt Sergeant for input not limited to
> the following valuable suggestions
> o add DispatchBase for dispatching on a protected,
> per-location basis
> o add DispatchMethod Prefix for protecting methods
> behind a dispatch_ prepend
> - changed behavior of directory and server merges
> - updated the documentation
You're gonna hate me for this...
Can you add pre and post methods for the dispatching? It would be really
useful to be able to (for example) save and restore $SIG{__DIE__}, and
maybe other things like that, rather than having to explicitly remember to
call them yourself.
--
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org
RE: [ANNOUNCE] Apache::Dispatch
On Mon, 31 Jul 2000, Geoffrey Young wrote: > > Of course, but thats not likely to happen too often :) > > > > I don't think DispatchClass is a great name though. It > > implies that you'll > > always be calling methods in that class. Prefix sounded better to > > me... But you're the boss :) > > Because you won't always be calling Foo, but also Foo::Bar::Blarg? > > That makes sense... Go for it. With this module its not like you have to hack the config files very often anyway! -- Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
RE: [ANNOUNCE] Apache::Dispatch
> -Original Message- > From: Matt Sergeant [mailto:[EMAIL PROTECTED]] > Sent: Monday, July 31, 2000 10:35 AM > To: Geoffrey Young > Cc: [EMAIL PROTECTED] > Subject: RE: [ANNOUNCE] Apache::Dispatch > > > On Mon, 31 Jul 2000, Geoffrey Young wrote: > > > > > I'll remove Foolish (the name was a dead givaway that it > would be gone soon > > :), but I think that Brave would greatly enhance the > development process by > > allowing you to test handlers without having to stop and > start the server to > > add location tags to reload the module. I'll be sure to > add documentation > > to that extent. > > OK, I think the documentation then should suggest (obviously not > enforce) that this is useful primarily for testing new > handlers, not as a > way to build your application due to the inherent security issues. ok - I might even change the name to Development or something like that... > > > > [basically the way I saw it working was you specified a > > > namespace prefix > > > for each , so you'd have DispatchPrefix MyApp, and > > > http://server/location/Foo would call MyApp::Foo->handler, > > > assuming that > > > /location is the entry in for the above config line] > > > > I did re-read the archives and I saw you mention this. I > think I may add an > > additional directive > > DispatchClass that only works from a tag that > does just that. It > > would be in addition to the existing API and would allow > only one class per > > location. I'll also add documentation suggesting that it exists for > > security reasons, so using it like > > > > DispatchClass Foo > > > > defeats the purpose :) > > Of course, but thats not likely to happen too often :) > > I don't think DispatchClass is a great name though. It > implies that you'll > always be calling methods in that class. Prefix sounded better to > me... But you're the boss :) Because you won't always be calling Foo, but also Foo::Bar::Blarg? That makes sense... > > > > > > > > But maybe we're missing eachother on this? Or you > > > > have something in mind that I don't? I'll admit, I'm > > > > far from a web security expert, and this does need to > > > > be quite secure to be a benefit to anyone... > > > > > > > > as for method restrictions, I can't remember if it was > > > > talked about - I'll have to go over the archives > > > > again. > > > > however, having to specify Foo::Bar->method for each > > > > method you want to use seems like overkill to me, > > > > almost as limiting as having to add all those location > > > > tags. > > > > > > Thats not what I meant. If you just force a method prefix, > > > the same way I > > > suggest above using a namespace prefix, and default to cmd_ > > > or something, > > > then its much easier to design a complex app in a class > where you have > > > web-space functions (those beginning with cmd_) and non-web space > > > functions (i.e. private functions that implement parts of your > > > application, where you don't want people directly calling the > > > method). Without that, it would be trivial for someone to > > > call new() or > > > something, which might not be intended (and might have > side effects). > > > > right, now I remember. I still think that implying > handler() should be an > > option, however, since some people do write one handler per > module for > > mod_perl. How about changing DispatchMethod Subroutine to > Prefix and having > > that prefix all method calls with dispatch_ , which seems a > bit more self > > documenting? > > Sure. And have http://server/location/Foo/ call > MyApp::Foo->dispatch_index() (or if you want to be microsoftian, > dispatch_default() ;-) wow - maybe later. right now I have it declining directory requests so that mod_dir can handle them. that's a really good idea, though - I'll see what I can do with it... --Geoff > > -- > > > Fastnet Software Ltd. High Performance Web Specialists > Providing mod_perl, XML, Sybase and Oracle solutions > Email for training and consultancy availability. > http://sergeant.org | AxKit: http://axkit.org >
RE: [ANNOUNCE] Apache::Dispatch
On Mon, 31 Jul 2000, Geoffrey Young wrote: > > I'll remove Foolish (the name was a dead givaway that it would be gone soon > :), but I think that Brave would greatly enhance the development process by > allowing you to test handlers without having to stop and start the server to > add location tags to reload the module. I'll be sure to add documentation > to that extent. OK, I think the documentation then should suggest (obviously not enforce) that this is useful primarily for testing new handlers, not as a way to build your application due to the inherent security issues. > > [basically the way I saw it working was you specified a > > namespace prefix > > for each , so you'd have DispatchPrefix MyApp, and > > http://server/location/Foo would call MyApp::Foo->handler, > > assuming that > > /location is the entry in for the above config line] > > I did re-read the archives and I saw you mention this. I think I may add an > additional directive > DispatchClass that only works from a tag that does just that. It > would be in addition to the existing API and would allow only one class per > location. I'll also add documentation suggesting that it exists for > security reasons, so using it like > > DispatchClass Foo > > defeats the purpose :) Of course, but thats not likely to happen too often :) I don't think DispatchClass is a great name though. It implies that you'll always be calling methods in that class. Prefix sounded better to me... But you're the boss :) > > > > > But maybe we're missing eachother on this? Or you > > > have something in mind that I don't? I'll admit, I'm > > > far from a web security expert, and this does need to > > > be quite secure to be a benefit to anyone... > > > > > > as for method restrictions, I can't remember if it was > > > talked about - I'll have to go over the archives > > > again. > > > however, having to specify Foo::Bar->method for each > > > method you want to use seems like overkill to me, > > > almost as limiting as having to add all those location > > > tags. > > > > Thats not what I meant. If you just force a method prefix, > > the same way I > > suggest above using a namespace prefix, and default to cmd_ > > or something, > > then its much easier to design a complex app in a class where you have > > web-space functions (those beginning with cmd_) and non-web space > > functions (i.e. private functions that implement parts of your > > application, where you don't want people directly calling the > > method). Without that, it would be trivial for someone to > > call new() or > > something, which might not be intended (and might have side effects). > > right, now I remember. I still think that implying handler() should be an > option, however, since some people do write one handler per module for > mod_perl. How about changing DispatchMethod Subroutine to Prefix and having > that prefix all method calls with dispatch_ , which seems a bit more self > documenting? Sure. And have http://server/location/Foo/ call MyApp::Foo->dispatch_index() (or if you want to be microsoftian, dispatch_default() ;-) -- Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
RE: [ANNOUNCE] Apache::Dispatch
> -Original Message-
> From: Matt Sergeant [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, July 29, 2000 6:16 AM
> To: Geoffrey Young
> Cc: [EMAIL PROTECTED]
> Subject: Re: [ANNOUNCE] Apache::Dispatch
>
>
> On Fri, 28 Jul 2000, Geoffrey Young wrote:
>
> > hi Matt...
> >
> > I can't access my normal email from home, so forgive
> > the non-quoting of your message... :)
> >
> > the way I set it up, when running in DispatchMode =
> > Safe (the default, which I didn't mention in the
> > docs), you wouldn't be able to call /File/Find/find
> > without explitily allowing File or File::Find in
> > DispatchAllow. I think this addresses the namespace
> > issue - if someone wants to open up File::Find, or
> > whatever, that badly, they can always do it anyway, I
> > suppose.
>
> OK, I think that covers the namespace issue - although I
> don't see a use
> for a non-safe mode!
thanks for the input. after thinking about it over the weekend, I think we
just need a few changes to make it better...
I'll remove Foolish (the name was a dead givaway that it would be gone soon
:), but I think that Brave would greatly enhance the development process by
allowing you to test handlers without having to stop and start the server to
add location tags to reload the module. I'll be sure to add documentation
to that extent.
>
> [basically the way I saw it working was you specified a
> namespace prefix
> for each , so you'd have DispatchPrefix MyApp, and
> http://server/location/Foo would call MyApp::Foo->handler,
> assuming that
> /location is the entry in for the above config line]
I did re-read the archives and I saw you mention this. I think I may add an
additional directive
DispatchClass that only works from a tag that does just that. It
would be in addition to the existing API and would allow only one class per
location. I'll also add documentation suggesting that it exists for
security reasons, so using it like
DispatchClass Foo
defeats the purpose :)
>
> > But maybe we're missing eachother on this? Or you
> > have something in mind that I don't? I'll admit, I'm
> > far from a web security expert, and this does need to
> > be quite secure to be a benefit to anyone...
> >
> > as for method restrictions, I can't remember if it was
> > talked about - I'll have to go over the archives
> > again.
> > however, having to specify Foo::Bar->method for each
> > method you want to use seems like overkill to me,
> > almost as limiting as having to add all those location
> > tags.
>
> Thats not what I meant. If you just force a method prefix,
> the same way I
> suggest above using a namespace prefix, and default to cmd_
> or something,
> then its much easier to design a complex app in a class where you have
> web-space functions (those beginning with cmd_) and non-web space
> functions (i.e. private functions that implement parts of your
> application, where you don't want people directly calling the
> method). Without that, it would be trivial for someone to
> call new() or
> something, which might not be intended (and might have side effects).
right, now I remember. I still think that implying handler() should be an
option, however, since some people do write one handler per module for
mod_perl. How about changing DispatchMethod Subroutine to Prefix and having
that prefix all method calls with dispatch_ , which seems a bit more self
documenting?
>
> > I suppose that setting DispatchMethod = Handler
> > (the default) along with Safe mode would offer a good
> > amount of protection against blunders, allowing only
> > Foo::Bar->handler. I guess I was just trying to offer
> > a fair amount of flexibility, but with flexibility
> > comes the ability to kill your server. of course, a
> > regular CGI script can do that too if you're not
> > careful. :)
>
> Thats too restrictive - that way you have to have one class
> per URL - not
> a nice way to work.
>
> > I don't really think that, in general, imposing method
> > restrictions is necessary, for there isn't really a
> > way to pass any arguments to the method anyway, right?
> > don't all mod_perl handlers get the request object as
> > the only argument (unless prototyped as $$)?
>
> Just because you can't pass arguments, doesn't mean bad stuff can
> happen... Imagine you write a sub clear_cache {...}, that empties some
> sort of cache. It doesn't take any arguments,
> Apache::Dispatch passes in a
> request object as the first param, but its ignored by the
> function, and
> the 733t h4x0r has cleared your cache. (not a terribly
> dangerous example,
> but hopefully you get the picture).
yeah, I see it now...
do you think the above addresses all your issues?
--Geoff
>
> --
>
>
> Fastnet Software Ltd. High Performance Web Specialists
> Providing mod_perl, XML, Sybase and Oracle solutions
> Email for training and consultancy availability.
> http://sergeant.org | AxKit: http://axkit.org
>
Re: [ANNOUNCE] Apache::Dispatch
On Fri, 28 Jul 2000, Geoffrey Young wrote:
> hi Matt...
>
> I can't access my normal email from home, so forgive
> the non-quoting of your message... :)
>
> the way I set it up, when running in DispatchMode =
> Safe (the default, which I didn't mention in the
> docs), you wouldn't be able to call /File/Find/find
> without explitily allowing File or File::Find in
> DispatchAllow. I think this addresses the namespace
> issue - if someone wants to open up File::Find, or
> whatever, that badly, they can always do it anyway, I
> suppose.
OK, I think that covers the namespace issue - although I don't see a use
for a non-safe mode!
[basically the way I saw it working was you specified a namespace prefix
for each , so you'd have DispatchPrefix MyApp, and
http://server/location/Foo would call MyApp::Foo->handler, assuming that
/location is the entry in for the above config line]
> But maybe we're missing eachother on this? Or you
> have something in mind that I don't? I'll admit, I'm
> far from a web security expert, and this does need to
> be quite secure to be a benefit to anyone...
>
> as for method restrictions, I can't remember if it was
> talked about - I'll have to go over the archives
> again.
> however, having to specify Foo::Bar->method for each
> method you want to use seems like overkill to me,
> almost as limiting as having to add all those location
> tags.
Thats not what I meant. If you just force a method prefix, the same way I
suggest above using a namespace prefix, and default to cmd_ or something,
then its much easier to design a complex app in a class where you have
web-space functions (those beginning with cmd_) and non-web space
functions (i.e. private functions that implement parts of your
application, where you don't want people directly calling the
method). Without that, it would be trivial for someone to call new() or
something, which might not be intended (and might have side effects).
> I suppose that setting DispatchMethod = Handler
> (the default) along with Safe mode would offer a good
> amount of protection against blunders, allowing only
> Foo::Bar->handler. I guess I was just trying to offer
> a fair amount of flexibility, but with flexibility
> comes the ability to kill your server. of course, a
> regular CGI script can do that too if you're not
> careful. :)
Thats too restrictive - that way you have to have one class per URL - not
a nice way to work.
> I don't really think that, in general, imposing method
> restrictions is necessary, for there isn't really a
> way to pass any arguments to the method anyway, right?
> don't all mod_perl handlers get the request object as
> the only argument (unless prototyped as $$)?
Just because you can't pass arguments, doesn't mean bad stuff can
happen... Imagine you write a sub clear_cache {...}, that empties some
sort of cache. It doesn't take any arguments, Apache::Dispatch passes in a
request object as the first param, but its ignored by the function, and
the 733t h4x0r has cleared your cache. (not a terribly dangerous example,
but hopefully you get the picture).
--
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org
Re: [ANNOUNCE] Apache::Dispatch
hi Matt... I can't access my normal email from home, so forgive the non-quoting of your message... :) the way I set it up, when running in DispatchMode = Safe (the default, which I didn't mention in the docs), you wouldn't be able to call /File/Find/find without explitily allowing File or File::Find in DispatchAllow. I think this addresses the namespace issue - if someone wants to open up File::Find, or whatever, that badly, they can always do it anyway, I suppose. But maybe we're missing eachother on this? Or you have something in mind that I don't? I'll admit, I'm far from a web security expert, and this does need to be quite secure to be a benefit to anyone... as for method restrictions, I can't remember if it was talked about - I'll have to go over the archives again. however, having to specify Foo::Bar->method for each method you want to use seems like overkill to me, almost as limiting as having to add all those location tags. I suppose that setting DispatchMethod = Handler (the default) along with Safe mode would offer a good amount of protection against blunders, allowing only Foo::Bar->handler. I guess I was just trying to offer a fair amount of flexibility, but with flexibility comes the ability to kill your server. of course, a regular CGI script can do that too if you're not careful. :) I don't really think that, in general, imposing method restrictions is necessary, for there isn't really a way to pass any arguments to the method anyway, right? don't all mod_perl handlers get the request object as the only argument (unless prototyped as $$)? It had occured to me not to allow Foolish behavior (allowing anything under the sun to execute) so I may remove it if there is much reservation from folks... let me know what you think... --Geoff __ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/
Re: [ANNOUNCE] Apache::Dispatch
On Fri, 28 Jul 2000, Geoffrey Young wrote: > The URL > > > http://morpheus.laserlink.net/~gyoung/modules/Apache-Dispatch-0.01.tar.gz > > has entered CPAN as > > file: $CPAN/authors/id/G/GE/GEOFF/Apache-Dispatch-0.01.tar.gz > size: 5170 bytes >md5: acee515fc8d19223f017c8380cae5b26 > > well, after the conference, I felt motivated to do some stuff. Then I got > on the red-eye and spent the early part of this week recovering :) > > anyway, Apache::Dispatch is a module we've talked about before and that I've > been meaning to get to for a while, but just found the tuits this week. > > Hopefully, it addresses some of the safety concerns expressed a few months > ago about such a concept. consider it REAL alphaware for the moment - it > works (at least for me), but until everyone pokes around it some and looks > for holes it may not be entirely safe. > > that said, if people are listening beyond the template traffic, here is the > README... Hmm... I'm not convinced of the security yet, although I'm tired so bear with me if I missed something in my reading of this. I thought we'd agreed that you needed at least two things: Namespace prefixes and method prefixes. If you don't require namespace prefixes you're going to get someone finding horrible exploits like using File/Find/find or something horrid, and if you don't require function prefixes someone is likely to find an exploit another way, and it doesn't allow you to have private functions... Let me know if I'm way off, or missed something in the docs. -- Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
