> > > > This might help, in you httpd.conf file set this
> > >>
> > >>   PerlSendHeader Off
> > >>
> > >> Tor.
> > >>
> > >That messes up all the standard responses. I have a work around now
> > >-- naturally it came to me moments after I posted
> > >
> > >don't know if this is "correct" so to speak, but it works fine.
> > >
> > >  open(F,$file) || return 404;
> > >  $r->send_fd(F);
> > >  close F;
> > >
> > >  pipe(R,W);
> > 
> > 
> > >  print W "some dynamically generated text\n";
> > >  close W;
> > >  $r->send_fd(R);
> > >  close R;
> > 
> > 
> > Won't this block after about 2048 bytes (on linux)?
> > 
> 
> Yep, you are right... bummer! there must be a better way. Certainly
> don't want to fork in Apache::mod_perl. Perhaps embedding the pipe
> process in a loop and breaking the strings into blocks < 2048 would
> be more efficient. If the darn headers could just be turned off it
> would be a piece of cake. Like
> 
> $r->send_cgi_header()
>            Take action on certain headers including Status:,
>            Location: and Content-type: just as mod_cgi does, then
>            calls $r->send_http_header().  Example of use:
> 
> but without the call to $r-send_http_header()
> 

what is the system overhead of something like this vs a fork

sub pipe_write {
  my ($tp) = @_;
  my $len = length($$tp);
  my $off = 0;
  while (1) { 
    my $ln = ($len-$off > 1024) ? 1024 : $len-$off;
    pipe(R,W);
    print W substr($$tp,$off,$ln);
    close W;
  $r->send_fd(R);
  close R;
    $off += $ln;
    last if $off >= $len;
  }
}  
[EMAIL PROTECTED]

Reply via email to