Populate CGI from HTTP::Request wo/ using %ENV ?

[renodino]

Does anyone know of a package I might cheat from to create a CGI subclass that gets populated directly from an HTTP::Request without using %ENV ? (I've seen HTTP::Request::AsCGI, but it appears to use %ENV to convey the values).

FWIW: I'm trying to build a CGI adapter for HTTP::Daemon::Threaded, but can't use %ENV, since modifying it in one thread would trash the values in the other active request threads. At present, it appears I have to re-implement big chunks of CGI.pm...and its some rather "interesting" code that I'd prefer to leave alone.

[ikegami]

You could use local *ENV; to remove the magic from %ENV, making it a normal per-thread variable.

[renodino]

Ah, yes! Thnx! Alas, I'll have to copy out the current %ENV into a temp, then copy back into the local'ized version, but that still makes things much easier.

[ikegami]

You can skip the temp:

local *ENV = { %ENV };

Just to be clear, child processes and forks won't see any change made to %ENV while this local is in effect.

[Errto]

To the best of my knowledge neither CGI nor CGI::Simple give you a way to populate header information directly into their respective objects; they just pull it from ENV automatically. Those are the only two CGI-related modules I've personally worked with; there may be others. A quick experiment shows you can localize %ENV though:

#!perl -l
sub foo {
  local %ENV;
  $ENV{foo} = '1';
  print $ENV{foo};
}
foo;
print 'yes' if $ENV{foo} eq '1';

doesn't print "yes"

[ikegami]

local %ENV doesn't remove the magic attached to %ENV, so changes to %ENV still affect every thread, so the race condition remains.

THREAD 1                                THREAD 2
----------------------------------      ------------------------------
+----
{                                   T
local %ENV;                         i
-> Process's R_M remains undef      m
$ENV{REQUEST_METHOD} = 'GET';       e
-> Process's R_M becomes GET        |
                                    |   {
                                    |   local %ENV;
                                    v   -> Process's R_M becomes undef
                                        $ENV{REQUEST_METHOD} = 'PUT';
                                        -> Process's R_M becomes PUT

print($ENV{REQUEST_METHOD});
-> Prints process's R_M (PUT)
}
-> Process's R_M restored to undef

                                        print($ENV{REQUEST_METHOD});
                                        -> Prints process's R_M (undef
+)
                                        }
                                        -> Process's R_M restored to u
+ndef

That's why I suggested local *ENV instead. Then modifying %ENV doesn't change the processes environment.

Update: Added illustration of two race conditions.

[CountZero]

RFC 3875 says that the meta-variables (which include the QUERY_STRING) are passed to the script in identically named environment variables. These are accessed by the C library routine getenv() or variable environ. (item 7.2 of RFC3875).

As thus the environment variables are populated outside of your script by the server, you will have to find a way to capture these variables in a local data structure before messing around with them.

[ikegami]

There's no relation between CGI (the protocol) using the environment and the need to create a CGI object from a HTTP::Request object.

For example, CGI (the module) can already create an object from an Apache::Request object without touching the environment.