cgiwrap-users

RE: [cgiwrap-users] cgiwrap and cvsweb.cgi

[Jeff B. <soi...@sg...>]

Nathan,

where did you put that script portion?

Jeff

> -----Original Message-----
> From: cgi...@li...
> [mailto:cgi...@li...]On Behalf Of Nathan
> Neulinger
> Sent: Friday, May 17, 2002 5:43 AM
> To: jeff
> Cc: cgi...@li...
> Subject: Re: [cgiwrap-users] cgiwrap and cvsweb.cgi
>
>
> I'm pretty sure I had cvsweb working with cgiwrap without any trouble,
> but have since switched to viewcvs, which I think works nicer.
>
> The one thing with it that I had to do was wrap it
>
> 	if ( $ENV{PATH_INFO} eq "" )
> 	{
> 	        $ENV{PATH_INFO} = "/";
> 	        $ENV{SCRIPT_NAME} =
> "/auth-cgi-bin/cgiwrap/viewcvs/viewcvs";
> 	}
>
> 	exec "/umr/s/viewcvs/install/cgi/viewcvs.cgi";
>
>
> On Fri, 2002-05-17 at 04:48, jeff wrote:
> > I'm trying to install cvsweb.cgi on my webserver on a wrapped
> users account.
> > If I call the script non-wrapped it at least brings up the front page.
> > However, if I call it wrapped then it seems to go into some
> endless loop and
> > never brings up the page.
> >
> > Is there an incompatibility with cgiwrap and cvsweb.cgi?
> >
> > Or do I have a setting wrong?
> >
> > Since it seems to load unwrapped I'm not sure what could be wrong.
> >
> > thanks,
> >
> > Jeff
> >
> >
> > _______________________________________________________________
> >
> > Have big pipes? SourceForge.net is looking for download
> mirrors. We supply
> > the hardware. You get the recognition. Email Us:
> ban...@so...
> > _______________________________________________
> > cgiwrap-users mailing list
> > cgi...@li...
> > https://lists.sourceforge.net/lists/listinfo/cgiwrap-users
> --
>
>
> ------------------------------------------------------------
> Nathan Neulinger                       EMail:  nn...@um...
> University of Missouri - Rolla         Phone: (573) 341-4841
> Computing Services                       Fax: (573) 341-4216
>
>
> _______________________________________________________________
>
> Have big pipes? SourceForge.net is looking for download mirrors. We supply
> the hardware. You get the recognition. Email Us: ban...@so...
> _______________________________________________
> cgiwrap-users mailing list
> cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgiwrap-users
>

Re: [cgiwrap-users] cgiwrap and cvsweb.cgi

[Nathan N. <nn...@um...>]

I'm pretty sure I had cvsweb working with cgiwrap without any trouble,
but have since switched to viewcvs, which I think works nicer.

The one thing with it that I had to do was wrap it

	if ( $ENV{PATH_INFO} eq "" )
	{
	        $ENV{PATH_INFO} = "/";
	        $ENV{SCRIPT_NAME} = 			"/auth-cgi-bin/cgiwrap/viewcvs/viewcvs";
	}

	exec "/umr/s/viewcvs/install/cgi/viewcvs.cgi";


On Fri, 2002-05-17 at 04:48, jeff wrote:
> I'm trying to install cvsweb.cgi on my webserver on a wrapped users account.
> If I call the script non-wrapped it at least brings up the front page.
> However, if I call it wrapped then it seems to go into some endless loop and
> never brings up the page.
> 
> Is there an incompatibility with cgiwrap and cvsweb.cgi?
> 
> Or do I have a setting wrong?
> 
> Since it seems to load unwrapped I'm not sure what could be wrong.
> 
> thanks,
> 
> Jeff
> 
> 
> _______________________________________________________________
> 
> Have big pipes? SourceForge.net is looking for download mirrors. We supply
> the hardware. You get the recognition. Email Us: ban...@so...
> _______________________________________________
> cgiwrap-users mailing list
> cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgiwrap-users
-- 


------------------------------------------------------------
Nathan Neulinger                       EMail:  nn...@um...
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216

[cgiwrap-users] cgiwrap and cvsweb.cgi

[jeff <je...@cy...>]

I'm trying to install cvsweb.cgi on my webserver on a wrapped users account.
If I call the script non-wrapped it at least brings up the front page.
However, if I call it wrapped then it seems to go into some endless loop and
never brings up the page.

Is there an incompatibility with cgiwrap and cvsweb.cgi?

Or do I have a setting wrong?

Since it seems to load unwrapped I'm not sure what could be wrong.

thanks,

Jeff

RE: [cgiwrap-users] problem with cgiwrap and dbi

[Neulinger, N. <nn...@um...>]

Run your script via cgiwrapd, it will dump errors so that you can see
them on the browser.

-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nn...@um...
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216


> -----Original Message-----
> From: dean browett [mailto:de...@pu...]=20
> Sent: Wednesday, May 01, 2002 11:14 AM
> To: cgi...@li...
> Subject: [cgiwrap-users] problem with cgiwrap and dbi
>=20
>=20
> Hi,
>=20
> Whilst running a cgi script I get the following error:
>=20
> [Wed May  1 16:40:12 2002] [error] [client 193.237.21.207]=20
> malformed header=20
> from
>   script. Bad header=3DCan't call method "prepare" on:=20
> /usr/cgiwrap/cgiwrap.
>=20
> What is REALLY annoying is that the error message is clipped.
>=20
> I am using a package that includes 'use DBI;' and this is=20
> where the prepare=20
> method is located (within a function). Part of the package=20
> code is as follows:
>=20
>      use strict;
>      use Push qw/$CFG/;
>      use DBI;
>=20
> sub _usr_details {
>=20
>      my ($db, $server, $dbusr, $dbpw, $query) =3D @_;
>      my $dbh;
>=20
>      eval {
>          $dbh =3D DBI->connect("DBI:mysql:$db:$server",$dbusr,$dbpw);
>      };
>=20
>      if ( $@ ) {
>      	warn "_usr_details: $@: ";
>      	return undef ;
>      }
>=20
>      my $sqlcmd =3D $dbh->prepare($query);
>      my $row_count =3D $sqlcmd->execute;
>=20
>      if ($row_count > 0) {
>          my $userdata =3D $sqlcmd->fetchrow_hashref;
>          $sqlcmd->finish;
>          $dbh->disconnect;
>=20
>          return $userdata;
>      }
>=20
>      return undef;
> }
>=20
> Can anyone tell me how to get around this problem?
>=20
> Also, how can I get cgiwrap to dump the ENTIRE error message?=20
> Is this a=20
> program or system software config issue?
>=20
> TIA
>=20
> Dean
>=20
>=20
>=20

[cgiwrap-users] problem with cgiwrap and dbi

[dean b. <de...@pu...>]

Hi,

Whilst running a cgi script I get the following error:

[Wed May  1 16:40:12 2002] [error] [client 193.237.21.207] malformed header 
from
  script. Bad header=Can't call method "prepare" on: /usr/cgiwrap/cgiwrap.

What is REALLY annoying is that the error message is clipped.

I am using a package that includes 'use DBI;' and this is where the prepare 
method is located (within a function). Part of the package code is as follows:

     use strict;
     use Push qw/$CFG/;
     use DBI;

sub _usr_details {

     my ($db, $server, $dbusr, $dbpw, $query) = @_;
     my $dbh;

     eval {
         $dbh = DBI->connect("DBI:mysql:$db:$server",$dbusr,$dbpw);
     };

     if ( $@ ) {
     	warn "_usr_details: $@: ";
     	return undef ;
     }

     my $sqlcmd = $dbh->prepare($query);
     my $row_count = $sqlcmd->execute;

     if ($row_count > 0) {
         my $userdata = $sqlcmd->fetchrow_hashref;
         $sqlcmd->finish;
         $dbh->disconnect;

         return $userdata;
     }

     return undef;
}

Can anyone tell me how to get around this problem?

Also, how can I get cgiwrap to dump the ENTIRE error message? Is this a 
program or system software config issue?

TIA

Dean

Re[2]: [cgiwrap-users] php-cgiwrap won't process authentication headers...

[Daniel L. <da...@lo...>]

hi,

Sorry Nathan, I misunderstood you.

Of course you are completely right - this headers are useless as you
won't get access to the password set by the HTTP authorization
mechanism.

You'd have to look out for Apache-based authentication mechanisms.
There are plenty of mod_auth_* for all your needs. Once a user has
logged in successfuly you can completely rely on the value
$_SERVER['REMOTE_USER'];

-daniel

----- Original Message -----
From   : Nathan Neulinger [mailto:nn...@um...]
Sent   : Mittwoch, 1. Mai 2002
Subject: [cgiwrap-users] php-cgiwrap won't process authentication headers...

> Problem is - even with that header, you are not going to be able to do
> anything, since the HTTP_AUTHORIZATION header is not provided to CGI's
> since it is such a gaping security hole on multi-user servers.

> Any malicious user on that server can easily trap that passwords for any
> other authenticated service on that server, simply by tricking someone
> into going to a different web page on that server.

> -- Nathan

RE: Re[2]: [cgiwrap-users] php-cgiwrap won't process authentication headers...

[Neulinger, N. <nn...@um...>]

That's true... forgot that most of these are vhosting.=20

-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nn...@um...
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216


> -----Original Message-----
> From: Daniel Lorch [mailto:da...@lo...]=20
> Sent: Wednesday, May 01, 2002 8:29 AM
> To: Neulinger, Nathan
> Cc: jeff bert; cgi...@li...
> Subject: Re[2]: [cgiwrap-users] php-cgiwrap won't process=20
> authentication headers...
>=20
>=20
> Hi,
>=20
> this is only a security problem if all virtual users are on the
> *same domain*, such as
>=20
>   hoster.com/~foo/
>   hoster.com/~bar/
>  =20
> If user "bar" succeds to hijack users logged in to "foo" he will be
> able to get user and password from that user.
>=20
> BUT this is only an issue with PHP running as module, as PHP-CGI does
> *not* set $PHP_AUTH_PW.
>=20
>   "The HTTP Authentication hooks in PHP are only available when it is
>   running as an Apache module and is hence not available in the CGI
>   version."
>   http://www.php.net/manual/en/features.http-auth.php
>=20
> You will only be able to find out what user has logged in by looking
> at $_SERVER['REMOTE_USER'];
>  =20
> -daniel
>=20
> ----- Original Message -----
> From   : Nathan Neulinger [mailto:nn...@um...]
> Sent   : Mittwoch, 1. Mai 2002
> Subject: [cgiwrap-users] php-cgiwrap won't process=20
> authentication headers...
>=20
> > Problem is - even with that header, you are not going to be=20
> able to do
> > anything, since the HTTP_AUTHORIZATION header is not=20
> provided to CGI's
> > since it is such a gaping security hole on multi-user servers.
>=20
> > Any malicious user on that server can easily trap that=20
> passwords for any
> > other authenticated service on that server, simply by=20
> tricking someone
> > into going to a different web page on that server.
>=20
> > -- Nathan
>=20
> > Daniel Lorch wrote:
> >>=20
> >> Hi,
> >>=20
> >> your php-cgiwrap is alright. This is a limitation of PHP running in
> >> CGI-mode. Use 'Status:' to make it work:
> >>=20
> >>   $realm =3D "Restricted";
> >>   header("WWW-authenticate: basic realm=3D\"$realm\"") ;
> >>   header("Status: 401 Unauthorized");
> >>=20
> >> Daniel Lorch http://daniel.lorch.cc/
> >>=20
> >> ----- Original Message -----
> >> From   : jeff bert [mailto:soi...@sg...]
> >> Sent   : Mittwoch, 1. Mai 2002
> >> Subject: [cgiwrap-users] php-cgiwrap won't process=20
> authentication headers...
> >>=20
> >> > my install of php-cgiwrap won't process authentication=20
> headers... called
> >> > like this:
> >>=20
> >> > $realm =3D "Restricted";
> >> > header("WWW-authenticate: basic realm=3D\"$realm\"") ;
> >> > header("HTTP/1.0 401 Unauthorized") ;
> >>=20
> >> > Do I have a funky setup or is this a limitation of php-cgiwrap?
> >>=20
> >> > The error log shows:
> >>=20
> >> > [Tue Apr 30 18:31:43 2002] [error] [client:xx.xx.xx.xx]=20
> malformed header
> >> > from script. Bad header=3DHTTP/1.0 401 Unauthorized:
> >> > /var/www/cgi-sys/php-cgiwrap
> >>=20
> >> > Thanks,
> >>=20
> >> > Jeff
>=20
>=20
>=20

Re[2]: [cgiwrap-users] php-cgiwrap won't process authentication headers...

[Daniel L. <da...@lo...>]

Hi,

this is only a security problem if all virtual users are on the
*same domain*, such as

  hoster.com/~foo/
  hoster.com/~bar/
  
If user "bar" succeds to hijack users logged in to "foo" he will be
able to get user and password from that user.

BUT this is only an issue with PHP running as module, as PHP-CGI does
*not* set $PHP_AUTH_PW.

  "The HTTP Authentication hooks in PHP are only available when it is
  running as an Apache module and is hence not available in the CGI
  version."
  http://www.php.net/manual/en/features.http-auth.php

You will only be able to find out what user has logged in by looking
at $_SERVER['REMOTE_USER'];
  
-daniel

----- Original Message -----
From   : Nathan Neulinger [mailto:nn...@um...]
Sent   : Mittwoch, 1. Mai 2002
Subject: [cgiwrap-users] php-cgiwrap won't process authentication headers...

> Problem is - even with that header, you are not going to be able to do
> anything, since the HTTP_AUTHORIZATION header is not provided to CGI's
> since it is such a gaping security hole on multi-user servers.

> Any malicious user on that server can easily trap that passwords for any
> other authenticated service on that server, simply by tricking someone
> into going to a different web page on that server.

> -- Nathan

> Daniel Lorch wrote:
>> 
>> Hi,
>> 
>> your php-cgiwrap is alright. This is a limitation of PHP running in
>> CGI-mode. Use 'Status:' to make it work:
>> 
>>   $realm = "Restricted";
>>   header("WWW-authenticate: basic realm=\"$realm\"") ;
>>   header("Status: 401 Unauthorized");
>> 
>> Daniel Lorch http://daniel.lorch.cc/
>> 
>> ----- Original Message -----
>> From   : jeff bert [mailto:soi...@sg...]
>> Sent   : Mittwoch, 1. Mai 2002
>> Subject: [cgiwrap-users] php-cgiwrap won't process authentication headers...
>> 
>> > my install of php-cgiwrap won't process authentication headers... called
>> > like this:
>> 
>> > $realm = "Restricted";
>> > header("WWW-authenticate: basic realm=\"$realm\"") ;
>> > header("HTTP/1.0 401 Unauthorized") ;
>> 
>> > Do I have a funky setup or is this a limitation of php-cgiwrap?
>> 
>> > The error log shows:
>> 
>> > [Tue Apr 30 18:31:43 2002] [error] [client:xx.xx.xx.xx] malformed header
>> > from script. Bad header=HTTP/1.0 401 Unauthorized:
>> > /var/www/cgi-sys/php-cgiwrap
>> 
>> > Thanks,
>> 
>> > Jeff

Re[2]: [cgiwrap-users] real hosting and cgiwrap

[Daniel L. <da...@lo...>]

Hi,

I'd like to make a suggestion to you. As you appear to know all
cgiwrap-patches very well, why not create a short summary (webpage)
with links to all these patches? You could call it "Unapproved
cgiwrap patches".

If an increasing number of people test these patches, there could be
more feedback about stability and security, which would help the
cgiwrap developers to evaluate whether they should be included
with cgiwrap or not.

You are frustrated because cgiwrap didn't work out-of-the-box as you
expected and now trying to find people you can blame. cgiwrap is
rock-solid, portable and was written by experts. It might be
cumbersome to set up, but it provides a high level of security and
basically you are still using it, aren't you? Quit ranting and do
something productive.

-daniel

----- Original Message -----
From   : Marten Lehmann [mailto:le...@va...]
Sent   : Mittwoch, 1. Mai 2002
Subject: [cgiwrap-users] real hosting and cgiwrap

>> why should this be impossible? I'm doing myself mass-hosting pretty well
>> with a combined cgiwrap and php-cgiwrap.
>> 
>> You could create templates for your virtualhosts:
>> 
>>   <VirtualHost *>
>>     ServerAdmin webmaster@%%domain%%
>>     ServerName %%domain%%
>>     ServerAlias *.%%domain%%
>> 
>>     [..]
>>   </VirtualHost>

> I'm talking about dynamically configured mass-hosting. I don't want to 
> generate a httpd.conf with 1000 VirtualHost entries. A user can easily 
> add a domain or subdomain. I can't give apache a -HUP each time a tiny 
> bit changes.

>> I still don't understand your problem. If there WOULD be another
>> perfect solution, why don't you just use it and stop ranting?

> Once for all: My solution of cgiwrap with mod_cgiwrap and mod_phpcgiwrap 
> _is_ perfect. I'm using this for several months. But the way to use it 
> and get everything started was to hard and I don't get why you don't 
> want to see that?! What you call ranting is just some words from a 
> cgiwrap user, that is annoyed because cgiwrap as it comes from the 
> official website is unusable and you're not willing to accept this fact. 
> Usually software improves, but in this point I can't see any improvement 
> in the recent cgiwrap-release.

> Please explain the need of several different projects like cgiwrap, a 
> php-cgiwrap patch and mod_cgiwrap/mod_phpcgiwrap! Please compare this 
> projects with the core apache, and it's modules or linux and it's device 
> drivers. Do you think they had prevailed if an apache-user had to find a 
> patch so he can use e.g. simple logging? Or Linux, if you had to find a 
> kernel-patch for each hardware-component, no matter that the hardware is 
> used by thousands of other users? Of course not. If you don't put 
> everything together so everyone can use it easliy, without everyone 
> having to go into detail to find appropriate patches, noone likes to use 
> it. Why has everyone to put the parts together again? Sorry, I can't get it.

> Regards
> Marten

Re: [cgiwrap-users] php-cgiwrap won't process authentication headers...

[Nathan N. <nn...@um...>]

Problem is - even with that header, you are not going to be able to do
anything, since the HTTP_AUTHORIZATION header is not provided to CGI's
since it is such a gaping security hole on multi-user servers.

Any malicious user on that server can easily trap that passwords for any
other authenticated service on that server, simply by tricking someone
into going to a different web page on that server.

-- Nathan

Daniel Lorch wrote:
> 
> Hi,
> 
> your php-cgiwrap is alright. This is a limitation of PHP running in
> CGI-mode. Use 'Status:' to make it work:
> 
>   $realm = "Restricted";
>   header("WWW-authenticate: basic realm=\"$realm\"") ;
>   header("Status: 401 Unauthorized");
> 
> Daniel Lorch http://daniel.lorch.cc/
> 
> ----- Original Message -----
> From   : jeff bert [mailto:soi...@sg...]
> Sent   : Mittwoch, 1. Mai 2002
> Subject: [cgiwrap-users] php-cgiwrap won't process authentication headers...
> 
> > my install of php-cgiwrap won't process authentication headers... called
> > like this:
> 
> > $realm = "Restricted";
> > header("WWW-authenticate: basic realm=\"$realm\"") ;
> > header("HTTP/1.0 401 Unauthorized") ;
> 
> > Do I have a funky setup or is this a limitation of php-cgiwrap?
> 
> > The error log shows:
> 
> > [Tue Apr 30 18:31:43 2002] [error] [client:xx.xx.xx.xx] malformed header
> > from script. Bad header=HTTP/1.0 401 Unauthorized:
> > /var/www/cgi-sys/php-cgiwrap
> 
> > Thanks,
> 
> > Jeff

-- 


------------------------------------------------------------
Nathan Neulinger                       EMail:  nn...@um...
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216

Re: [cgiwrap-users] php-cgiwrap won't process authentication headers...

[Daniel L. <da...@lo...>]

Hi,

your php-cgiwrap is alright. This is a limitation of PHP running in
CGI-mode. Use 'Status:' to make it work:

  $realm = "Restricted";
  header("WWW-authenticate: basic realm=\"$realm\"") ;
  header("Status: 401 Unauthorized");

Daniel Lorch http://daniel.lorch.cc/

----- Original Message -----
From   : jeff bert [mailto:soi...@sg...]
Sent   : Mittwoch, 1. Mai 2002
Subject: [cgiwrap-users] php-cgiwrap won't process authentication headers...

> my install of php-cgiwrap won't process authentication headers... called
> like this:

> $realm = "Restricted";
> header("WWW-authenticate: basic realm=\"$realm\"") ;
> header("HTTP/1.0 401 Unauthorized") ;

> Do I have a funky setup or is this a limitation of php-cgiwrap?

> The error log shows:

> [Tue Apr 30 18:31:43 2002] [error] [client:xx.xx.xx.xx] malformed header
> from script. Bad header=HTTP/1.0 401 Unauthorized:
> /var/www/cgi-sys/php-cgiwrap

> Thanks,

> Jeff

[cgiwrap-users] php-cgiwrap won't process authentication headers...

[jeff b. <soi...@sg...>]

my install of php-cgiwrap won't process authentication headers... called
like this:

$realm = "Restricted";
header("WWW-authenticate: basic realm=\"$realm\"") ;
header("HTTP/1.0 401 Unauthorized") ;

Do I have a funky setup or is this a limitation of php-cgiwrap?

The error log shows:

[Tue Apr 30 18:31:43 2002] [error] [client:xx.xx.xx.xx] malformed header
from script. Bad header=HTTP/1.0 401 Unauthorized:
/var/www/cgi-sys/php-cgiwrap

Thanks,

Jeff

Re[2]: [cgiwrap-users] real hosting and cgiwrap

[Daniel L. <da...@lo...>]

Hi,

> Since I'm talking about mass-hosting, you probably know, that it's 
> impossible to set several hunderts of ScriptAlias and mod_rewrite rules.

why should this be impossible? I'm doing myself mass-hosting pretty well
with a combined cgiwrap and php-cgiwrap.

You could create templates for your virtualhosts:

  <VirtualHost *>
    ServerAdmin webmaster@%%domain%%
    ServerName %%domain%%
    ServerAlias *.%%domain%%

    [..]
  </VirtualHost>

Which would then be written into a single httpd.conf. Also a
placeholder for %%user%% would make the implementation of cgiwrap
terribly easy, wouldn't it?

Use your imagination. This ain't magic - some lines in
Perl/PHP/Python/Ruby do the trick.

> In addition, scripts shall not only be executable in /cgi-bin/, but 
> everything. The script just should end with .pl or .php.

This is not cgiwrap-related. Please read the manual carefully.

  Options +ExecCGI
  http://httpd.apache.org/docs/mod/core.html#options

> This is done with "AddHandler", not ScriptAlias.

ScriptAlias to make cgiwrap available, AddHandler to add handlers for
file extensions to the wrapper. Looks like this:

  ScriptAlias /cgi-bin/cgiwrap/ /usr/local/cgi-bin/cgiwrap/

  AddHandler phpwrap .php3
  AddHandler phpwrap .php
  AddHandler cgiwrap .cgi
  AddHandler cgiwrap .pl

  Action phpwrap /cgi-bin/cgiwrap/php-cgiwrap/username
  Action cgiwrap /cgi-bin/cgiwrap/cgiwrap/username

I still don't understand your problem. If there WOULD be another
perfect solution, why don't you just use it and stop ranting?
  
-daniel

RE: [cgiwrap-users] real hosting and cgiwrap

[jeff b. <soi...@sg...>]

> > have you heard of the Apache Directive: RewriteRule?  try using
> that to hide
> > all the /cgiwrap/~user/ part:
> >
> > http://httpd.apache.org/docs/mod/mod_rewrite.html#RewriteRule
>
> If I have to use this, there is almost no difference to using suexec,
> because I have to do a virtualhost entry for each domain and define the
> rewrite rule for each of them.
>

Once you get a rewrite rule that works all you'd have to do is copy it to
each virtualhost and edit the username. That seems pretty simple to me.


> > have you heard of Piotr Klaban's php-cgiwrap patch? try using
> that to get
> > rid of having to put #!/path-to-php/ in your .php files.
> >
> > http://www.klaban.torun.pl/patches/cgiwrap/
>
> It's not, that I didn't find the appropriate patches. But please
> explain: Why has every new cgiwrap user to look for dozend of patches to
> get everything to work? We doesn't the maintainer of cgiwrap combine
> e.g. the php-patch, because in the end everyone needs it. Whats the
> virtue of prepending "#!/usr/bin/php" to each php-script and set it
> executable? That behavioir reminds me on qmail or djbdns: There is so
> much, that isn't perfect and there are so much really good patches. But
> every single new user has to start from beginning, because the author is
> not willing to include patches or improve his core-version. Is that your
> idea of open source?
>

I'm not sure why he hasn't included it.  But, here's a pretty good reason
why not.... If you write a script that requires that it be wrapped then
putting a flag in there of #!/path-to-php/ is a good way to do it.  That way
when someone else tries to use your script in a non-wrapped way they can be
flagged that "hey, this script needs to be wrapped and not run under the
apache user".  This way there is a visible difference between php files that
require wrapping and ones that do not.

Jeff

Re: [cgiwrap-users] real hosting and cgiwrap

[Marten L. <le...@va...>]

> Does mod_cgiwrap or suexec work on cern? netscape server? tinyhttpd?
> ncsa httpd? or any one of dozens of other http servers? No, of course
> not. 

Thats what I hate on very much open source projects: They try to be 
universal, no matter if anyone needs this features. My opinion is to be 
good in at least one point, not try to be little well in all possible 
points.

> Does cgiwrap? You bet it does. If the server supports the standard CGI
> spec, it will be 100% compatible with cgiwrap. I show approximately 40+
> different HTTP servers on freshmeat. At one time or another, and many
> still, cgiwrap has been used with most of the mainstream web servers,
> and some of the uncommon ones.

Fine. But my question wasn't if you can tell me how much different 
webservers exist, that someone started to code and that noone other than 
himself uses, but if mainstream providers (mass-hosting) with 
mainwebservers (apache) are using this. And they still don't do it.

> Yes, you can make cgiwrap apache-specific, and turn it into suexec, but
> I have no intention of making that the default. I personally don't see
> much point in using cgiwrap as suexec, but if I were doing it that way,
> I'd just use mod_rewrite. It's alot cleaner than most of the approaches
> that are being used. 

cgiwrap does more than suexec. Generally suexec would be ok, but it's 
howing bad performance, especially with mass-hosting, because it would 
require to set up a virtualhost-entry for each domain. Everything that 
most people are looking for is an apache-module, that replaces mod_exec 
by some module, that expands mod_exec in setting uid's.

You maybe will be astound, but I'm running apache with cgiwrap and 
mod_cgiwrap+mod_phpcgiwrap. I also coded some additional lines to handle 
our customized mass-hosting environment.

But after all I must say, that it took me several hours to got 
everything to work, because there is no easy-to-start README. Then it 
feels like cgiwrap shouldn't wear a 3.x release number.

Regards
Marten

Re: [cgiwrap-users] real hosting and cgiwrap

[Daniel L. <da...@lo...>]

Hi,

> Have you ever seen a major webhosting provider like verio.net, 
> schlund.de or whichever you know, that requires their customers to call 
> their scripts through strange addresses like 
> /~user/cgiwrap/scriptname.pl? I can tell you: No. [..]

please learn to read.

  http://cgiwrap.unixtools.org/tricks.html

ScriptAlias also works fine, but mod_rewrite gives you more
flexibility.
  
-daniel

RE: [cgiwrap-users] real hosting and cgiwrap

[jeff b. <soi...@sg...>]

Stop ranting and listen to two simple things:

have you heard of the Apache Directive: RewriteRule?  try using that to hide
all the /cgiwrap/~user/ part:

http://httpd.apache.org/docs/mod/mod_rewrite.html#RewriteRule

have you heard of Piotr Klaban's php-cgiwrap patch? try using that to get
rid of having to put #!/path-to-php/ in your .php files.

http://www.klaban.torun.pl/patches/cgiwrap/

I found this stuff and I'm very new to webserving, linux and am definitely
no genius.  where does that put you?

Jeff

> -----Original Message-----
> From: cgi...@li...
> [mailto:cgi...@li...]On Behalf Of Marten
> Lehmann
> Sent: Tuesday, April 30, 2002 10:32 AM
> To: cgi...@li...
> Subject: [cgiwrap-users] real hosting and cgiwrap
>
>
> Hello,
>
> I'm now going to say something about cgiwrap, I wanted to about it long
> time ago: cgiwrap is completely unusable for common needs!
>
> Have you ever seen a major webhosting provider like verio.net,
> schlund.de or whichever you know, that requires their customers to call
> their scripts through strange addresses like
> /~user/cgiwrap/scriptname.pl? I can tell you: No. The common case is,
> that static files and cgi-scripts are mixed up in the same directory and
> should be treated like that, too. If I have an image in /icon.gif and a
> script in /test.pl, I want to call /test.pl like I call /icon.gif, but I
> have to call it through /~user/cgiwrap/test.pl. Also, noone wants to
> enter "'/usr/bin/php" in the first line of each php-script and set it
> executable. Why all that crap?
>
> I was happy to find http://steven.haryan.to/mod_cgiwrap/mod_cgiwrap.html
> Why can't evolve cgiwrap as almost everyone needs it: hidden as
> apache-module. Why has it to be a separate binary? Or while it is a
> separate binary: Why can't the appropriate apache-module not be
> included? The documentation about how to use cgiwrap with apache is very
> lousy and as far as I can tell I had problems with POST-operations with
> AddHandler/AddAction combination.
>
> The best for all users would be a combination of a cgiwrap, which
> doesn't look for the user via the url, but through the file-uid of the
> cgi-script which is called, mod_cgiwrap and mod_phpcgiwrap.
>
> Regards
> Marten Lehmann
>
>
> _______________________________________________
> cgiwrap-users mailing list
> cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgiwrap-users
>

RE: [cgiwrap-users] real hosting and cgiwrap

[Neulinger, N. <nn...@um...>]

Real simple - the example you give is very narrow and limited-experience
in nature.=20

Does mod_cgiwrap or suexec work on cern? netscape server? tinyhttpd?
ncsa httpd? or any one of dozens of other http servers? No, of course
not.=20

Does cgiwrap? You bet it does. If the server supports the standard CGI
spec, it will be 100% compatible with cgiwrap. I show approximately 40+
different HTTP servers on freshmeat. At one time or another, and many
still, cgiwrap has been used with most of the mainstream web servers,
and some of the uncommon ones.

Do you have to change your syntax or user procedures to use on a
different server with cgiwrap? No - same syntax will work on ALL
platforms. Even on NT if they had setuid() support.

Yes, you can make cgiwrap apache-specific, and turn it into suexec, but
I have no intention of making that the default. I personally don't see
much point in using cgiwrap as suexec, but if I were doing it that way,
I'd just use mod_rewrite. It's alot cleaner than most of the approaches
that are being used.=20

-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nn...@um...
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216


> -----Original Message-----
> From: Marten Lehmann [mailto:le...@va...]=20
> Sent: Tuesday, April 30, 2002 12:32 PM
> To: cgi...@li...
> Subject: [cgiwrap-users] real hosting and cgiwrap
>=20
>=20
> Hello,
>=20
> I'm now going to say something about cgiwrap, I wanted to=20
> about it long=20
> time ago: cgiwrap is completely unusable for common needs!
>=20
> Have you ever seen a major webhosting provider like verio.net,=20
> schlund.de or whichever you know, that requires their=20
> customers to call=20
> their scripts through strange addresses like=20
> /~user/cgiwrap/scriptname.pl? I can tell you: No. The common case is,=20
> that static files and cgi-scripts are mixed up in the same=20
> directory and=20
> should be treated like that, too. If I have an image in=20
> /icon.gif and a=20
> script in /test.pl, I want to call /test.pl like I call=20
> /icon.gif, but I=20
> have to call it through /~user/cgiwrap/test.pl. Also, noone wants to=20
> enter "'/usr/bin/php" in the first line of each php-script and set it=20
> executable. Why all that crap?
>=20
> I was happy to find=20
> http://steven.haryan.to/mod_cgiwrap/mod_cgiwra> p.html
> Why=20
> can't evolve cgiwrap as almost everyone needs it:=20
> hidden as=20
> apache-module. Why has it to be a separate binary? Or while it is a=20
> separate binary: Why can't the appropriate apache-module not be=20
> included? The documentation about how to use cgiwrap with=20
> apache is very=20
> lousy and as far as I can tell I had problems with=20
> POST-operations with=20
> AddHandler/AddAction combination.
>=20
> The best for all users would be a combination of a cgiwrap, which=20
> doesn't look for the user via the url, but through the=20
> file-uid of the=20
> cgi-script which is called, mod_cgiwrap and mod_phpcgiwrap.
>=20
> Regards
> Marten Lehmann
>=20
>=20
> _______________________________________________
> cgiwrap-users mailing list
> cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgiwrap-users
>=20

[cgiwrap-users] real hosting and cgiwrap

[Marten L. <le...@va...>]

Hello,

I'm now going to say something about cgiwrap, I wanted to about it long 
time ago: cgiwrap is completely unusable for common needs!

Have you ever seen a major webhosting provider like verio.net, 
schlund.de or whichever you know, that requires their customers to call 
their scripts through strange addresses like 
/~user/cgiwrap/scriptname.pl? I can tell you: No. The common case is, 
that static files and cgi-scripts are mixed up in the same directory and 
should be treated like that, too. If I have an image in /icon.gif and a 
script in /test.pl, I want to call /test.pl like I call /icon.gif, but I 
have to call it through /~user/cgiwrap/test.pl. Also, noone wants to 
enter "'/usr/bin/php" in the first line of each php-script and set it 
executable. Why all that crap?

I was happy to find http://steven.haryan.to/mod_cgiwrap/mod_cgiwrap.html
Why can't evolve cgiwrap as almost everyone needs it: hidden as 
apache-module. Why has it to be a separate binary? Or while it is a 
separate binary: Why can't the appropriate apache-module not be 
included? The documentation about how to use cgiwrap with apache is very 
lousy and as far as I can tell I had problems with POST-operations with 
AddHandler/AddAction combination.

The best for all users would be a combination of a cgiwrap, which 
doesn't look for the user via the url, but through the file-uid of the 
cgi-script which is called, mod_cgiwrap and mod_phpcgiwrap.

Regards
Marten Lehmann

Re: [cgiwrap-users] trying to emulate a nice php-cgiwrap install...

[Piotr K. <ma...@ma...>]

On Mon, Apr 29, 2002 at 03:40:49PM -0700, jeff bert wrote:
> 3) compile cgiwrap... 2nd for .php's
> # ./configure --with-httpd-user=apache \
> --with-local-contact-email=<...> \
> --with-local-doc-url=<...> \
> --with-install-dir= /tmp \
> --with-cgi-dir=<root html folder for users, eg. =public_html>

> Action php-cgiwrap /cgi-sys/php-cgiwrap/username/cgi-bin/php4-12.cgi
> AddType php-cgiwrap .php .php3 .php4 .phtml

I do not understand the purpose of this solution.
Why users have to duplicate php binary ...

As I wrote in today's mail to you, Jeff, in order to use
my patch you need to configure cgiwrap with --with-php
option. Then on your disk there are now two normal cgiwrap
programs - cgiwrap and php-cgiwrap.

My patch allows you to run php on the given *.php script.
In your case this is not needed.
You run php directly from /cgi-sys/php-cgiwrap/username/cgi-bin/php4-12.cgi

-- 
Piotr Klaban

RE: [cgiwrap-users] trying to emulate a nice php-cgiwrap install...

[jeff b. <soi...@sg...>]

heh, the parsing error was due to a stupid mistake... --enable-discard-path
was used but I wasn't taking the php binary out of the web folders... doh!

Well I seem to have it working by doing this:

1) patch cgiwrap with Piotr Klaban's patch for php
2) compile cgiwrap... once for .cgi's
# ./configure --with-httpd-user=apache \
--with-local-contact-email=<...> \
--with-local-doc-url=<...> \
--with-install-dir= /var/www/cgi-sys
--with-cgi-dir=<root cgi-bin for users, eg. =public_html/cgi-bin
# make
# make install

3) compile cgiwrap... 2nd for .php's
# ./configure --with-httpd-user=apache \
--with-local-contact-email=<...> \
--with-local-doc-url=<...> \
--with-install-dir= /tmp \
--with-cgi-dir=<root html folder for users, eg. =public_html>
# make
# make install

4) copy cgiwrap from cgiwrap from /tmp over php-cgiwrap in /var/www/cgi-sys
and relink php-cgiwrapd to php-cgiwrap
# cp /tmp/cgiwrap /var/www/cgi-sys/php-cgiwrap
# rm -f php-cgiwrapd
# ln php-cgiwrap php-cgiwrapd

5) compiled php and copied the binary to the user's cgi-bin as php4-12.cgi

6) confs:

Then in my main apache conf I added:

ScriptAlias /cgi-sys/ /var/www/cgi-sys/

And in my virtual hosts conf I put:

Action php-cgiwrap /cgi-sys/php-cgiwrap/username/cgi-bin/php4-12.cgi
AddType php-cgiwrap .php .php3 .php4 .phtml

7) usage:

cgi scripts (exist in cgi-bin):
http://virt-domain.com/cgi-sys/cgiwrap/username/script.cgi

php files (exist in html folders, not cgi-bin)
http://virt-domain.com/file.php and the php file is wrapped and doesn't have
the #!/path-to-php/ in it.

and it seems to work.  Let me know if you see any glaring mistakes I'm
making... thanks.

(ps, thanks to Piotr and shimi for their help on the outside of this group)

Jeff




> -----Original Message-----
> From: cgi...@li...
> [mailto:cgi...@li...]On Behalf Of jeff bert
> Sent: Saturday, April 27, 2002 5:04 PM
> To: cgi...@li...
> Subject: [cgiwrap-users] trying to emulate a nice php-cgiwrap install...
>
>
> A friend of mine has his site hosted by a company that has a very nice
> php-cgiwrap setup. I'm trying to emulate it but can't figure out how they
> did it.  This is how it works:
>
> PHP runs normally from their binary install unwrapped.  However,
> if you want
> your scripts wrapped then you can compile your own php binary and
> put it in
> your cgi-bin.  This is done with the
> options --enable-discard-path, --with-config-file-path=<local dir>
> and --enable-force-cgi-redirect at the minimum.  Then you copy that php
> binary to your cgi-bin giving it the .cgi extension.
>
> Then in the folders where you want the php wrapped you add .htaccess files
> with:
>
> Action application/x-httpd-phpx /cgi-sys/php-cgiwrap/USERNAME/php.cgi
> AddType application/x-httpd-phpx .php <etc>
>
> Then you can call your scripts normally from any folder (governed by the
> .htaccess file) and they don't have to have the #!<path-to-php>
> in them nor
> do they have to be in the cgi-bin and yet they are wrapped.
>
> I've been trying to emulate this on my server and think I have a
> few of the
> components down but obviously not all as it's not working yet.
>
> This is what I've done:
>
> 1) patched cgiwrap-3.7.1 source with the php patch by Piotr Klaban
> (http://www.klaban.torun.pl/patches/cgiwrap/)
>
> 2) compiled my own php with the following options:
>
> ./configure --without-gd \
> --with-zlib \
> --without-mysql \
> --with-config-file-path=/home \
> --disable-debug \
> --enable-track-vars \
> --enable-ftp \
> --enable-force-cgi-redirect \
> --enable-discard-path
>
> 3) make (php)
>
> 4) copied php.ini-dist into /home/php.ini and php into
> /home/USERNAME/public_html/cgi-bin/php.cgi
>
> 5) compiled cgiwrap-3.7.1 with:
>
> ./configure --with-httpd-user=apache \
> --with-local-doc-url=<mydocs> \
> --with-local-contact-email=root@localhost \
> --with-install-dir=/var/www/cgi-sys \
> --with-php=/home/USERNAME/public_html/cgi-bin/php.cgi
>
> 6) make, make install (cgiwrap)
>
> 7) added the .htaccess file in the root of the USERNAME's webserver of:
>
> Action application/x-httpd-phpx /cgi-sys/php-cgiwrap/USERNAME/php.cgi
> AddType application/x-httpd-phpx .php .php3 .php4 .phtml
>
> After doing all that I test my cgiwrap stuff on .cgi files and there's no
> problems.
>
> But when I test it on php stuff I get the following parse errors on a php
> file that only has <?php phpinfo(); ?> in it:
>
> -----------------
> Warning: Unexpected character in input: '' (ASCII=4) state=1 in
> /home/USERNAME/public_html/cgi-bin/php4-12.cgi on line 2851
>
> Warning: Unexpected character in input: ' in
> /home/USERNAME/public_html/cgi-bin/php4-12.cgi on line 2852
>
> Warning: Unexpected character in input: '' (ASCII=4) state=1 in
> /home/USERNAME/public_html/cgi-bin/php4-12.cgi on line 2852
>
> Warning: Unexpected character in input: '' (ASCII=4) state=1 in
> /home/USERNAME/public_html/cgi-bin/php4-12.cgi on line 2853
>
> Warning: Unexpected character in input: '' (ASCII=27) state=1 in
> /home/USERNAME/public_html/cgi-bin/php4-12.cgi on line 2854
>
> Parse error: parse error in /home/USERNAME/public_html/cgi-bin/php4-12.cgi
> on line 2854
> -----------------
>
> Any ideas what I'm doing wrong?
>
> I know this seems more like a php question but i'm hoping someone in
> cgiwrap-users has come up against this and can help since it is a problem
> created by trying to wrap php in a special way.
>
> Thanks,
>
> Jeff
>
>
>
> _______________________________________________
> cgiwrap-users mailing list
> cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgiwrap-users
>

[cgiwrap-users] trying to emulate a nice php-cgiwrap install...

[jeff b. <soi...@sg...>]

A friend of mine has his site hosted by a company that has a very nice
php-cgiwrap setup. I'm trying to emulate it but can't figure out how they
did it.  This is how it works:

PHP runs normally from their binary install unwrapped.  However, if you want
your scripts wrapped then you can compile your own php binary and put it in
your cgi-bin.  This is done with the
options --enable-discard-path, --with-config-file-path=<local dir>
and --enable-force-cgi-redirect at the minimum.  Then you copy that php
binary to your cgi-bin giving it the .cgi extension.

Then in the folders where you want the php wrapped you add .htaccess files
with:

Action application/x-httpd-phpx /cgi-sys/php-cgiwrap/USERNAME/php.cgi
AddType application/x-httpd-phpx .php <etc>

Then you can call your scripts normally from any folder (governed by the
.htaccess file) and they don't have to have the #!<path-to-php> in them nor
do they have to be in the cgi-bin and yet they are wrapped.

I've been trying to emulate this on my server and think I have a few of the
components down but obviously not all as it's not working yet.

This is what I've done:

1) patched cgiwrap-3.7.1 source with the php patch by Piotr Klaban
(http://www.klaban.torun.pl/patches/cgiwrap/)

2) compiled my own php with the following options:

./configure --without-gd \
--with-zlib \
--without-mysql \
--with-config-file-path=/home \
--disable-debug \
--enable-track-vars \
--enable-ftp \
--enable-force-cgi-redirect \
--enable-discard-path

3) make (php)

4) copied php.ini-dist into /home/php.ini and php into
/home/USERNAME/public_html/cgi-bin/php.cgi

5) compiled cgiwrap-3.7.1 with:

./configure --with-httpd-user=apache \
--with-local-doc-url=<mydocs> \
--with-local-contact-email=root@localhost \
--with-install-dir=/var/www/cgi-sys \
--with-php=/home/USERNAME/public_html/cgi-bin/php.cgi

6) make, make install (cgiwrap)

7) added the .htaccess file in the root of the USERNAME's webserver of:

Action application/x-httpd-phpx /cgi-sys/php-cgiwrap/USERNAME/php.cgi
AddType application/x-httpd-phpx .php .php3 .php4 .phtml

After doing all that I test my cgiwrap stuff on .cgi files and there's no
problems.

But when I test it on php stuff I get the following parse errors on a php
file that only has <?php phpinfo(); ?> in it:

-----------------
Warning: Unexpected character in input: '' (ASCII=4) state=1 in
/home/USERNAME/public_html/cgi-bin/php4-12.cgi on line 2851

Warning: Unexpected character in input: ' in
/home/USERNAME/public_html/cgi-bin/php4-12.cgi on line 2852

Warning: Unexpected character in input: '' (ASCII=4) state=1 in
/home/USERNAME/public_html/cgi-bin/php4-12.cgi on line 2852

Warning: Unexpected character in input: '' (ASCII=4) state=1 in
/home/USERNAME/public_html/cgi-bin/php4-12.cgi on line 2853

Warning: Unexpected character in input: '' (ASCII=27) state=1 in
/home/USERNAME/public_html/cgi-bin/php4-12.cgi on line 2854

Parse error: parse error in /home/USERNAME/public_html/cgi-bin/php4-12.cgi
on line 2854
-----------------

Any ideas what I'm doing wrong?

I know this seems more like a php question but i'm hoping someone in
cgiwrap-users has come up against this and can help since it is a problem
created by trying to wrap php in a special way.

Thanks,

Jeff

[cgiwrap-users] .htaccess & CGIWrap (desperate)

[Kyle <ky...@cc...>]

I asked this of the Apache group first, but according to Apache rules,
I'm doing it right.  I'm wondering if I'm not using the .htaccess file
correctly with CGIWrap...

I have virtual host that uses a simple .htaccess file for error document
redirects.  The redirect for 404 errors works, but the one for 500
errors does not.  The server is Apache 1.3.22, RH7.1, and CGIWrap
3.7.1.  Here is the entire .htaccess file:

errordocument 404 /404.htm
errordocument 500 /500.htm

httpd.conf specifies the Apache default 404 & 500 pages and the
.htaccess overrides them with the local error documents.  The 404 one
works by overriding the default 404 document called out in the
httpd.conf as expected.  But for 500s, I get the default page that is
called out in httpd.conf instead of .htaccess.  Both 404.htm and 500.htm
files exist in the same directory with the same owner, same group, and
same permissions (644).

The way my virtual hosts are set up, each virtual host equates to a user
home directory.  If you go to that user's directory, you'll see the
following sub-dirs:
www
cgi-bin

www is the "root" for web domains and I have the following line to use
CGIWrap and make it appear that the cgi-bin is in the user's web area:
   Action cgi-wrapper /cgi-bin/cgiwrap/~wfp86007

I have copied the .htaccess to the user's home dir, the www dir, and the
cgi-bin dir, and in all cases, the 404.htm gets called (works
appropriately), but the 500.htm does not.

Neither the Apache nor the CGIWrap sites has any help on this.  Can
anybody offer any hints?

Or am I missing something about .htaccess & CGIWrap?  Maybe I should
instead ask, "How do I set up .htaccess to use a custom error 500 page
when using CGIWrap?"

Thanks!

-Kyle

Re: [cgiwrap-users] POST Method Problems

[Liam R. <ja...@ui...>]

Hey,

I compiled a vanilla version of Apache 1.3.23 with PHP 4.1.1 as a DSO and 
it works fine.

Sigh.

I'll let you know if I get any further with regards to making everything 
play nice.

--Liam

At 08:54 AM 4/16/2002 -0700, Liam Reimers wrote:
>Howdy folks,
>
>After an evening of testing, I have isolated the problem to Apache's 
>SetHandler directive.  AddHandler works fine, as does calling scripts with 
>cgiwrap directly.  I am testing on:
>
>FreeBSD wm.uia.net 4.4-RELEASE FreeBSD 4.4-RELEASE #0: Tue Sep 18 11:57:08 
>PDT 2001     mu...@bu...:/usr/src/sys/compile/GENERIC  i386
>
>Apache/1.3.23 (Unix) PHP/4.1.1 FrontPage/5.0.2.2510 mod_ssl/2.8.6 
>OpenSSL/0.9.6a
>
>...but I don't the the combination of modules has anything to do with the 
>problem.
>
>--Liam
>
>At 04:03 PM 4/15/2002 -0700, Liam Reimers wrote:
>>Hi folks,
>>
>>I've seen several posts on this, but no solutions.  The problem is that 
>>POSTed variables never make it through cgiwrap to the called script using 
>>the AddHandler directive.  Does anyone know what is going on with 
>>this?  I've been reading the list archive all afternoon without any luck, 
>>but maybe I missed it?
>>
>>Thanks in advance for any input,
>>
>>--Liam
>>
>>
>>Liam Reimers, Senior Systems Programmer
>>ULTIMATE Internet Access, Inc.
>>(909) 482-1634  (800) 982-6898
>>http://www.uia.net
>>
>>
>>_______________________________________________
>>cgiwrap-users mailing list
>>cgi...@li...
>>https://lists.sourceforge.net/lists/listinfo/cgiwrap-users
>
>
>Liam Reimers, Senior Systems Programmer
>ULTIMATE Internet Access, Inc.
>(909) 482-1634  (800) 982-6898
>http://www.uia.net
>
>
>_______________________________________________
>cgiwrap-users mailing list
>cgi...@li...
>https://lists.sourceforge.net/lists/listinfo/cgiwrap-users


Liam Reimers, Senior Systems Programmer
ULTIMATE Internet Access, Inc.
(909) 482-1634  (800) 982-6898
http://www.uia.net

Re: [cgiwrap-users] POST Method Problems

[Liam R. <ja...@ui...>]

Howdy folks,

After an evening of testing, I have isolated the problem to Apache's 
SetHandler directive.  AddHandler works fine, as does calling scripts with 
cgiwrap directly.  I am testing on:

FreeBSD wm.uia.net 4.4-RELEASE FreeBSD 4.4-RELEASE #0: Tue Sep 18 11:57:08 
PDT 2001     mu...@bu...:/usr/src/sys/compile/GENERIC  i386

Apache/1.3.23 (Unix) PHP/4.1.1 FrontPage/5.0.2.2510 mod_ssl/2.8.6 
OpenSSL/0.9.6a

...but I don't the the combination of modules has anything to do with the 
problem.

--Liam

At 04:03 PM 4/15/2002 -0700, Liam Reimers wrote:
>Hi folks,
>
>I've seen several posts on this, but no solutions.  The problem is that 
>POSTed variables never make it through cgiwrap to the called script using 
>the AddHandler directive.  Does anyone know what is going on with 
>this?  I've been reading the list archive all afternoon without any luck, 
>but maybe I missed it?
>
>Thanks in advance for any input,
>
>--Liam
>
>
>Liam Reimers, Senior Systems Programmer
>ULTIMATE Internet Access, Inc.
>(909) 482-1634  (800) 982-6898
>http://www.uia.net
>
>
>_______________________________________________
>cgiwrap-users mailing list
>cgi...@li...
>https://lists.sourceforge.net/lists/listinfo/cgiwrap-users


Liam Reimers, Senior Systems Programmer
ULTIMATE Internet Access, Inc.
(909) 482-1634  (800) 982-6898
http://www.uia.net