You are viewing a plain text version of this content. The canonical link for it is here.
Posted to embperl@perl.apache.org by "Steven D. Arnold" <st...@permanent.cc> on 2000/05/16 23:04:06 UTC

more udat persistence issues

Hi,

I'm having some strange udat persistence issues.  I have read through the 
previous threads on this and I'm attempting to implement those ideas, and 
also running into problems there.

I have attempted to set the session cookie timeout to 10 minutes and set 
the locking mechanism to NullLocker using the following directives in 
httpd.conf:

SetEnv EMBPERL_DEBUG 2369773
SetEnv EMBPERL_VIRTLOG /embperl/log
SetEnv EMBPERL_COOKIE_EXPIRES 10
SetEnv EMBPERL_SESSION_CLASSES "DBIStore NullLocker"

I've also tried using PerlSetEnv.

Despite this, %udat seems to disappear mysteriously at times.  When I click 
to a link on the same machine, in the same directory tree, none of the 
values of udat are available.

I've put some comments in HTML::Embperl.pm to see if it sees the 
environment variables I've set up, and it seems it does not.  Here's what 
it sees:

[647]SES:  EMBPERL_SESSION_CLASSES is
      ENV CONTAINS :
          GATEWAY_INTERFACE, CGI-Perl/1.1
          MOD_PERL, mod_perl/1.22
          PATH, 
/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/sbin:/opt/bin:/usr/games:/usr/local/bin:.:/home/dba:/home/thoth/bin:/usr/local/pgsql/bin:/usr/local/bin:/usr/sbin:/sbin:/usr/local/apache/bin:/home/dba/bin:/home/dba/lib

What am I doing wrong?  I am relatively new to some of the more in-depth 
Apache configurations, so I may be making a simple error here.  Any ideas 
are appreciated!


steve

--
Steven D. Arnold          Que quiero sera           stevena@permanent.cc
"We choose to go to the moon in this decade and do the other things, not
because they are easy, but because they are hard."    -- John F. Kennedy


RE: more udat persistence issues

Posted by Gerald Richter <ri...@ecos.de>.
> >Do you get the message "Embperl session management enabled" when
> you start
> >your server?
>
> No...didn't realize I was supposed to!  Interesting.  Here's what
> I get, in
> error_log:
>

You should see it when the server starts on the console, it doesn't makes it
way to the error log.

If you really don't get this message, then you configuration has an error
and session management isn't enabled at all!

>
> Well, this is puzzling enough that it ought to at least make a good FAQ
> item once we solve it. ;-)
>

Updates and patches for the documentaion are always wellcome!!

Gerald


RE: more udat persistence issues

Posted by "Steven D. Arnold" <st...@permanent.cc>.
<html>
At 10:08 PM 5/18/2000 +0200, Gerald Richter wrote:<br>
<blockquote type=cite cite>Are you running httpd with the -X option?</blockquote><br>
No, I'll do that.<br>
<br>
<br>
<blockquote type=cite cite>Do you get the message &quot;Embperl session management enabled&quot; when you start<br>
your server?</blockquote><br>
No...didn't realize I was supposed to!&nbsp; Interesting.&nbsp; Here's what I get, in error_log:<br>
<br>
[Thu May 18 12:35:25 2000] [notice] SIGHUP received.&nbsp; Attempting to restart<br>
[Thu May 18 12:35:25 2000] [notice] Apache/1.3.12 (Unix) mod_perl/1.22 configured -- resuming normal operations<br>
<br>
I'll also try out what Cesar recommended, though the fact that I don't see the message above leads me to suspect my configuration is somehow basically broken.&nbsp; Despite that, I've reviewed the documentation on session management and I feel that my configuration in httpd.conf implements what is suggested.&nbsp; I'll post a snippet tomorrow; I do not have access to the file from here.<br>
<br>
Well, this is puzzling enough that it ought to at least make a good FAQ item once we solve it. ;-)<br>
<br>
<br>
steve<br>
</html>



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


RE: more udat persistence issues

Posted by "Steven D. Arnold" <st...@permanent.cc>.
At 10:08 PM 5/18/2000 +0200, Gerald Richter wrote:
>Are you running httpd with the -X option?

No, I'll do that.


>Do you get the message "Embperl session management enabled" when you start
>your server?

No...didn't realize I was supposed to!  Interesting.  Here's what I get, in 
error_log:

[Thu May 18 12:35:25 2000] [notice] SIGHUP received.  Attempting to restart
[Thu May 18 12:35:25 2000] [notice] Apache/1.3.12 (Unix) mod_perl/1.22 
configured -- resuming normal operations

I'll also try out what Cesar recommended, though the fact that I don't see 
the message above leads me to suspect my configuration is somehow basically 
broken.  Despite that, I've reviewed the documentation on session 
management and I feel that my configuration in httpd.conf implements what 
is suggested.  I'll post a snippet tomorrow; I do not have access to the 
file from here.

Well, this is puzzling enough that it ought to at least make a good FAQ 
item once we solve it. ;-)


steve


--
Steven D. Arnold          Que quiero sera           stevena@permanent.cc
"We choose to go to the moon in this decade and do the other things, not
because they are easy, but because they are hard."    -- John F. Kennedy


RE: more udat persistence issues

Posted by Gerald Richter <ri...@ecos.de>.
> I've tried to make the problem as simple as possible.  I've written the
> following script:
>
> <HTML>
> <HEAD>
> <TITLE>Whee</TITLE>
> </HEAD>
> <BODY>
> <P>This is a test.</P>
> <P>udat{foo} is [+ $udat{foo} +]</P>
> [- $udat{foo} += 1 -]
> </BODY>
> </HTML>
>
> The first time this page is loaded, it displays:
>
>          udat{foo} is
>
> Reload, and it displays:
>
>          udat{foo} is 1
>
> Each subsequent reload increments the value.  However, the embperl logs
> show no indication of a cookie being received from the browser.
> This is IE
> 5.5 on Windows 2000.  The log segment follows:
>
> [609]HDR: 8
> [609]HDR: Accept=*/*
> [609]HDR: Accept-Language=en-us
> [609]HDR: Cache-Control=max-age=259200
> [609]HDR: Connection=keep-alive
> [609]HDR: Host=192.168.250.207
> [609]HDR: Pragma=no-cache
> [609]HDR: Via=1.0 proxy3.trusecure.net:80 (Squid/2.0.RELEASE)
> [609]HDR: X-Forwarded-For=unknown
>
> The packet capture validates this result:
>
> GET /embperl/foo.shtml HTTP/1.0
> Accept: */*
> Accept-Language: en-us
> Pragma: no-cache
> Host: 192.168.250.207
> Via: 1.0 proxy3.trusecure.net:80 (Squid/2.0.RELEASE)
> X-Forwarded-For: unknown
> Cache-Control: max-age=259200
> Connection: keep-alive
>
> HTTP/1.1 200 OK
> Date: Thu, 18 May 2000 11:44:49 GMT
> Server: Apache/1.3.12(Unix) mod_perl/1.22
> Content-Length: 283
> Keep-Alive: timeout=15, max=99
> Connection: Keep-Alive
> Content-Type: text/html
>
> No cookie was either set by the server or sent by the browser.
>

Strange...

> Interestingly, when I started Netscape 4.71 to try this
> experiment, when I
> first loaded the page, I got "udat{foo} is 3".  Then each time I
> reloaded,
> it incremented from there.  Perhaps embperl is using some means
> other than
> a cookie to identify my machine?
>

No, it only uses cookies.

> What would you say is the next step in debugging this?
>
Are you running httpd with the -X option?

Do you get the message "Embperl session management enabled" when you start
your server?

Gerald


RE: more udat persistence issues

Posted by "Steven D. Arnold" <st...@permanent.cc>.
At 09:59 AM 5/18/2000 +0200, Gerald Richter wrote:

>Embperl send a cookie the first time %udat is used and the browser should
>send it back on _every_ request.
>
>One other issuse that could arise is, that the browser send the cookie only
>back if the path is the same or below the one where the cookie was send. If
>the browser should send back the cookie for the whole site, than you have to
>add a
>
>PerlSetEnv EMBPERL_COOKIE_PATH /
>
>Maybe this is the reason?


Thanks for the idea.  I've implemented it, and I'm still getting the same 
result.

I've tried to make the problem as simple as possible.  I've written the 
following script:

<HTML>
<HEAD>
<TITLE>Whee</TITLE>
</HEAD>
<BODY>
<P>This is a test.</P>
<P>udat{foo} is [+ $udat{foo} +]</P>
[- $udat{foo} += 1 -]
</BODY>
</HTML>

The first time this page is loaded, it displays:

         udat{foo} is

Reload, and it displays:

         udat{foo} is 1

Each subsequent reload increments the value.  However, the embperl logs 
show no indication of a cookie being received from the browser.  This is IE 
5.5 on Windows 2000.  The log segment follows:

[609]HDR: 8
[609]HDR: Accept=*/*
[609]HDR: Accept-Language=en-us
[609]HDR: Cache-Control=max-age=259200
[609]HDR: Connection=keep-alive
[609]HDR: Host=192.168.250.207
[609]HDR: Pragma=no-cache
[609]HDR: Via=1.0 proxy3.trusecure.net:80 (Squid/2.0.RELEASE)
[609]HDR: X-Forwarded-For=unknown

The packet capture validates this result:

GET /embperl/foo.shtml HTTP/1.0
Accept: */*
Accept-Language: en-us
Pragma: no-cache
Host: 192.168.250.207
Via: 1.0 proxy3.trusecure.net:80 (Squid/2.0.RELEASE)
X-Forwarded-For: unknown
Cache-Control: max-age=259200
Connection: keep-alive

HTTP/1.1 200 OK
Date: Thu, 18 May 2000 11:44:49 GMT
Server: Apache/1.3.12(Unix) mod_perl/1.22
Content-Length: 283
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: text/html

No cookie was either set by the server or sent by the browser.

Interestingly, when I started Netscape 4.71 to try this experiment, when I 
first loaded the page, I got "udat{foo} is 3".  Then each time I reloaded, 
it incremented from there.  Perhaps embperl is using some means other than 
a cookie to identify my machine?

What would you say is the next step in debugging this?


steve


--
Steven D. Arnold          Que quiero sera           stevena@permanent.cc
"We choose to go to the moon in this decade and do the other things, not
because they are easy, but because they are hard."    -- John F. Kennedy


RE: more udat persistence issues

Posted by "Steven D. Arnold" <st...@permanent.cc>.
<html>
At 09:59 AM 5/18/2000 +0200, Gerald Richter wrote:<br>
<br>
<blockquote type=cite cite>Embperl send a cookie the first time %udat is used and the browser should<br>
send it back on _every_ request.<br>
<br>
One other issuse that could arise is, that the browser send the cookie only<br>
back if the path is the same or below the one where the cookie was send. If<br>
the browser should send back the cookie for the whole site, than you have to<br>
add a<br>
<br>
PerlSetEnv EMBPERL_COOKIE_PATH /<br>
<br>
Maybe this is the reason?</blockquote><br>
<br>
Thanks for the idea.&nbsp; I've implemented it, and I'm still getting the same result.<br>
<br>
I've tried to make the problem as simple as possible.&nbsp; I've written the following script:<br>
<br>
&lt;HTML&gt;<br>
&lt;HEAD&gt;<br>
&lt;TITLE&gt;Whee&lt;/TITLE&gt;<br>
&lt;/HEAD&gt;<br>
&lt;BODY&gt;<br>
&lt;P&gt;This is a test.&lt;/P&gt;<br>
&lt;P&gt;udat{foo} is [+ $udat{foo} +]&lt;/P&gt;<br>
[- $udat{foo} += 1 -]<br>
&lt;/BODY&gt;<br>
&lt;/HTML&gt;<br>
<br>
The first time this page is loaded, it displays:<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>udat{foo} is <br>
<br>
Reload, and it displays:<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>udat{foo} is 1<br>
<br>
Each subsequent reload increments the value.&nbsp; However, the embperl logs show no indication of a cookie being received from the browser.&nbsp; This is IE 5.5 on Windows 2000.&nbsp; The log segment follows:<br>
<br>
[609]HDR: 8<br>
[609]HDR: Accept=*/*<br>
[609]HDR: Accept-Language=en-us<br>
[609]HDR: Cache-Control=max-age=259200<br>
[609]HDR: Connection=keep-alive<br>
[609]HDR: Host=192.168.250.207<br>
[609]HDR: Pragma=no-cache<br>
[609]HDR: Via=1.0 proxy3.trusecure.net:80 (Squid/2.0.RELEASE)<br>
[609]HDR: X-Forwarded-For=unknown<br>
<br>
The packet capture validates this result:<br>
<br>
GET /embperl/foo.shtml HTTP/1.0<br>
Accept: */*<br>
Accept-Language: en-us<br>
Pragma: no-cache<br>
Host: 192.168.250.207<br>
Via: 1.0 proxy3.trusecure.net:80 (Squid/2.0.RELEASE)<br>
X-Forwarded-For: unknown<br>
Cache-Control: max-age=259200<br>
Connection: keep-alive<br>
<br>
HTTP/1.1 200 OK<br>
Date: Thu, 18 May 2000 11:44:49 GMT<br>
Server: Apache/1.3.12(Unix) mod_perl/1.22<br>
Content-Length: 283<br>
Keep-Alive: timeout=15, max=99<br>
Connection: Keep-Alive<br>
Content-Type: text/html<br>
<br>
No cookie was either set by the server or sent by the browser.<br>
<br>
Interestingly, when I started Netscape 4.71 to try this experiment, when I first loaded the page, I got &quot;udat{foo} is 3&quot;.&nbsp; Then each time I reloaded, it incremented from there.&nbsp; Perhaps embperl is using some means other than a cookie to identify my machine?<br>
<br>
What would you say is the next step in debugging this?<br>
<br>
<br>
steve<br>
</html>



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


RE: more udat persistence issues

Posted by Gerald Richter <ri...@ecos.de>.
>
> I admit I am completely lost at this point.  I don't even know
> how Embperl
> does what it does when it works, much less why it fails.  Shouldn't the
> browser be sending a Cookie: HTTP header in its request?
>
> Any ideas or thoughts welcome.
>
>

Embperl send a cookie the first time %udat is used and the browser should
send it back on _every_ request.

One other issuse that could arise is, that the browser send the cookie only
back if the path is the same or below the one where the cookie was send. If
the browser should send back the cookie for the whole site, than you have to
add a

PerlSetEnv EMBPERL_COOKIE_PATH /

Maybe this is the reason?

Gerald


RE: more udat persistence issues

Posted by "Steven D. Arnold" <st...@permanent.cc>.
At 05:16 AM 5/17/2000 +0200, Gerald Richter wrote:
>Hi,
>
> > SetEnv EMBPERL_COOKIE_EXPIRES 10
>
>unfortunately Embperl cannot handle relativ expire times. It just passes the
>value you set in EMBPERL_COOKIE_EXPIRES in the http header to the browser,
>so it must be the full date. Remove the above line from your config and it
>should work. In this case the browser forgets the cookie when it is closed
>by the user.

I did this.  Unfortunately, the problem is still occurring.  I forgot to 
mention something potentially of importance last time: the udat information 
seems to propagate correctly when I submit a form; the problem arises when 
I click a link.  I did a packet capture of the transaction when I clicked 
the link; the results are below.

The request:

GET /embperl/monitor/dosearch.shtml?start_item=10&num_items=10 HTTP/1.0
Accept: */*
Accept-Language: en-us
Host: 192.168.250.207
Via: 1.0 proxy3.trusecure.net:80 (Squid/2.0.RELEASE)
X-Forwarded-For: unknown
Cache-Control: max-age=259200
Connection: keep-alive

And the response:

HTTP/1.1 200 OK
Date: Wed, 17 May 2000 14:37:04 GMT
Server: Apache/1.3.12 (Unix) mod_perl/1.22
Content-Length: 8793
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html;charset=iso-8859-1

Incidentally, even though I have set EMBPERL_DEBUG to 2369773, I never see 
any information on cookies, even in cases where udat is clearly 
working.  Here's an illustration.  Below, I do a packet capture for a 
transaction where udat works.  First I show the headers as revealed by the 
packet capture, then I show the headers as indicated by Embperl's log file.

The request:

POST /embperl/monitor/dosearch.shtml HTTP/1.0
Accept: */*
Accept-Language: en-us
Content-Type: application/x-www-form-urlencoded
Host: 192.168.250.207
Content-Length: 164
Pragma: no-cache
Via: 1.0proxy3.trusecure.net:80 (Squid/2.0.RELEASE)
X-Forwarded-For: unknown
Cache-Control: max-age=259200
Connection: keep-alive

And the server's response:

HTTP/1.1 200 OK
Date: Wed, 17 May 2000 14:46:15 GMT
Server: Apache/1.3.12 (Unix) mod_perl/1.22
Content-Length: 82917
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type:text/html;charset=iso-8859-1


The Embperl log shows:

[508]HDR: 10
[508]HDR: Accept=*/*
[508]HDR: Accept-Language=en-us
[508]HDR: Cache-Control=max-age=259200
[508]HDR: Connection=keep-alive
[508]HDR: Content-Length=164
[508]HDR: Content-Type=application/x-www-form-urlencoded
[508]HDR: Host=192.168.250.207
[508]HDR: Pragma=no-cache
[508]HDR: Via=1.0 proxy3.trusecure.net:80 (Squid/2.0.RELEASE)
[508]HDR: X-Forwarded-For=unknown

At least this is consistent -- but where is the cookie that udat 
uses??  And this is a case where the persistent information of udat 
successfully propagated.

I admit I am completely lost at this point.  I don't even know how Embperl 
does what it does when it works, much less why it fails.  Shouldn't the 
browser be sending a Cookie: HTTP header in its request?

Any ideas or thoughts welcome.


steve


--
Steven D. Arnold          Que quiero sera           stevena@permanent.cc
"We choose to go to the moon in this decade and do the other things, not
because they are easy, but because they are hard."    -- John F. Kennedy


RE: more udat persistence issues

Posted by "Steven D. Arnold" <st...@permanent.cc>.
<html>
At 05:16 AM 5/17/2000 +0200, Gerald Richter wrote:<br>
<blockquote type=cite cite>Hi,<br>
<br>
&gt; SetEnv EMBPERL_COOKIE_EXPIRES 10<br>
<br>
unfortunately Embperl cannot handle relativ expire times. It just passes the<br>
value you set in EMBPERL_COOKIE_EXPIRES in the http header to the browser,<br>
so it must be the full date. Remove the above line from your config and it<br>
should work. In this case the browser forgets the cookie when it is closed<br>
by the user.</blockquote><br>
I did this.&nbsp; Unfortunately, the problem is still occurring.&nbsp; I forgot to mention something potentially of importance last time: the udat information seems to propagate correctly when I submit a form; the problem arises when I click a link.&nbsp; I did a packet capture of the transaction when I clicked the link; the results are below.<br>
<br>
The request:<br>
<br>
GET /embperl/monitor/dosearch.shtml?start_item=10&amp;num_items=10 HTTP/1.0<br>
Accept: */*<br>
Accept-Language: en-us<br>
Host: 192.168.250.207<br>
Via: 1.0 proxy3.trusecure.net:80 (Squid/2.0.RELEASE)<br>
X-Forwarded-For: unknown<br>
Cache-Control: max-age=259200<br>
Connection: keep-alive<br>
<br>
And the response:<br>
<br>
HTTP/1.1 200 OK<br>
Date: Wed, 17 May 2000 14:37:04 GMT<br>
Server: Apache/1.3.12 (Unix) mod_perl/1.22<br>
Content-Length: 8793<br>
Keep-Alive: timeout=15, max=100<br>
Connection: Keep-Alive<br>
Content-Type: text/html;charset=iso-8859-1<br>
<br>
Incidentally, even though I have set EMBPERL_DEBUG to 2369773, I never see any information on cookies, even in cases where udat is clearly working.&nbsp; Here's an illustration.&nbsp; Below, I do a packet capture for a transaction where udat works.&nbsp; First I show the headers as revealed by the packet capture, then I show the headers as indicated by Embperl's log file.<br>
<br>
The request:<br>
<br>
POST /embperl/monitor/dosearch.shtml HTTP/1.0<br>
Accept: */*<br>
Accept-Language: en-us<br>
Content-Type: application/x-www-form-urlencoded<br>
Host: 192.168.250.207<br>
Content-Length: 164<br>
Pragma: no-cache<br>
Via: 1.0proxy3.trusecure.net:80 (Squid/2.0.RELEASE)<br>
X-Forwarded-For: unknown<br>
Cache-Control: max-age=259200<br>
Connection: keep-alive<br>
<br>
And the server's response:<br>
<br>
HTTP/1.1 200 OK<br>
Date: Wed, 17 May 2000 14:46:15 GMT<br>
Server: Apache/1.3.12 (Unix) mod_perl/1.22<br>
Content-Length: 82917<br>
Keep-Alive: timeout=15, max=99<br>
Connection: Keep-Alive<br>
Content-Type:text/html;charset=iso-8859-1<br>
<br>
<br>
The Embperl log shows:<br>
<br>
[508]HDR: 10<br>
[508]HDR: Accept=*/*<br>
[508]HDR: Accept-Language=en-us<br>
[508]HDR: Cache-Control=max-age=259200<br>
[508]HDR: Connection=keep-alive<br>
[508]HDR: Content-Length=164<br>
[508]HDR: Content-Type=application/x-www-form-urlencoded<br>
[508]HDR: Host=192.168.250.207<br>
[508]HDR: Pragma=no-cache<br>
[508]HDR: Via=1.0 proxy3.trusecure.net:80 (Squid/2.0.RELEASE)<br>
[508]HDR: X-Forwarded-For=unknown<br>
<br>
At least this is consistent -- but where is the cookie that udat uses??&nbsp; And this is a case where the persistent information of udat successfully propagated.<br>
<br>
I admit I am completely lost at this point.&nbsp; I don't even know how Embperl does what it does when it works, much less why it fails.&nbsp; Shouldn't the browser be sending a Cookie: HTTP header in its request?<br>
<br>
Any ideas or thoughts welcome.<br>
<br>
<br>
steve<br>
</html>



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


RE: EmbPerl 2, was EmbPerl, Request Wap

Posted by Gerald Richter <ri...@ecos.de>.
> > I guess this will be issue for Embperl 2, were it is very easy
> to define new
> > tags and their behaviour and which includes the possibility for
> switching
> > between different tag sets.
>
> Do you have a place where to see the planned features for Embperl
> 2? Some of
> the things you mention look like it's becoming more application
> server like, or
> at least can be used like that.
>

I don't have a summary of the new (planned) features so far. I have here and
there written something about it. I currently working very hard on it
(that's the reason why I don't make changes to 1.3 at the moment) and I hope
to release a first beta soon (which will not have all planned features).

The main point is that Embperl is much more modularized, so you can plugin
your own parsers, compilers, processers. I will have the possibility to
chain multiple processors/handlers and to defined custom html/xml tags which
will call functions in your own module. Also there will be a very enhanced
caching scheme and the overall perfomance is improved.

Gerald


-------------------------------------------------------------
Gerald Richter    ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting

Post:       Tulpenstrasse 5         D-55276 Dienheim b. Mainz
E-Mail:     richter@ecos.de         Voice:    +49 6133 925151
WWW:        http://www.ecos.de      Fax:      +49 6133 925152
-------------------------------------------------------------


EmbPerl 2, was EmbPerl, Request Wap

Posted by Kaare Rasmussen <ka...@webline.dk>.
> I guess this will be issue for Embperl 2, were it is very easy to define new
> tags and their behaviour and which includes the possibility for switching
> between different tag sets.

Do you have a place where to see the planned features for Embperl 2? Some of
the things you mention look like it's becoming more application server like, or
at least can be used like that.

-- 
Kaare Rasmussen            --Linux, spil,--        Tlf:        3816 2582
Kaki Data                tshirts, merchandize      Fax:        3816 2582
Howitzvej 75               �ben 14.00-18.00        Email: kar@webline.dk
2000 Frederiksberg        L�rdag 11.00-17.00       Web:      www.suse.dk

RE: EmbPerl, Request Wap

Posted by Gerald Richter <ri...@ecos.de>.
Hi,
>
>           I have developed with EmbPerl and dynamic Wap Pages, very
> fast and easy.
>
>            It exists some plan to bear the meta-commands SELECT, TABLE
> ...  with EmbPerl, something so as HTML: :EmbPerl::Wap?
>

I didn't have taken a closer look at WAP so far. How would such tag's in WAP
look like?

I guess this will be issue for Embperl 2, were it is very easy to define new
tags and their behaviour and which includes the possibility for switching
between different tag sets.

Gerald


-------------------------------------------------------------
Gerald Richter    ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting

Post:       Tulpenstrasse 5         D-55276 Dienheim b. Mainz
E-Mail:     richter@ecos.de         Voice:    +49 6133 925151
WWW:        http://www.ecos.de      Fax:      +49 6133 925152
-------------------------------------------------------------


EmbPerl, Request Wap

Posted by mtoro <mt...@chat.cl>.
Hi,

          I have developed with EmbPerl and dynamic Wap Pages, very
fast and easy.

           It exists some plan to bear the meta-commands SELECT, TABLE 
...  with EmbPerl, something so as HTML: :EmbPerl::Wap?


Bye


RE: more udat persistence issues

Posted by Gerald Richter <ri...@ecos.de>.
Hi,

> SetEnv EMBPERL_COOKIE_EXPIRES 10

unfortunately Embperl cannot handle relativ expire times. It just passes the
value you set in EMBPERL_COOKIE_EXPIRES in the http header to the browser,
so it must be the full date. Remove the above line from your config and it
should work. In this case the browser forgets the cookie when it is closed
by the user.

Gerald