Request URI not being parsed correctly in CGI mode

[Joel Martinez]

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.

This is my current setup:

I have a file "my_redis.cgi" with the following:

use FindBin;

use lib "$FindBin::Bin/../lib";

# Start commands for application

require Mojolicious::Commands;

Mojolicious::Commands->start_app('MyRedis');

Then in lib/MyRedis.pm

package MyRedis;

use Mojo::Base 'Mojolicious';

 

# This method will run once at server start

sub startup {

    my $self = shift;

    

    # Router

    my $r = $self->routes;

    

    # Normal route to controller

    $r->route('/')->to(

        controller => 'Browser',

        action => 'index'

    );

    $r->get('/myredis/script/my_redis.cgi/#host/:port/key')->to('RedisKey#getKeys');

}

The problem is that no matter what URL I request from my_redis.cgi, I always get served the "index" page ('/' route).  For example:  http://mydomain/myredis/script/my_redis.cgi/somehost/6379/key will return the index page.

I've tried inspecting what Mojolicious is parsing as the url in a "before_dispatch" hook in my "startup" function and it's empty.  For example:

$self->hook(before_dispatch => sub {

        my $self = shift;

        warn $self->req->url->path;   #NOTHING!

 });

If someone could tell me what I'm missing here, I'd GREATLY appreciate it.  Thank you in advance.

Joel

[Skye Shaw!@#$]

On Friday, February 1, 2013 8:00:43 PM UTC-5, Joel Martinez wrote:

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 shouldn't have to give the full path. Normally when running under CGI Mojolicious will try to resolve the route based on the /#host/:port/key portion of the path. 

Try $r->get('/#host/:port/key')->to('RedisKey#getKeys');

-Skye

[Joel Martinez]

Thanks for your response, but I've actually already tried that. Nothing is getting through as the path. 

--
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.
 
 

[Skye Shaw!@#$]

Have a look at this too: https://metacpan.org/module/Mojolicious::Guides::Routing

-Skye

[Joel Martinez]

I scoured the documentation quite thoroughly.  Nothing seems to address this issue.  

Is there anyone that has any idea how to begin troubleshooting this issue?  Thanks.

[Tekki]

Am Dienstag, 5. Februar 2013 01:53:28 UTC+1 schrieb Joel Martinez:

Is there anyone that has any idea how to begin troubleshooting this issue?  Thanks.

In CGI mode, begin with your Apache config.

[Joel Martinez]

I found a solution to this.  It's a hack.  I feel like what I encountered is a bug in Mojolicious.  This is what I found...

I started inspecting the source code.  In Mojo::URL.pm there is a function called "parse" which is responsible for parsing the request URI and populating itself so that the appropriate route can be triggered based on the request.

In this function, I added a "warn" line to see what was being passed in:

sub parse {

  my ($self, $url) = @_;

  

  warn "URL: $url"; #NOTHING in $url

  

  return $self unless $url;

  # Official regex

  $url =~ m!(?:([^:/?#]+):)?(?://([^/?#]*))?([^?#]*)(?:\?([^#]*))?(?:#(.*))?!;

  $self->scheme($1);

  $self->authority($2);

  $self->path->parse($3);

  $self->query($4);

  $self->fragment($5);

  return $self;

}

When I ran this, the url parameter $url never gets passed to parse.  I have no idea why this is happening.  But to fix this issue, I added this to my main  controller script and it all began working:

$self->hook(before_dispatch => sub {

        my $self = shift;

        $self->req->url->parse($self->req->env->{REQUEST_URI}));

});

# Router

my $r = $self->routes;

#WORKS!

$r->get('/myredis/script/my_redis.cgi/#host/:port/key')->to('RedisKey#getKeys');

So essentially I'm just manually parsing the Environment REQUEST_URI variable in a "before_dispatch" hook.  Why Mojolicious can't do this automatically... I don't know.

Hope that helps someone.

[Sebastian Riedel]

> So essentially I'm just manually parsing the Environment REQUEST_URI variable in a "before_dispatch" hook. Why Mojolicious can't do this automatically... I don't know.

If you want to work on this, all our test cases can be found here.

https://github.com/kraih/mojo/blob/master/t/mojo/request_cgi.t

--
Sebastian Riedel
http://twitter.com/kraih
http://mojolicio.us

[sri]

> If you want to work on this, all our test cases can be found here.
>
>    https://github.com/kraih/mojo/blob/master/t/mojo/request_cgi.t

And the actual parser is here.

https://github.com/kraih/mojo/blob/master/lib/Mojo/Message/Request.pm#L203

[Joel Martinez]

Ok so after inspecting "_parse_env" in Mojo::Message::Request I think I've narrowed down the issue.  It appears as if some of the environment variables Mojolicious expects aren't being set correctly.   Here is what "$env" holds in that function:

$VAR1 = {

          'SERVER_NAME' => 'lcwebdev.llnl.gov',

          'REMOTE_ADDR' => 'xxx.xxx.xxx.xxx',

          'MOJO_HELP' => '',

          'REQUEST_METHOD' => 'GET',

          'PATH' => '/usr/local/bin:/usr/bin:/bin',

          'REQUEST_URI' => '/myredis/script/my_redis.cgi/some/other/stuff',

          'GATEWAY_INTERFACE' => 'CGI/1.1',

          'REMOTE_USER' => 'joeltine',

          'AUTH_TYPE' => 'Basic',

          'HTTP_USER_AGENT' => 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.57 Safari/537.17',

          'QUERY_STRING' => ''

        };

But it appears Mojolicious needs PATH_INFO, HTTPS or SERVER_PROTOCOL, and SCRIPT_NAME in it's routine.  Do you have any clue why these might not be set as environment variables correctly?

[Joel Martinez]

SOLVED!

It turns out an apache module "suexec" was blocking these (and many other) environment variables from being set.  Turns out "suexec" has a whitelist of environment variables that it allows.  I enabled these and everything is working splendidly.

On a side note... to save others the frustration I went through, perhaps you could add some sort of sanity check for these environment variables in CGI mode.  Seeing as how this parse_env function depends on them, it would be nice to see some sort of error if they couldn't be found instead of silently failing.

Thanks for your help.

On Tuesday, February 5, 2013 10:02:26 AM UTC-8, sri wrote:

[Sebastian Riedel]

> On a side note... to save others the frustration I went through, perhaps you could add some sort of sanity check for these environment variables in CGI mode. Seeing as how this parse_env function depends on them, it would be nice to see some sort of error if they couldn't be found instead of silently failing.

I'm in favor of this, but we would need one or more volunteers to work out which combinations of environment variables work and which are not enough to get all the information we need. A rather big task that would also require the addition of many new tests.

[Joel Martinez]

Well if you wanted to save some effort, you could just add a piece to the documentation mentioning the env variables referenced in this function. 

[Charlie Brady]

On Tue, 5 Feb 2013, Joel Martinez wrote:

> SOLVED!
>
> It turns out an apache module "suexec" was blocking these (and many other)
> environment variables from being set. Turns out "suexec" has a whitelist
> of environment variables that it allows. I enabled these and everything is
> working splendidly.

Instead of using suexec, you could use file permissions and a setuid perl
script as your CGI. You will need to make a few small patches to
Mojolicious - I've posted them earlier on this mailing list.

http://grokbase.com/t/gg/mojolicious/131dv7e35n/opinion-on-taint-mode

---
Charlie

[Charlie Brady]

On Tue, 5 Feb 2013, Joel Martinez wrote:

>> But it appears Mojolicious needs PATH_INFO, HTTPS or SERVER_PROTOCOL,
>> and SCRIPT_NAME in it's routine. Do you have any clue why these might
>> not be set as environment variables correctly?
>

> SOLVED!
>
> It turns out an apache module "suexec" was blocking these (and many other)
> environment variables from being set. Turns out "suexec" has a whitelist
> of environment variables that it allows. I enabled these and everything is
> working splendidly.

What version of apache were you using? I see PATH_INFO, HTTPS,
SERVER_PROTOCOL and SCRIPT_NAME in safe_env_lst[] in suexec.c in apache
2.2.15 source code, so they are already whitelisted in that version.

> On a side note... to save others the frustration I went through, perhaps
> you could add some sort of sanity check for these environment variables in
> CGI mode. Seeing as how this parse_env function depends on them, it would
> be nice to see some sort of error if they couldn't be found instead of
> silently failing.

If anyone knows of problems with request parsing/routing in CGI, please
report via github issues.

[Joel Martinez]

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.  

I would still recommend mentioning the requirement of these environment variables to exist somewhere in the Mojolicious docs.

[sri]

I would still recommend mentioning the requirement of these environment variables to exist somewhere in the Mojolicious docs.

Already mentioned, with links to the RFC.

    http://mojolicio.us/perldoc/Mojo/Server/CGI#DESCRIPTION

--

sebastian 

[Charlie Brady]

On Fri, 6 Jun 2014, Joel Martinez wrote:

> 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.

You said "I enabled these and everything is working splendidly". Can you
verify that you edited suexec.c and rebuilt apache? Do you have before and
after versions of the code?

> I would still recommend mentioning the requirement of these environment
> variables to exist somewhere in the Mojolicious docs.

I don't think repeating the specification of the CGI belongs in the

[sri]

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.

You bring up a very good point though, this shit really makes my blood boil, the RFC for CGI is basically worthless, because everybody cooks up their own little subset/superset. This might be the strongest argument yet for getting rid of Mojo::Server::CGI and leaving all legacy deployment to Mojo::Server::PSGI, which has been much less of a headache.

--

sebastian

[Joel Martinez]

Unfortunately, I can't verify your question regarding suexec.c and building Apache as I have moved on from that organization and, frankly, can't remember.  I've cc'd the current owners of the code.  They may be able to help you.

[Charlie Brady]

On Fri, 6 Jun 2014, sri wrote:

> > 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.
>
> You bring up a very good point though, this shit really makes my blood
> boil, the RFC for CGI is basically worthless, because everybody cooks up
> their own little subset/superset.

Everybody?

A subset is just broken, and not your problem. A superset is irrelevant.

> This might be the strongest argument yet for getting rid of
> Mojo::Server::CGI and leaving all legacy deployment to
> Mojo::Server::PSGI, which has been much less of a headache.

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?

[sri]

Everybody?

Even in mainstream servers, one setting that's not 100% correct and you'll spend hours tracking down whatever garbled up your paths.

A subset is just broken, and not your problem. A superset is irrelevant.

Some like IIS are both.

 

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.

What is *a* PSGI?

 

There's barely any change in CGI.pm between 3.33 and 5.04 - is it really
such a maintenance burden?

It's a burden on the community, we shouldn't have to waste so much time with legacy deployment methods here and on IRC, time to push forward.

--

sebastian

[Stefan Adams]

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?

[sri]

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.

--

sebastian 

[Stefan Adams]

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?

[sri]

Is that module literally the only dependency or does it depend on much more and possibly even a separate installed server?

There's an app for that.

    https://widgets.stratopan.com/wheel?q=Plack-1.0030&fs=1

Literally all you have to do is change the shebang line.

  #!/usr/bin/env plackup -s CGI

  use Mojolicious::Lite;

  get '/' => {text => 'Hello PSGI!'};

  app->start;

--

sebastian

[Stefan Adams]

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?

[Charlie Brady]

On Fri, 6 Jun 2014, sri wrote:

> > 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.
>
> What is *a* PSGI?

Sorry, a typo - an important missing word - "a PSGI environment". Which,
unfortunately, is not trivial. Unlike with Mojolicious, one soon enters
dependency hell...

[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 ~]#

[sri]

[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 ~]#

I'm having a very hard time following your argument here, are you implying that RHEL has no way of resolving the dependencies for you?

--

sebastian 

[Charlie Brady]

On Mon, 9 Jun 2014, sri wrote:

> > [root@sdfdsf ~]# rpm -Uhv perl-Plack-0.9979-2.el6.rfx.noarch.rpm
> > error: Failed dependencies:
> > perl(Devel::StackTrace) >= 1.23 is needed by

[snip]

> I'm having a very hard time following your argument here,

Sorry.

> are you implying that RHEL has no way of resolving the dependencies for
> you?

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.

...
--> Finished Dependency Resolution
Error: Package: perl-Plack-0.9979-2.el6.rfx.noarch
(/perl-Plack-0.9979-2.el6.rfx.noarch)
Requires: perl(Hash::MultiValue) >= 0.05
Error: Package: perl-Plack-0.9979-2.el6.rfx.noarch
(/perl-Plack-0.9979-2.el6.rfx.noarch)
Requires: perl(Devel::StackTrace::AsHTML) >= 0.11
Error: Package: perl-Plack-0.9979-2.el6.rfx.noarch
(/perl-Plack-0.9979-2.el6.rfx.noarch)
Requires: perl(Try::Tiny)
Error: Package: perl-Plack-0.9979-2.el6.rfx.noarch
(/perl-Plack-0.9979-2.el6.rfx.noarch)
Requires: perl(Devel::StackTrace) >= 1.23
Available: 1:perl-Devel-StackTrace-1.22-4.el6.noarch (base)
perl(Devel::StackTrace) = 1.22
Error: Package: perl-Plack-0.9979-2.el6.rfx.noarch
(/perl-Plack-0.9979-2.el6.rfx.noarch)
Requires: perl(Test::TCP) >= 0.11
Error: Package: perl-Plack-0.9979-2.el6.rfx.noarch
(/perl-Plack-0.9979-2.el6.rfx.noarch)
Requires: perl(File::ShareDir) >= 1.00
Error: Package: perl-Plack-0.9979-2.el6.rfx.noarch
(/perl-Plack-0.9979-2.el6.rfx.noarch)
Requires: perl(HTTP::Body) >= 1.06
Error: Package: perl-Plack-0.9979-2.el6.rfx.noarch
(/perl-Plack-0.9979-2.el6.rfx.noarch)
Requires: perl(Filesys::Notify::Simple)
...

Even with the addition of the epel repositories, there are still
unresolved dependencies.

...
Error: Package: perl-Plack-0.9979-2.el6.rfx.noarch
(/perl-Plack-0.9979-2.el6.rfx.noarch)
Requires: perl(Devel::StackTrace) >= 1.23
Available: 1:perl-Devel-StackTrace-1.22-4.el6.noarch (base)
perl(Devel::StackTrace) = 1.22
Error: Package: perl-Plack-0.9979-2.el6.rfx.noarch
(/perl-Plack-0.9979-2.el6.rfx.noarch)
Requires: perl(Devel::StackTrace::AsHTML) >= 0.11
...

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

[sri]

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

This is a very misleading statement, and i do not appreciate it, that thread is entirely about mod_perl.

--

sebastian

[Helmut Wollmersdorfer]

Am Montag, 9. Juni 2014 17:19:56 UTC+2 schrieb Charlie Brady:

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.

Then use another distribution. I always came back to Debian in the last 16 years.

Or use CPAN directly,  or perlbrew+cpanm, or carton, or ...

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.

Why not remove something deprecated? 

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

As I was involved in this thread, I cannot see why you got the impression "it's complicated".

E.g. with mod_perl it's as simple as the wiki chapter https://github.com/kraih/mojo/wiki/Apache-deployment#apachemod_perl-psgiplack which I reviewed and changed.

Users think complicated, and I also did in my first attempts. I needed many hours to go deep in the details of Plack/PSGI and other sources to learn the hard way, that it is simple.

IMHO users of Apache make the mistake to solve non-existing problems in Apache, thinking CGI/PHP, doing url-rewrite, redirect and so on. And that's harmful, where I can understand sri not willing to support or debug insane configurations.

[Helmut Wollmersdorfer]

IMHO that thread was about "How do I use Plack correctly?" and "How do I 'use lib ...' correctly?" 

Done the right way it's possible to start MyApp on the console, in t/*, under mod_perl, and under whatever-else-not-yet-tested-by-me.

Thanks the developers of Mojo and Plack it's that simple and flexible.

[Charlie Brady]

On Fri, 13 Jun 2014, Helmut Wollmersdorfer wrote:

> Am Montag, 9. Juni 2014 17:19:56 UTC+2 schrieb Charlie Brady:
> >
> > 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.
>
> Then use another distribution. I always came back to Debian in the last
> 16 years. Or use CPAN directly, or perlbrew+cpanm, or carton, or ...

That's great for you. If I were working alone, then perhaps I would do the
same. But I am working in a corporate situation where those choices are
not mine to make.

> IMHO users of Apache make the mistake to solve non-existing problems in
> Apache, thinking CGI/PHP, doing url-rewrite, redirect and so on. And that's
> harmful, where I can understand sri not willing to support or debug insane
> configurations.

I am not asking sri to support or debug insane configurations. I am just
asking that he not remove a perfectly good CGI implementation just because
some people use insane apache configurations.

--
Charlie

[Michael P. Soulier]

On 13/06/14 Charlie Brady said:

> That's great for you. If I were working alone, then perhaps I would do the
> same. But I am working in a corporate situation where those choices are
> not mine to make.

As am I. The assumption that we can simply change our platform always amazes
me.

> I am not asking sri to support or debug insane configurations. I am just
> asking that he not remove a perfectly good CGI implementation just because
> some people use insane apache configurations.

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?

Mike

[sri]

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?

 That's rather ignorant of the actual situation. CGI is not going away, just one of the two ways to deploy in CGI environments we currently support would get moved into a separate distribution. The simple truth is that nobody on the core team has actually used CGI in many years, know how is dwindling and at some point we will be unable to react to problems that may arise, this is an unacceptable situation.

I am well aware that there's a vocal minority that wants to keep Mojo::Server::CGI in core, but at the same time nobody from this minority has even attempted to solve our problems with better documentation. The relevant wiki page for example has seen no major edits in a very long time.

    https://github.com/kraih/mojo/wiki/Apache-deployment

--

sebastian

[Charlie Brady]

On Fri, 13 Jun 2014, sri wrote:

> That's rather ignorant of the actual situation. CGI is not going away,
> just one of the two ways to deploy in CGI environments we currently support
> would get moved into a separate distribution. The simple truth is that
> nobody on the core team has actually used CGI in many years, know how is
> dwindling and at some point we will be unable to react to problems that may
> arise, this is an unacceptable situation.

CGI is a static target. It doesn't change. AFAICT it works just perfectly,
and the test harnesses seem to say the same.

> I am well aware that there's a vocal minority that wants to keep
> Mojo::Server::CGI in core, but at the same time nobody from this minority
> has even attempted to solve our problems with better documentation. The
> relevant wiki page for example has seen no major edits in a very long time.
>
> https://github.com/kraih/mojo/wiki/Apache-deployment

If you or anyone else can identify deficiencies in the documentation I can
try to fix them. That said, I'm not an apache expert. Nor expert on any
other web server.

---
Charlie

[Abhijit Menon-Sen]

At 2014-06-13 16:18:43 -0400, msou...@digitaltorque.ca wrote:
>
> If CGI solves my problem, why should I care if someone ignorant of the
> problems that I must solve has decided to deprecate it?

I don't see why you should care either. But it sounds like you DO care.
You obviously have a working setup. Why does anything need to change?

If you want to use the latest version of Mojolicious, then surely you
can install Mojo::Server::CGI from a separate distribution. Or if you
can't install new modules, then you probably shouldn't try to upgrade
Mojolicious either.

I'm trying to understand why you're objecting. Help?

-- ams

[Charlie Brady]

[BTW, the Subject is ironic - Request URI *is* being parsed correctly in
CGI mode. OP had a broken suexec module in apache which didn't correctly
implement CGI.]

On Sat, 14 Jun 2014, Abhijit Menon-Sen wrote:

> If you want to use the latest version of Mojolicious, then surely you
> can install Mojo::Server::CGI from a separate distribution.

If Mojo::Server::CGI becomes abandonware, then Mojo::Server::CGI may not
actually work with the latest version of Mojolicious. With the current
bundling, the test harnesses ensure that it will work.

> Or if you can't install new modules, then you probably shouldn't try to
> upgrade Mojolicious either.

Continuing to use old versions of Mojolicious is deprecated. And also
undesirable because lots of wonderful new stuff is coming with new
versions of Mojolicious.

> I'm trying to understand why you're objecting. Help?

I can't speak for Michael Soulier, but I've tried to explain myself above.

But I should shut up. I see from IRC logs that some people think it
offensive for me to say "Please do not remove CGI - it is very useful to
me". I'm sorry - no offense is intended. I just want to be able to use
latest Mojolicious - within the constraints imposed upon me.

---
Charlie

[Abhijit Menon-Sen]

At 2014-06-14 10:13:16 -0400, charli...@budge.apana.org.au wrote:
>
> If Mojo::Server::CGI becomes abandonware, then Mojo::Server::CGI may
> not actually work with the latest version of Mojolicious.

I understand your concern.

The problem is really that it already *is* abandonware in a sense. This
is far from the first time we've had this discussion, and it's been a
very long time since anyone on the core team used or cared about CGI.
Nobody else has stepped up to maintain it either.

The test suite might prevent trivial breakage, but nothing more; and all
indications are that nobody will have both the motivation and expertise
to fix any non-trivial problem that comes up in future.

Given that nobody has actually cared enough about the module to say "I
will maintain this" for *years* now, I think it's just unsound to keep
it in core.

> I can't speak for Michael Soulier, but I've tried to explain
> myself above.

Thanks, I appreciate the explanation.

-- ams

[sri]

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.

    https://github.com/kraih/mojo/commit/dbcbb117c459e8b1b68a6646edb2270e3a403803

--

sebastian 

[sri]

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.

And again for the record, there's more work on the horizon in the form of a new RFC.

    http://tools.ietf.org/html/rfc7239

--

sebastian