Hey All,I'm having an issue where Mojolicious isn't parsing my request's URLs correctly. The result of which is that none of my routes are getting triggered correctly.
$r->get('/myredis/script/my_redis.cgi/#host/:port/key')->to('RedisKey#getKeys');
--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious...@googlegroups.com.
To post to this group, send email to mojol...@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Is there anyone that has any idea how to begin troubleshooting this issue? Thanks.
I would still recommend mentioning the requirement of these environment variables to exist somewhere in the Mojolicious docs.
I'm not sure of the apache version. I don't remember totally, but I wouldn't be surprised if it was a manual tweak to our suexec to increase security within our organization.
Everybody?
A subset is just broken, and not your problem. A superset is irrelevant.
I'd consider it to be quite a headache to need to set up a PSGI on all my
systems which currently run multiple CGIs just fine.
There's barely any change in CGI.pm between 3.33 and 5.04 - is it really
such a maintenance burden?
On Jun 6, 2014 4:59 PM, "sri" <kra...@googlemail.com> wrote:
>
> time to push forward.
Is it possible that someone (Charlie? :) could maintain Mojo:: Server:: CGI independently of core?
Is it possible that someone (Charlie? :) could maintain Mojo:: Server:: CGI independently of core?
On Jun 6, 2014 5:31 PM, "sri" <kra...@googlemail.com> wrote:
>>
>> Is it possible that someone (Charlie? :) could maintain Mojo:: Server:: CGI independently of core?
>
>
> Absolutely, but i think there are some misconceptions flying around here. CGI would still be supported through Mojo::Server::PSGI, you just have to install Plack::Handler::CGI.
Forgive me for not knowing anything about plack, but I thought it prudent for the sake of the thread. Is that module literally the only dependency or does it depend on much more and possibly even a separate installed server?
Is that module literally the only dependency or does it depend on much more and possibly even a separate installed server?
On Jun 6, 2014 5:54 PM, "sri" <kra...@googlemail.com> wrote:
>
> There's an app for that.
Wow! Thanks! Cookbook, FAQ, or Wiki that?
[root@sdfdsf ~]# rpm -Uhv perl-Plack-0.9979-2.el6.rfx.noarch.rpm
error: Failed dependencies:
perl(Devel::StackTrace) >= 1.23 is needed by perl-Plack-0.9979-2.el6.rfx.noarch
perl(Devel::StackTrace::AsHTML) >= 0.11 is needed by perl-Plack-0.9979-2.el6.rfx.noarch
perl(File::ShareDir) >= 1.00 is needed by perl-Plack-0.9979-2.el6.rfx.noarch
perl(Filesys::Notify::Simple) is needed by perl-Plack-0.9979-2.el6.rfx.noarch
perl(HTTP::Body) >= 1.06 is needed by perl-Plack-0.9979-2.el6.rfx.noarch
perl(Hash::MultiValue) >= 0.05 is needed by perl-Plack-0.9979-2.el6.rfx.noarch
perl(Test::TCP) >= 0.11 is needed by perl-Plack-0.9979-2.el6.rfx.noarch
perl(Try::Tiny) is needed by perl-Plack-0.9979-2.el6.rfx.noarch
perl(parent) is needed by perl-Plack-0.9979-2.el6.rfx.noarch
[root@sdfdsf ~]#
From what I can see, deployment using PSGI under apache is signficantly
more complex than with CGI, and not necessarily less error prone:
https://groups.google.com/forum/#!topic/mojolicious/oXeCLxe6hIY
No, RHEL does have a mechanism of resolving dependencies. 'yum' will do
that. However many of the modules required by Plack are not included in
the standard RHEL repositories.
The only point I am making is that this assertion is false:
Literally all you have to do is change the shebang line.
CGI "just works". It would be a shame to see it be removed.
From what I can see, deployment using PSGI under apache is signficantly
more complex than with CGI, and not necessarily less error prone:
https://groups.google.com/forum/#!topic/mojolicious/oXeCLxe6hIY
CGI solves a particular class of problem in a perfectly good, language
agnostic manner. Adding persistent services in place of those CGIs where none
is needed actually increases deployment complexity. I thought we liked simple.
I'm not using Mojo for a public website, I'm using it for less frequently
accessed, private services in a server management layer. If CGI solves my
problem, why should I care if someone ignorant of the problems that I must
solve has decided to deprecate it?
There's barely any change in CGI.pm between 3.33 and 5.04 - is it really
such a maintenance burden?
For the record, this change i just made, to get consistent reverse proxy support across all server backends, did have additional maintenance costs because of CGI.