Working with Node.js via Passenger 5.0.15 on Apache, I am seeking a method to retrieve per-HTTP-request environment variables inside a Node.js http.IncomingMessage
object or any alternative.
An example of what I mean by a per-request environment variable, would be one set by Apache mod_rewrite. This is not a real-world example, and I'm aware any path-related details could be easily retrieved in the Node app. Apache modules may set environment variables for the request1:
# Apache sets an environment variable for this HTTP request
RewriteRule path/([^/]+) - [E=pathvar:$1]
In Ruby's Rack, the input environment is passed to request.env
. In PHP it is passed into $_SERVER["pathvar"]
.
Passenger does make an attempt to set them, but does so somewhat incorrectly by setting them for the entire Node.js process, unassociated with the HTTP request they were set for. This may get fixed or changed in Passenger but doesn't help me find the per-request variables.
console.log(process.env.pathvar);
// Has the value, but has been set for the entire Node.js process
// Subsequent requests retain the SAME value due to Passenger's current implementation
// Environment variables aren't present
// in the http server request object
var s = http.createServer(function(request, response) {
// undefined, which makes sense because they're not headers
console.log(request.headers.pathvar);
});
- Do per-HTTP-request environment variables even make sense as a concept in Node.js, so that Passenger could be setting them correctly?
- If they do, are the supported by the
http
module, and how do I retrieve them? - If not by the
http
module, is there a middleware which supports them? (I find no mention of environment variables among Connect's middleware collection)
1The true use case we are trying to solve is retrieval of Shibboleth user authentication attributes, set by Apache mod_shib as environment variables similarly to how mod_rewrite would set them before invoking the Node.js application. Indeed this is the reason for involving Apache+Passenger in the first place. There is an available but undesirable workaround in Shibboleth configuration to send user attributes as HTTP headers instead. There are alternative SAML modules for Node.js as well, but current infrastructure already depends on Apache mod_shib.