Re: Help me fill a gap in my server-side knowledge?

[punch_card_don]

in reply to Help me fill a gap in my server-side knowledge?

I'd be very interested in one of the OP's questions:

How do you start and stop them?

As in, once I start, for example, Dancer, running on my Apache server, does it intercept all http requests? If I have www.siteone.com already running on simple html, and I build www.sitetwo.com running on the same server (separate accounts), is Dancer going to try to interpret http requests to siteone.com? And if so, once Is tart it, if I realize it's making a mess, how do I stop it?

Thanks.

[Cody Fendant]

I don't know that all your questions have been answered but see tobyink's answer. You can start and stop them the way you start and stop Apache, you can use init.d to make sure they start when the machine boots, and your two-site question can probably be answered by "they will use different ports".

[Shuraski]

Yes in Catalyst you can assign different ports to each service you want to run. So you can run multiple websites off the same server.

You start up your service like this:


$ script/yourapp_server.pl -p [port_goes_here]

Catalyst defaults to port 3000.

[Anonymous Monk]

Yes in Catalyst you can assign different ports

In sockets, ports being a feature of socket, they can all do it, dancer, catalyst, anything socket based

[Anonymous Monk]

As in, once I start, for example, Dancer, running on my Apache server, does it intercept all http requests?

Depends on what you did. Only one server can operate per socket/ip combo, if you're running apache, then apache is dispatching requests to, handing off requests to, deferring processing to, dancer ... -- apache is the server, dancer is an application, whether its running via cgi/mod_fcgi/mod_perl/whatever

[dsheroh]

Although Dancer (and most of these other frameworks, including Catalyst and Mojolicious) comes with a mini-webserver bundled into the framework, it's really only intended for development purposes, so that you can debug your app in a persistent environment without having to restart apache every time you modify the code. This HTTP server is not intended to be used in production deployments.

For production purposes, the app would normally be mounted under a specific base URI in apache (or starman or whatever your preferred web server might be) and any requests falling under that URI get passed off by apache to Dancer, just like they would for a bare-bones script running under CGI, FastCGI, PSGI, mod_perl, or whatever. Dancer would not normally be running as a server itself.

(If you really wanted to, I guess you could run Dancer as its own HTTP server on another port and have apache proxy requests to that port, but that would add unnecessary complexity and is neither the standard nor the intended way of doing it.)