[Mojolicious] Re: Migrated to CENTOS now IO::Socket::SSL failing

[Victor Sergeev]

show what is printed when perl -e 'use IO::Socket::SSL; print 
$INC{"IO/Socket/SSL.pm"};'

вторник, 6 августа 2024 г. в 20:51:53 UTC+5, bryan...@gmail.com: 

> Anyone still alive here?
>
> I migrated everything from a Gentoo server to a CENTOS server. Inclding 
> all local libraries, and for some reason an SSL connection is failing like 
> this:
>   
>
>  }, 'Mojo::Content::Single' ),
>
>  'error' => [
>
>   'IO::Socket::SSL 1.75 required for TLS 
> support'
>
> ],
>
>   
>
> I printed out the %inc in a dump and I get
>
>
> $VAR475 = 'IO/Socket/SSL.pm';
>
> $VAR476 = undef;
>
>
>
> And 
>
> $VAR161 = 'Net/SSLeay.pm';
>
> $VAR162 = undef;
>
>
>
>
>
> Whereas on the working (current, old server)
>
> It’s printing out correctly:
>
>
> $VAR479 = 'IO/Socket/SSL.pm';
>
> $VAR480 = '/var/home/tyeeapps/
> support.thetyee.ca/www/local/lib/perl5/IO/Socket/SSL.pm';
>
>
>
>
> $VAR161 = 'Net/SSLeay.pm';
>
> $VAR162 = '/var/home/tyeeapps/
> support.thetyee.ca/www/local/lib/perl5/x86_64-linux/Net/SSLeay.pm';
>
>
> Any ideas? I've tried reinstalling those modules in the sytem-wide perl, 
> the local perl i'm using with perlbrew, and in the requirements for Carton 
> which this app is using.  All three have a working version and same setup 
> as on the old server!
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/36f14d96-7fcd-4038-8e28-aa22001c591fn%40googlegroups.com.

[Mojolicious] Re: How to post request body with Mojo::UserAgent?

[jay m]

hi,
your code works for me with Mojolicious 8.12 -- i got the expected response 
back from postman-echo.com:

{
  "args": {},
  "data": "",
  "files": {},
  "form": {
"code": "whatever",
"grant_type": "authorization_code",
"xxx": "777"
  },
  "headers": {
"x-forwarded-proto": "https",
"x-forwarded-port": "443",
"host": "postman-echo.com",
"x-amzn-trace-id": "Root=1-653e7226-05cb12432a6ed6e652b6afe2",
"content-length": "51",
"user-agent": "Mojolicious (Perl)",
"authorization": "Basic xx",
"accept-encoding": "gzip",
"content-type": "application/x-www-form-urlencoded"
  },
  "json": {
"code": "whatever",
"grant_type": "authorization_code",
"xxx": "777"
  },
  "url": "https://postman-echo.com/post";
}';

maybe you are using a VERY old version of Mojo::UserAgent that has the 
post_form( $url => $data) method?
jay

On Friday, October 27, 2023 at 5:15:52 PM UTC-4 yuichi@gmail.com wrote:

> I tried below code. But the request body are missing.
>
> my $ua = Mojo::UserAgent->new;
>
> my $url = "https://postman-echo.com/post";;
>
> my $tx = $ua->post(
>
> $url => {
>
> 'Authorization' => 'Basic xx',
>
> 'Content-Type' => 'application/x-www-form-urlencoded'
>
> } => form => {
>
> 'grant_type' => 'authorization_code',
>
> 'code' => $code,
>
> 'xxx' => '777'
>
> }
>
> );
>
>
> Here is a result. I expected value at "form" variables.
>
> '{
>
> "args": {},
>
> "data": "",
>
> "files": {},
>
> "form": {},
>
> "headers": {
>
> "x-forwarded-proto": "https",
>
> "x-forwarded-port": "443",
>
> "host": "postman-echo.com",
>
> "x-amzn-trace-id": "Root=1-653c253d-2bee01d92fa16ed279d4b219",
>
> "content-type": "application/x-www-form-urlencoded",
>
> "authorization": "Basic xx"
>
> },
>
> "json": null,
>
> "url": "https://postman-echo.com/post";
>
> }';
>
>
> Anyone know the reason?
>
>
>
> With regards,
>
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/2b9ec768-7d45-4342-ab85-abf16bf771d0n%40googlegroups.com.

[Mojolicious] Re: GitHub Discussions

[Sebastian Riedel]

Since everybody seems to like GitHub Discussions so far, we are going to 
use that as our default forum for a bit. And https://forum.mojolicious.org 
will redirect to it.

--
sebastian

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/dd49d0ab-c0a8-45d3-9d65-fe35f33d1a2en%40googlegroups.com.

[Mojolicious] Re: Using something like HTTP::Exception for exception handling

[Robert Rothenberg]

As per discussion in https://github.com/mojolicious/mojo/issues/1622, one 
can use something like

 $c->reply->exception('Division by zero!')->rendered(400)

On Friday, November 27, 2020 at 8:54:33 AM UTC Robert Rothenberg wrote:

> I should be more specific. In a "before_render" method, overriding 
> "status" in the arguments hash or in the stash does not actually change the 
> status.  I'd like to be able to change the status from 500 to something 
> else.
>
> On Thursday, November 26, 2020 at 9:12:51 AM UTC Robert Rothenberg wrote:
>
>> That's helpful for customising the error pages. But how do I update the 
>> HTTP status code?
>>
>>
>> On Wednesday, November 25, 2020 at 4:51:48 PM UTC Sebastian Riedel wrote:
>>
>>> Likewise, is a plugin or documented method for overriding the 
 `reply.exception` helper to use a specific template/layout when there are 
 errors?

>>>
>>>
>>> https://docs.mojolicious.org/Mojolicious/Guides/Rendering#Rendering-exception-and-not_found-pages
>>>
>>> --
>>> sebastian 
>>>
>>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/b42e4d23-e49e-47da-bde5-d336e6b67eafn%40googlegroups.com.

[Mojolicious] Re: Using something like HTTP::Exception for exception handling

[Robert Rothenberg]

I should be more specific. In a "before_render" method, overriding "status" 
in the arguments hash or in the stash does not actually change the status.  
I'd like to be able to change the status from 500 to something else.

On Thursday, November 26, 2020 at 9:12:51 AM UTC Robert Rothenberg wrote:

> That's helpful for customising the error pages. But how do I update the 
> HTTP status code?
>
>
> On Wednesday, November 25, 2020 at 4:51:48 PM UTC Sebastian Riedel wrote:
>
>> Likewise, is a plugin or documented method for overriding the 
>>> `reply.exception` helper to use a specific template/layout when there are 
>>> errors?
>>>
>>
>>
>> https://docs.mojolicious.org/Mojolicious/Guides/Rendering#Rendering-exception-and-not_found-pages
>>
>> --
>> sebastian 
>>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/794161c3-c579-4c52-98c0-4bdb496a17e2n%40googlegroups.com.

[Mojolicious] Re: Using something like HTTP::Exception for exception handling

[Robert Rothenberg]

That's helpful for customising the error pages. But how do I update the 
HTTP status code?


On Wednesday, November 25, 2020 at 4:51:48 PM UTC Sebastian Riedel wrote:

> Likewise, is a plugin or documented method for overriding the 
>> `reply.exception` helper to use a specific template/layout when there are 
>> errors?
>>
>
>
> https://docs.mojolicious.org/Mojolicious/Guides/Rendering#Rendering-exception-and-not_found-pages
>
> --
> sebastian 
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/70cddb53-6244-43f2-be91-b97fd3cb30a3n%40googlegroups.com.

[Mojolicious] Re: Using something like HTTP::Exception for exception handling

[Sebastian Riedel]

>
> Likewise, is a plugin or documented method for overriding the 
> `reply.exception` helper to use a specific template/layout when there are 
> errors?
>

https://docs.mojolicious.org/Mojolicious/Guides/Rendering#Rendering-exception-and-not_found-pages

--
sebastian 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/a13a7231-a3c3-4171-8e6c-7f53ea6f07c9n%40googlegroups.com.

Re: [Mojolicious] Re: perlbrew fails, IO::Socket::SSL, perhaps my paths or @INC ?

[Andrew]

Great to hear you're making progress.

I wonder if plugging a video I made for a former employer back in August might 
offer any insights?
I had to disable a lot of environment variables myself, 
and I run through that in the video at 9 minutes 28 seconds...
Here's the link to that part:
https://www.youtube.com/watch?v=eTnvcNkvDfY&t=9m28s


Here's the video in full:

https://www.youtube.com/watch?v=eTnvcNkvDfY

0:00:00 - Introduction
0:00:13 - Herzberg
0:01:15 - Why a Video?

0:02:12 - ImageMagick Script
0:03:50 - NetNerd Shell Access
0:04:05 - Example Perlbrew Installation
0:04:46 - About Perlbrew
0:04:58 - Perlbrew Live Demonstration
0:05:39 - Install Perl 5.30.3
0:09:11 - Switching Perl Versions
0:09:28 - Cpanm and Perlbrew
0:11:16 - Alien::ImageMagick Module
0:12:15 - System Perl & Perlbrew Perl
0:13:30 - Script Shebangs
0:14:26 - Cpanm and System Perl
0:16:06 - Berrybrew for Windows

0:16:13 - Why Git?
0:16:27 - Git Tutorials & Cheat Sheets
0:17:13 - About Git
0:17:35 - Downloading Git

0:17:48 - Create a Git Repository
0:18:25 - Add to a Git Repository
0:19:59 - Change a Git Repository
0:20:55 - Configure Name & Email for Git

0:22:44 - Create a Central Repository
0:24:08 - Access a Central Repository
0:24:49 - Clone a Central Repository
0:25:30 - Add to a Cloned Repository
0:26:34 - Push to a Central Repository

0:27:52 - Clone a Central Repository Again
0:28:29 - Pull from a Central Repository
0:29:03 - Push Rejected because of Conflicts
0:29:39 - Resolve Conflicts with Pull
0:30:26 - Resolve Conflicts with Fetch
0:31:00 - Local and Remote Branches
0:31:23 - Checkout Different Branches
0:32:01 - Manually Resolve Conflicts
0:32:39 - Merge Branches
0:32:53 - Checkout Conflicting File Versions
0:34:22 - Push to a Central Repository Again
0:34:39 - Resolve Conflicts Summary - Pull, or Fetch & Merge

0:35:12 - Video Notes Available

0:35:24 - Git Completion

0:35:41 - Git GUI Apps
0:35:55 - Perl Programmer's Facebook Group

0:36:31 - Git GUI Clients Live Demonstrations

0:37:32 - Installing SourceTree
0:38:31 - Mercurial Source Control Management
0:38:48 - Automatic Line Ending Handling
0:40:18 - Make a SourceTree Icon/Shortcut

0:40:44 - Clone with SourceTree
0:43:31 - Git Version Comparisons
0:44:13 - Add & Commit with SourceTree
0:46:41 - Push with SourceTree
0:47:11 - Fetch & Checkout with Linux VPS
0:47:55 - SourceTree Thoughts Before Exit

0:48:20 - Installing Sublime Merge
0:49:06 - Clone with Sublime Merge
0:51:12 - Add & Commit with Sublime Merge

0:53:47 - Comparison with Windows Explorer
0:54:15 - Push with Sublime Merge
0:54:30 - Pull with SourceTree
0:54:49 - Comparison with Windows Explorer Again
0:55:13 - Git GUI Thoughts Before Exit

0:55:31 - Using PuTTY in Windows

0:56:55 - What's in the Repository?
0:56:58 - Email Folder & Libemail
0:57:27 - ServerDetails Fix
0:57:54 - Automatic Line Ending Handling & Email Template Implications
0:58:39 - Git_Notes Folder
0:58:47 - ImageMagick Folder
0:59:15 - Invoices Folder
0:59:23 - Video_Notes Folder - Perlbrew & Git Notes

0:59:35 - Things to Point Out:
0:59:38 - NetNerd VPS
1:00:00 - Amazon Web Services
1:00:07 - Google Cloud Platform
1:00:15 - Clone Local to the Central Repository

1:00:54 - Weird Things:
1:00:55 - Commit & Bash's Exclamation Mark Error
1:01:38 - Empty Folders and Git

1:02:09 - Perl 7 Announcement!

1:02:31 - Things not covered:
1:02:35 - Branches
1:02:54 - Gitlab & Continuous Integration



  - Original Message - 
  From: Michael W. J. West 
  To: mojolicious@googlegroups.com 
  Sent: Monday, November 23, 2020 2:49 AM
  Subject: Re: [Mojolicious] Re: perlbrew fails, IO::Socket::SSL, perhaps my 
paths or @INC ?


  Thanks Andrew and gugod.  I am making progress, I have things running, but 
not completely understood.   


  I think where I possibly messed up was early on, allowing cpan to run with 
local::lib, then getting App::cpanminus from there. So much for accepting 
defaults. But memory fails me.


  Of course, I tried various things, so now my situation has changed, but the 
good news is it's running right.  I will try to use your hints to better 
understand why.


  eval $(perl -Mlocal::lib=--deactivate)


  in my .profile or commented out has been helpful in getting IO::Socket::SSL 
things running.




   Mike West  

  Phone & WhatsApp: +1-302-559-3642 
  Address: Casa Alquimía
  350 m SUR y 80 m ESTE 
  de la Gasolinera Monteverde
  Monteverde, Puntarenas, Costa Rica  60109
  www.facebook.com/mwjwest mwjwest.wordpress.com






  On Sun, Nov 22, 2020 at 7:09 PM gugod  wrote:



  I want to use perlbrew, but it fails.

  success with system perl:   perl -Mojo -E 'say 
g("mojolicious.org")->dom->at("title")->text'


  fails with perlbrew, error involves IO::Socket::SSL but that seems to be 
up to date.




this statement is not entirely correct. See my repl

Re: [Mojolicious] Re: perlbrew fails, IO::Socket::SSL, perhaps my paths or @INC ?

[Michael W. J. West]

As I said, things are different now, but check this out:

westmj@penguin:~$ *perlbrew off*
perlbrew is turned off.
westmj@penguin:~$ perl -e 'print "@INC\n"'
/home/westmj/perl5/lib/perl5/5.28.1/x86_64-linux-gnu-thread-multi
/home/westmj/perl5/lib/perl5/5.28.1
/home/westmj/perl5/lib/perl5/x86_64-linux-gnu-thread-multi
/home/westmj/perl5/lib/perl5 /etc/perl
/usr/local/lib/x86_64-linux-gnu/perl/5.28.1 /usr/local/share/perl/5.28.1
/usr/lib/x86_64-linux-gnu/perl5/5.28 /usr/share/perl5
/usr/lib/x86_64-linux-gnu/perl/5.28 /usr/share/perl/5.28
/home/westmj/perl5/lib/perl5/5.28.0
/home/westmj/perl5/lib/perl5/5.28.0/x86_64-linux-gnu-thread-multi
/usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base
westmj@penguin:~$ perl -v

This is *perl 5, version 28, subversion 1 (v5.28.1)* built for
x86_64-linux-gnu-thread-multi
(with 65 registered patches, see perl -V for more detail)

Copyright 1987-2018, Larry Wall

Perl may be copied only under the terms of either the Artistic License or
the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl".  If you have access to the
Internet, point your browser at http://www.perl.org/, the Perl Home Page.

westmj@penguin:~$ cpan -D IO::Socket::SSL
Reading '/home/westmj/.cpan/Metadata'
  Database was generated on Mon, 23 Nov 2020 00:41:03 GMT
IO::Socket::SSL
-
CPAN: Module::CoreList loaded ok (v5.20181129_28)
(no description)
S/SU/SULLR/IO-Socket-SSL-2.068.tar.gz
*/home/westmj/perl5/lib/perl5/IO/Socket/SSL.pm*
Installed: 2.068
*CPAN:  2.068  up to date*
Steffen Ullrich (SULLR)
steffen_ullr...@genua.de

westmj@penguin:~$ *perlbrew switch  perl-5.32.0 *
westmj@penguin:~$ perl -v

This is perl 5, version 32, subversion 0 (v5.32.0) built for x86_64-linux

Copyright 1987-2020, Larry Wall

Perl may be copied only under the terms of either the Artistic License or
the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl".  If you have access to the
Internet, point your browser at http://www.perl.org/, the Perl Home Page.

westmj@penguin:~$ *perl -e 'print "@INC\n"'*
/home/westmj/perl5/lib/perl5/x86_64-linux /home/westmj/perl5/lib/perl5
/home/westmj/perl5/perlbrew/perls/perl-5.32.0/lib/site_perl/5.32.0/x86_64-linux
/home/westmj/perl5/perlbrew/perls/perl-5.32.0/lib/site_perl/5.32.0
/home/westmj/perl5/perlbrew/perls/perl-5.32.0/lib/5.32.0/x86_64-linux
/home/westmj/perl5/perlbrew/perls/perl-5.32.0/lib/5.32.0
westmj@penguin:~$ cpan -D IO::Socket::SSL
Reading '/home/westmj/.cpan/Metadata'
  Database was generated on Mon, 23 Nov 2020 00:41:03 GMT
IO::Socket::SSL
-
CPAN: Module::CoreList loaded ok (v5.20200620)
(no description)
S/SU/SULLR/IO-Socket-SSL-2.068.tar.gz
/home/westmj/perl5/lib/perl5/IO/Socket/SSL.pm
Installed: 2.068
CPAN:  2.068  up to date
Steffen Ullrich (SULLR)
steffen_ullr...@genua.de

westmj@penguin:~$ *eval $(perl -Mlocal::lib=--deactivate)*
westmj@penguin:~$ *perl -e 'print "@INC\n"'*
/home/westmj/perl5/perlbrew/perls/perl-5.32.0/lib/site_perl/5.32.0/x86_64-linux
/home/westmj/perl5/perlbrew/perls/perl-5.32.0/lib/site_perl/5.32.0
/home/westmj/perl5/perlbrew/perls/perl-5.32.0/lib/5.32.0/x86_64-linux
/home/westmj/perl5/perlbrew/perls/perl-5.32.0/lib/5.32.0
westmj@penguin:~$ cpan -D IO::Socket::SSL
Loading internal logger. Log::Log4perl recommended for better logging
Reading '/home/westmj/.cpan/Metadata'
  Database was generated on Mon, 23 Nov 2020 00:41:03 GMT
IO::Socket::SSL
-
(no description)
S/SU/SULLR/IO-Socket-SSL-2.068.tar.gz

*/home/westmj/perl5/perlbrew/perls/perl-5.32.0/lib/site_perl/5.32.0/IO/Socket/SSL.pm*
Installed: 2.068
CPAN:  2.068  up to date
Steffen Ullrich (SULLR)
steffen_ullr...@genua.de


 Mike West 

Phone & WhatsApp: +1-302-559-3642
Address: Casa Alquimía
350 m SUR y 80 m ESTE
de la Gasolinera Monteverde
Monteverde, Puntarenas, Costa Rica  60109
www.facebook.com/mwjwest mwjwest.wordpress.com



On Sun, Nov 22, 2020 at 8:49 PM Michael W. J. West 
wrote:

> Thanks Andrew and gugod.  I am making progress, I have things running, but
> not completely understood.
>
> I think where I possibly messed up was early on, allowing cpan to run with
> local::lib, then getting App::cpanminus from there. So much for accepting
> defaults. But memory fails me.
>
> Of course, I tried various things, so now my situation has changed, but
> the good news is it's running right.  I will try to use your hints to
> better unde

Re: [Mojolicious] Re: perlbrew fails, IO::Socket::SSL, perhaps my paths or @INC ?

[Michael W. J. West]

Thanks Andrew and gugod.  I am making progress, I have things running, but
not completely understood.

I think where I possibly messed up was early on, allowing cpan to run with
local::lib, then getting App::cpanminus from there. So much for accepting
defaults. But memory fails me.

Of course, I tried various things, so now my situation has changed, but the
good news is it's running right.  I will try to use your hints to better
understand why.

eval $(perl -Mlocal::lib=--deactivate)

in my .profile or commented out has been helpful in getting IO::Socket::SSL
things running.


 Mike West 

Phone & WhatsApp: +1-302-559-3642
Address: Casa Alquimía
350 m SUR y 80 m ESTE
de la Gasolinera Monteverde
Monteverde, Puntarenas, Costa Rica  60109
www.facebook.com/mwjwest mwjwest.wordpress.com



On Sun, Nov 22, 2020 at 7:09 PM gugod  wrote:

>
> I want to use perlbrew, but it fails.
>> success with system perl:   perl -Mojo -E 'say g("mojolicious.org
>> ")->dom->at("title")->text'
>>
>> fails with perlbrew, error involves IO::Socket::SSL but that seems to be
>> up to date.
>>
>>
> this statement is not entirely correct. See my replies below.
>
>
>> westmj@penguin:~$ perlbrew switch  perl-5.32.0
>> westmj@penguin:~$ perl -Mojo -E 'say g("mojolicious.org
>> ")->dom->at("title")->text'
>> IO::Socket::SSL 2.009+ required for TLS support at
>> /home/westmj/perl5/lib/perl5/ojo.pm line 35.
>> westmj@penguin:~$ /home/westmj/perl5/perlbrew/perls/perl-5.32.0/bin/perl
>> -Mojo -E 'say g("mojolicious.org")->dom->at("title")->text'
>> IO::Socket::SSL 2.009+ required for TLS support at
>> /home/westmj/perl5/lib/perl5/ojo.pm line 35.
>> westmj@penguin:~$ cpanm install IO::Socket::SSL
>> install is up to date. (0.01)
>> IO::Socket::SSL is up to date. (2.068)
>>
>
> based on these commands, I'm guessing you have two installations at
> IO::Socket::SSL.
>
> There is one with verios < 2.009 under
>
> [1] ~/perl5/lib/perl5
>
> ... and the other with version 2.068 is under
>
> [2] ~/perl5/perlbrew/perls/perl-5.32.0/lib/site_perl
>
> Also [1] is most likely part of your PERL5LIB
>
> I made these guesses based on the origin of message being:
>
>  /home/westmj/perl5/lib/perl5/ojo.pm line 35.
>
> ... which is outside perlbrew's realm. The fact this is loaded by
> perl-5.32.0/bin/perl indicates that there some
>  entries in @INC that comes before the  default values of @INC -- you can
> see this partt at the end of `perl -V` (big V)
>
> There are probably some reason why that hapeens.. and the solution to this
> could be different.  if you just want to make Mojo
> work for those commands, you could reinstall IO::Socket::SSL to path [1] by
>
> cpanm -L ~/perl5/ IO::Socket::SSL
>
> ... that said. do so will most likely break something somewhere else.
>
> In your case, cleaning PERL5LIB for that command might make it load the
> IO::Socket::SSL inside path [2]:
>
> perlbrew switch perl-5.32.0
> PERL5LIB= perl -Mojo -E 'say g("mojolicious.org
> ")->dom->at("title")->text'
>
> ... and if not, perhaps there are some other envs that's in the way. All
> in all, you could try to temporarily move ~/perl5 away
> to verify my guess.
>
> I also want to mention that there could be a third place where
> IO::Socket::SSL might live that is inside
> the site lib of your 'system perl'. This dependss on the shebang of your
> 'cpanm' command.  (head -1 `which cpanm`)
>
> If the shebang of cpanm looks like '/usr/bin/env perl', it should be
> compatible with perlbrew, in termss of how
> version-switching works. If the shebang of cpanm looks like
> '/usr/bin/perl', or any path that pins to a particualr installation perl,
> then it cannot work with perlbrew. No mather what perlbrew version you
> switched to, that 'cpanm' command always
> install modules to one single place and is unrelated to perlbrew,,
> basically.
>
> If that seems to be the case, you could try invoking `perlbrew
> install-cpanm`, which should download a copy cpanm and save
> it right next to `perlbrew` executable.  usually here:
>
> ~/perl5/perlbrew/bin/cpanm
>
> the shebang line of this one is slightly modified so it should be
> compatible with how perlbrew do version-switching .
>
> --
> 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/T8HAtzp44tA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> mojolicious+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mojolicious/897ba3a0-6038-4f4d-959b-300fd690aa36n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from

[Mojolicious] Re: perlbrew fails, IO::Socket::SSL, perhaps my paths or @INC ?

[gugod]

> I want to use perlbrew, but it fails.
> success with system perl:   perl -Mojo -E 'say g("mojolicious.org
> ")->dom->at("title")->text'
>
> fails with perlbrew, error involves IO::Socket::SSL but that seems to be 
> up to date.
>
>
this statement is not entirely correct. See my replies below. 
 

> westmj@penguin:~$ perlbrew switch  perl-5.32.0 
> westmj@penguin:~$ perl -Mojo -E 'say g("mojolicious.org
> ")->dom->at("title")->text'
> IO::Socket::SSL 2.009+ required for TLS support at 
> /home/westmj/perl5/lib/perl5/ojo.pm line 35.
> westmj@penguin:~$ /home/westmj/perl5/perlbrew/perls/perl-5.32.0/bin/perl 
> -Mojo -E 'say g("mojolicious.org")->dom->at("title")->text'
> IO::Socket::SSL 2.009+ required for TLS support at 
> /home/westmj/perl5/lib/perl5/ojo.pm line 35.
> westmj@penguin:~$ cpanm install IO::Socket::SSL
> install is up to date. (0.01)
> IO::Socket::SSL is up to date. (2.068)
>
 
based on these commands, I'm guessing you have two installations at 
IO::Socket::SSL. 

There is one with verios < 2.009 under

[1] ~/perl5/lib/perl5

... and the other with version 2.068 is under

[2] ~/perl5/perlbrew/perls/perl-5.32.0/lib/site_perl

Also [1] is most likely part of your PERL5LIB

I made these guesses based on the origin of message being:

 /home/westmj/perl5/lib/perl5/ojo.pm line 35.

... which is outside perlbrew's realm. The fact this is loaded by 
perl-5.32.0/bin/perl indicates that there some
 entries in @INC that comes before the  default values of @INC -- you can 
see this partt at the end of `perl -V` (big V)

There are probably some reason why that hapeens.. and the solution to this 
could be different.  if you just want to make Mojo
work for those commands, you could reinstall IO::Socket::SSL to path [1] by

cpanm -L ~/perl5/ IO::Socket::SSL

... that said. do so will most likely break something somewhere else.

In your case, cleaning PERL5LIB for that command might make it load the 
IO::Socket::SSL inside path [2]:

perlbrew switch perl-5.32.0
PERL5LIB= perl -Mojo -E 'say 
g("mojolicious.org")->dom->at("title")->text'

... and if not, perhaps there are some other envs that's in the way. All in 
all, you could try to temporarily move ~/perl5 away
to verify my guess.

I also want to mention that there could be a third place where 
IO::Socket::SSL might live that is inside
the site lib of your 'system perl'. This dependss on the shebang of your 
'cpanm' command.  (head -1 `which cpanm`)

If the shebang of cpanm looks like '/usr/bin/env perl', it should be 
compatible with perlbrew, in termss of how
version-switching works. If the shebang of cpanm looks like 
'/usr/bin/perl', or any path that pins to a particualr installation perl,
then it cannot work with perlbrew. No mather what perlbrew version you 
switched to, that 'cpanm' command always
install modules to one single place and is unrelated to perlbrew,, 
basically.

If that seems to be the case, you could try invoking `perlbrew 
install-cpanm`, which should download a copy cpanm and save
it right next to `perlbrew` executable.  usually here:

~/perl5/perlbrew/bin/cpanm

the shebang line of this one is slightly modified so it should be 
compatible with how perlbrew do version-switching .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/897ba3a0-6038-4f4d-959b-300fd690aa36n%40googlegroups.com.

[Mojolicious] Re: perlbrew fails, IO::Socket::SSL, perhaps my paths or @INC ?

[Michael W. J. West]

Re: Publishing logs from our IRC channel is against the rules. I'm just 
giving you a warning for now, please don't do that again.

ok, thanks, sorry.  Done in ignorance, won't happen again.  Those being the 
rules of your IRC channel?  And how would I find those rules?  Pretty new 
here, I think you can see by that log.  Ciao. 

On Friday, November 20, 2020 at 2:37:04 PM UTC-6 Sebastian Riedel wrote:

> Publishing logs from our IRC channel is against the rules. I'm just giving 
> you a warning for now, please don't do that again.
>
> --
> sebastian
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/b163f41b-e98d-4c7c-ae11-525a4aee1ab2n%40googlegroups.com.

[Mojolicious] Re: perlbrew fails, IO::Socket::SSL, perhaps my paths or @INC ?

[Sebastian Riedel]

Publishing logs from our IRC channel is against the rules. I'm just giving 
you a warning for now, please don't do that again.

--
sebastian

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/0e982c57-cb98-4283-8e06-64f08a1788d3n%40googlegroups.com.

RE: [Mojolicious] Re: csrf vs testing

[dcook]

I think that most browsers default to SameSite=Lax 
(https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite),
 so you could still do a CSRF attack via a GET request / top-level navigation, 
although that’s only if you’ve coded your application to *do* things in a GET 
request.  

 

If you explicitly use SameSite=Strict, then I suppose that CSRF protections 
could probably matter less. I hadn’t actually thought about that until now. I 
wonder about CSRF attacks that don’t require cookies. It’s been a few months 
since I’ve chatted with security experts, but I think I was advised to ensure 
CSRF protection as well as secure strict cookies. 

 

David Cook

Software Engineer

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

From: mojolicious@googlegroups.com  On Behalf Of 
Sebastian Riedel
Sent: Wednesday, 4 November 2020 4:10 AM
To: Mojolicious 
Subject: [Mojolicious] Re: csrf vs testing

 

These CSRF protection features are mostly legacy features these days for 
backwards compatibility. Now we have SameSite cookies, to which modern browsers 
default.

 

--

sebastian

-- 
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 
<mailto:mojolicious+unsubscr...@googlegroups.com> .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/6cce769b-2b91-4532-aa01-cf5cc58a0d5bn%40googlegroups.com
 
<https://groups.google.com/d/msgid/mojolicious/6cce769b-2b91-4532-aa01-cf5cc58a0d5bn%40googlegroups.com?utm_medium=email&utm_source=footer>
 .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/056801d6b3c4%244d1b8760%24e7529620%24%40prosentient.com.au.

Re: [Mojolicious] Re: csrf vs testing

[Lars Madsen]

ahh, nice, thanks

On Tue, Nov 3, 2020 at 6:09 PM Sebastian Riedel  wrote:

> These CSRF protection features are mostly legacy features these days for
> backwards compatibility. Now we have SameSite cookies, to which modern
> browsers default.
>
> --
> sebastian
>
> --
> 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/Cngym3QNeQs/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> mojolicious+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mojolicious/6cce769b-2b91-4532-aa01-cf5cc58a0d5bn%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CAPfJcws5Qc2tDLaHZrn0iQ5kTt62dUSOzrGNm-yZJ4FqfuobJQ%40mail.gmail.com.

[Mojolicious] Re: csrf vs testing

[Sebastian Riedel]

These CSRF protection features are mostly legacy features these days for 
backwards compatibility. Now we have SameSite cookies, to which modern 
browsers default.

--
sebastian

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/6cce769b-2b91-4532-aa01-cf5cc58a0d5bn%40googlegroups.com.

Re: [Mojolicious] Re: Mojo::Log and UTF-8

[Dan Book]

Any layer on standard handles will cause double encoding when a module like
Mojo::Log encodes to bytes before printing. These layers are global
unfortunately.

-Dan

On Sat, Oct 31, 2020 at 1:54 PM kon...@gmail.com  wrote:

> I found a problem. Some module did:
>
> binmode STDOUT, ':encoding(UTF-8)';
> binmode STDERR, ':encoding(UTF-8)';
>
> and, probably, when STDERR was redirected to STDOUT by Mojo::Log then
> double encoding occur.
>
> Is it worth to check that STDERR and STDOUT have not same layers before
> redirecting?
>
> On Saturday, October 31, 2020 at 6:16:55 PM UTC+2 Sebastian Riedel wrote:
>
>> Ok, data is encoded from UTF-8 into bytes when I log a message,
>>> but when this data is printed to STDERR
>>> How make it decoded from bytes to UTF-8 back?
>>> my terminal supports UTF-8 and I want see nice messages instead of
>>> ХабÐ
>>>
>>
>> UTF-8 *is* bytes. If you are encoding already encoded UTF-8 then you are
>> double encoding.
>>
>> --
>> sebastian
>>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/mojolicious/f276d64e-f215-47d8-af7b-893d9c200ef4n%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CABMkAVX4mqdx6m0HPR8fo5owa4B6rixb9i4bsocimop5755GEQ%40mail.gmail.com.

Re: [Mojolicious] Re: Mojo::Log and UTF-8

[kon...@gmail.com]

I found a problem. Some module did:

binmode STDOUT, ':encoding(UTF-8)';
binmode STDERR, ':encoding(UTF-8)';

and, probably, when STDERR was redirected to STDOUT by Mojo::Log then 
double encoding occur.

Is it worth to check that STDERR and STDOUT have not same layers before 
redirecting?

On Saturday, October 31, 2020 at 6:16:55 PM UTC+2 Sebastian Riedel wrote:

> Ok, data is encoded from UTF-8 into bytes when I log a message, 
>> but when this data is printed to STDERR
>> How make it decoded from bytes to UTF-8 back? 
>> my terminal supports UTF-8 and I want see nice messages instead of ХабÐ
>>
>
> UTF-8 *is* bytes. If you are encoding already encoded UTF-8 then you are 
> double encoding.
>
> --
> sebastian 
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/f276d64e-f215-47d8-af7b-893d9c200ef4n%40googlegroups.com.

Re: [Mojolicious] Re: Mojo::Log and UTF-8

[kon...@gmail.com]

I do nothing, except: 
$app->log->info('тест лога'); 
and get at console:
[Sat Oct  6 15:22:43 2018] [info] �е�� лога 

Should I configure console or add some options to app?

On Saturday, October 31, 2020 at 6:16:55 PM UTC+2 Sebastian Riedel wrote:

> Ok, data is encoded from UTF-8 into bytes when I log a message, 
>> but when this data is printed to STDERR
>> How make it decoded from bytes to UTF-8 back? 
>> my terminal supports UTF-8 and I want see nice messages instead of ХабÐ
>>
>
> UTF-8 *is* bytes. If you are encoding already encoded UTF-8 then you are 
> double encoding.
>
> --
> sebastian 
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/de69d3d9-5823-4b4d-af0f-c20a7c656397n%40googlegroups.com.

Re: [Mojolicious] Re: Mojo::Log and UTF-8

[Sebastian Riedel]

>
> Ok, data is encoded from UTF-8 into bytes when I log a message, 
> but when this data is printed to STDERR
> How make it decoded from bytes to UTF-8 back? 
> my terminal supports UTF-8 and I want see nice messages instead of ХабÐ
>

UTF-8 *is* bytes. If you are encoding already encoded UTF-8 then you are 
double encoding.

--
sebastian 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/9e334bec-97fd-45d7-b385-c28e813a0dd3n%40googlegroups.com.

Re: [Mojolicious] Re: Mojo::Log and UTF-8

[kon...@gmail.com]

Hi.
Ok, data is encoded from UTF-8 into bytes when I log a message, 
but when this data is printed to STDERR
How make it decoded from bytes to UTF-8 back? 
my terminal supports UTF-8 and I want see nice messages instead of ХабÐ

On Wednesday, October 10, 2018 at 7:08:03 PM UTC+3 gri...@gmail.com wrote:

> Mojo::Log already encodes data by default. Anything you send to stderr 
> outside of that should be encoded if necessary.
>
> -Dan
>
> On Wed, Oct 10, 2018 at 11:53 AM Alex Povolotsky  wrote:
>
>> So I should not binmode STDERR, ':utf8' if I'm using Mojo::Log and always 
>> explicitly encode() data?
>>
>> суббота, 6 октября 2018 г., 20:30:12 UTC+3 пользователь Dan Book написал:
>>>
>>> The script is not quite correct. I suspect if you add "use warnings" you 
>>> will see a "Wide character in print" warning, because you are not encoding 
>>> your unicode characters to UTF-8 before printing them. However, on the 
>>> server where you are seeing the double encoding, perhaps you have a 
>>> PERL5OPT environment variable which is setting something like "-CSAD" and 
>>> thus encoding all output handles by default (this should not be globally 
>>> set, because it can mess with modules that don't expect it like this).
>>>
>>> -Dan
>>>
>>> On Sat, Oct 6, 2018 at 10:15 AM Alex Povolotsky  
>>> wrote:
>>>
 Quite interesting. The simple script

 === cut mojolog === 

 #!/usr/bin/env perl 
 use strict; 
 use utf8; 
 use Mojo::Log; 
 my $log = new Mojo::Log; 
 print "Просто принт\n"; 
 $log->info('тест лога'); 
 === cut mojolog === 

 yields fine results on all my servers but one.

 On it, I'm getting

 % perl mojolog 
 Просто принт 
 [Sat Oct  6 15:22:43 2018] [info] �е�� лога 

 The second line is clearly wrong and seems to be badly encoded. Same 
 version of OS, Perl, Mojolicious, same set of environment variables. What 
 else could influence unicode processing?

 суббота, 6 октября 2018 г., 13:35:48 UTC+3 пользователь Alex Povolotsky 
 написал:
>
> Hello
>
> How do I send UTF-8 constants to Mojo::Log? It forcefully encodes 
> everything so UTF-8 goes with double encoding and unreadable. Trying to 
> decode UTF-8 cat 
>
> $log->info(decode('UTF-8', 'тест лога'));
>
> results in
>
> Use of uninitialized value $_[0] in join or string at 
> /usr/local/lib/perl5/site_perl/Mojo/Log.pm line 55.
>
> Looks like something is wrong...
>
 -- 
 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 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...@googlegroups.com.
>> To post to this group, send email to mojol...@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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/7c222687-fa61-4588-97fb-ae3d358b365dn%40googlegroups.com.

RE: [Mojolicious] Re: Ways of rendering a stream

[dcook]

Thanks for your reply, Sebastian. 

 

After I sent my email, I figured that the drain callback must be the only way. 
I just had to brush off the Node.js memories and then it all made enough sense. 
I think it was just confusing because a lot of Mojolicious code can be written 
in a direct style without needing to use continuation passing, and the 
documentation didn’t quite make the drain event requirement clear to me, 
although it all makes more sense in hindsight. 

 

We’re in a slow process of trying to move the 20 year old Koha project away 
from CGI, so originally I was going to do a bare bones PSGI handler, but we’re 
starting to use Mojolicious for new parts of the project, so I thought I’d try 
that instead. While the continuation passing style might not be intuitive, 
it’ll be much nicer to have an asynchronous Mojolicious handler, so that one 
request for a large stream of data doesn’t totally tie up the backend server 
processes. I’m excited to play with Mojolicious more. 

 

And thanks for mentioning the async/await. That looks like a much more 
user-friendly alternative, although I think that we’ll wait until Mojo::Base 
doesn’t flag it as experimental. We also have a long tail of older Perl 
versions to support, unfortunately. 

 

Cheers,

 

David Cook

Software Engineer

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

From: mojolicious@googlegroups.com  On Behalf Of 
Sebastian Riedel
Sent: Friday, 23 October 2020 8:16 PM
To: Mojolicious 
Subject: [Mojolicious] Re: Ways of rendering a stream

 

Typically, with a stream, you'd just write the HTTP headers, and then just 
start writing out your content. I don't understand why it's so challenging with 
Mojolicious. I figured finalizing the response headers would be what I needed, 
but now I have no idea.  

 

I'm not trying to do anything fancy. I'm just trying to read records from a 
database, and write them out to in a stream to the browser. I would think many 
people would have this same use case without doing anything too complicated in 
their web framework.

 

The drain callback is the only way, because we use an event loop and 
non-blocking I/O. The whole thing could theoretically be wrapped in promises 
and then made to look blocking with async/await, but that doesn't really change 
how it works internally.

 

--

sebastian 

-- 
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 
<mailto:mojolicious+unsubscr...@googlegroups.com> .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/c4412264-2954-4f5b-a0ed-45f506d53df4n%40googlegroups.com
 
<https://groups.google.com/d/msgid/mojolicious/c4412264-2954-4f5b-a0ed-45f506d53df4n%40googlegroups.com?utm_medium=email&utm_source=footer>
 .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/06ff01d6ab31%249f0c29d0%24dd247d70%24%40prosentient.com.au.

[Mojolicious] Re: Ways of rendering a stream

[Sebastian Riedel]

>
> Typically, with a stream, you'd just write the HTTP headers, and then just 
> start writing out your content. I don't understand why it's so challenging 
> with Mojolicious. I figured finalizing the response headers would be what I 
> needed, but now I have no idea.  
>
> I'm not trying to do anything fancy. I'm just trying to read records from 
> a database, and write them out to in a stream to the browser. I would think 
> many people would have this same use case without doing anything too 
> complicated in their web framework.
>

The drain callback is the only way, because we use an event loop and 
non-blocking I/O. The whole thing could theoretically be wrapped in 
promises and then made to look blocking with async/await, but that doesn't 
really change how it works internally.

--
sebastian 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/c4412264-2954-4f5b-a0ed-45f506d53df4n%40googlegroups.com.

[Mojolicious] Re: How to "connect" embedded user agent to application being tested?

[Sebastian Riedel]

>
> my $got = $self->ua->get('/welcome')->result->text;
>

Relative URLs are resolved by the user agent to $self->ua->server->app, 
which in this case is probably a Mojo::HelloWorld instance. I strongly 
suggest you use a custom service class with its own Mojo::UserAgent 
instance as an attribute. Then make the full service base URL configurable 
and just set it to $app->foo_service->ua->server->url. Or similar... you 
get the idea.

--
sebastian

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/731af92e-9aea-4625-a714-424244abc942n%40googlegroups.com.

[Mojolicious] Re: With Mojo::IOLoop's delay, timer, and recurring, can I use them in a promises's "then" clause?

[Heiko Jansen]

I actually don't know about any pitfalls when using Mojo::IOLoop's delay 
etc. methods within "then" clauses, but 
from my (limited) experience I'd suggest to avoid mixing traditional IOLoop 
methods and promises if only 
because it makes it even harder to follow the code flow.

To me it looks like you're just trying to kill some time when you using 
the Mojo::IOLoop->delay() construct in the 
snippet in your first post?
If so, I believe something along these lines should work (note: I just 
typed that here and did not test it):

print STDERR qq{Get the job out ...\n};
return Mojo::Promise->timer(3);
} )->then( sub {
print STDERR '3 seconds'; 
return Mojo::Promise->timer(3);
} )->then( sub {
print STDERR '6 seconds'; 
return Mojo::Promise->timer(3);
} )->then( sub {
print STDERR '9 seconds'; 
$t->ua->get_p( $retrieve_enqueued_job_url => $header )
} )->then(
sub ($tx) {
  print STDERR qq{ the job RESULTS : }
 . Dumper( $tx->result->body );
}
);

Declaration of the variables $retrieve_enqueued_job_url  and  $header would 
have to be lifted outside the 
first "then" clause, of course, to be available in the later ones.

I hope that actually works and helps you move forward... ;-)

Gordon Dollarnanda schrieb am Freitag, 25. September 2020 um 09:15:48 UTC+2:

> Apologies-  i hit the "send" button a bit too quickly.
>
> The test script works this way:
>
> 1. enqueue a new job by calling a given endpoint api. A Test::Mojo 
> instance is instantiated. Assume the port is 51611. This is done with a 
> promise using $t->ua->post_p(...) where $t is a Test::Mojo.
> 2. the job will be picked up by a minion service running in the 
> background. The newly enqueued job's id is recorded.
> 3. this is when i need a delay or a recurring loop because the job's 
> argument will have another endpoint url (with the same port currently used 
> by my current Test::Mojo instance) which uses the same port , 51611
> 4. after the job runs, the results of the run is going to be stored in the 
> Minion's job under results (ie $minion->info->{'result'}). 
> 5. a call to another API endpoint to retrieve the results of the job (of 
> the job id in step 2).
> 6. Will test for the job result's values against my expected values (part 
> of Test::More).
>
> Step 3 is the reason for me to want to plant a delay in the 'then()' 
> section of the promise in step 1.
>
>
>
>
> On Friday, 25 September 2020 at 17:08:01 UTC+10 Gordon Dollarnanda wrote:
>
>> hi, guys,
>>
>>  Been reading up 
>> https://docs.mojolicious.org/Mojo/IOLoop/Delay
>> https://docs.mojolicious.org/Mojolicious/Guides/Cookbook
>> and a few threads in the group.
>>
>> Apologies if i had missed this in advance but with Mojo::IOLoop's delay, 
>> timer, and recurring, can I use them in a promises's "then" clause? 
>>  I am trying to do that to no avail.
>>
>>  For example, in the following code snippet,  the test runs very quickly 
>> and doesn't delay at all.
>>
>> *Output:*
>>
>> [16:50:12] anexiole:server git:(bugfix/ET750-asyncTests*) $ prove -v 
>> t/api/fwm/job/up.t 
>> t/api/fwm/job/up.t .. 
>> [info] Setting log level to: debug
>> [info] Manager started: MG EMU: Mojo::Server::Daemon
>> [info] Worker started: MG EMU: [27346]
>> [info] Manager started: MG EMU: Mojo::Server::Daemon
>> [info] Worker started: MG EMU: [27346]
>>  Current port of t is 50016
>>  RESULTS : $VAR1 = '{"jobId":2530,"task":"upgrade"}';
>> job id is 2530
>> Get the job out ...
>> IOLOoP is active
>> After the ioloop...
>> 1..0
>> skipped: (no reason given)
>>
>>
>>
>> *Snippet:*
>>
>>
>>
>>my $data = from_json( $test_scenario->{contents}->{data} );
>>
>> my $enqueue_job = Mojo::URL->new($url);
>>
>> $enqueue_job->query(
>> Mojo::Parameters->new(
>> 'format' => 
>> $test_scenario->{'contents'}->{'format'},
>> 'scope'  => $scope,
>> 'deviceType' => $data->{'deviceType'},
>> 'data'   => 
>> $test_scenario->{'contents'}->{'data'},
>> )
>> );
>> print STDERR qq{ Current port of t is }
>> . $t->ua->server->url->port . qq{\n};
>>
>> $t->ua->post_p( $enqueue_job => $header )->then(
>> sub ($tx) {
>> print STDERR qq{ RESULTS : }
>> . Dumper( $tx->result->body );
>> my $job_id = from_json( $tx->result->body 
>> )->{'jobId'};
>> print STDERR qq{job id is $job_id\n};
>>
>> # Grab the report of the job out
>> my $retrieve_enqueued_job_url
>> = 
>> Mojo::URL->new(qq{/myTestApp/api/job/v12/result/$job_id});
>> $retrieve_enqueued_job_url->query(
>> Mojo::Parameters->new( 'format' => q{json}, ),
>> );
>> print 

[Mojolicious] Re: With Mojo::IOLoop's delay, timer, and recurring, can I use them in a promises's "then" clause?

[Gordon Dollarnanda]

Apologies-  i hit the "send" button a bit too quickly.

The test script works this way:

1. enqueue a new job by calling a given endpoint api. A Test::Mojo instance 
is instantiated. Assume the port is 51611. This is done with a promise 
using $t->ua->post_p(...) where $t is a Test::Mojo.
2. the job will be picked up by a minion service running in the background. 
The newly enqueued job's id is recorded.
3. this is when i need a delay or a recurring loop because the job's 
argument will have another endpoint url (with the same port currently used 
by my current Test::Mojo instance) which uses the same port , 51611
4. after the job runs, the results of the run is going to be stored in the 
Minion's job under results (ie $minion->info->{'result'}). 
5. a call to another API endpoint to retrieve the results of the job (of 
the job id in step 2).
6. Will test for the job result's values against my expected values (part 
of Test::More).

Step 3 is the reason for me to want to plant a delay in the 'then()' 
section of the promise in step 1.




On Friday, 25 September 2020 at 17:08:01 UTC+10 Gordon Dollarnanda wrote:

> hi, guys,
>
>  Been reading up 
> https://docs.mojolicious.org/Mojo/IOLoop/Delay
> https://docs.mojolicious.org/Mojolicious/Guides/Cookbook
> and a few threads in the group.
>
> Apologies if i had missed this in advance but with Mojo::IOLoop's delay, 
> timer, and recurring, can I use them in a promises's "then" clause? 
>  I am trying to do that to no avail.
>
>  For example, in the following code snippet,  the test runs very quickly 
> and doesn't delay at all.
>
> *Output:*
>
> [16:50:12] anexiole:server git:(bugfix/ET750-asyncTests*) $ prove -v 
> t/api/fwm/job/up.t 
> t/api/fwm/job/up.t .. 
> [info] Setting log level to: debug
> [info] Manager started: MG EMU: Mojo::Server::Daemon
> [info] Worker started: MG EMU: [27346]
> [info] Manager started: MG EMU: Mojo::Server::Daemon
> [info] Worker started: MG EMU: [27346]
>  Current port of t is 50016
>  RESULTS : $VAR1 = '{"jobId":2530,"task":"upgrade"}';
> job id is 2530
> Get the job out ...
> IOLOoP is active
> After the ioloop...
> 1..0
> skipped: (no reason given)
>
>
>
> *Snippet:*
>
>
>
>my $data = from_json( $test_scenario->{contents}->{data} );
>
> my $enqueue_job = Mojo::URL->new($url);
>
> $enqueue_job->query(
> Mojo::Parameters->new(
> 'format' => 
> $test_scenario->{'contents'}->{'format'},
> 'scope'  => $scope,
> 'deviceType' => $data->{'deviceType'},
> 'data'   => $test_scenario->{'contents'}->{'data'},
> )
> );
> print STDERR qq{ Current port of t is }
> . $t->ua->server->url->port . qq{\n};
>
> $t->ua->post_p( $enqueue_job => $header )->then(
> sub ($tx) {
> print STDERR qq{ RESULTS : }
> . Dumper( $tx->result->body );
> my $job_id = from_json( $tx->result->body )->{'jobId'};
> print STDERR qq{job id is $job_id\n};
>
> # Grab the report of the job out
> my $retrieve_enqueued_job_url
> = 
> Mojo::URL->new(qq{/myTestApp/api/job/v12/result/$job_id});
> $retrieve_enqueued_job_url->query(
> Mojo::Parameters->new( 'format' => q{json}, ),
> );
> print STDERR qq{Get the job out ...\n};
>
> if ( $t->ua->ioloop->is_running() ) {
> print STDERR qq{IOLOoP is active\n};
> }
> else {
> print STDERR qq{IOLOoP is not active\n};
> }
> *use Mojo::IOLoop::Delay;*
> *my $delay = Mojo::IOLoop->delay(*
> *sub ($delay) {*
> *Mojo::IOLoop->timer( 3 => $delay->begin );*
> *},*
> *sub ($delay) {*
> *print STDERR '3 seconds';*
> *Mojo::IOLoop->timer( 3 => $delay->begin );*
> *},*
> *sub ($delay) {*
> *print STDERR '6 seconds';*
> *Mojo::IOLoop->timer( 3 => $delay->begin );*
> *},*
> *sub ($delay) { print STDERR '9 seconds'; }*
> *);*
> *$delay->wait;*
>
> $t->ua->get_p( $retrieve_enqueued_job_url => $header 
> )->then(
> sub ($tx) {
> print STDERR qq{ the job RESULTS : }
> . Dumper( $tx->result->body );
> }
> );
>
> print STDERR qq{Aft

[Mojolicious] Re: Deprecating or Transferring Mojo::ACME

[joel.a...@gmail.com]

I've finally managed to write up my article that I referred to back in ... 
checks notes ... February ?! Hmmm I wonder what happened back then? 
(Pandemic, buying new house, moving, selling old house, baby moves from 
crawling to running/climbing).

Anyway, finally here it is. I've posted it on dev.to which is a platform 
for technical articles like this. I'm trying it out to see if I like it and 
to see if I get more engagement outside of the Perl 
community. 
https://dev.to/joelaberger/no-magic-letsencrypt-certbot-and-nginx-configuration-recipe-3a97

I'll be officially deprecating Mojo::ACME soon unless someone else wants to 
adopt it. Let me know SOON because whenever I can get around to making a 
release I'll be doing so.

On Wednesday, February 19, 2020 at 9:28:04 PM UTC-6 joel.a...@gmail.com 
wrote:

> As I've posted on blogs.perl.org, I'll be deprecating or transferring 
> maintainership of Mojo::ACME in the near future. If you're interested in 
> taking it please let me know and I'll consider it. 
>
>
> http://blogs.perl.org/users/joel_berger/2020/02/deprecating-or-transferring-mojoacme.html
>
> Cheers,
> Joel
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/e58fb1f8-acae-4902-a0e1-442e034c1a1dn%40googlegroups.com.

Re: [Mojolicious] Re: web cam websocket

[Felipe Gasper]

> On Sep 15, 2020, at 11:20 AM, Sebastian Riedel  wrote:
> 
> An HTTP-level error response--maybe 426--would probably be most sensible. 
> 
> What error would common browsers give in that case? 

They’d give whatever error as with any other HTTP-level failure during a WS 
handshake.

Chrome shows a console error with the response code. A 404, for example, yields:


Error during WebSocket handshake: Unexpected response code: 404


-FG

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/6AB67496-744B-4CC5-9899-DFE0DEDF6965%40felipegasper.com.

Re: [Mojolicious] Re: web cam websocket

[Sebastian Riedel]

>
> An HTTP-level error response--maybe 426--would probably be most sensible. 
>

What error would common browsers give in that case? 

--
Sebastian

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/648435bf-62f7-45f6-a5fc-958d13411c42n%40googlegroups.com.

Re: [Mojolicious] Re: web cam websocket

[Felipe Gasper]

> On Sep 15, 2020, at 9:30 AM, Sebastian Riedel  wrote:
> 
> Given this, should Mojo even send a response? Or if it does, should it at 
> least warn “failed to negotiate subprotocol; sending handshake response 
> anyway”?
> 
>  So you want Mojolicious to cause a TCP level connection error instead of 
> letting the handshake fail properly? That seems like a really bad idea.

An HTTP-level error response--maybe 426--would probably be most sensible.

-FG

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/BA5FBD04-A338-481B-9D9A-CE5834EE732F%40felipegasper.com.

Re: [Mojolicious] Re: web cam websocket

[Sebastian Riedel]

>
> Given this, should Mojo even send a response? Or if it does, should it at 
> least warn “failed to negotiate subprotocol; sending handshake response 
> anyway”?
>

 So you want Mojolicious to cause a TCP level connection error instead of 
letting the handshake fail properly? That seems like a really bad idea.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/82d92a26-0dc5-4493-be0b-9d89c67ae14fn%40googlegroups.com.

Re: [Mojolicious] Re: web cam websocket

[Felipe Gasper]

RFC 6455/1.9 states:

The client can request that the server use a specific subprotocol by
   including the |Sec-WebSocket-Protocol| field in its handshake.  If it
   is specified, the server needs to include the same field and one of
   the selected subprotocol values in its response for the connection to
   be established.

Given this, should Mojo even send a response? Or if it does, should it at least 
warn “failed to negotiate subprotocol; sending handshake response anyway”?

-FG

> On Sep 15, 2020, at 04:21, Mikhail  wrote:
> 
> 
> Chrome browser  absolutely described the error in that it sent a subprotocol 
> header ('null' for that case). So solve
> 
> $ws->tx->with_protocols('binary', 'null');
> 
> Let binary subprotocol is present also.
> понедельник, 14 сентября 2020 г. в 17:29:31 UTC+5, fel...@felipegasper.com: 
>> That seems an odd error from Chrome, if that’s the fix .. was the browser 
>> sending a subprotocol in the handshake?
>> 
>> -F
>> 
 On Sep 14, 2020, at 07:37, Mikhail  wrote:
 
>>> Thanks! Forever ♥ Mojolicious!
>> 
>>> 
>>> 
>>> понедельник, 14 сентября 2020 г. в 13:41:46 UTC+5, Sebastian Riedel: 
 Then you need to negotiate a subprotocol.
 
 --
 sebastian
>>> 
>> 
>>> -- 
>>> 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 view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/mojolicious/68624663-2baf-4bc2-a24e-b8fc135ff15dn%40googlegroups.com.
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/mojolicious/e4166da1-91ce-40e3-810b-2511725ad8b1n%40googlegroups.com.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/A14CC5C0-FA85-45B6-9334-DDF35FAD175B%40felipegasper.com.

Re: [Mojolicious] Re: web cam websocket

[Mikhail]

Chrome browser  absolutely described the error in that it sent a 
subprotocol header ('null' for that case). So solve

$ws->tx->with_protocols('binary', 'null');

Let binary subprotocol is present also.
понедельник, 14 сентября 2020 г. в 17:29:31 UTC+5, fel...@felipegasper.com: 

> That seems an odd error from Chrome, if that’s the fix .. was the browser 
> sending a subprotocol in the handshake?
>
> -F
>
> On Sep 14, 2020, at 07:37, Mikhail  wrote:
>
> Thanks! Forever ♥ Mojolicious!
>
>
>
> понедельник, 14 сентября 2020 г. в 13:41:46 UTC+5, Sebastian Riedel: 
>
>> Then you need to negotiate a subprotocol.
>>
>> --
>> sebastian
>>
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/mojolicious/68624663-2baf-4bc2-a24e-b8fc135ff15dn%40googlegroups.com
>  
> 
> .
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/e4166da1-91ce-40e3-810b-2511725ad8b1n%40googlegroups.com.

Re: [Mojolicious] Re: web cam websocket

[Felipe Gasper]

That seems an odd error from Chrome, if that’s the fix .. was the browser 
sending a subprotocol in the handshake?

-F

> On Sep 14, 2020, at 07:37, Mikhail  wrote:
> 
> Thanks! Forever ♥ Mojolicious!
> 
> понедельник, 14 сентября 2020 г. в 13:41:46 UTC+5, Sebastian Riedel: 
>> Then you need to negotiate a subprotocol.
>> 
>> --
>> sebastian
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/mojolicious/68624663-2baf-4bc2-a24e-b8fc135ff15dn%40googlegroups.com.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/33AC68A2-F3E8-4C8B-BB60-05D6EABA46A1%40felipegasper.com.

[Mojolicious] Re: web cam websocket

[Mikhail]

Thanks! Forever ♥ Mojolicious!

понедельник, 14 сентября 2020 г. в 13:41:46 UTC+5, Sebastian Riedel: 

> Then you need to negotiate a subprotocol.
>
> --
> sebastian
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/68624663-2baf-4bc2-a24e-b8fc135ff15dn%40googlegroups.com.

[Mojolicious] Re: web cam websocket

[Sebastian Riedel]

Then you need to negotiate a subprotocol.

--
sebastian

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/24ee8e0a-9470-425a-93e0-c2827a8d6152n%40googlegroups.com.

[Mojolicious] Re: Puzzled by error message in Mojo::IOLoop::Subprocess::run

[Edward Baudrez]

In case anyone is curious: this was discussed on GitHub 
(https://github.com/mojolicious/mojo/issues/1555) and is not a bug. It 
turns out it's not trivial to trap calls to *exit* in Perl. For my 
particular problem, I was able to find a workaround by overriding *exit* 
(i.e., setting *CORE::GLOBAL::exit* to a subroutine reference) and using 
the module *Scope::Upper*.

Kind regards
Edward
On Tuesday, August 11, 2020 at 5:08:30 PM UTC+2 Sebastian Riedel wrote:

> Please open an issue on GitHub, that looks like a bug in 
> Mojo::IOLoop::Subprocess.
>
> --
> sebastian
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/57ea8007-4c8a-4ac7-b906-cd6b18079b72n%40googlegroups.com.

[Mojolicious] Re: how do i get the pid of a minion::job?

[Gordon Dollarnanda]

>From what i can tell , i revisited the docs and code in Minion and seems to 
me that the relationship between jobs and workers is many to many. 

If this is not right, please let me know.


*HOW START, STOP AND RESTART WORK:*

a) when START is called on a given job, it returns a process id.

See "sub start" in https://docs.mojolicious.org/Minion/Job.txt

b) STOP and RESTART both send signals to the kernel and they rely on the 
process id(s).

 How about the case when some jobs that have been scheduled and currently 
running? They do not have a pid as they were not kick started by calling 
->start().

 What I am thinking of is:  We get the pids of workers currently working on 
the given job we want to kill. .

Note: Use https://metacpan.org/pod/Minion::Backend::Pg#list_workers for 
which we retrieve the workers based on a given job id. From there, we issue 
kill/stop (https://metacpan.org/pod/Minion::Worker#kill) by broadcasting to 
the minion

  Is there a better solution that this?


Issue:  The issue is such that given the relationship between workers and 
jobs being many to many, if we got the workers by job id and kill the pids 
of the workers, killing those workers may also kill other jobs. 

 Can anyone confirm about this issue I raised?

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/54236b78-d312-4013-9f8e-db49e51f1231n%40googlegroups.com.

[Mojolicious] Re: Puzzled by error message in Mojo::IOLoop::Subprocess::run

[Sebastian Riedel]

Please open an issue on GitHub, that looks like a bug in 
Mojo::IOLoop::Subprocess.

--
sebastian

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/b1bff866-dbf3-462e-9c56-c15f16f94f59n%40googlegroups.com.

Re: [Mojolicious] Re: Where to put view logic?

[James Szinger]

On Wed, 29 Jul 2020 10:17:05 -0700 (PDT)
Sebastian Riedel  wrote:

> >
> > The problem is that some of the display logic is fairly
> > complicated: one of my templates has a 30 line <% %> block before
> > anything can be displayed. It strikes me that these 30 lines (and
> > others) are better off in a subroutine or method. But where?
> > MyApp::View? How would I call it from a template? None of the
> > documentation I can find addresses this. I appreciate any pointers
> > or examples. 
> 
>  You want application specific plugins with helpers.
> 
> https://mojolicious.org/perldoc/Mojolicious/Guides/Cookbook#Adding-a-plugin-to-your-application
> https://mojolicious.org/perldoc/Mojolicious/Guides/Rendering#Adding-helpers

Thanks.  The cookbook is especially helpful.  I just didn't grasp its
significance the previous times I read it.  I'll be creating
MyApp::Plugins::ViewHelpers.

Jim

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/20200729133413.67f531c0%40doliolum.thaliacea.lan.

[Mojolicious] Re: Where to put view logic?

[Sebastian Riedel]

>
> The problem is that some of the display logic is fairly complicated: 
> one of my templates has a 30 line <% %> block before anything can be 
> displayed. It strikes me that these 30 lines (and others) are better 
> off in a subroutine or method. But where? MyApp::View? How would I 
> call it from a template? None of the documentation I can find 
> addresses this. I appreciate any pointers or examples. 
>

 You want application specific plugins with helpers.

https://mojolicious.org/perldoc/Mojolicious/Guides/Cookbook#Adding-a-plugin-to-your-application
https://mojolicious.org/perldoc/Mojolicious/Guides/Rendering#Adding-helpers

--
sebastian

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/0ed8a6ec-6654-43b1-9bc4-6563174d0976n%40googlegroups.com.

Re: [Mojolicious] Re: proxy->start_p with custom response body

[Tom Adamo]

Oh, ok. Thanks for the response.

On Thu, Jul 9, 2020 at 2:40 PM Sebastian Riedel  wrote:

> I'm setting up an application that needs to proxy a request.
>>
>> I found this example and it's working well:
>>
>> https://metacpan.org/pod/Mojolicious::Plugin::DefaultHelpers#proxy-%3Estart_p
>>
>> I may need to possibly transform the response body (from HTML to JSON).
>> What would be the best way to do so when using this helper?
>>
>
> You would not use the helper. It is specifically for passing along
> unaltered response content efficiently.
>
> --
> sebastian
>
> --
> 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/q-NXEiq0m6I/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> mojolicious+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mojolicious/22d5202a-2f29-4c41-9d5c-6db8c60fd9b5n%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CAGw3raSEu3WqNZ4qG1RidmmkuhfX9Txycxq6%2BKXv839v-t0hAg%40mail.gmail.com.

[Mojolicious] Re: proxy->start_p with custom response body

[Sebastian Riedel]

>
> I'm setting up an application that needs to proxy a request.
>
> I found this example and it's working well:
>
> https://metacpan.org/pod/Mojolicious::Plugin::DefaultHelpers#proxy-%3Estart_p
>
> I may need to possibly transform the response body (from HTML to JSON). 
> What would be the best way to do so when using this helper?
>

You would not use the helper. It is specifically for passing along 
unaltered response content efficiently.

--
sebastian

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/22d5202a-2f29-4c41-9d5c-6db8c60fd9b5n%40googlegroups.com.

[Mojolicious] Re: multiline %= include

[Sebastian Riedel]

>
> How can I write a include statement in multiple lines?
> Something like this:
>

<%= include 'breadcrumb', path=> [
{ one=> 'first'  },
{ two=> 'second' }
] %>

--
sebastian 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/79a893e7-12a6-40d0-9ce0-3d83aec1ea0co%40googlegroups.com.

[Mojolicious] Re: mojo async/await with controller

[Jeyaraj Durairaj]

Sure sir.

On Wednesday, 27 May 2020 00:21:34 UTC+5:30, Sebastian Riedel wrote:
>
> I am still getting the following.
>>
>> Note: my router is  
>>  $r->post('/login')->to('sessions#on_user_login_p')->name('do_login');
>>
>> [2020-05-26 23:47:28.06952] [-19048] [debug] Routing to controller 
>> "ConvergeAtCommex::Controller::Sessions" and action "on_user_login_p"
>>
>> [2020-05-26 23:47:28.06985] [-19048] [debug] Action not found in controller
>>
>>
> That information seems completely unrelated to the original question in 
> this thread. Please refrain from necroing.
>
> --
> sebastian 
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/d5ed2dda-19ab-47ba-91d2-37cf20ccfa43%40googlegroups.com.

[Mojolicious] Re: mojo async/await with controller

[Sebastian Riedel]

>
> I am still getting the following.
>
> Note: my router is  
>  $r->post('/login')->to('sessions#on_user_login_p')->name('do_login');
>
> [2020-05-26 23:47:28.06952] [-19048] [debug] Routing to controller 
> "ConvergeAtCommex::Controller::Sessions" and action "on_user_login_p"
>
> [2020-05-26 23:47:28.06985] [-19048] [debug] Action not found in controller
>
>
That information seems completely unrelated to the original question in 
this thread. Please refrain from necroing.

--
sebastian 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/e64dd2e6-bd40-4560-9737-45471c30e661%40googlegroups.com.

[Mojolicious] Re: mojo async/await with controller

[Jeyaraj Durairaj]

Hi Tobias,

I am still getting the following.

Note: my router is  
 $r->post('/login')->to('sessions#on_user_login_p')->name('do_login');

[2020-05-26 23:47:28.06952] [-19048] [debug] Routing to controller 
"ConvergeAtCommex::Controller::Sessions" and action "on_user_login_p"

[2020-05-26 23:47:28.06985] [-19048] [debug] Action not found in controller


On Friday, 10 January 2020 19:58:55 UTC+5:30, Tobias Oetiker wrote:
>
> I am answering my own questions here ... so it seems I still have to call 
> render_later in the controller to make this work ..
>
> async sub hello ($self) {
>   # Render template "example/welcome.html.ep" with message
>   *$self**->render_later;*
>   await Mojo::Promise->new(sub ($resolve,$fail) {
>   Mojo::IOLoop->timer(3 => sub { 
>   $resolve->();
>   });
>   });
>   $self->render(text => 'hello');
> }
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/4a4d2d01-7687-4de6-97b5-2794f53ad996%40googlegroups.com.

Re: [Mojolicious] Re: Problem with streaming...

[Dan Book]

Take a look at the proxy helpers added recently, at the least they should
provide inspiration:
https://metacpan.org/pod/Mojolicious::Plugin::DefaultHelpers#proxy-%3Eget_p

-Dan

On Fri, May 15, 2020 at 1:13 AM Joseph Fridy  wrote:

> I have Mojo::UserAgent working to get the file from AWS S3 (including all
> the crypto foo), but I cannot stream its output from a controller attached
> to a Mojolicious::Lite route.  I am running into the same problem as is
> discussed in this thread from 2018:
>
> https://groups.google.com/forum/#!topic/mojolicious/fIGwnDOxl2E
>
> $ua->start($tx) is a blocking call, and as a result my chunks merely
> append to a buffer with nowhere to go until memory fills up.
> Unfortunately, if the way to solve this problem is answered in the
> responses to the thread above, said answer is too subtle for me to suss out.
>
> So, to restate my problem in words:
>
> given a Mojo::UserAgent transaction that can read a very large file, how
> can I stream its output, buffer by buffer, into a browser via a
> Mojolicious::Lite route?
>
> Regards,
>
> Joe Fridy
>
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/mojolicious/ce448a79-c8d4-4098-b0b0-d9564259b632%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CABMkAVWo9iLVHZMF0YaGkCEekqXQ_XN4bLZDRB-4%3DJ6O9ezPgg%40mail.gmail.com.

Re: [Mojolicious] Re: curl works, Mojo::UserAgent doesn't

[Dan Book]

The built in "multipart" generator is pretty similar to this. You need to
create the parts and set the content type yourself still but it does give
you a little flexibility with hashrefs. See the end of the docs for
https://metacpan.org/pod/Mojo::UserAgent::Transactor#tx

-Dan

On Fri, May 15, 2020 at 12:10 AM Stefan Adams  wrote:

>
>
> On Thu, May 14, 2020 at 7:52 AM 'Michael Lackhoff' via Mojolicious <
> mojolicious@googlegroups.com> wrote:
>
>> When I change the sequence of the form parameters in curl, it fails in
>> the same way. So I guess the sequence is important and my question now is:
>>   Is there a way to pass the form parameters with fixed sequence in M::U
>> (the form-hash of course has a random order)? Perhaps as an array?
>>
>
> Good question.  Probably what you want then is to override the built-in "
> form "
> generator.  You can either override (by simply redefining it), or you can 
> create
> your own generator
> 
> and use it.
>
> $ua->transactor->add_generator(fritz => sub {
>   my ($t, $tx, $args) = @_;
>   my ($sid, $pwd, $config) = @$args;
>   my $sorted_parts = [...];
>   $tx->req->content->parts($sorted_parts);
> });
> $ua->post('http://fritz.box/cgi-bin/firmwarecfg' => fritz => [$SID,
> $BAKPWD, undef]);
>
> You could use a hash instead of an array for your fritz args if you wanted
> to, and still pull out the pieces you want to assemble the array as
> desired.  It's very flexible.
>
> But since you're currently using the "form" generator and learning a good
> deal about it and have determined a solution using the form generator, you
> might want to copy the form generator into your own fritz generator and
> then do the differences you need to (as you wished).  Or you might be able
> to simplify it and just do the content->parts as you alluded to.
> TMTOWTDI!  :D
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFRSawHXv92ScBL8nc2U_dWVFWwD5KnLqwjCvtKdX8eaPg%40mail.gmail.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CABMkAVWK%3Dki20sC_fhzQpWskD9qrB0qygZuJWMTp2Zsy1zewdw%40mail.gmail.com.

[Mojolicious] Re: Problem with streaming...

[Joseph Fridy]

I have Mojo::UserAgent working to get the file from AWS S3 (including all 
the crypto foo), but I cannot stream its output from a controller attached 
to a Mojolicious::Lite route.  I am running into the same problem as is 
discussed in this thread from 2018:

https://groups.google.com/forum/#!topic/mojolicious/fIGwnDOxl2E

$ua->start($tx) is a blocking call, and as a result my chunks merely append 
to a buffer with nowhere to go until memory fills up.  Unfortunately, if 
the way to solve this problem is answered in the responses to the thread 
above, said answer is too subtle for me to suss out.

So, to restate my problem in words:

given a Mojo::UserAgent transaction that can read a very large file, how 
can I stream its output, buffer by buffer, into a browser via a 
Mojolicious::Lite route?

Regards,

Joe Fridy


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/ce448a79-c8d4-4098-b0b0-d9564259b632%40googlegroups.com.

Re: [Mojolicious] Re: curl works, Mojo::UserAgent doesn't

[Stefan Adams]

On Thu, May 14, 2020 at 7:52 AM 'Michael Lackhoff' via Mojolicious <
mojolicious@googlegroups.com> wrote:

> When I change the sequence of the form parameters in curl, it fails in the
> same way. So I guess the sequence is important and my question now is:
>   Is there a way to pass the form parameters with fixed sequence in M::U
> (the form-hash of course has a random order)? Perhaps as an array?
>

Good question.  Probably what you want then is to override the built-in "
form "
generator.  You can either override (by simply redefining it), or you
can create
your own generator

and use it.

$ua->transactor->add_generator(fritz => sub {
  my ($t, $tx, $args) = @_;
  my ($sid, $pwd, $config) = @$args;
  my $sorted_parts = [...];
  $tx->req->content->parts($sorted_parts);
});
$ua->post('http://fritz.box/cgi-bin/firmwarecfg' => fritz => [$SID,
$BAKPWD, undef]);

You could use a hash instead of an array for your fritz args if you wanted
to, and still pull out the pieces you want to assemble the array as
desired.  It's very flexible.

But since you're currently using the "form" generator and learning a good
deal about it and have determined a solution using the form generator, you
might want to copy the form generator into your own fritz generator and
then do the differences you need to (as you wished).  Or you might be able
to simplify it and just do the content->parts as you alluded to.
TMTOWTDI!  :D

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFRSawHXv92ScBL8nc2U_dWVFWwD5KnLqwjCvtKdX8eaPg%40mail.gmail.com.

[Mojolicious] Re: curl works, Mojo::UserAgent doesn't

['Michael Lackhoff' via Mojolicious]

Ok, got it :-

1. get the content-parts:
$tx->req->content->parts;
2. by checking each parts body_contains method identify them
3. build a new parts array with correct sequence by copying the objects 
into a new array.
4. change the whole thing:
$tx->req->content->parts($sorted_parts);

This request eventually saves the backup as I want it :-)

You might ask if it is really worth it but I learned quite a lot debugging 
this problem
And there is a wish: please allow adding form parameters as an array. After 
all they end up in an array eventually (parts is an array_ref). It is a 
pitty that the sequence is just determined by a sort on the names i.e. 
arbitrarily.
In most cases it doesn't matter but if it does this saves a lot of fuzz.

-Michael

Am Mittwoch, 13. Mai 2020 23:56:26 UTC+2 schrieb Michael Lackhoff:
>
> I had quite a bit of success recently using Mojo::UserAgent so I tried to 
> replace a curl command to do a backup of my Fritz.box router with M::U.
>
> Here is the curl command:
> curl -s -k -o $OUT --form sid=$SID --form ImportExportPassword=$BAKPWD \
> --form ConfigExport= http://fritz.box/cgi-bin/firmwarecfg
>
> It should be equivalent to this M::U request:
>
> my $tx = $ua->build_tx(
> POST => 'http://fritz.box/cgi-bin/firmwarecfg' =>
> {
> 'Accept'   => '*/*',
> 'Content-Type' => 'multipart/form-data',
> } => form => {
> sid  => $SID,
> ImportExportPassword => $BAKPWD,
> ConfigExport => '',
> }
> );
>
> # for debugging:
> print $tx->req->to_string;
>
> $tx = $ua->start($tx);
> $tx->res->save_to($OUT);
>
> As far as I can tell both the headers and the POST body is very much the 
> same (except the boundary value to separate the form fields) but to my 
> surprise the curl command works ($OUT is the backup file) but with the M::U 
> version $OUT consists of some HTML output indicating an error.
>
> If I could see a difference I could try to better adjust my script but as 
> I said, they look very much the same (I compared it with the -v and 
> --trace-ascii output of curl), so I run out of ideas what could trigger the 
> differnt response of my Fritz.box.
> Any ideas? At the moment I just solve it by using the curl command with 
> "system" but I would prefer a Perl-only solution and what is even more 
> important to me: I want to understand what is going on here.
>
> -Michael
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/99009410-9157-443e-ad36-879418436310%40googlegroups.com.

Re: [Mojolicious] Re: curl works, Mojo::UserAgent doesn't

['Michael Lackhoff' via Mojolicious]

I think I am getting closer.
When I change the sequence of the form parameters in curl, it fails in the 
same way. So I guess the sequence is important and my question now is:
  Is there a way to pass the form parameters with fixed sequence in M::U 
(the form-hash of course has a random order)? Perhaps as an array?

-Michael

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/64deb6a2-dfad-4d64-869f-87c2a09f4079%40googlegroups.com.

Re: [Mojolicious] Re: curl works, Mojo::UserAgent doesn't

['Michael Lackhoff' via Mojolicious]

Am Donnerstag, 14. Mai 2020 14:23:41 UTC+2 schrieb Felipe Gasper:
 

> The idea is more that, if you know curl is doing what you want, then just 
> use curl rather than M::UA, and keep on trucking with all else that Mojo 
> has to offer. 
>

Of course you are right. Your suggestion would be the most sensible way of 
dealing with it.
I just happen to have a little daemon sitting on my shoulder, saying "you 
have to understand what is going on here!" "Don't give up until your tool 
that is made for this kind of task does what you want"
It isn't easy for me to silence this little daemon ;-) and so I still hope 
there are others more knowledgable than me in this group who have the same 
kind of ambition...

-Michael

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/7cba2d2e-78bc-43c4-8d36-864ef8991179%40googlegroups.com.

Re: [Mojolicious] Re: curl works, Mojo::UserAgent doesn't

[Felipe Gasper]

Net::Curl::Promiser wouldn’t keep you from using any of Mojo’s other 
capabilities. It’s just an alternative way of doing asynchronous HTTP requests; 
i.e., it’s a substitute specifically for Mojo::UserAgent. It can also 
facilitate use of FTP, IMAP, etc. by virtue of libcurl’s support for those 
protocols.

I wouldn’t necessarily describe the interface itself as “easy” since it’s 
basically a direct port of libcurl’s own interface. The idea is more that, if 
you know curl is doing what you want, then just use curl rather than M::UA, and 
keep on trucking with all else that Mojo has to offer.

-FG

> On May 14, 2020, at 8:06 AM, 'Michael Lackhoff' via Mojolicious 
>  wrote:
> 
> Well, the easiest solution would be to just use curl.
> But M::U is a powerful tool I find myself using it more and more and I would 
> like to better understand such tools.
> It looks great but if it has some severe shortcomings I want to know before 
> doing lots of mission critical stuff with it.
> 
> But thanks for your suggestion. It is always good to know further options.
> -Michael
> 
> 
> Am Donnerstag, 14. Mai 2020 13:47:41 UTC+2 schrieb Felipe Gasper:
> FWIW, you can use libcurl with Mojo via Net::Curl::Promiser::Mojo. That may 
> be your easiest solution?
> 
> -FG
> 
>> On May 14, 2020, at 07:38, 'Michael Lackhoff' via Mojolicious 
>>  wrote:
>> 
>> 
>> Am 14.05.2020 um 05:08 schrieb Stefan Adams:
>> 
>>> > 
>>> I'm certain you'll be able to accomplish this with M::UA. Can you share
>>> 
>> Just to reduce complexity I changed everything to plain HTTP, so no SSL,
>> keys or certificates.
>> 
>> 
>>> > 
>>> what the HTML error produced is?
>>> 
>> It is not really a normal error page, just a page from the UI. The most
>> relevant lines are these:
>> Invalid variable name.
>> Wiederholen Sie das Update oder starten Sie die FRITZ!Box neu.
>> [German for: repeat the update(sic! I wanted to backup the box, not
>> update) or restart your FRITZ!Box]
>> 
>> 
>>> > 
>>> Can you share the output that you are comparing that you are noticing is so
>>> 
>>> > 
>>> similar between curl and M::UA? You're using -v for curl. Also set the
>>> 
>>> > 
>>> MOJO_CLIENT_DEBUG env variable to 1.
>>> 
>> Here is what curl gives (with --trace-ascii):
>> => Send header, 200 bytes (0xc8)
>> : POST /cgi-bin/firmwarecfg HTTP/1.1
>> 0024: Host: fritz.box
>> 0035: User-Agent: curl/7.58.0
>> 004e: Accept: */*
>> 005b: Content-Length: 370
>> 0070: Content-Type: multipart/form-data; boundary=
>> 00b0: 565a580ebeb0c567
>> 00c6:
>> => Send data, 370 bytes (0x172)
>> : --
>> 565a580ebeb0c567
>> 002c: Content-Disposition: form-data; name="sid"
>> 0058:
>> 005a: 4e240384c30c909d
>> 006c: --
>> 565a580ebeb0c567
>> 0098: Content-Disposition: form-data; name="ImportExportPassword"
>> 00d5:
>> 00d7: backup
>> 00df: --
>> 565a580ebeb0c567
>> 010b: Content-Disposition: form-data; name="ConfigExport"
>> 0140:
>> 0142:
>> 0144: --
>> 565a580ebeb0c567--
>> <= Recv header, 17 bytes (0x11)
>> : HTTP/1.1 200 OK
>> 
>> 
>> 
>>> > 
>>> See how it works comparing curl to:
>>> 
>>> > 
>>> > 
>>>$ env MOJO_CLIENT_DEBUG=1 mojo get -v -M POST -f sid=$SID -f
>>> 
>>> > 
>>> ImportExportPassword=$BAKPWD -f ConfigExport= http
>>> 
>>> > ://fritz.box/cgi-bin/firmwarecfg 
>> The empty ConfigExport parameter gets lost with this command and the
>> Content-Type is different:
>> 
>> -- Blocking request (
>> http://fritz.box/cgi-bin/firmwarecfg
>> )
>> -- Connect 7c84d2d7396d9d2ff9571982f73240
>> cb (http://fritz.box:80
>> )
>> -- Client >>> Server (
>> http://fritz.box/cgi-bin/firmwarecfg
>> )
>> POST /cgi-bin/firmwarecfg HTTP/1.1\x0d
>> Content-Length: 48\x0d
>> User-Agent: Mojolicious (Perl)\x0d
>> Accept-Encoding: gzip\x0d
>> Content-Type: application/x-www-form-
>> urlencoded\x0d
>> Host: fritz.box\x0d
>> \x0d
>> ImportExportPassword=backup&
>> sid=4e240384c30c909d
>> -- Client >>> Server (
>> http://fritz.box/cgi-bin/firmwarecfg
>> )
>> 
>> -- Client <<< Server (
>> http://fritz.box/cgi-bin/firmwarecfg
>> )
>> HTTP/1.1 200 OK\x0d
>> 
>> 
>> 
>> With DEBUG on and my code (s. my original message and below) I get this:
>> 
>> -- Client >>> Server (
>> http://fritz.box/cgi-bin/firmwarecfg
>> )
>> POST /cgi-bin/firmwarecfg HTTP/1.1\x0d
>> Accept-Encoding: gzip, deflate\x0d
>> Content-Type: multipart/form-data; boundary=tyUPX\x0d
>> Accept: */*\x0d
>> Host: fritz.box\x0d
>> Content-Length: 230\x0d
>> User-Agent: Mojolicious (Perl)\x0d
>> \x0d
>> --tyUPX\x0d
>> 
>> -- Client >>> Server (
>> http://fritz.box/cgi-bin/firmwarecfg
>> )
>> Content-Disposition: form-data; name="ConfigExport"\x0d
>> \x0d
>> 
>> -- Client >>> Server (
>> http://fritz.box/cgi-bin/firmwarecfg
>> )
>> \x0d
>> --tyUPX\x0d
>> 
>> -- Client >>> Server (
>> http://fritz.box/cgi-bin/firmwarecfg
>> )
>> Content-Disposition: form-data; name="ImportExpo

Re: [Mojolicious] Re: curl works, Mojo::UserAgent doesn't

['Tobias Oetiker' via Mojolicious]

Michael, 

I find the descriptions in [ 
https://mojolicious.org/perldoc/Mojo/UserAgent/Transactor#tx | 
https://mojolicious.org/perldoc/Mojo/UserAgent/Transactor#tx ] pretty helpful 

cheers 
tobi 

- On May 14, 2020, at 2:06 PM, 'Michael Lackhoff' via Mojolicious 
 wrote: 

> Well, the easiest solution would be to just use curl.
> But M::U is a powerful tool I find myself using it more and more and I would
> like to better understand such tools.
> It looks great but if it has some severe shortcomings I want to know before
> doing lots of mission critical stuff with it.

> But thanks for your suggestion. It is always good to know further options.
> -Michael

> Am Donnerstag, 14. Mai 2020 13:47:41 UTC+2 schrieb Felipe Gasper:
>> FWIW, you can use libcurl with Mojo via Net::Curl::Promiser::Mojo. That may 
>> be
>> your easiest solution?

>> -FG

>>> On May 14, 2020, at 07:38, 'Michael Lackhoff' via Mojolicious <
>>> mojol...@googlegroups.com > wrote:

>>> Am 14.05.2020 um 05:08 schrieb Stefan Adams:

 > I'm certain you'll be able to accomplish this with M::UA. Can you share

>>> Just to reduce complexity I changed everything to plain HTTP, so no SSL,
>>> keys or certificates.

 > what the HTML error produced is?

>>> It is not really a normal error page, just a page from the UI. The most
>>> relevant lines are these:
>>> Invalid variable name.
>>> Wiederholen Sie das Update oder starten Sie die FRITZ!Box neu.
>>> [German for: repeat the update(sic! I wanted to backup the box, not
>>> update) or restart your FRITZ!Box]

 > Can you share the output that you are comparing that you are noticing is 
 > so
 > similar between curl and M::UA? You're using -v for curl. Also set the
 > MOJO_CLIENT_DEBUG env variable to 1.

>>> Here is what curl gives (with --trace-ascii):
>>> => Send header, 200 bytes (0xc8)
>>> : POST /cgi-bin/firmwarecfg HTTP/1.1
>>> 0024: Host: fritz.box
>>> 0035: User-Agent: curl/7.58.0
>>> 004e: Accept: */*
>>> 005b: Content-Length: 370
>>> 0070: Content-Type: multipart/form-data; boundary=
>>> 00b0: 565a580ebeb0c567
>>> 00c6:
>>> => Send data, 370 bytes (0x172)
>>> : --565a580ebeb0c567
>>> 002c: Content-Disposition: form-data; name="sid"
>>> 0058:
>>> 005a: 4e240384c30c909d
>>> 006c: --565a580ebeb0c567
>>> 0098: Content-Disposition: form-data; name="ImportExportPassword"
>>> 00d5:
>>> 00d7: backup
>>> 00df: --565a580ebeb0c567
>>> 010b: Content-Disposition: form-data; name="ConfigExport"
>>> 0140:
>>> 0142:
>>> 0144: --565a580ebeb0c567--
>>> <= Recv header, 17 bytes (0x11)
>>> : HTTP/1.1 200 OK

 > See how it works comparing curl to:

 >$ env MOJO_CLIENT_DEBUG=1 mojo get -v -M POST -f sid=$SID -f
 > ImportExportPassword=$BAKPWD -f ConfigExport= http
> ://fritz.box/cgi-bin/firmwarecfg [ http://fritz.box/cgi-bin/firmwarecfg |
 >  ]

>>> The empty ConfigExport parameter gets lost with this command and the
>>> Content-Type is different:

>>> -- Blocking request ( [ http://fritz.box/cgi-bin/firmwarecfg |
>>> http://fritz.box/cgi-bin/firmwarecfg ] )
>>> -- Connect 7c84d2d7396d9d2ff9571982f73240cb ( [ http://fritz.box/ |
>>> http://fritz.box:80 ] )
>>> -- Client >>> Server ( [ http://fritz.box/cgi-bin/firmwarecfg |
>>> http://fritz.box/cgi-bin/firmwarecfg ] )
>>> POST /cgi-bin/firmwarecfg HTTP/1.1\x0d
>>> Content-Length: 48\x0d
>>> User-Agent: Mojolicious (Perl)\x0d
>>> Accept-Encoding: gzip\x0d
>>> Content-Type: application/x-www-form-urlencoded\x0d
>>> Host: fritz.box\x0d
>>> \x0d
>>> ImportExportPassword=backup&sid=4e240384c30c909d
>>> -- Client >>> Server ( [ http://fritz.box/cgi-bin/firmwarecfg |
>>> http://fritz.box/cgi-bin/firmwarecfg ] )

>>> -- Client <<< Server ( [ http://fritz.box/cgi-bin/firmwarecfg |
>>> http://fritz.box/cgi-bin/firmwarecfg ] )
>>> HTTP/1.1 200 OK\x0d

>>> With DEBUG on and my code (s. my original message and below) I get this:

>>> -- Client >>> Server ( [ http://fritz.box/cgi-bin/firmwarecfg |
>>> http://fritz.box/cgi-bin/firmwarecfg ] )
>>> POST /cgi-bin/firmwarecfg HTTP/1.1\x0d
>>> Accept-Encoding: gzip, deflate\x0d
>>> Content-Type: multipart/form-data; boundary=tyUPX\x0d
>>> Accept: */*\x0d
>>> Host: fritz.box\x0d
>>> Content-Length: 230\x0d
>>> User-Agent: Mojolicious (Perl)\x0d
>>> \x0d
>>> --tyUPX\x0d

>>> -- Client >>> Server ( [ http://fritz.box/cgi-bin/firmwarecfg |
>>> http://fritz.box/cgi-bin/firmwarecfg ] )
>>> Content-Disposition: form-data; name="ConfigExport"\x0d
>>> \x0d

>>> -- Client >>> Server ( [ http://fritz.box/cgi-bin/firmwarecfg |
>>> http://fritz.box/cgi-bin/firmwarecfg ] )
>>> \x0d
>>> --tyUPX\x0d

>>> -- Client >>> Server ( [ http://fritz.box/cgi-bin/firmwarecfg |
>>> http://fritz.box/cgi-bin/firmwarecfg ] )
>>> Content-Disposition: form-data; name="ImportExportPassword"\x0d
>>> \x0d

>>> -- Client >>> Server ( [ http://fritz

Re: [Mojolicious] Re: curl works, Mojo::UserAgent doesn't

['Michael Lackhoff' via Mojolicious]

Well, the easiest solution would be to just use curl.
But M::U is a powerful tool I find myself using it more and more and I 
would like to better understand such tools.
It looks great but if it has some severe shortcomings I want to know before 
doing lots of mission critical stuff with it.

But thanks for your suggestion. It is always good to know further options.
-Michael


Am Donnerstag, 14. Mai 2020 13:47:41 UTC+2 schrieb Felipe Gasper:
>
> FWIW, you can use libcurl with Mojo via Net::Curl::Promiser::Mojo. That 
> may be your easiest solution?
>
> -FG
>
> On May 14, 2020, at 07:38, 'Michael Lackhoff' via Mojolicious <
> mojol...@googlegroups.com > wrote:
>
> 
>
> Am 14.05.2020 um 05:08 schrieb Stefan Adams:
>
> > I'm certain you'll be able to accomplish this with M::UA. Can you share
>
> Just to reduce complexity I changed everything to plain HTTP, so no SSL,
> keys or certificates.
>
>
> > what the HTML error produced is?
>
> It is not really a normal error page, just a page from the UI. The most
> relevant lines are these:
> Invalid variable name.
> Wiederholen Sie das Update oder starten Sie die FRITZ!Box neu.
> [German for: repeat the update(sic! I wanted to backup the box, not
> update) or restart your FRITZ!Box]
>
>
> > Can you share the output that you are comparing that you are noticing is 
> > so> similar between curl and M::UA? You're using -v for curl. Also set the> 
> > MOJO_CLIENT_DEBUG env variable to 1.
>
> Here is what curl gives (with --trace-ascii):
> => Send header, 200 bytes (0xc8)
> : POST /cgi-bin/firmwarecfg HTTP/1.1
> 0024: Host: fritz.box
> 0035: User-Agent: curl/7.58.0
> 004e: Accept: */*
> 005b: Content-Length: 370
> 0070: Content-Type: multipart/form-data; boundary=
> 00b0: 565a580ebeb0c567
> 00c6:
> => Send data, 370 bytes (0x172)
> : --565a580ebeb0c567
> 002c: Content-Disposition: form-data; name="sid"
> 0058:
> 005a: 4e240384c30c909d
> 006c: --565a580ebeb0c567
> 0098: Content-Disposition: form-data; name="ImportExportPassword"
> 00d5:
> 00d7: backup
> 00df: --565a580ebeb0c567
> 010b: Content-Disposition: form-data; name="ConfigExport"
> 0140:
> 0142:
> 0144: --565a580ebeb0c567--
> <= Recv header, 17 bytes (0x11)
> : HTTP/1.1 200 OK
>
>
>
> > See how it works comparing curl to:> >$ env MOJO_CLIENT_DEBUG=1 mojo 
> > get -v -M POST -f sid=$SID -f> ImportExportPassword=$BAKPWD -f 
> > ConfigExport= http> ://fritz.box/cgi-bin/firmwarecfg 
> >  
> > 
>
> The empty ConfigExport parameter gets lost with this command and the
> Content-Type is different:
>
> -- Blocking request (http://fritz.box/cgi-bin/firmwarecfg)
> -- Connect 7c84d2d7396d9d2ff9571982f73240cb (http://fritz.box:80)
> -- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
> POST /cgi-bin/firmwarecfg HTTP/1.1\x0d
> Content-Length: 48\x0d
> User-Agent: Mojolicious (Perl)\x0d
> Accept-Encoding: gzip\x0d
> Content-Type: application/x-www-form-urlencoded\x0d
> Host: fritz.box\x0d
> \x0d
> ImportExportPassword=backup&sid=4e240384c30c909d
> -- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
>
> -- Client <<< Server (http://fritz.box/cgi-bin/firmwarecfg)
> HTTP/1.1 200 OK\x0d
>
>
>
> With DEBUG on and my code (s. my original message and below) I get this:
>
> -- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
> POST /cgi-bin/firmwarecfg HTTP/1.1\x0d
> Accept-Encoding: gzip, deflate\x0d
> Content-Type: multipart/form-data; boundary=tyUPX\x0d
> Accept: */*\x0d
> Host: fritz.box\x0d
> Content-Length: 230\x0d
> User-Agent: Mojolicious (Perl)\x0d
> \x0d
> --tyUPX\x0d
>
> -- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
> Content-Disposition: form-data; name="ConfigExport"\x0d
> \x0d
>
> -- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
> \x0d
> --tyUPX\x0d
>
> -- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
> Content-Disposition: form-data; name="ImportExportPassword"\x0d
> \x0d
>
> -- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
> backup
> -- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
> \x0d
> --tyUPX\x0d
>
> -- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
> Content-Disposition: form-data; name="sid"\x0d
> \x0d
>
> -- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
> 33cb272bcd34940b
> -- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
> \x0d
> --tyUPX--\x0d
>
> -- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
>
> -- Client <<< Server (http://fritz.box/cgi-bin/firmwarecfg)
> HTTP/1.1 200 OK\x0d
>
> which for me looks very much the same as the curl version but as I said,
> curl gives the backup file whereas M::U just gives the HTML page back,
> indicating that something went wrong.
> I can only spot very minor differences that is why I am running out of
> ideas:
> - the boundary used by M::U is qu

Re: [Mojolicious] Re: curl works, Mojo::UserAgent doesn't

[Felipe Gasper]

FWIW, you can use libcurl with Mojo via Net::Curl::Promiser::Mojo. That may be 
your easiest solution?

-FG

> On May 14, 2020, at 07:38, 'Michael Lackhoff' via Mojolicious 
>  wrote:
> 
> 
>> Am 14.05.2020 um 05:08 schrieb Stefan Adams:
>> > I'm certain you'll be able to accomplish this with M::UA. Can you share
> Just to reduce complexity I changed everything to plain HTTP, so no SSL,
> keys or certificates.
> 
>> > what the HTML error produced is?
> It is not really a normal error page, just a page from the UI. The most
> relevant lines are these:
> Invalid variable name.
> Wiederholen Sie das Update oder starten Sie die FRITZ!Box neu.
> [German for: repeat the update(sic! I wanted to backup the box, not
> update) or restart your FRITZ!Box]
> 
>> > Can you share the output that you are comparing that you are noticing is so
>> > similar between curl and M::UA? You're using -v for curl. Also set the
>> > MOJO_CLIENT_DEBUG env variable to 1.
> Here is what curl gives (with --trace-ascii):
> => Send header, 200 bytes (0xc8)
> : POST /cgi-bin/firmwarecfg HTTP/1.1
> 0024: Host: fritz.box
> 0035: User-Agent: curl/7.58.0
> 004e: Accept: */*
> 005b: Content-Length: 370
> 0070: Content-Type: multipart/form-data; boundary=
> 00b0: 565a580ebeb0c567
> 00c6:
> => Send data, 370 bytes (0x172)
> : --565a580ebeb0c567
> 002c: Content-Disposition: form-data; name="sid"
> 0058:
> 005a: 4e240384c30c909d
> 006c: --565a580ebeb0c567
> 0098: Content-Disposition: form-data; name="ImportExportPassword"
> 00d5:
> 00d7: backup
> 00df: --565a580ebeb0c567
> 010b: Content-Disposition: form-data; name="ConfigExport"
> 0140:
> 0142:
> 0144: --565a580ebeb0c567--
> <= Recv header, 17 bytes (0x11)
> : HTTP/1.1 200 OK
> 
> 
>> > See how it works comparing curl to:
>> > 
>> >$ env MOJO_CLIENT_DEBUG=1 mojo get -v -M POST -f sid=$SID -f
>> > ImportExportPassword=$BAKPWD -f ConfigExport= http
>> > ://fritz.box/cgi-bin/firmwarecfg 
> The empty ConfigExport parameter gets lost with this command and the
> Content-Type is different:
> 
> -- Blocking request (http://fritz.box/cgi-bin/firmwarecfg)
> -- Connect 7c84d2d7396d9d2ff9571982f73240cb (http://fritz.box:80)
> -- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
> POST /cgi-bin/firmwarecfg HTTP/1.1\x0d
> Content-Length: 48\x0d
> User-Agent: Mojolicious (Perl)\x0d
> Accept-Encoding: gzip\x0d
> Content-Type: application/x-www-form-urlencoded\x0d
> Host: fritz.box\x0d
> \x0d
> ImportExportPassword=backup&sid=4e240384c30c909d
> -- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
> 
> -- Client <<< Server (http://fritz.box/cgi-bin/firmwarecfg)
> HTTP/1.1 200 OK\x0d
> 
> 
> 
> With DEBUG on and my code (s. my original message and below) I get this:
> 
> -- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
> POST /cgi-bin/firmwarecfg HTTP/1.1\x0d
> Accept-Encoding: gzip, deflate\x0d
> Content-Type: multipart/form-data; boundary=tyUPX\x0d
> Accept: */*\x0d
> Host: fritz.box\x0d
> Content-Length: 230\x0d
> User-Agent: Mojolicious (Perl)\x0d
> \x0d
> --tyUPX\x0d
> 
> -- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
> Content-Disposition: form-data; name="ConfigExport"\x0d
> \x0d
> 
> -- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
> \x0d
> --tyUPX\x0d
> 
> -- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
> Content-Disposition: form-data; name="ImportExportPassword"\x0d
> \x0d
> 
> -- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
> backup
> -- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
> \x0d
> --tyUPX\x0d
> 
> -- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
> Content-Disposition: form-data; name="sid"\x0d
> \x0d
> 
> -- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
> 33cb272bcd34940b
> -- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
> \x0d
> --tyUPX--\x0d
> 
> -- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
> 
> -- Client <<< Server (http://fritz.box/cgi-bin/firmwarecfg)
> HTTP/1.1 200 OK\x0d
> 
> which for me looks very much the same as the curl version but as I said,
> curl gives the backup file whereas M::U just gives the HTML page back,
> indicating that something went wrong.
> I can only spot very minor differences that is why I am running out of
> ideas:
> - the boundary used by M::U is quite short
> - the form parameters are not in the same order
> - Accept-Encoding header (is also sent from Firefox where it works)
> - the different SID is normal (my script always makes a fresch login)
> 
> Looks very strange to me
> -Michael
> 
>> > On Wed, May 13, 2020, 4:56 PM 'Michael Lackhoff' via Mojolicious <
>> > mojolicious@googlegroups.com> wrote:
>> > 
>>> >> I had quite a bit of success recently using Mojo::UserAgent so I tried to
>>> >> replace a curl command to do a backup of my Fritz.box router with M:

[Mojolicious] Re: curl works, Mojo::UserAgent doesn't

['Michael Lackhoff' via Mojolicious]

 

Am 14.05.2020 um 05:08 schrieb Stefan Adams:

> I'm certain you'll be able to accomplish this with M::UA. Can you share

Just to reduce complexity I changed everything to plain HTTP, so no SSL,
keys or certificates.


> what the HTML error produced is?

It is not really a normal error page, just a page from the UI. The most
relevant lines are these:
Invalid variable name.
Wiederholen Sie das Update oder starten Sie die FRITZ!Box neu.
[German for: repeat the update(sic! I wanted to backup the box, not
update) or restart your FRITZ!Box]


> Can you share the output that you are comparing that you are noticing is so> 
> similar between curl and M::UA? You're using -v for curl. Also set the> 
> MOJO_CLIENT_DEBUG env variable to 1.

Here is what curl gives (with --trace-ascii):
=> Send header, 200 bytes (0xc8)
: POST /cgi-bin/firmwarecfg HTTP/1.1
0024: Host: fritz.box
0035: User-Agent: curl/7.58.0
004e: Accept: */*
005b: Content-Length: 370
0070: Content-Type: multipart/form-data; boundary=
00b0: 565a580ebeb0c567
00c6:
=> Send data, 370 bytes (0x172)
: --565a580ebeb0c567
002c: Content-Disposition: form-data; name="sid"
0058:
005a: 4e240384c30c909d
006c: --565a580ebeb0c567
0098: Content-Disposition: form-data; name="ImportExportPassword"
00d5:
00d7: backup
00df: --565a580ebeb0c567
010b: Content-Disposition: form-data; name="ConfigExport"
0140:
0142:
0144: --565a580ebeb0c567--
<= Recv header, 17 bytes (0x11)
: HTTP/1.1 200 OK



> See how it works comparing curl to:> >$ env MOJO_CLIENT_DEBUG=1 mojo get 
> -v -M POST -f sid=$SID -f> ImportExportPassword=$BAKPWD -f ConfigExport= 
> http> ://fritz.box/cgi-bin/firmwarecfg  
> 

The empty ConfigExport parameter gets lost with this command and the
Content-Type is different:

-- Blocking request (http://fritz.box/cgi-bin/firmwarecfg)
-- Connect 7c84d2d7396d9d2ff9571982f73240cb (http://fritz.box:80)
-- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
POST /cgi-bin/firmwarecfg HTTP/1.1\x0d
Content-Length: 48\x0d
User-Agent: Mojolicious (Perl)\x0d
Accept-Encoding: gzip\x0d
Content-Type: application/x-www-form-urlencoded\x0d
Host: fritz.box\x0d
\x0d
ImportExportPassword=backup&sid=4e240384c30c909d
-- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)

-- Client <<< Server (http://fritz.box/cgi-bin/firmwarecfg)
HTTP/1.1 200 OK\x0d



With DEBUG on and my code (s. my original message and below) I get this:

-- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
POST /cgi-bin/firmwarecfg HTTP/1.1\x0d
Accept-Encoding: gzip, deflate\x0d
Content-Type: multipart/form-data; boundary=tyUPX\x0d
Accept: */*\x0d
Host: fritz.box\x0d
Content-Length: 230\x0d
User-Agent: Mojolicious (Perl)\x0d
\x0d
--tyUPX\x0d

-- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
Content-Disposition: form-data; name="ConfigExport"\x0d
\x0d

-- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
\x0d
--tyUPX\x0d

-- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
Content-Disposition: form-data; name="ImportExportPassword"\x0d
\x0d

-- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
backup
-- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
\x0d
--tyUPX\x0d

-- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
Content-Disposition: form-data; name="sid"\x0d
\x0d

-- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
33cb272bcd34940b
-- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
\x0d
--tyUPX--\x0d

-- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)

-- Client <<< Server (http://fritz.box/cgi-bin/firmwarecfg)
HTTP/1.1 200 OK\x0d

which for me looks very much the same as the curl version but as I said,
curl gives the backup file whereas M::U just gives the HTML page back,
indicating that something went wrong.
I can only spot very minor differences that is why I am running out of
ideas:
- the boundary used by M::U is quite short
- the form parameters are not in the same order
- Accept-Encoding header (is also sent from Firefox where it works)
- the different SID is normal (my script always makes a fresch login)

Looks very strange to me
-Michael


> On Wed, May 13, 2020, 4:56 PM 'Michael Lackhoff' via Mojolicious <> 
> mojolicious@googlegroups.com> wrote:> 

>> I had quite a bit of success recently using Mojo::UserAgent so I tried to>> 
>> replace a curl command to do a backup of my Fritz.box router with M::U. 
>> Here is the curl command:>> curl -s -k -o $OUT --form sid=$SID --form 
>> ImportExportPassword=$BAKPWD \>> --form ConfigExport= 
>> http://fritz.box/cgi-bin/firmwarecfg It should be equivalent to this 
>> M::U request: my $tx = $ua->build_tx(>> POST => 
>> 'http://fritz.box/cgi-bin/firmwarecfg' =>>> {>> 'Accept' 
>>   => '*/*',>> 'Content-Typ

[Mojolicious] Re: curl works, Mojo::UserAgent doesn't

[Scott Wiersdorf]

It's possible the `-k` option to curl is the difference. The equivalent in 
Mojo::UserAgent is `$ua->insecure(1)` (which you can chain off of).

Scott

On Wednesday, May 13, 2020 at 3:56:26 PM UTC-6, Michael Lackhoff wrote:
>
> I had quite a bit of success recently using Mojo::UserAgent so I tried to 
> replace a curl command to do a backup of my Fritz.box router with M::U.
>
> Here is the curl command:
> curl -s -k -o $OUT --form sid=$SID --form ImportExportPassword=$BAKPWD \
> --form ConfigExport= http://fritz.box/cgi-bin/firmwarecfg
>
> It should be equivalent to this M::U request:
>
> my $tx = $ua->build_tx(
> POST => 'http://fritz.box/cgi-bin/firmwarecfg' =>
> {
> 'Accept'   => '*/*',
> 'Content-Type' => 'multipart/form-data',
> } => form => {
> sid  => $SID,
> ImportExportPassword => $BAKPWD,
> ConfigExport => '',
> }
> );
>
> # for debugging:
> print $tx->req->to_string;
>
> $tx = $ua->start($tx);
> $tx->res->save_to($OUT);
>
> As far as I can tell both the headers and the POST body is very much the 
> same (except the boundary value to separate the form fields) but to my 
> surprise the curl command works ($OUT is the backup file) but with the M::U 
> version $OUT consists of some HTML output indicating an error.
>
> If I could see a difference I could try to better adjust my script but as 
> I said, they look very much the same (I compared it with the -v and 
> --trace-ascii output of curl), so I run out of ideas what could trigger the 
> differnt response of my Fritz.box.
> Any ideas? At the moment I just solve it by using the curl command with 
> "system" but I would prefer a Perl-only solution and what is even more 
> important to me: I want to understand what is going on here.
>
> -Michael
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/61ee3b8a-ca87-424d-91e1-f807001afa37%40googlegroups.com.

[Mojolicious] Re: Problem with streaming...

[Joseph Fridy]

My sincere apologies.  The two scraps are:

$tx->res->content->unsubscribe('read')->on(read => sub {

my($content, $bytes) = @_;

our $globalC;

our $digester;

our $transferLength;

our $contentLength;

if (!$content->headers->header('headersWritten')) {

  foreach my $name (@{$content->headers->names}) {

my $value = $content->headers->header($name);


 # $globalC should receive 
the streamed file

 # This is setting the 
headers from the S3

 # presigned URL.


$globalC->res->headers->header($name => $value);

if ($name =~ /[cC]ontent-[lL]ength/) {

  $contentLength = $value;

}

  }

  $content->headers->header('headersWritten' => 1);

  $globalC->write;

}

$digester->add($bytes);

$transferLength += length($bytes);

$globalC->write($bytes);

print "$transferLength bytes written...\n";

  });


Which fails after reading 668MB,


and 


  $c->proxy->get_p($url => $headers)->catch(sub {

  my $err = shift;

  print "Proxy error is $err\n";

  $c->render(text => "Error: $err\n");

});

Which fails after trying three or four times with a Connection refused.

Thanks,

Joe Fridy
On Sunday, May 10, 2020 at 6:53:42 AM UTC-4, Sebastian Riedel wrote:
>
> Please don't use HTML for formatting, the code is completely unreadable.
>
> --
> sebastian
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/6d17adda-fd0e-4e82-acc0-81e2f04617f2%40googlegroups.com.

[Mojolicious] Re: Problem with streaming...

[Sebastian Riedel]

Please don't use HTML for formatting, the code is completely unreadable.

--
sebastian

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/29a905a1-0836-479a-935b-60a8e38c456a%40googlegroups.com.

[Mojolicious] Re: Problem with streaming...

[Joseph Fridy]

I reproduced the curl command with UserAgent successfully, and fixed my 
confusion with the headers.  Now I just have to be able to stream the 
results to the browser.  Here is the heart of my initial attempt, where 
$globalC points to the controller argument that should send data to the 
browser.  This reads data for 688MB, without apparently writing any of it 
to the browser, and then fails with an "Out of memory!"

$tx->res->content->unsubscribe('read')->on(read => sub {

my($content, $bytes) = @_;

our $globalC;

our $digester;

our $transferLength;

our $contentLength;

if (!$content->headers->header('headersWritten')) {

  foreach my $name (@{$content->headers->names}) {

my $value = $content->headers->header($name);


 # $globalC should receive 
the streamed file

 # This is setting the 
headers from the S3

 # presigned URL.


$globalC->res->headers->header($name => $value);

if ($name =~ /[cC]ontent-[lL]ength/) {

  $contentLength = $value;

}

  }

  $content->headers->header('headersWritten' => 1);

  $globalC->write;

}

$digester->add($bytes);

$transferLength += length($bytes);

$globalC->write($bytes);

print "$transferLength bytes written...\n";

  });

Attempted to use the $c->proxy->get_p helper in the following manner:

  $c->proxy->get_p($url => $headers)->catch(sub {

  my $err = shift;

  print "Proxy error is $err\n";

  $c->render(text => "Error: $err\n");

});



This appears to restart three or four times before failing with a 
"Connection refused".  The headers are the same headers that work correctly 
in the download with Mojo::UserAgent.

Any guidance?  I assure you I have read the references you have mentioned 
heretofore assiduously.  

Regards,

Joe Fridy



On Monday, May 4, 2020 at 3:05:11 AM UTC-4, Joseph Fridy wrote:
>
> I am attempting to stream the output of a curl command with Mojolicious.  
> The curl command looks (roughly) like this:
>
> curl -H "x-amz-server-side-encryption-customer-algorithm:AES256" -H 
> "x-amz-server-side-encryption-cust\
>
> omer-key:secretKey=" -H "x-amz-server-side-encryption-customer-key-M\
>
> D5:HashOfASecret==" 
> "https://mybucket.s3.amazonaws.com/obscureFileLocation?AWSAccessKeyId=secretStuff&Expires=1588568911&Signature=moreSecrets";
>  
> --\
>
> dump-header header.461 --silent
>
>
> The curl command references a pre-signed URL of a file in AWS stored with 
> Server Side Encryption with Client Side Keys (SSE-C), and supplies the 
> necessary key information via HTTP headers (the -H command options).  The 
> curl command works - but I don't want my users to have to have a system 
> with curl on it to access their files.  The plan is to open the curl 
> command as input to a pipe, and stream its output to the user's browser 
> with Mojolicious.  The curl command also dumps out the HTTP headers from 
> Amazon, so they can be used by Mojolicious.  They look like this:
>
>
> x-amz-id-2: 
> sgMzHD2FJEGJrcbvzQwdhZK6mxUW+ePd6xdghTfgSlV45lMhliIw4prfk4cZMTHbS4fJN8N7xio=
>
> x-amz-request-id: 99B9CA56083DD9ED
>
> Date: Mon, 04 May 2020 04:57:22 GMT
>
> Last-Modified: Sat, 02 May 2020 03:47:35 GMT
>
> ETag: "b3a11409be2705e4581119fa59af79d3-1025"
>
> x-amz-server-side-encryption-customer-algorithm: AES256
>
> x-amz-server-side-encryption-customer-key-MD5: HashOfSecretKey==
>
> Content-Disposition: attachment; filename = "fiveGigFile"
>
> Accept-Ranges: bytes
>
> Content-Type: application/octet-stream; charset=UTF-8
>
> Content-Length: 5368709125
>
> Server: AmazonS3 
>
>
> Note that the file is 5Gig.
>
>
>
> This is my stab at streaming with Mojolicious:
>
>
> use strict;
> use Mojolicious::Lite;
> use FileHandle;
> use Digest::MD5;
>
> any '/' => sub {
>   my $c = shift;
>   $c->render(template => "test");
> };
>
> any 'pickup' => sub {
>   my $c = shift;
>   my $nGigs = 0;
>   my $nMegs = 0;
>   $| = 1;
>   open(CURLCMD,"curlCmd");
>   my $curlCmd = ;
>   if ($curlCmd =~ /dump-header\s*(\S+)\s+/) {
>
> my $headerFile = $1;
> open(my $curl,"$curlCmd |");
> binmode $curl;
> my $initialized = 0;
> my $digester = Digest::MD5->new;
>
>   my $transferLength = 0;
>
>   my $drain;
>
>   $drain = sub {
>
>   my $c = shift;
>
>   my $chunk;
>
>   sysread($curl,$chunk,1024*1024);
>
>   if (!$initialized) {
>   # read the headers, and set up the transfer...
>
>open(HEADERS,$headerFile);
>
>while(my $line = ) {
>
>  $c->res->headers->parse($line);
>
>}
>close(HEADERS);
>
>$initialized = 1;
>
>print "header initialization completed for the following 
> headers\n";
>
>print join("\n",@{$c->res->headers->names}),"\n";
>
>   }
>
>   if ($initialized) {
>
>  while (length($chunk)) {
>
>  

Re: [Mojolicious] Re: Testing internal method

[Alberto Mijares]

On Mon, Apr 27, 2020 at 11:46 PM Glen  wrote:
>
> He's implying that you wouldn't test this internal method with Test::Mojo; 
> Test::Mojo is for testing endpoints.


Thank you, guys.

This was the explanation I was needing.

Tests running now.


Alberto Mijares

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CAGZBXN-d8r%2BaeJ63nN_Ns56SWS%3DzTmjjOCx%2Bn%3DvdpP4JCV%3DPsw%40mail.gmail.com.

Re: [Mojolicious] Re: Testing internal method

[Stefan Adams]

I think Scott and Glen are both pointing out that your method in your
controller class that is not associated with a route ("filter") is not a
method of your controller, but instead in the "model" portion of MVC.  It
might help you to move that code outside of the controller class, and then
it'll make much more sense to test it normally with Test::More instead of
Test::Mojo.

# lib/App/Controller/This.pm
package App::Controller::This;
use Mojo::Base 'Mojolicious::Controller';
sub list {
  my $self = shift;
  my $model = App::Model->new;
  my $value = $self->req->json('/value');
  $self->render(json => {value => $model->filter(@$value)});
}

# lib/App/Model.pm
package App::Model;
use Mojo::Base -base;
sub filter {
  my $self = shift;
  my $final;
  /something/ and push @$final, $_ for @_;
  return $final;
}

And then you can test your filter method normally:

# t/basic.t
use Test::More;
use Test::Mojo;

# Test the controller / action and the use of any models
my $t = Test::Mojo->new('App');
$t->get_ok('/list' => json => {value => ['abc', 'def something ghi', 'jkl',
'mno something pqr']})
   ->status_is(200)
   ->json_is('/value', ['def something ghi', 'mno something pqr']);

# Test just the model
my $model = App::Model->new;
isa_ok $model, 'App::Model';
is_deeply $model->filter('abc', 'def something ghi', 'jkl', 'mno something
pqr'), ['def something ghi', 'mno something pqr'];

On Mon, Apr 27, 2020 at 10:46 PM Glen  wrote:

> He's implying that you wouldn't test this internal method with Test::Mojo; 
> Test::Mojo
> is for testing endpoints.
>
> If you want to test a specific method that is not an endpoint, load the
> module manually and test it with Test::More.
>
> On Apr 27, 2020, 11:32 PM -0400, Alberto Mijares ,
> wrote:
>
>
>
> On Mon, Apr 27, 2020, 7:09 PM Scott Wiersdorf 
> wrote:
>
>> Test::Mojo can help you test your views and controllers, as well as your
>> internal helpers:
>>
>>
>> https://metacpan.org/pod/distribution/Mojolicious/lib/Mojolicious/Guides/Testing.pod#Testing-application-helpers
>>
>
> Thank you Scott.
>
> I did read the documentation before writing this email and saw what you
> are pointing out. The thing is: it's not clear enough for me.
>
> Given the example in my original post, could you give me a more detailed
> explanation? I don't know how to trigger this specific method.
>
> Thanks in advance for your help.
>
> Alberto Mijares
>
>
>> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/mojolicious/CAGZBXN9VBvBFZdkmpaJOPHFJ5V5h98GdqmsqjH%2B7wN6bRNpAuQ%40mail.gmail.com
> 
> .
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/mojolicious/985dbe91-4202-406e-9b28-dd44922933a7%40Spark
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFSRKsEpxnRvmP1MJ9mHpQVZq9SqhUUiywOS3zuROj5nDQ%40mail.gmail.com.

Re: [Mojolicious] Re: Testing internal method

[Glen]

He's implying that you wouldn't test this internal method with Test::Mojo; 
Test::Mojo is for testing endpoints.

If you want to test a specific method that is not an endpoint, load the module 
manually and test it with Test::More.

On Apr 27, 2020, 11:32 PM -0400, Alberto Mijares , wrote:
>
>
> > On Mon, Apr 27, 2020, 7:09 PM Scott Wiersdorf  
> > wrote:
> > > Test::Mojo can help you test your views and controllers, as well as your 
> > > internal helpers:
> > >
> > > https://metacpan.org/pod/distribution/Mojolicious/lib/Mojolicious/Guides/Testing.pod#Testing-application-helpers
>
> Thank you Scott.
>
> I did read the documentation before writing this email and saw what you are 
> pointing out. The thing is: it's not clear enough for me.
>
> Given the example in my original post, could you give me a more detailed 
> explanation? I don't know how to trigger this specific method.
>
> Thanks in advance for your help.
>
> Alberto Mijares
>
> > >
> --
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/mojolicious/CAGZBXN9VBvBFZdkmpaJOPHFJ5V5h98GdqmsqjH%2B7wN6bRNpAuQ%40mail.gmail.com.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/985dbe91-4202-406e-9b28-dd44922933a7%40Spark.

Re: [Mojolicious] Re: Testing internal method

[Alberto Mijares]

On Mon, Apr 27, 2020, 7:09 PM Scott Wiersdorf 
wrote:

> Test::Mojo can help you test your views and controllers, as well as your
> internal helpers:
>
>
> https://metacpan.org/pod/distribution/Mojolicious/lib/Mojolicious/Guides/Testing.pod#Testing-application-helpers
>

Thank you Scott.

I did read the documentation before writing this email and saw what you are
pointing out. The thing is: it's not clear enough for me.

Given the example in my original post, could you give me a more detailed
explanation? I don't know how to trigger this specific method.

Thanks in advance for your help.

Alberto Mijares


>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CAGZBXN9VBvBFZdkmpaJOPHFJ5V5h98GdqmsqjH%2B7wN6bRNpAuQ%40mail.gmail.com.

[Mojolicious] Re: Testing internal method

[Scott Wiersdorf]

Test::Mojo can help you test your views and controllers, as well as your 
internal helpers:

https://metacpan.org/pod/distribution/Mojolicious/lib/Mojolicious/Guides/Testing.pod#Testing-application-helpers

If you are wanting to test your application *model* (i.e., non-Mojolicious 
code), you should probably use standard Test::More to create an object, 
exercise its methods, etc.

Scott

On Monday, April 27, 2020 at 4:55:43 PM UTC-6, Alberto Mijares wrote:
>
> Hi guys, 
>
> I've been reading about testing and can't figure out how to test 
> internal methods; meaning those methods not directly associated to a 
> route. 
>
> I'm sure most of you know what I'm talking about but just for the 
> record. Let's say you have in App::Controller::This 
>
> sub list { 
> my $self = shift; 
> $self->render(text => $self->filter($value)); 
> } 
>
> sub filter { 
> my $self = shift; 
> for @list {push (@final, $line) if ($line =~ /something/);} 
> return \@final 
> } 
>
> And in lib/App.pm you have 
>
> $c->get('/list)->to('this#list'); 
>
> So, I want to test returned values from App::Controller::This->filter. 
>
> Thanks in advance for your help. 
>
>
> Alberto Mijares 
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/6fd72956-78ed-4922-bf30-e3cad431e5e0%40googlegroups.com.

Re: [Mojolicious] Re: $ ->has_error validation method in Mojolicious higher than 8.33 version

[Ivan Kolisnyk]

Thank you Sebastian.
All works now.
I did not pay attention to the combination of 'required' method and filters.
середа, 15 квітня 2020 р. 00:48:40 UTC+3 користувач Sebastian Riedel 
написав:
>
> > The same code is used in the example of blog included in Mojo::Pg 
> module. 
> > Method has_error is not working in this example too with 8.36 
> Mojolicious version. 
> > The feedback of $v->has_error cannot be used for creating alert message 
> about empty field in a web form. 
> > Can you fix it so it worked like in previous versions? 
>
> Thanks, fixed. 
>
> 
> https://github.com/mojolicious/mojo-pg/compare/e44efd108841...7a4a016fd69d 
> -- 
> Sebastian Riedel 
> https://mojolicious.org 
> https://github.com/kraih 
> https://twitter.com/kraih 
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/f108c1be-ab68-4c91-ae1f-618a71683d53%40googlegroups.com.

Re: [Mojolicious] Re: $ ->has_error validation method in Mojolicious higher than 8.33 version

[Sebastian Riedel]

> The same code is used in the example of blog included in Mojo::Pg module.
> Method has_error is not working in this example too with 8.36 Mojolicious 
> version.
> The feedback of $v->has_error cannot be used for creating alert message about 
> empty field in a web form.
> Can you fix it so it worked like in previous versions?

Thanks, fixed.

https://github.com/mojolicious/mojo-pg/compare/e44efd108841...7a4a016fd69d
-- 
Sebastian Riedel
https://mojolicious.org
https://github.com/kraih
https://twitter.com/kraih

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CANn9nhH8mfBG6OxKZCd-sbLv%3Dz9p_vT9uCKNeuooTWtm7CCB4Q%40mail.gmail.com.

[Mojolicious] Re: $ ->has_error validation method in Mojolicious higher than 8.33 version

[Ivan Kolisnyk]

The same code is used in the example of blog included in Mojo::Pg module.
Method has_error is not working in this example too with 8.36 Mojolicious 
version.
The feedback of $v->has_error cannot be used for creating alert message 
about empty field in a web form.
Can you fix it so it worked like in previous versions?

неділя, 12 квітня 2020 р. 14:57:55 UTC+3 користувач Sebastian Riedel 
написав:
>
> I have installed last version of Mojolicious and I found that the $ 
>> ->has_error validation method was working with an error. 
>> When I send data form with empty field, which must be required full, I 
>> get empty value of $v->has_error. This method worked correctly in previous 
>> version of Mojolicious (8.28 and 8.33) I used. 
>> Please explain how to fix this bug.
>>
>
> Your description is very vague, so i can only guess. But you probably want 
> to use the not_empty filter on the affected field.
>
> https://mojolicious.org/perldoc/Mojolicious/Validator#not_empty
>
> --
> sebastian 
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/f6728954-753b-47ac-8ee5-ca226fa9a24c%40googlegroups.com.

Re: [Mojolicious] Re: $ ->has_error validation method in Mojolicious higher than 8.33 version

[Stefan Adams]

The conversation in the PR 
might provide some insight to Sebastian's pointer.  The change
 was made in 8.35.

On Sun, Apr 12, 2020 at 7:55 AM Ivan Kolisnyk  wrote:

> This is the code I use in my project:
>
> In helper:
> $app->helper(_validation => sub { my($c, $required_fields) = @_;
> my $v = $c->validation;
> foreach my $item($required_fields
> ->@*){
> $v->required($item);
> }
> return $v;
>  });
>
> and in controller:
> my $v = $app->_validation($ref_required_fields);
> if( $v->has_error ) { sub{ ... } }
>
> This code works correctly in Mojolicious versions lower than 8.34. You can
> see how it works at https://dev.mojoblog.me/authentication
>
>
> неділя, 12 квітня 2020 р. 14:57:55 UTC+3 користувач Sebastian Riedel
> написав:
>>
>> I have installed last version of Mojolicious and I found that the $
>>> ->has_error validation method was working with an error.
>>> When I send data form with empty field, which must be required full, I
>>> get empty value of $v->has_error. This method worked correctly in previous
>>> version of Mojolicious (8.28 and 8.33) I used.
>>> Please explain how to fix this bug.
>>>
>>
>> Your description is very vague, so i can only guess. But you probably
>> want to use the not_empty filter on the affected field.
>>
>> https://mojolicious.org/perldoc/Mojolicious/Validator#not_empty
>>
>> --
>> sebastian
>>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/mojolicious/2514dc71-e198-4277-8d2a-a170f943dca1%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFSbta9LcrCKZ_cmqsfX8YkVPSu4KfYDEVkzr_38xUz%2Bmw%40mail.gmail.com.

[Mojolicious] Re: $ ->has_error validation method in Mojolicious higher than 8.33 version

[Ivan Kolisnyk]

This is the code I use in my project:

In helper:
$app->helper(_validation => sub { my($c, $required_fields) = @_; 
my $v = $c->validation;
foreach my $item($required_fields
->@*){
$v->required($item);
}
return $v;  
 });

and in controller:
my $v = $app->_validation($ref_required_fields);
if( $v->has_error ) { sub{ ... } }

This code works correctly in Mojolicious versions lower than 8.34. You can 
see how it works at https://dev.mojoblog.me/authentication


неділя, 12 квітня 2020 р. 14:57:55 UTC+3 користувач Sebastian Riedel 
написав:
>
> I have installed last version of Mojolicious and I found that the $ 
>> ->has_error validation method was working with an error. 
>> When I send data form with empty field, which must be required full, I 
>> get empty value of $v->has_error. This method worked correctly in previous 
>> version of Mojolicious (8.28 and 8.33) I used. 
>> Please explain how to fix this bug.
>>
>
> Your description is very vague, so i can only guess. But you probably want 
> to use the not_empty filter on the affected field.
>
> https://mojolicious.org/perldoc/Mojolicious/Validator#not_empty
>
> --
> sebastian 
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/2514dc71-e198-4277-8d2a-a170f943dca1%40googlegroups.com.

[Mojolicious] Re: $ ->has_error validation method in Mojolicious higher than 8.33 version

[Sebastian Riedel]

>
> I have installed last version of Mojolicious and I found that the $ 
> ->has_error validation method was working with an error. 
> When I send data form with empty field, which must be required full, I get 
> empty value of $v->has_error. This method worked correctly in previous 
> version of Mojolicious (8.28 and 8.33) I used. 
> Please explain how to fix this bug.
>

Your description is very vague, so i can only guess. But you probably want 
to use the not_empty filter on the affected field.

https://mojolicious.org/perldoc/Mojolicious/Validator#not_empty

--
sebastian 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/10a06567-66d7-46f3-a8e3-e74bc02b86e8%40googlegroups.com.

Re: [Mojolicious] Re: Best practices for dynamic workflows

[Alberto Mijares]

> Fyi. Mojolicious has a job queue too.
>
> https://github.com/mojolicious/minion
>
> --
> sebastian


This is what I had in mind when wrote "Pg".

Thanks ;-)

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CAGZBXN9Wj87AhFbT4vcFRv%2Bn%2BP7fJJF3tFYHv1O2Q_a-iL1c0w%40mail.gmail.com.

Re: [Mojolicious] Re: New server status plugin

[Stefan Adams]

Fair enough! Thank you!

On Sun, Feb 16, 2020, 10:36 AM Sebastian Riedel  wrote:

> Just curious -- why did you choose to make Mojo::MemoryMap a part of
>> Mojolicious::Plugin::Status instead of its own stand alone?
>>
>
> For my convenience. Both are being developed together and coordinating
> multiple CPAN distributions costs time. Unfortunately spare time is a very
> limited resource for me these days, so i've got to cut some corners.
>
> --
> sebastian
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/mojolicious/430da8f5-0d8b-47c7-9bda-d1eb9dc1b4e5%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFStnoqhv5jDhD_n1HGJbAcVgE-OcvZWAj8%3Dg%3Da30eVO3Q%40mail.gmail.com.

Re: [Mojolicious] Re: New server status plugin

[Sebastian Riedel]

>
> Just curious -- why did you choose to make Mojo::MemoryMap a part of 
> Mojolicious::Plugin::Status instead of its own stand alone?
>

For my convenience. Both are being developed together and coordinating
multiple CPAN distributions costs time. Unfortunately spare time is a very
limited resource for me these days, so i've got to cut some corners.

--
sebastian

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/430da8f5-0d8b-47c7-9bda-d1eb9dc1b4e5%40googlegroups.com.

Re: [Mojolicious] Re: New server status plugin

[Stefan Adams]

This plugin is awesome!  And Mojo::MemoryMap looks like it will be so
useful in some projects!

Just curious -- why did you choose to make Mojo::MemoryMap a part of
Mojolicious::Plugin::Status instead of its own stand alone?

On Fri, Feb 14, 2020 at 10:46 AM Sebastian Riedel  wrote:

> Forgot to mention that it will now also show you the slowest requests,
> with a little smiley
> indicating the urgency of optimising that part of your code. :)
>
> --
> sebastian
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/mojolicious/cc1a86c7-e6c9-4ef1-9fc3-7d7e85b11b8a%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFRqQ1_GWN%2B%3D%3DUWDxLeXeDTyzxMQx2s3yC9MuUjQyJz%3DNA%40mail.gmail.com.

[Mojolicious] Re: New server status plugin

[Sebastian Riedel]

Forgot to mention that it will now also show you the slowest requests, with 
a little smiley
indicating the urgency of optimising that part of your code. :)

--
sebastian

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/cc1a86c7-e6c9-4ef1-9fc3-7d7e85b11b8a%40googlegroups.com.

[Mojolicious] Re: Best practices for dynamic workflows

[Sebastian Riedel]

>
> The link between 
> modules would be a queue, not sure about the backend for those queues 
> yet, though, perhaps Pg or Celery.
>

Fyi. Mojolicious has a job queue too.

https://github.com/mojolicious/minion

--
sebastian 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/c59b4bf6-a8f0-4eb8-b156-6ff3fe8fceec%40googlegroups.com.

[Mojolicious] Re:

[Sebastian Riedel]

Thank you, glad it's working well for you. :)

--
sebastian

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/b63e9fc3-91cc-4a1c-b1ae-71d422d80738%40googlegroups.com.

[Mojolicious] Re: mojo async/await with controller

['Tobias Oetiker' via Mojolicious]

I am answering my own questions here ... so it seems I still have to call 
render_later in the controller to make this work ..

async sub hello ($self) {
  # Render template "example/welcome.html.ep" with message
  *$self**->render_later;*
  await Mojo::Promise->new(sub ($resolve,$fail) {
  Mojo::IOLoop->timer(3 => sub { 
  $resolve->();
  });
  });
  $self->render(text => 'hello');
}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/d146761e-e634-455d-acb3-1a8007f8b076%40googlegroups.com.

[Mojolicious] Re: mojo async/await with controller

['Tobias Oetiker' via Mojolicious]

ps. it also does not work when the method in the controller is called hello 
...

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/2067b561-de13-4357-8e94-f5098fa186a7%40googlegroups.com.

[Mojolicious] Re: Websocket cat

[sri]

>
> I began with the documentation: 
>
> https://mojolicious.org/perldoc/Mojo/IOLoop/Stream/WebSocketClient 
>

That module doesn't actually exist anymore for quite some time. Use the 
guides to get started.

https://mojolicious.org/perldoc/Mojolicious/Guides/Cookbook#USER-AGENT

--
sebastian 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/833cbf71-9d23-4b5d-af84-26d5283fc6ad%40googlegroups.com.

[Mojolicious] Re: Mojolicious Web Clients Book

['Daniel Böhringer' via Mojolicious]

this link does not work for me.
is this possibly a typo?

Am Donnerstag, 21. November 2019 10:17:23 UTC+1 schrieb sri:
>
> You can now pre-order the book brian d foy announced at Mojoconf.
>
> https://www.amazon.com/gp/product/B0815XLYJX/
>
> --
> sebastian
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/c693fa79-efc4-4cb0-990d-1f1fbdffb595%40googlegroups.com.

[Mojolicious] Re: Mojolicious - Development vs. Deployment (PostgreSQL)

[sri]

This is a crosspost from Reddit.


https://www.reddit.com/r/perl/comments/dzibxq/mojolicious_development_vs_deployment_postgresql/

--
sebastian

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/e3566497-d3b5-422f-b372-24b072ca865d%40googlegroups.com.

Re: [Mojolicious] Re: mojo generate role

[Dan Book]

The general policy is the same as applied to plugins or things in the
Mojo:: namespace: it's fine to upload CPAN modules under them as long as
you defer to the core team if they want to claim the namespace.

-Dan

On Wed, Oct 23, 2019 at 6:50 PM Roger Crew  wrote:

> yes, mine actually is under ..::Author::generate::
>
> (didn't realize it was actually okay to pee in that space, although maybe
> this is more of a case of cant-do-anything-about-it; welcome to CPAN)
>
> On Wednesday, October 23, 2019 at 3:30:00 PM UTC-7, Dan Book wrote:
>>
>> Actually the generate command moved so it would be under
>> Mojolicious::Command::Author::generate::foo in recent versions.
>>
>> -Dan
>>
>> On Wed, Oct 23, 2019 at 6:25 PM Dan Book  wrote:
>>
>>> You would install it under Mojolicious::Command::generate, as described
>>> at
>>> https://metacpan.org/pod/Mojolicious::Guides::Cookbook#Adding-commands-to-Mojolicious.
>>> Easiest if you have a local::lib and simply put it under
>>> ~/perl5/lib/perl5/Mojolicious/Command/...
>>>
>>> -Dan
>>>
>>> On Wed, Oct 23, 2019 at 6:16 PM Roger Crew 
>>> wrote:
>>>
 what's the right way to get something like this
 (i.e., new mojo generate commands, or variations/additional-options on
 existing ones)
 added to my 'mojo' command search space.

 I can't do it as a plugin, since plugin stuff doesn't becomes available
 until you actually *add* the plugin to the application you're
 currently working on (assuming it even *is *an application that you're
 working on, as opposed to a plugin, or a role, or something else), and the 
 mojo
 generate commands are all for *creating* source-trees from scratch.

 About the only thing I can come up with is playing games with @INC in
 order to swap in my own version of Mojo::HelloWorld to add stuff to
 its ->commands,

 ... which all looks to be at least medium evil.

 but I also hate to ask for Yet Another Environment Variable (but maybe
 that's the RIght Thing here?)


 On Tuesday, October 1, 2019 at 6:23:53 AM UTC-7, Roger Crew wrote:
>
> so, on the theory that if I'm doing something at least twice there
> should be a script for it,
> I wrote a "mojo generate role", role.pm,
>
> that is mostly a ripoff of "mojo generate plugin" but with some better
> defaults
> i.e.,
>
> mojo generate role BaseClass RoleName
>
> creates a rudimentary development directory for the
> BaseClass::Role::RoleName role
> with a single testcase template (...that will actually work straight
> out of the box if you chose
> a baseclass that doesn't require arguments to build...).
>
> I can do a pull request if there's interest in this and you want
> actual code to look at.
>
 --
 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 mojol...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/mojolicious/e3795845-2934-4dce-b95f-a1d76fc9d6f4%40googlegroups.com
 
 .

>>> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/mojolicious/4265d0f9-01bd-4f60-bd7a-b69fa3951d62%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CABMkAVWQNxv%3D-1gYP0tob31uTB8p0Ev9zUTVVOh4US7gLfKu2Q%40mail.gmail.com.

Re: [Mojolicious] Re: mojo generate role

[Roger Crew]

yes, mine actually is under ..::Author::generate::

(didn't realize it was actually okay to pee in that space, although maybe 
this is more of a case of cant-do-anything-about-it; welcome to CPAN)

On Wednesday, October 23, 2019 at 3:30:00 PM UTC-7, Dan Book wrote:
>
> Actually the generate command moved so it would be under 
> Mojolicious::Command::Author::generate::foo in recent versions.
>
> -Dan
>
> On Wed, Oct 23, 2019 at 6:25 PM Dan Book > 
> wrote:
>
>> You would install it under Mojolicious::Command::generate, as described 
>> at 
>> https://metacpan.org/pod/Mojolicious::Guides::Cookbook#Adding-commands-to-Mojolicious.
>>  
>> Easiest if you have a local::lib and simply put it under 
>> ~/perl5/lib/perl5/Mojolicious/Command/...
>>
>> -Dan
>>
>> On Wed, Oct 23, 2019 at 6:16 PM Roger Crew > > wrote:
>>
>>> what's the right way to get something like this
>>> (i.e., new mojo generate commands, or variations/additional-options on 
>>> existing ones)
>>> added to my 'mojo' command search space.  
>>>
>>> I can't do it as a plugin, since plugin stuff doesn't becomes available 
>>> until you actually *add* the plugin to the application you're currently 
>>> working on (assuming it even *is *an application that you're working 
>>> on, as opposed to a plugin, or a role, or something else), and the mojo 
>>> generate commands are all for *creating* source-trees from scratch.
>>>
>>> About the only thing I can come up with is playing games with @INC in 
>>> order to swap in my own version of Mojo::HelloWorld to add stuff to its 
>>> ->commands, 
>>>
>>> ... which all looks to be at least medium evil.
>>>
>>> but I also hate to ask for Yet Another Environment Variable (but maybe 
>>> that's the RIght Thing here?)  
>>>
>>>
>>> On Tuesday, October 1, 2019 at 6:23:53 AM UTC-7, Roger Crew wrote:

 so, on the theory that if I'm doing something at least twice there 
 should be a script for it,
 I wrote a "mojo generate role", role.pm, 

 that is mostly a ripoff of "mojo generate plugin" but with some better 
 defaults
 i.e.,

 mojo generate role BaseClass RoleName

 creates a rudimentary development directory for the 
 BaseClass::Role::RoleName role
 with a single testcase template (...that will actually work straight 
 out of the box if you chose
 a baseclass that doesn't require arguments to build...).

 I can do a pull request if there's interest in this and you want actual 
 code to look at.

>>> -- 
>>> 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 mojol...@googlegroups.com .
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/mojolicious/e3795845-2934-4dce-b95f-a1d76fc9d6f4%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/4265d0f9-01bd-4f60-bd7a-b69fa3951d62%40googlegroups.com.

Re: [Mojolicious] Re: mojo generate role

[Dan Book]

Actually the generate command moved so it would be under
Mojolicious::Command::Author::generate::foo in recent versions.

-Dan

On Wed, Oct 23, 2019 at 6:25 PM Dan Book  wrote:

> You would install it under Mojolicious::Command::generate, as described at
> https://metacpan.org/pod/Mojolicious::Guides::Cookbook#Adding-commands-to-Mojolicious.
> Easiest if you have a local::lib and simply put it under
> ~/perl5/lib/perl5/Mojolicious/Command/...
>
> -Dan
>
> On Wed, Oct 23, 2019 at 6:16 PM Roger Crew  wrote:
>
>> what's the right way to get something like this
>> (i.e., new mojo generate commands, or variations/additional-options on
>> existing ones)
>> added to my 'mojo' command search space.
>>
>> I can't do it as a plugin, since plugin stuff doesn't becomes available
>> until you actually *add* the plugin to the application you're currently
>> working on (assuming it even *is *an application that you're working on,
>> as opposed to a plugin, or a role, or something else), and the mojo
>> generate commands are all for *creating* source-trees from scratch.
>>
>> About the only thing I can come up with is playing games with @INC in
>> order to swap in my own version of Mojo::HelloWorld to add stuff to its
>> ->commands,
>>
>> ... which all looks to be at least medium evil.
>>
>> but I also hate to ask for Yet Another Environment Variable (but maybe
>> that's the RIght Thing here?)
>>
>>
>> On Tuesday, October 1, 2019 at 6:23:53 AM UTC-7, Roger Crew wrote:
>>>
>>> so, on the theory that if I'm doing something at least twice there
>>> should be a script for it,
>>> I wrote a "mojo generate role", role.pm,
>>>
>>> that is mostly a ripoff of "mojo generate plugin" but with some better
>>> defaults
>>> i.e.,
>>>
>>> mojo generate role BaseClass RoleName
>>>
>>> creates a rudimentary development directory for the
>>> BaseClass::Role::RoleName role
>>> with a single testcase template (...that will actually work straight out
>>> of the box if you chose
>>> a baseclass that doesn't require arguments to build...).
>>>
>>> I can do a pull request if there's interest in this and you want actual
>>> code to look at.
>>>
>> --
>> 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 view this discussion on the web visit
>> https://groups.google.com/d/msgid/mojolicious/e3795845-2934-4dce-b95f-a1d76fc9d6f4%40googlegroups.com
>> 
>> .
>>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CABMkAVU0s%3DRfr9N7a4iQb0W%3Dfz5no6A%2B0Z5VNUt5gNF0%2BZ6Eew%40mail.gmail.com.

Re: [Mojolicious] Re: mojo generate role

[Dan Book]

There are many such global commands released to CPAN for example:
https://metacpan.org/search?q=Mojolicious%3A%3ACommand%3A%3A

-Dan

On Wed, Oct 23, 2019 at 6:25 PM Dan Book  wrote:

> You would install it under Mojolicious::Command::generate, as described at
> https://metacpan.org/pod/Mojolicious::Guides::Cookbook#Adding-commands-to-Mojolicious.
> Easiest if you have a local::lib and simply put it under
> ~/perl5/lib/perl5/Mojolicious/Command/...
>
> -Dan
>
> On Wed, Oct 23, 2019 at 6:16 PM Roger Crew  wrote:
>
>> what's the right way to get something like this
>> (i.e., new mojo generate commands, or variations/additional-options on
>> existing ones)
>> added to my 'mojo' command search space.
>>
>> I can't do it as a plugin, since plugin stuff doesn't becomes available
>> until you actually *add* the plugin to the application you're currently
>> working on (assuming it even *is *an application that you're working on,
>> as opposed to a plugin, or a role, or something else), and the mojo
>> generate commands are all for *creating* source-trees from scratch.
>>
>> About the only thing I can come up with is playing games with @INC in
>> order to swap in my own version of Mojo::HelloWorld to add stuff to its
>> ->commands,
>>
>> ... which all looks to be at least medium evil.
>>
>> but I also hate to ask for Yet Another Environment Variable (but maybe
>> that's the RIght Thing here?)
>>
>>
>> On Tuesday, October 1, 2019 at 6:23:53 AM UTC-7, Roger Crew wrote:
>>>
>>> so, on the theory that if I'm doing something at least twice there
>>> should be a script for it,
>>> I wrote a "mojo generate role", role.pm,
>>>
>>> that is mostly a ripoff of "mojo generate plugin" but with some better
>>> defaults
>>> i.e.,
>>>
>>> mojo generate role BaseClass RoleName
>>>
>>> creates a rudimentary development directory for the
>>> BaseClass::Role::RoleName role
>>> with a single testcase template (...that will actually work straight out
>>> of the box if you chose
>>> a baseclass that doesn't require arguments to build...).
>>>
>>> I can do a pull request if there's interest in this and you want actual
>>> code to look at.
>>>
>> --
>> 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 view this discussion on the web visit
>> https://groups.google.com/d/msgid/mojolicious/e3795845-2934-4dce-b95f-a1d76fc9d6f4%40googlegroups.com
>> 
>> .
>>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CABMkAVUix3H%2BSs9s7UaQsSo7kSKwHS%2BonEphPhJmpjfPLsq6GQ%40mail.gmail.com.

Re: [Mojolicious] Re: mojo generate role

[Dan Book]

You would install it under Mojolicious::Command::generate, as described at
https://metacpan.org/pod/Mojolicious::Guides::Cookbook#Adding-commands-to-Mojolicious.
Easiest if you have a local::lib and simply put it under
~/perl5/lib/perl5/Mojolicious/Command/...

-Dan

On Wed, Oct 23, 2019 at 6:16 PM Roger Crew  wrote:

> what's the right way to get something like this
> (i.e., new mojo generate commands, or variations/additional-options on
> existing ones)
> added to my 'mojo' command search space.
>
> I can't do it as a plugin, since plugin stuff doesn't becomes available
> until you actually *add* the plugin to the application you're currently
> working on (assuming it even *is *an application that you're working on,
> as opposed to a plugin, or a role, or something else), and the mojo
> generate commands are all for *creating* source-trees from scratch.
>
> About the only thing I can come up with is playing games with @INC in
> order to swap in my own version of Mojo::HelloWorld to add stuff to its
> ->commands,
>
> ... which all looks to be at least medium evil.
>
> but I also hate to ask for Yet Another Environment Variable (but maybe
> that's the RIght Thing here?)
>
>
> On Tuesday, October 1, 2019 at 6:23:53 AM UTC-7, Roger Crew wrote:
>>
>> so, on the theory that if I'm doing something at least twice there should
>> be a script for it,
>> I wrote a "mojo generate role", role.pm,
>>
>> that is mostly a ripoff of "mojo generate plugin" but with some better
>> defaults
>> i.e.,
>>
>> mojo generate role BaseClass RoleName
>>
>> creates a rudimentary development directory for the
>> BaseClass::Role::RoleName role
>> with a single testcase template (...that will actually work straight out
>> of the box if you chose
>> a baseclass that doesn't require arguments to build...).
>>
>> I can do a pull request if there's interest in this and you want actual
>> code to look at.
>>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/mojolicious/e3795845-2934-4dce-b95f-a1d76fc9d6f4%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CABMkAVVnGpdR_7U07hR_NV3KMA1R3A-Pg-eBjYuS117U9QfUsQ%40mail.gmail.com.

[Mojolicious] Re: mojo generate role

[Roger Crew]

what's the right way to get something like this
(i.e., new mojo generate commands, or variations/additional-options on 
existing ones)
added to my 'mojo' command search space.  

I can't do it as a plugin, since plugin stuff doesn't becomes available 
until you actually *add* the plugin to the application you're currently 
working on (assuming it even *is *an application that you're working on, as 
opposed to a plugin, or a role, or something else), and the mojo generate 
commands 
are all for *creating* source-trees from scratch.

About the only thing I can come up with is playing games with @INC in order 
to swap in my own version of Mojo::HelloWorld to add stuff to its ->commands, 


... which all looks to be at least medium evil.

but I also hate to ask for Yet Another Environment Variable (but maybe 
that's the RIght Thing here?)  


On Tuesday, October 1, 2019 at 6:23:53 AM UTC-7, Roger Crew wrote:
>
> so, on the theory that if I'm doing something at least twice there should 
> be a script for it,
> I wrote a "mojo generate role", role.pm, 
>
> that is mostly a ripoff of "mojo generate plugin" but with some better 
> defaults
> i.e.,
>
> mojo generate role BaseClass RoleName
>
> creates a rudimentary development directory for the 
> BaseClass::Role::RoleName role
> with a single testcase template (...that will actually work straight out 
> of the box if you chose
> a baseclass that doesn't require arguments to build...).
>
> I can do a pull request if there's interest in this and you want actual 
> code to look at.
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/e3795845-2934-4dce-b95f-a1d76fc9d6f4%40googlegroups.com.

[Mojolicious] Re: Minion: getting data out.

[BobbyBrown]

@sri

Thank you, this explains the perceived strangeness.

I still have not figured out how to reliably get data out of a minion task, 
I'll have to work on events and read up on non-blocking.
If I understand the code correctly the linkcheck example simply fails if 
the minion job has not finished when it looks up the result?

For the time being though I can get data from one minion process to 
another, because {parents = "$id"} keeps things in order. So I'll continue 
building like this, and see if in the end I can get everything in place. (I 
suppose I'll write final data processed to a database, and set up something 
non-blocking to update the page rendered from the database. I've still got 
lots to learn.)

Kind regards,

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/9a35093f-acae-4ff7-ac33-56340f3ea2de%40googlegroups.com.

[Mojolicious] Re: changing the class of promises returned by UserAgent->get_p / post_p / start_p /...

[Roger Crew]

Note that what I actually want here is for promise_class() to live directly 
on UserAgent and for start_p to directly do ->promise_class->new rather 
than Mojo::Promise->new; this module is essentially a way to try that out.

And, yes, this is providing rope for people to choose a stupid class that 
doesn't implement promises correctly, which is arguably fragile (and part 
of why I provide ->promise_roles(); it's not strictly necessary but it 
makes this kind of mistake less likely, though a badly written role can 
screw things up, too..), but, if so, then large parts of Mojolicious are 
similarly fragile (e.g., someone could just as easily do 
ua->transactor(something that doesn't implement Transactor right) and 
likewise lose).

... and since I can't/shouldn't edit UserAgent directly, the next best 
thing is to intercept promise creation as early as possible.  And as far as 
I can tell this implementation is as close as it gets:  start_p() creates 
the promise, then calls start() but doesn't actually pass the promise 
itself (it only shows up in the callback which won't get invoked until 
after start_p returns).  The reblessing is happening before any possibility 
of method calls on the object.

Also, this way, if someone wants to customize Transactor::promisify, the 
additional promise behaviours/methods will be available there.  Your 
solution of returning a fresh promise out of start_p wouldn't allow that.

(yes, I understand start_p could get entirely rewritten, but I'm using an 
around() hook which is already asking for trouble on that front; I guess 
I'm not clear on why reblessing is such a huge sin on top of that...)


On Wednesday, October 2, 2019 at 8:10:16 AM UTC-7, Joel Berger wrote:
>
> Reblessing the returned object into the class of your choosing seems like 
> an incredibly fragile way of doing that. I'd recommend that you could just 
> chain the returned promise with one that you create/return. 
>
> On Tuesday, October 1, 2019 at 8:21:13 AM UTC-5, Roger Crew wrote:
>>
>> Mojo::UserAgent::Role::PromiseClass now exists on CPAN to play with.
>>
>> Promises returned by get_p can now be automatically blessed into whatever 
>> class you want by just specifying it once on the UserAgent
>>
>> $ua = Mojo::UserAgent->new(...)
>>  ->with_roles('+PromiseClass')
>>  ->promise_roles('+Feature');  # add promise features to UserAgent
>> $ua->get_p(...)->feature(sub{...}); # and they show up on every get_p 
>> call
>>
>> as opposed to having to type 
>>
>> $ua->get_p(...)->with_roles('+Feature')->feature(sub{...})
>>
>> everywhere.
>>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/b93e96eb-557e-460a-ac43-17086d38038e%40googlegroups.com.

[Mojolicious] Re: changing the class of promises returned by UserAgent->get_p / post_p / start_p /...

[Joel Berger]

Reblessing the returned object into the class of your choosing seems like 
an incredibly fragile way of doing that. I'd recommend that you could just 
chain the returned promise with one that you create/return. 

On Tuesday, October 1, 2019 at 8:21:13 AM UTC-5, Roger Crew wrote:
>
> Mojo::UserAgent::Role::PromiseClass now exists on CPAN to play with.
>
> Promises returned by get_p can now be automatically blessed into whatever 
> class you want by just specifying it once on the UserAgent
>
> $ua = Mojo::UserAgent->new(...)
>  ->with_roles('+PromiseClass')
>  ->promise_roles('+Feature');  # add promise features to UserAgent
> $ua->get_p(...)->feature(sub{...}); # and they show up on every get_p call
>
> as opposed to having to type 
>
> $ua->get_p(...)->with_roles('+Feature')->feature(sub{...})
>
> everywhere.
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/1dbae250-02b5-4daa-9e04-6879f753d12e%40googlegroups.com.

[Mojolicious] Re: Workers/Clients Best Practices for good performance

[sri]

Side note: Please stop sending the same message over and over, they all go 
to the
moderation queue. And very soon Google will automatically block you from 
Groups
as a spammer.

--
sebastian

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/63e6140b-9740-4b7f-911b-aa8547aa822f%40googlegroups.com.

[Mojolicious] Re: Workers/Clients Best Practices for good performance

[sri]

>
> I know that this is dependent on your application, but the problem is that 
> an external company has written this for us and they don't want to advice 
> us on the best practice settings. :-(
>

Without knowledge about what exactly the application does it's pretty much 
impossible to help
you. There is no one size fits all best practice for Mojolicious 
performance. Mojolicious is a
web framework that allows for many different paradigms to be used that all 
require different
optimizations.

--
sebastian

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/7559ff79-a70c-47ce-b455-2b84163a073c%40googlegroups.com.

[Mojolicious] Re: Mojolicious - how to intercept the incoming request before controller method handles and renders

[Sachin Dangol]

Thank you very much for the best web framework and for the answer. 🙏👏😊

I have posted the answer to stack overflow. 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/b45ed1bf-72e5-4615-8b3e-7d8e89526f58%40googlegroups.com.

[Mojolicious] Re: Mojolicious - how to intercept the incoming request before controller method handles and renders

[sri]

There is no good solution for this. Best you're going to get is the 
around_action
hook and the information from $c->match->stack.

https://metacpan.org/pod/Mojolicious#around_action
https://metacpan.org/pod/Mojolicious::Routes::Match#stack

--
sebastian

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/85ba5bb9-695e-41a3-9c48-3202774f5210%40googlegroups.com.

[Mojolicious] Re: Mojo::Server::Morbo

[Tekki]

Morbo should listen to http://*:8080, not 127.0.0.1:8080. 127.0.0.1 is 
localhost inside the container.

Am Mittwoch, 14. August 2019 13:10:38 UTC+2 schrieb verenceLola:
>
> ENV MOJO_LISTEN=http://127.0.0.1:8080
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/b9adfdab-4d55-4b09-8ec4-7f511bc2bc56%40googlegroups.com.