"Print can't be called before the response phase"

[Dysangel PS4]

Hi guys, I've tried creating apps with both Catalyst and Dancer and serving them through apache - both have had this error

[perl:error] [pid 32310:tid 140700242867968] [client ::1:33130] mpxs_Apache2__RequestRec_print: $r->print can't be called before the response phase at /usr/local/share/perl/5.18.2/Plack/Handler/Apache2.pm line 183.\n

I've only found one other person with a similar error message on Google. Has anyone seen it before? I have Apache 2.4.7, and Plack 1.0030-1. The applications ran fine on the built in Catalyst and Dancer servers

Any help would be appreciated, though maybe I should try a fresh Perl directory, or even a fresh distro..

[Aj]

I'm a n00b, so not pro enough to know how to trouble shoot that specific error for you. What I can tell you is how I got Plack running on my Apache2 server, and deploying my Catalyst app. Am away from home right now typing on an ipod, so I'll share what I did when I get back home and on my computer - late tonight or tomorrow morning.

Sent from my iPod

--

---
You received this message because you are subscribed to the Google Groups "psgi-plack" group.
To unsubscribe from this group and stop receiving emails from it, send an email to psgi-plack+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dan Axtell]

The module Apache2::RequestRec is part of mod_perl, which suggests you are serving your script from a directory that executes Perl code through mod_perl.  If you are writing a Plack app, you probably want to serve it via a Plack server (e.g. starman), not Apache + mod_perl.  You can then use Apache as a reverse proxy to point to that server, with something like:

<Location /myapp>
    ProxyPass http://myserver.com:3000
    ProxyPassReverse http://myserver.com:3000
</Location>

assuming your Plack server is running on port 3000

[Alistair Stewart]

I was under the impression that plack was more of a "glue layer" than a server? I'd be happy executing the app via either mod_perl or fast_cgi and Apache. Proxying could perhaps work, but I'm not sure if it will allow me to do authenticated API requests via ajax since it's still technically on a different port and may qualify for cross site scripting restrictions?

I'm considering just writing a new login and authentication component specifically for the app, since it isn't strictly necessary that people log in through the existing interface (that is running as standard CGI scripts, rather than on an application server.)

--

---
You received this message because you are subscribed to a topic in the Google Groups "psgi-plack" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/psgi-plack/iFvqT9zwOmo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to psgi-plack+...@googlegroups.com.

[Ævar Arnfjörð Bjarmason]

On Tue, Nov 17, 2015 at 5:35 PM, Alistair Stewart <dysan...@gmail.com> wrote:
> I was under the impression that plack was more of a "glue layer" than a
> server?

You're correct. There's no reason not to execute Plack apps directly
under mod_perl, that's the recommended way of doing it if you're using
the Apache webserver.

You can also do without Apache (in which case I'd recommend uWSGI),
but that's another question entirely.

[Alistair Stewart]

the reason I want to do it with Apache is so that it is running on the same port as my existing applications, with no cross site scripting restrictions when for example trying to run AJAX calls or retrieve cookies.

I'm using a setup like this

<Location /api/>

 SetHandler perl-script

 PerlResponseHandler Plack::Handler::Apache2

 PerlSetVar psgi_app /home/ali/www/dancer-apps/MyAPI/bin/app.pl

 Require all granted

</Location>

<Directory "/home/ali/www/dancer-apps/MyAPI">

                  Require all granted

</Directory>

app.pl runs correctly with Plackup, so I know it is valid as a psgi file..

Looks like maybe I just need to try a fresh distro, my CPAN setup has probably taken a lot of abuse over the last while with me trying out things like cpanm, cpanp and installing various frameworks.

[Ævar Arnfjörð Bjarmason]

On Tue, Nov 17, 2015 at 6:05 PM, Alistair Stewart <dysan...@gmail.com> wrote:
> the reason I want to do it with Apache is so that it is running on the same
> port as my existing applications, with no cross site scripting restrictions
> when for example trying to run AJAX calls or retrieve cookies.

There's many reasons to run under mod_perl, but this is not one of
them. If you use the <Location> method to forward a to a local port as
seen earlier in this thread that's invisible to the users of your
site, they'll just see it on one port, and it has no impact on AJAX or
cookies or whatever. It's purely an internal webserver level of
indirection.

[Alistair Stewart]

okay, will give that a go. Thanks for your help

[Dan Axtell]

I was under the impression from the Apache docs that running a monolithic Apache instance that serves your static content as well as mod_perl or other apps was not recommended.  They recommended a light-weight front end server for static content, with reverse proxying to a mod_perl enabled Apache for dynamic content.  You could also use Nginx for the front, and Plack servers for the back end, same basic idea.   Some time ago I did some load testing that showed a noticeable improvement when I did nginx + Apache/mod_perl vs. monolithic Apache.

Also, I was under the impression that until recently, Apache 2.4 was incompatible with mod_perl because of API changes.  I think mod_perl 2.0.9 came out this summer which finally addressed this, but I still use Apache 2.2 for building mod_perl legacy apps.  If you are not using any Apache API calls it seems simpler just to use a dedicated Plack server.

[Alistair Stewart]

Maybe I'm misunderstanding what you regard as static vs dynamic, but I've been using Apache with mod_perl to serve up my content for about 8 years now, the only "static" content is the front page redirecting to the login page, and a few javascript and css files. I thought it would be better to run any applications through mod_perl too, especially if it comes to running several applications to reduce overhead. But I guess it's acceptable to use a proxy since I could just build future applications out as separate packages/modules/subtrees of the Dancer instance, so as to not create even more unnecessary overhead.

(I was brought up in the days where CPUs were measured in in Mhz and RAM in KB, rather than Ghz and GB, so I tend to try and make efficient use of memory where possible!).

--

[Ævar Arnfjörð Bjarmason]

On Tue, Nov 17, 2015 at 7:29 PM, Dan Axtell <dax...@linescale.com> wrote:
> I was under the impression from the Apache docs that running a monolithic
> Apache instance that serves your static content as well as mod_perl or other
> apps was not recommended.

It's generally not recommended because it's a huge hammer if you're
only proxying to a backend app that does all the logic.

But there's nothing wrong with it. Apache's a fine webserver.

> Some time ago I did some load testing
> that showed a noticeable improvement when I did nginx + Apache/mod_perl vs.
> monolithic Apache.

Interesting. I did the migration of all the Booking.com webserving
systems from Apache+mod_perl to nginx+uWSGI. There were a lot of
reasons we did that, but performance was not one of them.

We saw no performance improvement by migrating, and we're measuring
performance down to the millisecond-level.

I'd say the most likely cause of performance differences is that you
were either doing something really high performance <1ms apps, or
misconfiguration, most likely you ran out of Apache workers, which'll
butcher your performance since now you have a backlog.

> Also, I was under the impression that until recently, Apache 2.4 was
> incompatible with mod_perl because of API changes. I think mod_perl 2.0.9
> came out this summer which finally addressed this, but I still use Apache
> 2.2 for building mod_perl legacy apps. If you are not using any Apache API
> calls it seems simpler just to use a dedicated Plack server.

Yeah I don't know about that, I stopped using it in 2.2 IIRC. This was
February 2014-ish.

I'd totally recommend Apache+mod_perl for Plack, actually more so than
a lot of the homegrown CPAN-servers that don't have some really handy
stuff like async cleanup handlers and advanced worker configuration
etc.

uWSGI gives you a few more bells & wistles, but most won't care about
them, and if you have an existing Apache setup you're happy with just
use Apache+mod_perl for Plack.