We use redirect() for similar purposes here on D1, and it works. Maybe
that will suffice for you.
Tried it, still got the same error. We're also using D1.
However, I think I cracked it. This appears to work:
if (!$client) {
request->path_info('/error/notfound');
return;
}
Then I can either define '/error/notfound' or not, in which case no routes
match which gets treated like a 404 error anyway. Perfect!
netstat -na | grep 3306.*ESTA | wc -l or sudo lsof -n | grep
mysql.sock | wc -l
Thank you. Very useful trick to keep in the toolbox!
Redirecting to a login or home page is probably a more common response to
that sort of error, since a 404 page doesn’t help the user fix the
problem.
We have a bunch of different "clients" and they're all completely separate
companies. Think "https://payroll.com/microsoft";,
"https://payroll.com/ibm";, "https://payroll.com/apple";, etc. We don't
really want anyone knowing who the clients are, etc. So if they can't find
their particular '/client' page, a 404 is perfect. Again, just the nuances
of my particular business logic.
Thanks for your help!
-----Original Message-----
From: Warren Young
Sent: Tuesday, November 10, 2015 12:05 PM
To: Perl Dancer users mailing list
Subject: Re: [dancer-users] Triggering 404 error from a hook
On Nov 9, 2015, at 11:16 PM, Hermann Calabria <[email protected]> wrote:
It seems maybe send_error() is not allowed within a before_hook.
We use redirect() for similar purposes here on D1, and it works. Maybe that
will suffice for you.
You should be caching database connections.
Hmmm does this code not do that? I'm using the Dancer Database plugin
(and not the old plain DBI),
I had no idea where database() came from when I wrote that, and I don’t use
that plugin anyway. If you force it to use a TCP connection by giving a
host name, you can probably find out if it creates a new connection for each
page load with:
netstat -na | grep 3306.*ESTA | wc -l
or
sudo lsof -n | grep mysql.sock | wc -l
(The first for TCP, the second for the Unix domain socket.)
Why 404?
Because the routes are named
/:client
/:client/foo
/:client/bar
/:client/foo/bar/foobar
etc...
so, if a database for /:client doesn't exist, it means (within the context
of my app) the URI doesn't exist.
Redirecting to a login or home page is probably a more common response to
that sort of error, since a 404 page doesn’t help the user fix the problem.
404 would be appropriate if a logged-in user tried to go to
/:client/foo/qux, for example: i.e. a clear case of a dead bookmark, or
bogus hand-hacking of the URL.
_______________________________________________
dancer-users mailing list
[email protected]
http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
_______________________________________________
dancer-users mailing list
[email protected]
http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
