Thanks for replying so fast!
I set EMBPERL_DEBUG as you suggested. When I try the first case (using
Execute('../subs.html') and with subs.html present at every level of the
hierarchy), there is just a pause, followed by a message dialog from
Netscape saying that the document contained no data. There is no output
in the error log. I have tried re-starting the webserver, but it has the
same behavior. As a sanity check, here's the relevant section from my
httpd.conf:
<VirtualHost xxx.xxx.xxx.xxx:80>
ServerName test.dev.nilspace.com
SSLDisable
ServerAdmin [EMAIL PROTECTED]
DocumentRoot /www/nilspace/com/test
DirectoryIndex index.html
ErrorLog /www/nilspace/com/logs/error_log
TransferLog /www/nilspace/com/logs/access_log
PerlSetEnv EMBPERL_ESCMODE 3
PerlSetEnv EMBPERL_OPTIONS 16
PerlSetEnv EMBPERL_MAILHOST mail.nilspace.com
PerlSetEnv EMBPERL_OBJECT_BASE base.html
PerlSetEnv EMBPERL_DEBUG 66609149
</VirtualHost>
# Set EmbPerl handler for test directory
<Directory "/www/nilspace/com/test/">
<FilesMatch ".*\.(epl|htm|html)$">
SetHandler perl-script
PerlHandler HTML::EmbperlObject
Options ExecCGI
</FilesMatch>
</Directory>
You know, looking at this it strikes me that I forgot to mention I am
using Apache 1.3.12 with Ben-SSL 1.41 on Linux (Red Hat 7.0). The server
was built from source, as was mod_perl and EmbPerl. Should that matter?
The second case, where foo/subs.html is missing and we go to /foo/bar/,
now mysteriously seemed to work. I tried it without your debug setting,
and it still worked. I think I know what happened here: When I was
testing this stuff yesterday, I did not restart apache when making
changes (such as renaming foo/subs.html to something else). This seems
to trip up the system. As long as I restart apache after making changes
to file names, then it does work. So, the case of Execute() looking back
up the directory tree *IS* working, it seems. I just need to remember to
restart the web server, I guess to re-initialize the cache. I am sorry
that I apparently didn't do rigorous enough testing on that one.
Thanks again,
-Neil
p.s. I am new to email lists, and aware that every message goes to
everybody else. In a case like this message, should I be addressing
privately to you, or to the group as a whole too? Not too sure of the
etiquette. TIA!
Gerald Richter wrote:
>
> Hi Neil,
>
> the setup you outlined below should work as you expected with 1.3b6.
>
> To give me a chance to track down why it doesn't please set EMBPERL_DEBUG to
> 66609149 and send me the embperl.log file of your request and the output you
> see at the browser.
>
> The issue with ESCMODE = 0 is that, in 1.3b6, if ESCMODE is 0, no crlf is
> appended to the page, so it is possible to output binary data. Try to add a
> newline to the end of your source, does it work then with ESCMODE = 0 ?
>
> Gerald
>
> -------------------------------------------------------------
> Gerald Richter ecos electronic communication services gmbh
> Internetconnect * Webserver/-design/-datenbanken * Consulting
>
> Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
> E-Mail: [EMAIL PROTECTED] Voice: +49 6133 925151
> WWW: http://www.ecos.de Fax: +49 6133 925152
> -------------------------------------------------------------
>
> ----- Original Message -----
> From: "Neil Gunton" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, November 01, 2000 12:35 AM
> Subject: EmbperlObject in 1.3b6
>
> > Hi Gerald,
> >
> > I am still having problems with a scenario which I will outline in
> > detail below. I hope this functionality is not too much of a pain to
> > incorporate. I have tried to supply a minimal case.
> >
> > Assume the following in the httpd.conf:
> >
> > SetHandler perl-script
> > PerlHandler HTML::EmbperlObject
> > Options ExecCGI
> >
> > DirectoryIndex base.html
> > PerlSetEnv EMBPERL_ESCMODE 3
> > PerlSetEnv EMBPERL_OPTIONS 16
> > PerlSetEnv EMBPERL_OBJECT_BASE base.html
> >
> > And the following files (stripped of all extraneous HTML - the contents
> > of each file are indented):
> >
> > /base.html
> > [- Execute ('subs.html') -]
> > /subs.html
> > subs
> > /foo/subs.html
> > [- Execute ('../subs.html') -]
> > <P>
> > foo/subs
> > /foo/bar/subs.html
> > [- Execute ('../subs.html') -]
> > <P>
> > foo/bar/subs
> >
> > Ok, now if you point your browser at / you will see:
> >
> > subs
> >
> > If you go to /foo/ then you should see:
> >
> > subs
> >
> > foo/subs
> >
> > And if you go to /foo/bar/ then you should get:
> >
> > subs
> >
> > foo/subs
> >
> > foo/bar/subs
> >
> > However, it the latter two examples will fail (in my setup). I believe
> > it is due to the use of the relative '../subs.html' path in the
> > Execute() call. I confirmed this by adding a couple of symbolic links
> > thus:
> >
> > ln -s .. /foo/foo..
> > ln -s .. /foo/bar/bar..
> >
> > This places a uniquely named link to the parent directory (..) in each
> > of the directories /foo/ and /foo/bar/.
> >
> > Now if I change files as follows:
> >
> > /foo/subs.html
> > [- Execute ('foo../subs.html') -]
> > <P>
> > foo/subs
> > /foo/bar/subs.html
> > [- Execute ('bar../subs.html') -]
> > <P>
> > foo/bar/subs
> >
> > Now it works. The output is as expected.
> >
> > So, there appears to be a problem with the use of relative paths - but,
> > though I am not familiar with the code, I would surmise that it is
> > rather a problem with duplicate filenames in the internal cache. Since
> > '../subs.html' will be called more than once during any session, it is
> > important that there be some way of uniquely identifying references to
> > relative filenames internally (perhaps by using the fully qualified
> > path?).
> >
> > Having said all that, I hope I'm not doing something really stupid. I
> > think the minimal example outlined above is a useful pattern which
> > occurs frequently in object-oriented design, and it would be great if
> > EmbPerl could handle it without the need for special relative symbolic
> > links.
> >
> > The other issue can be illustrated by using the same example, the only
> > difference being that we remove the file /foo/subs.html. So this means
> > that if we go to /foo/bar/ then the /foo/bar/subs.html file will try to
> > execute the "parent" subs.html in the immediate parent directory, but
> > it's not there. Currently, it seems to fail. It would be nice if the
> > EmbPerl Execute() function could recognise that it needs to trace back
> > up the directory tree and find the next valid instance of the file,
> > which in this case is in /subs.html.
> >
> > Again, this is quite a common OO pattern and it would make directories
> > cleaner by ensuring we didn't need to put almost-empty proxies at every
> > level of the directory tree.
> >
> > I hope this is clear, and again I hope I haven't missed some glaring
> > feature which makes it all work. If there's anything else that I can
> > clarify then I would be more than glad to oblige.
> >
> > One last thing: I noticed some weirdness with EMBPERL_ESCMODE in the
> > latest version. If I set it to zero then pages tend to hang at the very
> > end for a few seconds, before finally completing as normal. If you hit
> > the "stop" button on the (Netscape) browser then you get the usual
> > "transmission interrupted" message inserted at the bottom of the page. I
> > note that if you change the EMBPERL_ESCMODE in httpd.conf to 3 then
> > everything works normally. I can achieve the effect I want (for $escmode
> > to be 0) by setting it explicitly in the code, in those pages which are
> > sensitive to the value. Is this a known problem? It also seems to happen
> > on pages which aren't using EmbperlObject, for what it's worth.
> >
> > Anyway, I hope all this makes sense!
> >
> > Thanks
> >
> > -Neil
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
