You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Pascal MILON <pm...@addsoft.fr> on 2003/08/18 17:30:18 UTC
Need example of filter code for method POST data
Hello everybody,
We use a cgi-bin developed in C to perform some tags treatments on our pages.
We have installed the Apache 2.0.47 on our server and it is working well.
We think about transform our C program to an apache filter but we block on :
"How to read the Post arguments of the page when we ask a post request (e.g. by a form in multi-part/data) " ?
We have already developed a filter test that is work well but only if the request is in GET method.
>From our tests, we think that the filter receive only the body of the page with some variables avalaible in the record_rec and
filter_rec structure. We don't understand how to access to the post_data of the request in POST method.
We have also tested a hook function, but it does not work. We can't find a hook function help in the apache documentation.
Is anybody have an example of a code that read the post_data in a filter, just the minimum of the prototyped functions and the good
functions to call to read the args in POST request ?
We may haven't found the good hook and the good structure from the request pool.
Pascal MILON
Re: [PATCH] mod_rewrite RewriteLock permissions fix
Posted by Jeff Trawick <tr...@attglobal.net>.
Gregory (Grisha) Trubetskoy wrote:
> Hmm... I think it went into MAIN as opposed to APACHE_2_0_BRANCH. It's not
> in 2.0.47, which still has the RewriteLock problem.
Right, but it is listed in the STATUS file on the APACHE_2_0_BRANCH
branch as something proposed for merging into APACHE_2_0_BRANCH.
JimJag had some comments there today that need to be properly addressed
though.
Re: [PATCH] mod_rewrite RewriteLock permissions fix
Posted by "Gregory (Grisha) Trubetskoy" <gr...@apache.org>.
Hmm... I think it went into MAIN as opposed to APACHE_2_0_BRANCH. It's not
in 2.0.47, which still has the RewriteLock problem.
Grisha
On Wed, 20 Aug 2003, Jeff Trawick wrote:
> I humbly submit that the patch already listed in
> APACHE_2_0_BRANCH/STATUS is what should be available in the next 2.0.x
> release:
>
> * Unix: Handle permissions settings for flock-based mutexes in
> unixd_set_global|proc_mutex_perms(). Allow the functions to
> be called for any type of mutex. PR 20312
> modules/mappers/mod_rewrite.c 1.153
> modules/ssl/mod_ssl.h 1.136
> modules/ssl/ssl_engine_config.c 1.81
> modules/ssl/ssl_engine_mutex.c 1.26
> os/unix/unixd.c 1.58
> os/unix/unixd.h 1.38
> +1: trawick, jerenkrantz
>
Re: [PATCH] mod_rewrite RewriteLock permissions fix
Posted by "Gregory (Grisha) Trubetskoy" <gr...@apache.org>.
On Wed, 20 Aug 2003, Jeff Trawick wrote:
> The issues with your patch are:
>
> . your patch does the chown() for more than just flock()-ed files
>
> . there is a better place to put the non-portable flock() code, both to
> keep it out of mod_rewrite and to help solve the problem for any other
> modules
>
I agree - my patch was just a copycat from something similar done in
mod_ssl - I'm guessing the code i was copying from was probably removed by
the patch you mentioned.
Grisha
Re: [PATCH] mod_rewrite RewriteLock permissions fix
Posted by Jeff Trawick <tr...@attglobal.net>.
Gregory (Grisha) Trubetskoy wrote:
> Most likely it *is* fixed in 2.1 - I saw this problem on 2.0, but I looked
> at the code of 2.1 and saw that the code looks the same, so assumed (I
> know, assuming is bad...) that it is still broken.
hey, that's a pretty mean trick :)
> But this can be applied to 2.0, where I think it isn't fixed yet.
I humbly submit that the patch already listed in
APACHE_2_0_BRANCH/STATUS is what should be available in the next 2.0.x
release:
* Unix: Handle permissions settings for flock-based mutexes in
unixd_set_global|proc_mutex_perms(). Allow the functions to
be called for any type of mutex. PR 20312
modules/mappers/mod_rewrite.c 1.153
modules/ssl/mod_ssl.h 1.136
modules/ssl/ssl_engine_config.c 1.81
modules/ssl/ssl_engine_mutex.c 1.26
os/unix/unixd.c 1.58
os/unix/unixd.h 1.38
+1: trawick, jerenkrantz
The parts that fix mod_rewrite specifically are the changes to
mod_rewrite.c, unixd.c, and unixd.h. the ssl changes are just a cleanup
made possible by the infrastructure knowing when a chown() is necessary.
The issues with your patch are:
. your patch does the chown() for more than just flock()-ed files
. there is a better place to put the non-portable flock() code, both to
keep it out of mod_rewrite and to help solve the problem for any other
modules
Re: [PATCH] mod_rewrite RewriteLock permissions fix
Posted by "Gregory (Grisha) Trubetskoy" <gr...@apache.org>.
Most likely it *is* fixed in 2.1 - I saw this problem on 2.0, but I looked
at the code of 2.1 and saw that the code looks the same, so assumed (I
know, assuming is bad...) that it is still broken. I haven't actually
tried verifying that it is a problem with 2.1 (it didn't occur to me to
look at unixd_set_global_mutex_perms() as in 2.0 IIRC it was something
SysV-specific).
But this can be applied to 2.0, where I think it isn't fixed yet.
P.S. My OS is FreeBSD 4.8 the preferred locking is flock() indeed.
Grisha
On Tue, 19 Aug 2003, Jeff Trawick wrote:
> Gregory (Grisha) Trubetskoy wrote:
>
> > When the RewriteLock creates the global mutex on a system where file-based
> > locking is the default mechanism, the file is owned by root, and after
> > setuid/fork children will not have permissions to it. This should fix it.
>
> hmmm... some joker allegedly fixed this in 2.1-dev recently, yet you're
> apparently using 2.1-dev already based on the looks of your patch :(
>
> >
> > Grisha
> >
> > --- modules/mappers/mod_rewrite.c 19 Aug 2003 00:52:43 -0000 1.228
> > +++ modules/mappers/mod_rewrite.c 19 Aug 2003 14:55:32 -0000
> > @@ -2372,6 +2372,11 @@
> > "file %s", lockname);
> > return rc;
> > }
> > + else {
> > +#if !defined(OS2) && !defined(WIN32) && !defined(BEOS) && !defined(NETWARE)
> > + chown(lockname, unixd_config.user_id, -1);
> > +#endif
>
> the unixd_set_global_mutex_perms() is supposed to do the chown() now
> when necessary... what is the mutex type for this mutex on your
> system, and can you check why unixd_set_proc_mutex_perms() isn't doing
> the chown() for you?
>
> (btw, the chown() is only needed when flock mutexes are used, as that is
> the implementation where the lock file has to be re-opened in the child
> process)
>
> > + }
> >
> > #ifdef MOD_REWRITE_SET_MUTEX_PERMS
> > rc = unixd_set_global_mutex_perms(rewrite_mapr_lock_acquire);
>
>
Re: [PATCH] mod_rewrite RewriteLock permissions fix
Posted by Jeff Trawick <tr...@attglobal.net>.
Gregory (Grisha) Trubetskoy wrote:
> When the RewriteLock creates the global mutex on a system where file-based
> locking is the default mechanism, the file is owned by root, and after
> setuid/fork children will not have permissions to it. This should fix it.
hmmm... some joker allegedly fixed this in 2.1-dev recently, yet you're
apparently using 2.1-dev already based on the looks of your patch :(
>
> Grisha
>
> --- modules/mappers/mod_rewrite.c 19 Aug 2003 00:52:43 -0000 1.228
> +++ modules/mappers/mod_rewrite.c 19 Aug 2003 14:55:32 -0000
> @@ -2372,6 +2372,11 @@
> "file %s", lockname);
> return rc;
> }
> + else {
> +#if !defined(OS2) && !defined(WIN32) && !defined(BEOS) && !defined(NETWARE)
> + chown(lockname, unixd_config.user_id, -1);
> +#endif
the unixd_set_global_mutex_perms() is supposed to do the chown() now
when necessary... what is the mutex type for this mutex on your
system, and can you check why unixd_set_proc_mutex_perms() isn't doing
the chown() for you?
(btw, the chown() is only needed when flock mutexes are used, as that is
the implementation where the lock file has to be re-opened in the child
process)
> + }
>
> #ifdef MOD_REWRITE_SET_MUTEX_PERMS
> rc = unixd_set_global_mutex_perms(rewrite_mapr_lock_acquire);
[PATCH] mod_rewrite RewriteLock permissions fix
Posted by "Gregory (Grisha) Trubetskoy" <gr...@ispol.com>.
When the RewriteLock creates the global mutex on a system where file-based
locking is the default mechanism, the file is owned by root, and after
setuid/fork children will not have permissions to it. This should fix it.
Grisha
--- modules/mappers/mod_rewrite.c 19 Aug 2003 00:52:43 -0000 1.228
+++ modules/mappers/mod_rewrite.c 19 Aug 2003 14:55:32 -0000
@@ -2372,6 +2372,11 @@
"file %s", lockname);
return rc;
}
+ else {
+#if !defined(OS2) && !defined(WIN32) && !defined(BEOS) && !defined(NETWARE)
+ chown(lockname, unixd_config.user_id, -1);
+#endif
+ }
#ifdef MOD_REWRITE_SET_MUTEX_PERMS
rc = unixd_set_global_mutex_perms(rewrite_mapr_lock_acquire);
Re: Need example of filter code for method POST data
Posted by Pascal MILON <pm...@addsoft.fr>.
Thanks a lot.
That is what I need to encapsulate our own C program in an apache 2 filter.
Thanks to all.
My request is answered.
Pascal MILON
----- Original Message -----
From: "Nick Kew" <ni...@webthing.com>
To: <de...@httpd.apache.org>; "Pascal MILON" <pm...@addsoft.fr>
Sent: Monday, August 18, 2003 7:08 PM
Subject: Re: Need example of filter code for method POST data
On Mon, 18 Aug 2003, Pascal MILON wrote:
> Is anybody have an example of a code that read the post_data in a filter, just the minimum of the prototyped functions and the
good
> functions to call to read the args in POST request ?
Take a look at <URL:http://www.webthing.com/software/mod_upload/>
which serves to parse and decode multipart forms.
If you want to deal with URLencoded forms in a filter, that's easier:
just take some decoding code (e.g. from a CGI library, or write your own)
and put it in a filter.
--
Nick Kew
In urgent need of paying work - see http://www.webthing.com/~nick/cv.html
Re: Need example of filter code for method POST data
Posted by Nick Kew <ni...@webthing.com>.
On Mon, 18 Aug 2003, Pascal MILON wrote:
> Is anybody have an example of a code that read the post_data in a filter, just the minimum of the prototyped functions and the good
> functions to call to read the args in POST request ?
Take a look at <URL:http://www.webthing.com/software/mod_upload/>
which serves to parse and decode multipart forms.
If you want to deal with URLencoded forms in a filter, that's easier:
just take some decoding code (e.g. from a CGI library, or write your own)
and put it in a filter.
--
Nick Kew
In urgent need of paying work - see http://www.webthing.com/~nick/cv.html