10 articles CGI & Passenger

CGI, FastCGI, Passenger, and WSGI topics

File uploads in a Passenger-backed application fail

Overview A file upload initiated in an application written in Ruby, Node, or Python launched through Passenger will fail to upload. Thus far, the confirmed failure occurs in RefineryCMS with a generic undefined route message following upload. Cause It is a conflict between upload screening and Passenger, but the underlying cause is not clearly understood. Upload…

Passenger applications do not inherit htaccess rules

Overview .htaccess files are used to control behaviors of applications by overriding global server configuration. Any Passenger-based application, which includes Node, Python, and Ruby, will stop processing rules beyond the document root, often noted by convention as public/. Cause Passenger is managed by a separate facility that immediately takes control of the request once Apache detects that the…

Passenger-backed apps perform unscripted optimizations

Overview Applications launched through Passenger, which includes Node, Python, Ruby, and Meteor, may receive optimizations to JavaScript, CSS, and image assets which are not explicitly defined within application logic. Take for example a small external JavaScript asset that may become inlined after the first request: <head> <script src=”//test.js””></script> <!– rest of head –> becomes: <head> <script>//<![CDATA[ console.log(“Hello 212a.”);…

Reclaiming process slots

Overview When trying to redeploy a Passenger process, Passenger may refuse deployment, because you have maxed out on available process slots. Terminating the process will free a connection slot and permit Passenger to launch a new process. Symptoms Upon launching an application after restarting, the app will hang and log an error similar to: […

Viewing launcher errors

Overview Applications launched by Passenger on v6+ platforms may emit output on stdout or stderr channels. Any output emitted is logged to an aggregate log called passenger.log in /var/log. Important: since these logs are combined among all accounts using Passenger, never output anything confidential to stdout or stderr when launched using Passenger. Once an application is up and…

Passenger application layout

Overview All Passenger applications require a compatible filesystem layout to launch and manage a Passenger-backed application. A layout consists of 4 features: Startup file Passenger loads this file to start the application Startup file names differ by application type (Python, Ruby, Node.js, Meteor) Document root folder called public/ all static content goes here (images, JavaScript, CSS) Apache configuration…

Passenger-supported apps

Overview Passenger supports Python, Ruby, Node.js, Meteor as well as any application built using this technology. In creating several of the articles in this knowledgebase, we also created a very basic application to guide during writing. These applications are up and running under a sandbox domain and represent just a sliver of the applications that you…

Disabling Passenger built-in error handler

Overview Passenger provides a user-friendly, on-screen error handler to assist debugging a Python/Ruby/Node.js application. During production, however, this may result in unnecessary and possibly dangerous information disclosure. You can turn off Passenger’s built-in logger and use Apache’s generic error handler by adding the following line to your .htaccess file located within the public/ folder of your app:…

Restarting Passenger processes

Overview An application launched by Passenger may be restarted by creating a file in tmp/ (NB: not /tmp) within the application root directory, usually one level down from public/. Create a file under tmp/ named restart.txt to restart the application once. A restart will happen within 2 minutes. To restart an application on every request, very useful for…