> -Original Message-
> From: Markus Wichitill [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, 31 August 2004 4:16 PM
> To: Scott Fagg
> Cc:
> Subject: Re: handling multipart/form-data POSTed content in
> mod_perl 2.0
>
> Scott Fagg wrote:
> > Can someone point me in the direction of a worked
Scott Fagg wrote:
Can someone point me in the direction of a worked example of handling
multipart/form-data POSTed content in mod_perl 2.0 ?
Closest i've come is a sample bit of code that just dumps the contents,
but not parses it and i haven't been able to find any modules that help
in parsing.
Can someone point me in the direction of a worked example of handling
multipart/form-data POSTed content in mod_perl 2.0 ?
Closest i've come is a sample bit of code that just dumps the contents,
but not parses it and i haven't been able to find any modules that help
in parsing.
--
Report prob
I'm running RH 8, apache 1.3.23, mod_perl 1.29. They wanted me to
install a CMS (Plone) that uses Zope, which requires that I put
mod_proxy into the apache setup. So I redid the apache ./configure
(forgetting about mod_perl for the moment).
Then I remembered about mod_perl, learned about APAC
While trying to debug an issue with a section in mod_perl2, I
noticed that these sections are not shown in mod_info's output. I also
ran into some issues in mod_info itself.
In case these tools are useful to someone else, I have placed the new
improved mod_info.c and a patch for mod_perl-1.99.
In the course of trying to figure out why mod_info does not reveal
directives added in PerlSections (see other email), I stumbled across
the following problem:
I created a simple seven-line .htaccess file, and did 100,000 requests
to a file in the corresponding directory with ab. All processes
David Castro wrote:
> Okay, a little more tracking down revealed that handler #5 ("check if
> the user is ok _here_") is never getting called when my module is being
> used, but is for Basic auth. Happen to know under which circumstances
> this occurs/doesn't occur? Maybe there is something els
Okay, a little more tracking down revealed that handler #5 ("check if
the user is ok _here_") is never getting called when my module is being
used, but is for Basic auth. Happen to know under which circumstances
this occurs/doesn't occur? Maybe there is something else I can set to
get that me
on 08/30/04 15:01 Geoffrey Young wrote:
Ooops, yeah. A follow-up email corrected "mod_authz_ldap" to
"mod_auth_ldap". Sorry 'bout that. To give a bit more detail, I am
using "mod_authz_ldap-0.22" on Apache 2 under RHAS 3.0. Went looking
through the C code of the authz module and fou
> Ooops, yeah. A follow-up email corrected "mod_authz_ldap" to
> "mod_auth_ldap". Sorry 'bout that. To give a bit more detail, I am
> using "mod_authz_ldap-0.22" on Apache 2 under RHAS 3.0. Went looking
> through the C code of the authz module and found the function it gets
> the credentials f
on 08/30/04 13:43 Geoffrey Young wrote:
then all you should need to do is set $r->user to the authenticated
user and
you should be good to go. for completeness, you might also want to set
$r->connection->auth_type to 'Basic', but that is most likely not
required
to get things wo
Apache HTTP Server Request Library 2.04-dev Released
The Apache Software Foundation and The Apache HTTP Server Project
are pleased to announce the 2.04-dev release of libapreq2. This
Announcement notes significant changes introduced by this release.
The package libapreq2-2.04_03-dev.tar
>> then all you should need to do is set $r->user to the authenticated
>> user and
>> you should be good to go. for completeness, you might also want to set
>> $r->connection->auth_type to 'Basic', but that is most likely not
>> required
>> to get things working.
>>
>>
> Hrmm. Yeah, this is wh
on 08/30/04 12:09 Geoffrey Young wrote:
Heh. Yeah, maybe the point I needed to make more clear is this. The
PerlAuthenHandler is NOT relying on basic auth to actually have ever
occured. It is a handler that gets credentials via another service
altogether. Suffice it to say that no b
So, I ran the t/TEST -conf and t/TEST tests separately, replacing "_default_" with
the actual name of the
host machine. LOTS of errors and ultimately a completely wedged test script. I was
also able to run
some tests after, as individual tests.
Here is the log of the tests with "ok" tests del
Gossamer-Threads has a pretty cool mod_perl setup. You can get a
dedicated server or a shared account. Each shared account has its own
apache process, which means that you can log in and control (i.e. stop /
start / restart) your own modperl httpd.
All the mod_perl processes are behind a small,
>> t/TEST -verbose apache/util.t
SB> [...]
>> t/apache/util1..8
SB> [...]
>> # testing : Apache::Util::ht_time($pool)
>> # expected: (?-xism:^\w+, \d\d \w+ \d\d\d\d \d\d:\d\d:\d\d)
>> # received: A?A?A?A?A?A?, 25 A?A?A?A?A?A? 2004 09:09:26 GMT
>> not ok 1
SB> Dmitry, please take a look at t/re
17 matches
Mail list logo
