Mailing List Archive

Issue with getting Apache to pass %ENV to sub-scripts on Apache2/mod_perl2
Hi,

When testing our server (RHEL 5, x86_64, Apache 2.2.3, mod_perl2,
Embperl 2.3.0), we had no virtual hosts defined (testing was done on the
raw hostname) and all of our forms seemed to work fine.

Now that we have gone to a NamedVirtualHost configuration (because in
production this server answers to many domains), we have run into an
issue with some of our forms. For the most part, changing the encoding
to "application/x-www-form-urlencoded" has solved our problems.

However, the one form that *has* to be "multipart/form-data" now cannot
seem to pull in the $ENV{REMOTE_USER} variable from Apache.

It is a file-upload form, and goes through 3 stages, all run by calling
back to itself and Execute-ing a different Embperl page based on which
stage it is at.
1) Query user about *what* is being uploaded (add_files_1)
2) Gather file metadata (add_files_2)
3) Upload files (and inform user of successful upload when they finish)
(add_files_3)

The code looks like this:
<form name="Add_Files" method="post" action="bv.add_files.epl"
enctype="multipart/form-data" style="display: inline;">
[# execute the appropriate page #]
[$ if $fdat{Add_Files_3} $]
[- Execute('lower/bv.add_files_3.epl'); -]
[$ elsif $fdat{Add_Files_2} $]
[- Execute('lower/bv.add_files_2.epl'); -]
[$ else $] [# go to the starting page #]
[- Execute('lower/bv.add_files_1.epl'); -]
[$ endif $]
</form>

At the moment, if we change the encoding to x-www-form-urlencode, we can
get through steps 1 and 2 without losing the $ENV{REMOTE_USER} variable.
However, as you might expect, step 3 won't work that way.

If any part of the form is set to "multipart/form-data", the Embperl
scripts cannot read the ENV variable and give our "Not allowed to view
this" page.

Authentication exists in this set of directories, and ExecCGI has been
added explicitly to these directories both in the main configuration and
in the vhost.

Additionally, the configuration directives for Embperl exist in both the
main server configuration and in the vhost.

Am I missing something about the transition to Apache2/mod_perl2 that
alters what ENV information is passed from instance to instace of an
Embperl page?

Any ideas would be most helpful.

-R

--
Robby Desmond
BiblioVault Operations Assistant
University of Chicago Press
http://www.bibliovault.org/
ph: 773-834-2387
cell: 773-458-0959
rdesmond@press.uchicago.edu

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Issue with getting Apache to pass %ENV to sub-scripts on Apache2/mod_perl2 [ In reply to ]
Hi all,

Sorry, but I have to amend this question. It appears that the ENV is
being passed just fine.

The issue is that Embperl is not parsing the form data when it is not
URL-encoded. (Some of the form data includes the book id of the files
being uploaded, and must be included for the "are you authorized" to
work correctly.)

Why would Embperl code not be properly interpreting mutlipart/form-data?

-R

On 7/29/2010 10:04 AM, Robby Desmond wrote:
> Hi,
>
> When testing our server (RHEL 5, x86_64, Apache 2.2.3, mod_perl2,
> Embperl 2.3.0), we had no virtual hosts defined (testing was done on the
> raw hostname) and all of our forms seemed to work fine.
>
> Now that we have gone to a NamedVirtualHost configuration (because in
> production this server answers to many domains), we have run into an
> issue with some of our forms. For the most part, changing the encoding
> to "application/x-www-form-urlencoded" has solved our problems.
>
> However, the one form that *has* to be "multipart/form-data" now cannot
> seem to pull in the $ENV{REMOTE_USER} variable from Apache.
>
> It is a file-upload form, and goes through 3 stages, all run by calling
> back to itself and Execute-ing a different Embperl page based on which
> stage it is at.
> 1) Query user about *what* is being uploaded (add_files_1)
> 2) Gather file metadata (add_files_2)
> 3) Upload files (and inform user of successful upload when they finish)
> (add_files_3)
>
> The code looks like this:
> <form name="Add_Files" method="post" action="bv.add_files.epl"
> enctype="multipart/form-data" style="display: inline;">
> [# execute the appropriate page #]
> [$ if $fdat{Add_Files_3} $]
> [- Execute('lower/bv.add_files_3.epl'); -]
> [$ elsif $fdat{Add_Files_2} $]
> [- Execute('lower/bv.add_files_2.epl'); -]
> [$ else $] [# go to the starting page #]
> [- Execute('lower/bv.add_files_1.epl'); -]
> [$ endif $]
> </form>
>
> At the moment, if we change the encoding to x-www-form-urlencode, we can
> get through steps 1 and 2 without losing the $ENV{REMOTE_USER} variable.
> However, as you might expect, step 3 won't work that way.
>
> If any part of the form is set to "multipart/form-data", the Embperl
> scripts cannot read the ENV variable and give our "Not allowed to view
> this" page.
>
> Authentication exists in this set of directories, and ExecCGI has been
> added explicitly to these directories both in the main configuration and
> in the vhost.
>
> Additionally, the configuration directives for Embperl exist in both the
> main server configuration and in the vhost.
>
> Am I missing something about the transition to Apache2/mod_perl2 that
> alters what ENV information is passed from instance to instace of an
> Embperl page?
>
> Any ideas would be most helpful.
>
> -R
>


--
Robby Desmond
BiblioVault Operations Assistant
University of Chicago Press
http://www.bibliovault.org/
ph: 773-834-2387
cell: 773-458-0959
rdesmond@press.uchicago.edu

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Issue with getting Apache to pass %ENV to sub-scripts on Apache2/mod_perl2 [ In reply to ]
To answer my own question (thanks to the help of our programmer here),
the issue is with the way Embperl.pm attempts to read parameters from a
CGI object.

Embperl.pm lines 320-22:

# the param_fetch needs CGI.pm 2.43
#$params = $cgi->param_fetch( $_ ) ;
$params = $cgi->{$_} ;


In fact, that older method will not work (and is not documented to work)
for CGI any more. The commented out method is the one that works for CGI
3.49.

Our form now works.

-R

On 7/29/2010 12:55 PM, Robby Desmond wrote:
> Hi all,
>
> Sorry, but I have to amend this question. It appears that the ENV is
> being passed just fine.
>
> The issue is that Embperl is not parsing the form data when it is not
> URL-encoded. (Some of the form data includes the book id of the files
> being uploaded, and must be included for the "are you authorized" to
> work correctly.)
>
> Why would Embperl code not be properly interpreting mutlipart/form-data?
>
> -R
>
> On 7/29/2010 10:04 AM, Robby Desmond wrote:
>> Hi,
>>
>> When testing our server (RHEL 5, x86_64, Apache 2.2.3, mod_perl2,
>> Embperl 2.3.0), we had no virtual hosts defined (testing was done on the
>> raw hostname) and all of our forms seemed to work fine.
>>
>> Now that we have gone to a NamedVirtualHost configuration (because in
>> production this server answers to many domains), we have run into an
>> issue with some of our forms. For the most part, changing the encoding
>> to "application/x-www-form-urlencoded" has solved our problems.
>>
>> However, the one form that *has* to be "multipart/form-data" now cannot
>> seem to pull in the $ENV{REMOTE_USER} variable from Apache.
>>
>> It is a file-upload form, and goes through 3 stages, all run by calling
>> back to itself and Execute-ing a different Embperl page based on which
>> stage it is at.
>> 1) Query user about *what* is being uploaded (add_files_1)
>> 2) Gather file metadata (add_files_2)
>> 3) Upload files (and inform user of successful upload when they finish)
>> (add_files_3)
>>
>> The code looks like this:
>> <form name="Add_Files" method="post" action="bv.add_files.epl"
>> enctype="multipart/form-data" style="display: inline;">
>> [# execute the appropriate page #]
>> [$ if $fdat{Add_Files_3} $]
>> [- Execute('lower/bv.add_files_3.epl'); -]
>> [$ elsif $fdat{Add_Files_2} $]
>> [- Execute('lower/bv.add_files_2.epl'); -]
>> [$ else $] [# go to the starting page #]
>> [- Execute('lower/bv.add_files_1.epl'); -]
>> [$ endif $]
>> </form>
>>
>> At the moment, if we change the encoding to x-www-form-urlencode, we can
>> get through steps 1 and 2 without losing the $ENV{REMOTE_USER} variable.
>> However, as you might expect, step 3 won't work that way.
>>
>> If any part of the form is set to "multipart/form-data", the Embperl
>> scripts cannot read the ENV variable and give our "Not allowed to view
>> this" page.
>>
>> Authentication exists in this set of directories, and ExecCGI has been
>> added explicitly to these directories both in the main configuration and
>> in the vhost.
>>
>> Additionally, the configuration directives for Embperl exist in both the
>> main server configuration and in the vhost.
>>
>> Am I missing something about the transition to Apache2/mod_perl2 that
>> alters what ENV information is passed from instance to instace of an
>> Embperl page?
>>
>> Any ideas would be most helpful.
>>
>> -R
>>
>
>


--
Robby Desmond
BiblioVault Operations Assistant
University of Chicago Press
http://www.bibliovault.org/
ph: 773-834-2387
cell: 773-458-0959
rdesmond@press.uchicago.edu

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Issue with getting Apache to pass %ENV to sub-scripts on Apache2/mod_perl2 [ In reply to ]
Robby Desmond schrieb:
> To answer my own question (thanks to the help of our programmer here),
> the issue is with the way Embperl.pm attempts to read parameters from a
> CGI object.
>
> Embperl.pm lines 320-22:
>
> # the param_fetch needs CGI.pm 2.43
> #$params = $cgi->param_fetch( $_ ) ;
> $params = $cgi->{$_} ;
>
>
>
This was a known issue
http://www.gossamer-threads.com/lists/modperl/embperl/98672?search_string=CGI.pm
and has been fixed in Embperl 2.4

> In fact, that older method will not work (and is not documented to work)
> for CGI any more. The commented out method is the one that works for CGI
> 3.49.
>
> Our form now works.
>
> -R
>
> On 7/29/2010 12:55 PM, Robby Desmond wrote:
>
>> Hi all,
>>
>> Sorry, but I have to amend this question. It appears that the ENV is
>> being passed just fine.
>>
>> The issue is that Embperl is not parsing the form data when it is not
>> URL-encoded. (Some of the form data includes the book id of the files
>> being uploaded, and must be included for the "are you authorized" to
>> work correctly.)
>>
>> Why would Embperl code not be properly interpreting mutlipart/form-data?
>>
>> -R
>>
>> On 7/29/2010 10:04 AM, Robby Desmond wrote:
>>
>>> Hi,
>>>
>>> When testing our server (RHEL 5, x86_64, Apache 2.2.3, mod_perl2,
>>> Embperl 2.3.0), we had no virtual hosts defined (testing was done on the
>>> raw hostname) and all of our forms seemed to work fine.
>>>
>>> Now that we have gone to a NamedVirtualHost configuration (because in
>>> production this server answers to many domains), we have run into an
>>> issue with some of our forms. For the most part, changing the encoding
>>> to "application/x-www-form-urlencoded" has solved our problems.
>>>
>>> However, the one form that *has* to be "multipart/form-data" now cannot
>>> seem to pull in the $ENV{REMOTE_USER} variable from Apache.
>>>
>>> It is a file-upload form, and goes through 3 stages, all run by calling
>>> back to itself and Execute-ing a different Embperl page based on which
>>> stage it is at.
>>> 1) Query user about *what* is being uploaded (add_files_1)
>>> 2) Gather file metadata (add_files_2)
>>> 3) Upload files (and inform user of successful upload when they finish)
>>> (add_files_3)
>>>
>>> The code looks like this:
>>> <form name="Add_Files" method="post" action="bv.add_files.epl"
>>> enctype="multipart/form-data" style="display: inline;">
>>> [# execute the appropriate page #]
>>> [$ if $fdat{Add_Files_3} $]
>>> [- Execute('lower/bv.add_files_3.epl'); -]
>>> [$ elsif $fdat{Add_Files_2} $]
>>> [- Execute('lower/bv.add_files_2.epl'); -]
>>> [$ else $] [# go to the starting page #]
>>> [- Execute('lower/bv.add_files_1.epl'); -]
>>> [$ endif $]
>>> </form>
>>>
>>> At the moment, if we change the encoding to x-www-form-urlencode, we can
>>> get through steps 1 and 2 without losing the $ENV{REMOTE_USER} variable.
>>> However, as you might expect, step 3 won't work that way.
>>>
>>> If any part of the form is set to "multipart/form-data", the Embperl
>>> scripts cannot read the ENV variable and give our "Not allowed to view
>>> this" page.
>>>
>>> Authentication exists in this set of directories, and ExecCGI has been
>>> added explicitly to these directories both in the main configuration and
>>> in the vhost.
>>>
>>> Additionally, the configuration directives for Embperl exist in both the
>>> main server configuration and in the vhost.
>>>
>>> Am I missing something about the transition to Apache2/mod_perl2 that
>>> alters what ENV information is passed from instance to instace of an
>>> Embperl page?
>>>
>>> Any ideas would be most helpful.
>>>
>>> -R
>>>
>>>
>>
>
>
>


--
mit freundlichem Gruß,

Frank Wesemann
Fotofinder GmbH USt-IdNr. DE812854514
Software Entwicklung Web: http://www.fotofinder.com/
Potsdamer Str. 96 Tel: +49 30 25 79 28 90
10785 Berlin Fax: +49 30 25 79 28 999

Sitz: Berlin
Amtsgericht Berlin Charlottenburg (HRB 73099)
Geschäftsführer: Ali Paczensky
RE: Issue with getting Apache to pass %ENV to sub-scripts on Apache2/mod_perl2 [ In reply to ]
 

http://www.embperl.org/downloads/Embperl-2.4.0_3.tar.gz

 

Gerald

 

 

From: Frank Wesemann [mailto:f.wesemann@fotofinder.net]
Sent: Friday, July 30, 2010 11:48 AM
To: Robby Desmond; embperl@perl.apache.org
Subject: Re: Issue with getting Apache to pass %ENV to sub-scripts on Apache2/mod_perl2



 

Robby Desmond schrieb:

To answer my own question (thanks to the help of our programmer here),

the issue is with the way Embperl.pm attempts to read parameters from a

CGI object.

 

Embperl.pm lines 320-22:

 

        # the param_fetch needs CGI.pm 2.43

        #$params = $cgi->param_fetch( $_ ) ;

        $params = $cgi->{$_} ;

 

 

 

This was a known issue
http://www.gossamer-threads.com/lists/modperl/embperl/98672?search_string=CGI.pm
and has been fixed in Embperl 2.4




In fact, that older method will not work (and is not documented to work)

for CGI any more. The commented out method is the one that works for CGI

3.49.

 

Our form now works.

 

-R

 

On 7/29/2010 12:55 PM, Robby Desmond wrote:

 

Hi all,

 

Sorry, but I have to amend this question. It appears that the ENV is

being passed just fine.

 

The issue is that Embperl is not parsing the form data when it is not

URL-encoded. (Some of the form data includes the book id of the files

being uploaded, and must be included for the "are you authorized" to

work correctly.)

 

Why would Embperl code not be properly interpreting mutlipart/form-data?

 

-R

 

On 7/29/2010 10:04 AM, Robby Desmond wrote:

   

Hi,

 

When testing our server (RHEL 5, x86_64, Apache 2.2.3, mod_perl2,

Embperl 2.3.0), we had no virtual hosts defined (testing was done on the

raw hostname) and all of our forms seemed to work fine.

 

Now that we have gone to a NamedVirtualHost configuration (because in

production this server answers to many domains), we have run into an

issue with some of our forms. For the most part, changing the encoding

to "application/x-www-form-urlencoded" has solved our problems.

 

However, the one form that *has* to be "multipart/form-data" now cannot

seem to pull in the $ENV{REMOTE_USER} variable from Apache.

 

It is a file-upload form, and goes through 3 stages, all run by calling

back to itself and Execute-ing a different Embperl page based on which

stage it is at.

1) Query user about *what* is being uploaded (add_files_1)

2) Gather file metadata (add_files_2)

3) Upload files (and inform user of successful upload when they finish)

(add_files_3)

 

The code looks like this:

<form name="Add_Files" method="post" action="bv.add_files.epl"

enctype="multipart/form-data" style="display: inline;">

  [# execute the appropriate page #]

  [$ if $fdat{Add_Files_3} $]

    [- Execute('lower/bv.add_files_3.epl'); -]

  [$ elsif $fdat{Add_Files_2} $]

    [- Execute('lower/bv.add_files_2.epl'); -]

  [$ else $] [# go to the starting page #]

    [- Execute('lower/bv.add_files_1.epl'); -]

  [$ endif $]

</form>

 

At the moment, if we change the encoding to x-www-form-urlencode, we can

get through steps 1 and 2 without losing the $ENV{REMOTE_USER} variable.

However, as you might expect, step 3 won't work that way.

 

If any part of the form is set to "multipart/form-data", the Embperl

scripts cannot read the ENV variable and give our "Not allowed to view

this" page.

 

Authentication exists in this set of directories, and ExecCGI has been

added explicitly to these directories both in the main configuration and

in the vhost.

 

Additionally, the configuration directives for Embperl exist in both the

main server configuration and in the vhost.

 

Am I missing something about the transition to Apache2/mod_perl2 that

alters what ENV information is passed from instance to instace of an

Embperl page?

 

Any ideas would be most helpful.

 

-R

 

     

 

   

 

 

 






--

mit freundlichem Gruß,

 

Frank Wesemann

Fotofinder GmbH         USt-IdNr. DE812854514

Software Entwicklung    Web: http://www.fotofinder.com/

Potsdamer Str. 96       Tel: +49 30 25 79 28 90

10785 Berlin            Fax: +49 30 25 79 28 999

 

Sitz: Berlin

Amtsgericht Berlin Charlottenburg (HRB 73099)

Geschäftsführer: Ali Paczensky

 

 
Re: Issue with getting Apache to pass %ENV to sub-scripts on Apache2/mod_perl2 [ In reply to ]
If Embperl-2.4.0 is considered stable/non-beta, it should be committed
to the CPAN repository. At the moment, 2.3 is still considered the
stable release and, as this is a production server, I'm not moving away
from it for the moment.

Perhaps a backport ought to be created to alleviate this issue in the
CPAN version of Embperl?

-R

On 8/2/2010 2:13 AM, Gerald Richter - ECOS wrote:
>
>
> http://www.embperl.org/downloads/Embperl-2.4.0_3.tar.gz
>
>
>
> Gerald
>
>
>
>
>
> *From:* Frank Wesemann [mailto:f.wesemann@fotofinder.net]
> *Sent:* Friday, July 30, 2010 11:48 AM
> *To:* Robby Desmond; embperl@perl.apache.org
> *Subject:* Re: Issue with getting Apache to pass %ENV to sub-scripts on
> Apache2/mod_perl2
>
>
>
> Robby Desmond schrieb:
>
> To answer my own question (thanks to the help of our programmer here),
>
> the issue is with the way Embperl.pm attempts to read parameters from a
>
> CGI object.
>
>
>
> Embperl.pm lines 320-22:
>
>
>
> # the param_fetch needs CGI.pm 2.43
>
> #$params = $cgi->param_fetch( $_ ) ;
>
> $params = $cgi->{$_} ;
>
>
>
>
>
>
>
> This was a known issue
> http://www.gossamer-threads.com/lists/modperl/embperl/98672?search_string=CGI.pm
> and has been fixed in Embperl 2.4
>
>
> In fact, that older method will not work (and is not documented to work)
>
> for CGI any more. The commented out method is the one that works for CGI
>
> 3.49.
>
>
>
> Our form now works.
>
>
>
> -R
>
>
>
> On 7/29/2010 12:55 PM, Robby Desmond wrote:
>
>
>
> Hi all,
>
>
>
> Sorry, but I have to amend this question. It appears that the ENV is
>
> being passed just fine.
>
>
>
> The issue is that Embperl is not parsing the form data when it is not
>
> URL-encoded. (Some of the form data includes the book id of the files
>
> being uploaded, and must be included for the "are you authorized" to
>
> work correctly.)
>
>
>
> Why would Embperl code not be properly interpreting mutlipart/form-data?
>
>
>
> -R
>
>
>
> On 7/29/2010 10:04 AM, Robby Desmond wrote:
>
>
>
> Hi,
>
>
>
> When testing our server (RHEL 5, x86_64, Apache 2.2.3, mod_perl2,
>
> Embperl 2.3.0), we had no virtual hosts defined (testing was done on the
>
> raw hostname) and all of our forms seemed to work fine.
>
>
>
> Now that we have gone to a NamedVirtualHost configuration (because in
>
> production this server answers to many domains), we have run into an
>
> issue with some of our forms. For the most part, changing the encoding
>
> to "application/x-www-form-urlencoded" has solved our problems.
>
>
>
> However, the one form that *has* to be "multipart/form-data" now cannot
>
> seem to pull in the $ENV{REMOTE_USER} variable from Apache.
>
>
>
> It is a file-upload form, and goes through 3 stages, all run by calling
>
> back to itself and Execute-ing a different Embperl page based on which
>
> stage it is at.
>
> 1) Query user about *what* is being uploaded (add_files_1)
>
> 2) Gather file metadata (add_files_2)
>
> 3) Upload files (and inform user of successful upload when they finish)
>
> (add_files_3)
>
>
>
> The code looks like this:
>
> <form name="Add_Files" method="post" action="bv.add_files.epl"
>
> enctype="multipart/form-data" style="display: inline;">
>
> [# execute the appropriate page #]
>
> [$ if $fdat{Add_Files_3} $]
>
> [- Execute('lower/bv.add_files_3.epl'); -]
>
> [$ elsif $fdat{Add_Files_2} $]
>
> [- Execute('lower/bv.add_files_2.epl'); -]
>
> [$ else $] [# go to the starting page #]
>
> [- Execute('lower/bv.add_files_1.epl'); -]
>
> [$ endif $]
>
> </form>
>
>
>
> At the moment, if we change the encoding to x-www-form-urlencode, we can
>
> get through steps 1 and 2 without losing the $ENV{REMOTE_USER} variable.
>
> However, as you might expect, step 3 won't work that way.
>
>
>
> If any part of the form is set to "multipart/form-data", the Embperl
>
> scripts cannot read the ENV variable and give our "Not allowed to view
>
> this" page.
>
>
>
> Authentication exists in this set of directories, and ExecCGI has been
>
> added explicitly to these directories both in the main configuration and
>
> in the vhost.
>
>
>
> Additionally, the configuration directives for Embperl exist in both the
>
> main server configuration and in the vhost.
>
>
>
> Am I missing something about the transition to Apache2/mod_perl2 that
>
> alters what ENV information is passed from instance to instace of an
>
> Embperl page?
>
>
>
> Any ideas would be most helpful.
>
>
>
> -R
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
>
> mit freundlichem Gruß,
>
>
>
> Frank Wesemann
>
> Fotofinder GmbH USt-IdNr. DE812854514
>
> Software Entwicklung Web: http://www.fotofinder.com/
>
> Potsdamer Str. 96 Tel: +49 30 25 79 28 90
>
> 10785 Berlin Fax: +49 30 25 79 28 999
>
>
>
> Sitz: Berlin
>
> Amtsgericht Berlin Charlottenburg (HRB 73099)
>
> Geschäftsführer: Ali Paczensky
>
>
>
>
>


--
Robby Desmond
BiblioVault Operations Assistant
University of Chicago Press
http://www.bibliovault.org/
ph: 773-834-2387
cell: 773-458-0959
rdesmond@press.uchicago.edu

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org