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!@#$]

Post by 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.
$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/keyportion 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.

Post by Skye Shaw!@#$

Post by 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.
$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/keyportion of the path.
Try $r->get('/#host/:port/key')->to('RedisKey#getKeys');
-Skye
--
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
.
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

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

Post by Skye Shaw!@#$
https://metacpan.org/module/Mojolicious::Guides::Routing
-Skye

[Tekki]

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

Post by 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.
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
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
$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

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

Post by Sebastian Riedel
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

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

[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?

Post by sri

Post by Sebastian Riedel
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
--
Sebastian Riedel
http://twitter.com/kraih
http://mojolicio.us

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

Post by sri

Post by Sebastian Riedel
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
--
Sebastian Riedel
http://twitter.com/kraih
http://mojolicio.us

[Sebastian Riedel]

X-Received: by 10.180.86.66 with SMTP id n2mr38787wiz.11.1360092791251;
Tue, 05 Feb 2013 11:33:11 -0800 (PST)
X-BeenThere: ***@googlegroups.com
Received: by 10.180.20.111 with SMTP id m15ls92815wie.38.gmail; Tue, 05 Feb
2013 11:33:10 -0800 (PST)
X-Received: by 10.14.220.131 with SMTP id o3mr27093515eep.3.1360092790529;
Tue, 05 Feb 2013 11:33:10 -0800 (PST)
X-Received: by 10.14.220.131 with SMTP id o3mr27093514eep.3.1360092790518;
Tue, 05 Feb 2013 11:33:10 -0800 (PST)
Received: from mail-ee0-f49.google.com (mail-ee0-f49.google.com [74.125.83.49])
by gmr-mx.google.com with ESMTPS id m6si5167201een.1.2013.02.05.11.33.10
(version=TLSv1 cipherìDHE-RSA-RC4-SHA bits8/128);
Tue, 05 Feb 2013 11:33:10 -0800 (PST)
Received-SPF: pass (google.com: domain of ***@googlemail.com designates 74.125.83.49 as permitted sender) client-ipt.125.83.49;
Received: by mail-ee0-f49.google.com with SMTP id d4so306176eek.22
for <***@googlegroups.com>; Tue, 05 Feb 2013 11:33:10 -0800 (PST)
X-Received: by 10.14.221.9 with SMTP id q9mr88451834eep.3.1360092790362;
Tue, 05 Feb 2013 11:33:10 -0800 (PST)
Received: from odyssey.fritz.box (dyndsl-091-096-120-059.ewe-ip-backbone.de. [91.96.120.59])
by mx.google.com with ESMTPS id q5sm33434378eep.11.2013.02.05.11.33.09
(version=TLSv1 cipherìDHE-RSA-RC4-SHA bits8/128);
Tue, 05 Feb 2013 11:33:10 -0800 (PST)
In-Reply-To: <cc54b64a-a2cc-4bf2-90c4-***@googlegroups.com>
X-Mailer: Apple Mail (2.1499)
X-Original-Sender: ***@googlemail.com
X-Original-Authentication-Results: gmr-mx.google.com; spf=pass
(google.com: domain of ***@googlemail.com designates 74.125.83.49 as
permitted sender) smtp.mail=***@googlemail.com; dkim=pass header.i=@googlemail.com
Precedence: list
Mailing-list: list ***@googlegroups.com; contact mojolicious+***@googlegroups.com
List-ID: <mojolicious.googlegroups.com>
X-Google-Group-Id: 522435015060
List-Post: <http://groups.google.com/group/mojolicious/post?hl=en_US>, <mailto:***@googlegroups.com>
List-Help: <http://groups.google.com/support/?hl=en_US>, <mailto:mojolicious+***@googlegroups.com>
List-Archive: <http://groups.google.com/group/mojolicious?hl=en_US>
Sender: ***@googlegroups.com
List-Subscribe: <http://groups.google.com/group/mojolicious/subscribe?hl=en_US>,
<mailto:mojolicious+***@googlegroups.com>
List-Unsubscribe: <http://groups.google.com/group/mojolicious/subscribe?hl=en_US>,
<mailto:googlegroups-manage+522435015060+***@googlegroups.com>
Archived-At: <http://permalink.gmane.org/gmane.comp.web.mojolicious/847>

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.

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

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

Post by Joel Martinez

Post by Joel Martinez
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.
--
Sebastian Riedel
http://twitter.com/kraih
http://mojolicio.us
--
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
.
Visit this group at http://groups.google.com/group/mojolicious?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Charlie Brady]

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

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]

Post by Joel Martinez

Post by Joel Martinez
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.

Post by Joel Martinez
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.

Post by Joel Martinez
Thanks for your help.

Post by Joel Martinez

Post by Sebastian Riedel
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
--
Sebastian Riedel
http://twitter.com/kraih
http://mojolicio.us

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

Post by Joel Martinez

Post by Joel Martinez

Post by Joel Martinez
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)

Post by Joel Martinez
environment variables from being set. Turns out "suexec" has a

whitelist

Post by Joel Martinez
of environment variables that it allows. I enabled these and everything

is

Post by Joel Martinez
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.

Post by Joel Martinez
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

Post by Joel Martinez
CGI mode. Seeing as how this parse_env function depends on them, it

would

Post by Joel Martinez
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.

Post by Joel Martinez
Thanks for your help.

Post by Joel Martinez

Post by Sebastian Riedel
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

Post by Joel Martinez

Post by Joel Martinez
--
Sebastian Riedel
http://twitter.com/kraih
http://mojolicio.us

[Charlie Brady]

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

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?

Post by Joel Martinez
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
Mojolicious docs.

Post by Joel Martinez

Post by Joel Martinez

Post by Joel Martinez

Post by Joel Martinez
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)

Post by Joel Martinez
environment variables from being set. Turns out "suexec" has a

whitelist

Post by Joel Martinez
of environment variables that it allows. I enabled these and everything

is

Post by Joel Martinez
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.

Post by Joel Martinez
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

Post by Joel Martinez
CGI mode. Seeing as how this parse_env function depends on them, it

would

Post by Joel Martinez
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.

Post by Joel Martinez
Thanks for your help.

Post by Joel Martinez

Post by Sebastian Riedel
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

Post by Joel Martinez

Post by Joel Martinez
--
Sebastian Riedel
http://twitter.com/kraih
http://mojolicio.us

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

Post by Charlie Brady

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

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?

Post by Joel Martinez
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
Mojolicious docs.

Post by Joel Martinez

Post by Joel Martinez

Post by Joel Martinez

Post by Joel Martinez
But it appears Mojolicious needs PATH_INFO, HTTPS or

SERVER_PROTOCOL,

Post by Joel Martinez

Post by Joel Martinez

Post by Joel Martinez

Post by Joel Martinez
and SCRIPT_NAME in it's routine. Do you have any clue why these

might

Post by Joel Martinez

Post by Joel Martinez

Post by Joel Martinez

Post by Joel Martinez
not be set as environment variables correctly?

SOLVED!
It turns out an apache module "suexec" was blocking these (and many

other)

Post by Joel Martinez
environment variables from being set. Turns out "suexec" has a

whitelist

Post by Joel Martinez
of environment variables that it allows. I enabled these and

everything

Post by Joel Martinez

Post by Joel Martinez
is

Post by Joel Martinez
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

Post by Joel Martinez

Post by Joel Martinez
2.2.15 source code, so they are already whitelisted in that version.

Post by Joel Martinez
On a side note... to save others the frustration I went through,

perhaps

Post by Joel Martinez

Post by Joel Martinez

Post by Joel Martinez
you could add some sort of sanity check for these environment

variables

Post by Joel Martinez

Post by Joel Martinez
in

Post by Joel Martinez
CGI mode. Seeing as how this parse_env function depends on them, it

would

Post by Joel Martinez
be nice to see some sort of error if they couldn't be found instead

of

Post by Joel Martinez

Post by Joel Martinez

Post by Joel Martinez
silently failing.

If anyone knows of problems with request parsing/routing in CGI,

please

Post by Joel Martinez

Post by Joel Martinez
report via github issues.

Post by Joel Martinez
Thanks for your help.

Post by Joel Martinez

Post by Sebastian Riedel
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

Post by Joel Martinez

Post by Joel Martinez

Post by Joel Martinez

Post by Joel Martinez
And the actual parser is here.

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

Post by Joel Martinez

Post by Joel Martinez

Post by Joel Martinez

Post by Joel Martinez
--
Sebastian Riedel
http://twitter.com/kraih
http://mojolicio.us

[sri]

Post by Joel Martinez
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

[sri]

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

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

[Charlie Brady]

Post by sri

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

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.

Post by sri
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]

Post by Charlie Brady
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.

Post by Charlie Brady
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?

Post by Charlie Brady
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]

Post by sri
time to push forward.

Is it possible that someone (Charlie? :) could maintain Mojo:: Server:: CGI

[sri]

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]

CGI independently of core?

Post by sri
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

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

Post by sri
There's an app for that.

[Charlie Brady]

Post by sri

Post by Charlie Brady
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...

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

[sri]

Post by Charlie Brady
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

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]

Post by sri

Post by Charlie Brady
perl(Devel::StackTrace) >= 1.23 is needed by

[snip]

Post by sri
I'm having a very hard time following your argument here,

Sorry.

Post by sri
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.

Post by 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

[sri]

Post by sri
From what I can see, deployment using PSGI under apache is signficantly
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]

Post by sri
From what I can see, deployment using PSGI under apache is signficantly

Post by Charlie Brady
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.

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.

[Helmut Wollmersdorfer]

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

Post by Charlie Brady
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?

Post by Charlie Brady
From what I can see, deployment using PSGI under apache is signficantly
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.

[Charlie Brady]

Post by Helmut Wollmersdorfer

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

Post by Helmut Wollmersdorfer
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]

Post by Charlie Brady
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.

Post by Charlie Brady
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]

Post by Michael P. Soulier
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]

Post by sri
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.

Post by sri
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]

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

Post by Abhijit Menon-Sen
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.

Post by Abhijit Menon-Sen
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.

Post by Abhijit Menon-Sen
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]

Post by Charlie Brady
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.

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

Thanks, I appreciate the explanation.

-- ams

[sri]

Post by Charlie Brady
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]

Post by 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