Re: [Mojolicious] Re: Emulate CGI.pm (CGI::param mostly) in Mojolicious...

[Peter Valdemar Mørch]

Thanks for all your pointers. I'll see what makes most sense when I get my
hands dirty.

For many reasons, it probably is a good idea to refactor our shared
utilities to take query parameters as arguments somehow instead of
extracting them from $c or global context anyway, so thats my plan for now.

Cheers!

Peter

On Wed, Aug 3, 2016 at 2:39 PM, Ben van Staveren 
wrote:

> If it's just to get the parameter values,
>
> $app->add_helper('param' => sub { return shift->req->param(shift) })
>
> might do the trick, as long as you pass the controller object to whatever
> expects to be able to use ->param. For a full CGI-compatible mockup, I
> guess you can just create a plugin that creates all the required helpers to
> make that work.
>
> If I have some free time I might just do that...
>
>
>
> On 08/03/2016 02:33 PM, Lee J wrote:
>
> On Tuesday, August 2, 2016 at 4:58:05 PM UTC+2, Joel Berger wrote:
>>
>> Have you tried using https://metacpan.org/pod/Mojolicious::Plugin::CGI I
>> know that Lee Johnson has used it to help port other CGI applications and
>> has put it to video at least once (yes the title card seems to be wrong):
>> https://www.youtube.com/watch?v=dywft_QfGLI
>>
>
> I think the problem here is the half and half approach. M::P::CGI will
> just exec your cgi scripts and return the output once finished, whereas the
> OG poster here wants to emulate CGI->param *within* the mojo app process
> due to the tight coupling of their library code to CGI.pm. I think
> fundamentally you will have problems with any code running CGI.pm under
> Mojolicious (i.e. not exec'd like the plugin) as CGI will do all sorts of
> evil things with STDIN and such. That said, i know there have been changes
> to the plugin recently as the author of some ancient wiki software was
> porting to Mojo and running into the same problems (i forget which
> software, you'll find various PRs and Issues in the M::P::CGI repo on
> github).
>
> The least evil thing (hoho) you can do here is probably create a
> compatibility package as stated. If they're still shared between legacy and
> new code then you're going to have fun, and you probably just want to throw
> that stuff away anyway.
>
> Lee.
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to mojolicious@googlegroups.com.
> Visit this group at https://groups.google.com/group/mojolicious.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Mojolicious" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/mojolicious/h5Xau2NP__A/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> mojolicious+unsubscr...@googlegroups.com.
> To post to this group, send email to mojolicious@googlegroups.com.
> Visit this group at https://groups.google.com/group/mojolicious.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Re: Mojo::Template *returns* Mojo::Exceptions? Why doesn't it *throw* them?

[Peter Valdemar Mørch]

Ok, thanks! It helps to understand the reasons behind why things are as as
they are.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

[Mojolicious] Mojo::Template *returns* Mojo::Exceptions? Why doesn't it *throw* them?

[Peter Valdemar Mørch]

I'm just getting my feet wet with Mojolicious. One of the things I loved
immediately was Mojo::Template, so I've started using it also outside of
Mojolicious. I was very surprised to see error output on STDOUT without my
$SIG{__DIE__} kicking in.

So now I am curious as to why it returns Mojo::Exception objects on error
instead of die-ing them outright. This choice seems unusual to me, and I'd
like to understand why it is. The perldoc suggests:

my $mt = Mojo::Template->new;
say $mt->render(<<'EOF');

EOF

But really one cannot do that. One really needs to:

my $mt = Mojo::Template->new;
my $output = $mt->render(<<'EOF');

EOF
die $output if ref $output
say $output;

"die $$output if ref $$output;" is found in
Mojolicious/Plugin/EPLRenderer.pm and "return ref $output ? die $output :
$output;" is found in Mojolicious/Plugin/JSONConfig.pm, so I guess
Mojolicious itself also needs to do that.

The perldoc does say that " Mojo::Template will return Mojo::Exception
objects that stringify to error messages with context." but doesn't show
any such "die if exception" code in the actual examples.

Is there a good reason for this somewhat non-standard exception behavior?

Sincerely,

Peter

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

[Mojolicious] Mojolicious inactivity_timeout inconsistencies...

[Peter Valdemar Mørch]

I'm having trouble with all the different ways of setting
inactivity_timeout.

http://mojolicious.org/perldoc/Mojolicious/Guides/FAQ#What-does-Inactivity-timeout-mean
says:

> It defaults to 20 seconds for the user agent and 15 seconds for all
> built-in web servers, and can be changed with the attributes 
> "inactivity_timeout"
> in Mojo::UserAgent
>  and 
> "inactivity_timeout"
> in Mojo::Server::Daemon
>  or
> the MOJO_INACTIVITY_TIMEOUT environment variable. In Mojolicious
>  applications you can also
> use the helper "inactivity_timeout" in Mojolicious::Plugin::DefaultHelpers
> 
> to change it on demand for each connection individually. This timeout
> always applies, so you might have to tweak it for applications that take a
> long time to process a request.
>

Most confusing is that morbo declares an inactivity timeout *sometimes* if
I both set MOJO_INACTIVITY_TIMEOUT=2 and set $c->inactivity_timeout(2) via
the helper and then sleep 3. (see morboruns.txt)

Here is the tiny app I'm testing with:

#!/usr/bin/perl -w
use Mojolicious::Lite;
use 5.20.0;
use experimental 'signatures';

get '/' => sub {
my ($c) = @_;
if (defined $ENV{MY_INACTIVITY}) {
$c->app->log->debug( sprintf "setting \$c->inactivity_timeout(%d)",
  $ENV{MY_INACTIVITY} );
$c->inactivity_timeout($ENV{MY_INACTIVITY});
}
my $sleep = $ENV{SLEEP} // 20;
$c->app->log->debug( sprintf "sleeping %d", $sleep );
sleep $sleep;
$c->render(text => "hello world")
};

app->start;

I get similar inconsistencies when running both:
SLEEP=3 MY_INACTIVITY=2 MOJO_INACTIVITY_TIMEOUT=2 morbo lite.pl
and
SLEEP=3 MY_INACTIVITY=2 MOJO_INACTIVITY_TIMEOUT=2 ./lite.pl daemon -m
production -l http://*:8081


Is there anything I'm doing wrong? I was expecting it to always declare an
inactivity timeout given these settings.

Sincerely,

Peter

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
In two terminals:

* First terminal runs the morbo webserver with a timeout of 2 and a sleep of 3.
  I would expect it declare intactivity every time!

* Second terminal runs wget --tries=5


# First terminal

londo@peter:~/git/capmon/mojo> SLEEP=3 MY_INACTIVITY=2 
MOJO_INACTIVITY_TIMEOUT=2 morbo lite.pl
Server available at http://127.0.0.1:3000
[Mon Jan 16 17:29:51 2017] [debug] GET "/"
[Mon Jan 16 17:29:51 2017] [debug] Routing to a callback
[Mon Jan 16 17:29:51 2017] [debug] setting $c->inactivity_timeout(2)
[Mon Jan 16 17:29:51 2017] [debug] sleeping 3
[Mon Jan 16 17:29:54 2017] [debug] 200 OK (3.001306s, 0.333/s)
[Mon Jan 16 17:29:54 2017] [debug] Inactivity timeout
[Mon Jan 16 17:29:55 2017] [debug] GET "/"
[Mon Jan 16 17:29:55 2017] [debug] Routing to a callback
[Mon Jan 16 17:29:55 2017] [debug] setting $c->inactivity_timeout(2)
[Mon Jan 16 17:29:55 2017] [debug] sleeping 3
[Mon Jan 16 17:29:58 2017] [debug] 200 OK (3.000581s, 0.333/s)
[Mon Jan 16 17:30:03 2017] [debug] GET "/"
[Mon Jan 16 17:30:03 2017] [debug] Routing to a callback
[Mon Jan 16 17:30:03 2017] [debug] setting $c->inactivity_timeout(2)
[Mon Jan 16 17:30:03 2017] [debug] sleeping 3
[Mon Jan 16 17:30:06 2017] [debug] 200 OK (3.000774s, 0.333/s)
[Mon Jan 16 17:30:09 2017] [debug] GET "/"
[Mon Jan 16 17:30:09 2017] [debug] Routing to a callback
[Mon Jan 16 17:30:09 2017] [debug] setting $c->inactivity_timeout(2)
[Mon Jan 16 17:30:09 2017] [debug] sleeping 3
[Mon Jan 16 17:30:12 2017] [debug] 200 OK (3.000549s, 0.333/s)
[Mon Jan 16 17:30:12 2017] [debug] Inactivity timeout
[Mon Jan 16 17:30:13 2017] [debug] GET "/"
[Mon Jan 16 17:30:13 2017] [debug] Routing to a callback
[Mon Jan 16 17:30:13 2017] [debug] setting $c->inactivity_timeout(2)
[Mon Jan 16 17:30:13 2017] [debug] sleeping 3
[Mon Jan 16 17:30:16 2017] [debug] 200 OK (3.000612s, 0.333/s)
[Mon Jan 16 17:30:16 2017] [debug] Inactivity timeout
[Mon Jan 16 17:30:18 2017] [debug] GET "/"
[Mon Jan 16 17:30:18 2017] [debug] Routing to a callback
[Mon Jan 16 17:30:18 2017] [debug] setting $c->inactivity_timeout(2)
[Mon Jan 16 17:30:18 2017] [debug] sleeping 3
[Mon Jan 16 17:30:21 2017] [debug] 200 OK (3.000569s, 0.333/s)
[Mon Jan 16 17:30:21 2017] [debug] Inactivity timeout
[Mon Jan 16 17:30:24 2017] 

[Mojolicious] Re: Mojo::Exception and UTF-8 - again...

[Peter Valdemar Mørch]

I tried to create a short patch. Perhaps it became too short and this is
better:

londo@peter:~/work/mojo> git diff
diff --git a/lib/Mojo/Exception.pm b/lib/Mojo/Exception.pm
index b218ee0..64a6899 100644
--- a/lib/Mojo/Exception.pm
+++ b/lib/Mojo/Exception.pm
@@ -20,7 +20,15 @@ sub inspect {
   # Search for context in files
   for my $file (@files) {
 next unless -r $file->[0] && open my $handle, '<:utf8', $file->[0];
-$self->_context($file->[1], [[<$handle>]]);
+# If there are UTF-8 problems in the source file, don't store any
context
+my @lines = eval {
+  use warnings 'FATAL' => 'utf8';
+  <$handle>;
+};
+if ($@) {
+  next;
+}
+$self->_context($file->[1], [\@lines]);
 return $self;
   }

Now we're not ignoring any potentially unrelated errors from
$self->_context(). I'll shut up for now. :-)

Peter

On Mon, Nov 7, 2016 at 12:35 PM, Peter Valdemar Mørch <pmo...@gmail.com>
wrote:

> Hi,
>
> Today we encountered an exception in a source file that wasn't in UTF-8.
> This caused first a warning and then an error in the morbo output. Apache2
> showed a "502 Proxy Error: Error reading from remote server" from in our
> apache2+morbo setup.
>
> The file on-disk is "binary", because it uses a perl source filter
> <http://perldoc.perl.org/perlfilter.html>. Once given to the parser, it
> *is* UTF-8. The same situation could've been occurred in a 3rd-party
> library if it was encoded in other than [UTF-8, ASCII]. Something similar
> was previously discussed in an old thread, Molo::Exception generate
> warnings while read non-utf8 file
> <https://groups.google.com/forum/#%21searchin/mojolicious/Mojo$3A$3AException$20UTF-8%7Csort:relevance/mojolicious/6c-ZavT2KzQ/vTsJO2E6RQkJ>,
> but no solution was presented there.
>
> This occurs when an exception is encountered in a source file, and
> "Mojo::Exception->throw($@)" is called because of Mojolicious.pm's
>
> local $SIG{__DIE__}
>   = sub { ref $_[0] ? CORE::die $_[0] : Mojo::Exception->throw(shift) };
>
> First, Mojo::Exception's "sub inspect" gave warnings because it guesses
> the source file from parsing $@ and opens the source file with:
>
> next unless -r $file->[0] && open my $handle, '<:utf8', $file->[0];
> $self->_context($file->[1], [[<$handle>]]);
>
> Next we get a "Malformed UTF-8 character" fatal error from Mojolicious
> (when generating output?) because of a s/// in Mojo::Util's xml_escape:
>
> sub xml_escape {
>   return $_[0] if ref $_[0] && ref $_[0] eq 'Mojo::ByteStream';
>   my $str = shift // '';
>   $str =~ s/([&<>"'])/$XML{$1}/ge;
>   return $str;
> }
>
> It seems to be that the reading of non-UTF-8 data causes a warning, but
> the later s/// causes a fatal exception. The behavior I see is replicated
> by this snippet:
>
> #!/usr/bin/perl -w
> use strict;
> open my $handle, '<:utf8', "binary.bin";
> my $str = join('', <$handle>);
> $str =~ s/([&<>"'])/foo/;
>
> I'd like to suggest that reading a source file with UTF-8 problems be
> treated as if the file was unreadable. To that end, I suggest this patch
> (against current master HEAD 49dd3e7):
>
> londo@peter:~/work/mojo> git diff
> diff --git a/lib/Mojo/Exception.pm b/lib/Mojo/Exception.pm
> index b218ee0..08759f5 100644
> --- a/lib/Mojo/Exception.pm
> +++ b/lib/Mojo/Exception.pm
> @@ -20,7 +20,14 @@ sub inspect {
># Search for context in files
>for my $file (@files) {
>  next unless -r $file->[0] && open my $handle, '<:utf8', $file->[0];
> -$self->_context($file->[1], [[<$handle>]]);
> +# If there are UTF-8 problems in the source file, don't store any
> context
> +eval {
> +  use warnings 'FATAL' => 'utf8';
> +  $self->_context($file->[1], [[<$handle>]]);
> +};
> +if ($@) {
> +  next;
> +}
>  return $self;
>}
>
> For ASCII or UTF-8 encoded source files there is no change. For files with
> UTF-8 problems, they are simply not stored as _context(). But they also
> don't cause the entire application to crash. The best of both worlds.
>
> Would that be acceptable? If so, should I just create a github PR? If not,
> can somebody suggest an alternative given that some source files are in
> fact not UTF-8?
>
> Sincerely,
>
> Peter
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

[Mojolicious] Mojo::Exception and UTF-8 - again...

[Peter Valdemar Mørch]

Hi,

Today we encountered an exception in a source file that wasn't in UTF-8.
This caused first a warning and then an error in the morbo output. Apache2
showed a "502 Proxy Error: Error reading from remote server" from in our
apache2+morbo setup.

The file on-disk is "binary", because it uses a perl source filter
. Once given to the parser, it
*is* UTF-8. The same situation could've been occurred in a 3rd-party
library if it was encoded in other than [UTF-8, ASCII]. Something similar
was previously discussed in an old thread, Molo::Exception generate
warnings while read non-utf8 file
,
but no solution was presented there.

This occurs when an exception is encountered in a source file, and
"Mojo::Exception->throw($@)" is called because of Mojolicious.pm's

local $SIG{__DIE__}
  = sub { ref $_[0] ? CORE::die $_[0] : Mojo::Exception->throw(shift) };

First, Mojo::Exception's "sub inspect" gave warnings because it guesses the
source file from parsing $@ and opens the source file with:

next unless -r $file->[0] && open my $handle, '<:utf8', $file->[0];
$self->_context($file->[1], [[<$handle>]]);

Next we get a "Malformed UTF-8 character" fatal error from Mojolicious
(when generating output?) because of a s/// in Mojo::Util's xml_escape:

sub xml_escape {
  return $_[0] if ref $_[0] && ref $_[0] eq 'Mojo::ByteStream';
  my $str = shift // '';
  $str =~ s/([&<>"'])/$XML{$1}/ge;
  return $str;
}

It seems to be that the reading of non-UTF-8 data causes a warning, but the
later s/// causes a fatal exception. The behavior I see is replicated by
this snippet:

#!/usr/bin/perl -w
use strict;
open my $handle, '<:utf8', "binary.bin";
my $str = join('', <$handle>);
$str =~ s/([&<>"'])/foo/;

I'd like to suggest that reading a source file with UTF-8 problems be
treated as if the file was unreadable. To that end, I suggest this patch
(against current master HEAD 49dd3e7):

londo@peter:~/work/mojo> git diff
diff --git a/lib/Mojo/Exception.pm b/lib/Mojo/Exception.pm
index b218ee0..08759f5 100644
--- a/lib/Mojo/Exception.pm
+++ b/lib/Mojo/Exception.pm
@@ -20,7 +20,14 @@ sub inspect {
   # Search for context in files
   for my $file (@files) {
 next unless -r $file->[0] && open my $handle, '<:utf8', $file->[0];
-$self->_context($file->[1], [[<$handle>]]);
+# If there are UTF-8 problems in the source file, don't store any
context
+eval {
+  use warnings 'FATAL' => 'utf8';
+  $self->_context($file->[1], [[<$handle>]]);
+};
+if ($@) {
+  next;
+}
 return $self;
   }

For ASCII or UTF-8 encoded source files there is no change. For files with
UTF-8 problems, they are simply not stored as _context(). But they also
don't cause the entire application to crash. The best of both worlds.

Would that be acceptable? If so, should I just create a github PR? If not,
can somebody suggest an alternative given that some source files are in
fact not UTF-8?

Sincerely,

Peter

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

[Mojolicious] How to stop rendering after user error?

[Peter Valdemar Mørch]

Say in my controller I'm 5 levels deep and discover there is a problem with
the user's input. I call:

$c->render(
template => 'errors/badValues',
message => 'The value of foo cannot be "bar"',
);

And now I want to stop the entire request right there. I guess the
behaviour I'm looking for is that of an exception - return up the call
stack - without having to do something with a return value and then

callSub()
  or return;

at every stack level. So what I've done is create an exception type and

$c->render(
template => 'errors/badValues',
message => 'The value of foo cannot be "bar"',
);
die(StopRenderingException->new());

And then in setup:

$self->hook( around_dispatch => sub {
my ( $next, $c ) = @_;
eval {
$next->();
};
if ($@) {
my $err = $@;
if (blessed($err) && $err->isa('StopRenderingException')) {
return;
} else {
die $err;
}
}
});

It does have a hacky smell to it though. Is there a better best-practice?

Peter

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.