Re: Resetting STDIN after r-read

[Doug MacEachern]

On Fri, 8 Jun 2001, Rodney Broom wrote:

 OK, here's what the solution was. According to Doug in a posting that I
 found in an archive search, mod_perl's STDIN is really just a Perl glob, and
 not a file handle. So instead of reading from it (and thereby emptying the
 file handle named STDIN so that CGI and other things can't get this data),
 now I simply assign from it:

*{STDIN} is a Perl glob.  STDIN is a Perl IO 'handle', which is normally
used to access C's stdio stdin FILE pointer.  under mod_perl, the STDIN
handle is tied to the  Apache request_rec, rather than stdio stdin. 

i never said anything about using the $STDIN scalar.  $STDIN is just like
any other global variable, except that it aliased to $main::STDIN no
matter what package you reference it from.  $STDIN != STDIN
 
   if ($first_pass) {
 print TEMP_FILE, $STDIN;

this will only work if you first read(STDIN, $STDIN, $content_length);
otherwise, you're getting the global value from the previous request,
since $STDIN is not reset.  and again is no different from using a global
such as $Foo::PostData, other than the aliasing mentioned above.

RE: Resetting STDIN after r-read

[Geoffrey Young]

 -Original Message-
 From: rodney Broom [mailto:[EMAIL PROTECTED]]
 Sent: Friday, June 08, 2001 3:25 PM
 To: [EMAIL PROTECTED]
 Subject: Resetting STDIN after r-read
 
 
 
 I've got this module that needs to redirect sometimes. In 
 doing this, the
 next request misses any POST data. I was playing with saving 
 the data to
 disk and then reloading it on the next request like this:
 
   if ($first_pass) {
 $r-read($data, ...);
 print TEMP_FILE, $data;
 return REDIRECT;
   }
   else {
 open(STDIN, $temp_file);
 $r-subprocess_env(CONTENT_LENGTH = -s $temp_file);
   }
 
 The idea here is that normal packages like CGI won't have to 
 know what's up
 and my programmers won't have to work around this. But, when 
 I get to the
 script, STDIN is empty. Ay thouhts about how to handle this?

of course
http://perl.apache.org/guide/snippets.html#Redirecting_POST_Requests

--Geoff
 

Re: Resetting STDIN after r-read

[rodney Broom]

From: Geoffrey Young [EMAIL PROTECTED]
 of course
 http://perl.apache.org/guide/snippets.html#Redirecting_POST_Requests


Heh, close. I'm using an external redirect because my purpose is to reset
the address in the client's Location bar. So an internal redirect won't
give me the desired effect.

---
Rodney Broom
Programmer: Desert.Net

Re: Resetting STDIN after r-read

[Rodney Broom]

From: rodney Broom [EMAIL PROTECTED]
 I've got this module that needs to redirect sometimes. In doing this, the
 next request misses any POST data. I was playing with saving the data to
 disk and then reloading it on the next request like this:

   if ($first_pass) {
 $r-read($data, ...);
 print TEMP_FILE, $data;
 return REDIRECT;
   }
   else {
 open(STDIN, $temp_file);
 $r-subprocess_env(CONTENT_LENGTH = -s $temp_file);
   }

 The idea here is that normal packages like CGI won't have to know what's
up
 and my programmers won't have to work around this. But, when I get to the
 script, STDIN is empty. Ay thouhts about how to handle this?


OK, here's what the solution was. According to Doug in a posting that I
found in an archive search, mod_perl's STDIN is really just a Perl glob, and
not a file handle. So instead of reading from it (and thereby emptying the
file handle named STDIN so that CGI and other things can't get this data),
now I simply assign from it:




  if ($first_pass) {
print TEMP_FILE, $STDIN;
return REDIRECT;
  }
  else {
read(TEMP_FILE, my $buf, (-s $temp_file))
$STDIN = $buf;

$r-subprocess_env(CONTENT_LENGTH = -s $temp_file);
  }


I'm obviously doing a lot more testing than that, but this is the jist.

---
Rodney Broom
Programmer: Desert.Net