16 Mar
2007
16 Mar
'07
4:43 a.m.
I get error's like this sometimes when I click a link in pier:
Error: "/seaside/mmiki/seaside/mmiki/A-Page" not found.
Notice the path is duplicated. I figure that this is an error that
occurs after the page time's out. yes?
How can I fix this? Why does this happen? Lukas mentioned a thread to
search for but I can't find that message (sorry!) and I haven't found a
good explanation.
Can anyone point me in the right direction?
thanks,
brad
--
brad fuller
http://www.Sonaural.com/
+1 (408) 799-6124
16 Mar
16 Mar
7:52 a.m.
I get error's like this sometimes when I click a
link in pier:
Error: "/seaside/mmiki/seaside/mmiki/A-Page" not found.
Notice the path is duplicated. I figure that this is an error that
occurs after the page time's out. yes?
How can I fix this? Why does this happen? Lukas mentioned a thread to
search for but I can't find that message (sorry!) and I haven't
found a
good explanation.
Can anyone point me in the right direction?
Again this can be solved with a RewrtieRule that you put before
RewriteCond in your Apache config:
RewriteRule $/seaside/mmiki/(.*)^ http://localhost:9999/$1
[proxy,last]
The reason you need this is a problem of Seaside redirecting to the
wrong URL when a session has a timeout. Unfortunately this is not
that easy to fix. I did several attempts during the development of
2.7, but could not figure out a way that did not break a lot of other
applications altogether. Anyway, for now the above RewriteRule does
the trick.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
3:35 p.m.
Lukas Renggli wrote:
Bummer... I thought that there was something in the image so I wouldn't
have to write another rule, but now I remember you saying you
investigated this.
BTW: just to be clear the rule above has the "^" and "$" flipped
around.
Shouldn't it be:
RewriteRule ^/seaside/mmiki/(.*)$ http://localhost:9999/$1 [proxy,last]
--
brad fuller
http://www.Sonaural.com/
+1 (408) 799-6124
I get
error's like this sometimes when I click a link in pier:
Error: "/seaside/mmiki/seaside/mmiki/A-Page" not found.
Notice the path is duplicated. I figure that this is an error that
occurs after the page time's out. yes?
How can I fix this? Why does this happen? Lukas mentioned a thread to
search for but I can't find that message (sorry!) and I haven't
found a
good explanation.
Can anyone point me in the right direction?
Again this can be solved with a RewrtieRule that you put before
RewriteCond in your Apache config:
RewriteRule $/seaside/mmiki/(.*)^ http://localhost:9999/$1
[proxy,last]
The reason you need this is a problem of Seaside redirecting to the
wrong URL when a session has a timeout. Unfortunately this is not
that easy to fix. I did several attempts during the development of
2.7, but could not figure out a way that did not break a lot of other
applications altogether. Anyway, for now the above RewriteRule does
the trick.
3:41 p.m.
BTW: just to be clear the rule above has the
"^" and "$" flipped
around.
Shouldn't it be:
RewriteRule ^/seaside/mmiki/(.*)$ http://localhost:9999/$1
[proxy,last]
Yes, exactly.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
19 Mar
19 Mar
9:47 p.m.
Lukas Renggli wrote:
OK, I admit this is a bit OT, but it does have something to do with
getting Seaside and Apache working together. Others might benefit too...
and I'm surprised that others don't see this problem.
Actually, one would think that the solution above would work, but in my
case it does not. In fact, sometimes I get the path repeated 3 times!
What I did was bypass apache, set the Pier app default timeout low and
go at it to see if I could find something useful. In every case of a
timeout, Pier worked fine when bypassing apache. After timeouts, seaside
went to the next page just fine. So, I think my issue is something to do
with apache. I thought maybe there is a cache problem on the server
side, so I made sure that no cache module is loaded. Why would the path
get duplicated so many times and KOM/Seaside work just fine?
brad
I get
error's like this sometimes when I click a link in pier:
Error: "/seaside/mmiki/seaside/mmiki/A-Page" not found.
Notice the path is duplicated. I figure that this is an error that
occurs after the page time's out. yes?
How can I fix this? Why does this happen? Lukas mentioned a thread to
search for but I can't find that message (sorry!) and I haven't
found a
good explanation.
Can anyone point me in the right direction?
Again this can be solved with a RewrtieRule that you put before
RewriteCond in your Apache config:
RewriteRule $/seaside/mmiki/(.*)^ http://localhost:9999/$1
[proxy,last]
The reason you need this is a problem of Seaside redirecting to the
wrong URL when a session has a timeout. Unfortunately this is not
that easy to fix. I did several attempts during the development of
2.7, but could not figure out a way that did not break a lot of other
applications altogether. Anyway, for now the above RewriteRule does
the trick.
10 p.m.
Actually, one would think that the solution above
would work, but
in my
case it does not. In fact, sometimes I get the path repeated 3 times!
That's strange this never occurred to me. Did you check the Apache
logs (access.log, error.log, rewrite.log)?
What I did was bypass apache, set the Pier app default
timeout low and
go at it to see if I could find something useful.
You could also evaluate
WARegistry clearAllHandlers
to expire all existing session at once ;)
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
10:11 p.m.
Lukas Renggli wrote:
Absolutely, that's what I've been looking at so long... ;-(
Yeah, I'll add that to my ritual. Thanks!
Actually, one
would think that the solution above would work, but
in my
case it does not. In fact, sometimes I get the path repeated 3 times!
That's strange this never occurred to me. Did you check the Apache
logs (access.log, error.log, rewrite.log)?
What I did was bypass apache, set the Pier app
default timeout low and
go at it to see if I could find something useful.
You could also evaluate
WARegistry clearAllHandlers
to expire all existing session at once ;)
Lukas
--
brad fuller
http://www.Sonaural.com/
+1 (408) 799-6124
20 Mar
20 Mar
12:57 a.m.
Lukas Renggli wrote:
It would help to find this problem if I understood more of what Seaside
is suppose to do when there is a page time-out. Can anyone explain the
logic at page-time out for seaside?
=======================
For those interested (I suppose it's only me), Here are traces from the
rewrite log with different rewrite rules.
Modules loaded:
rewrite_module
proxy_module
proxy_http_module
No cache modules loaded
*No* other "proxy" directives used except below
*===TRACE 1=====
*ProxyPreserveHost On
RewriteEngine ON
RewriteRule ^/seaside/files/(.*)$ http://localhost:9999/seaside/files/$1
[proxy,last]
RewriteCond /home/web/mmiki/%{REQUEST_FILENAME} !-f
RewriteRule ^/(.*)$ http://localhost:9999/seaside/mmiki/$1 [proxy,last]
Result: at page timeout, it appears that seaside writes the path to the
Pier app, resulting in a duplicated path
[Start rewrite engine on request]
(2) init rewrite engine with requested uri /DonsTestPage
[is there a match with first rule?]
(3) applying pattern '^/seaside/files/(.*)$' to uri '/DonsTestPage'
[nope, check next rule]
(3) applying pattern '^/(.*)$' to uri '/DonsTestPage'
[yep, look at the condition before this]
(4) RewriteCond: input='/home/web/mmiki//DonsTestPage'
pattern='!-f' => matched
[nope, this isn't a local file, so rewrite it]
(2) rewrite /DonsTestPage ->
http://localhost:9999/seaside/mmiki/DonsTestPage
[and send it to seaside with the proper path]
(2) forcing proxy-throughput with
http://localhost:9999/seaside/mmiki/DonsTestPage
(1) go-ahead with proxy request
proxy:http://localhost:9999/seaside/mmiki/DonsTestPage [OK]
[but, then it continues - THIS MUST BE THE TIME OUT]
[Start rewrite engine on request]
(2) init rewrite engine with requested uri
/seaside/mmiki/DonsTestPage
[is there a match with first rule?]
(3) applying pattern '^/seaside/files/(.*)$' to uri
'/seaside/mmiki/DonsTestPage'
[nope, check next rule]
(3) applying pattern '^/(.*)$' to uri '/seaside/mmiki/DonsTestPage'
[yep, look at the condition before this]
(4) RewriteCond: input='/home/web/mmiki//seaside/mmiki/DonsTestPage'
pattern='!-f' => matched
[nope, this isn't a file, so rewrite it]
(2) rewrite /seaside/mmiki/DonsTestPage ->
http://localhost:9999/seaside/mmiki/seaside/mmiki/DonsTestPage
[and send it on it's way]
(2) forcing proxy-throughput with
http://localhost:9999/seaside/mmiki/seaside/mmiki/DonsTestPage
(1) go-ahead with proxy request
proxy:http://localhost:9999/seaside/mmiki/seaside/mmiki/DonsTestPage [OK]
*===TRACE 2=============*
If a rewrite rule is added to eliminate the path at the time out:
================
ProxyPreserveHost On
RewriteEngine ON
RewriteRule ^/seaside/files/(.*)$ http://localhost:9999/seaside/files/$1
[proxy,last]
RewriteRule ^/seaside/mmiki/(.*)$ http://localhost:9999/$1 [proxy,last]
RewriteCond /home/web/mmiki/%{REQUEST_FILENAME} !-f
RewriteRule ^/(.*)$ http://localhost:9999/seaside/mmiki/$1 [proxy,last]
Result: 2nd rewrite rule catches path but seaside really needs the path
to the Pier app.
(2) init rewrite engine with requested uri /DonsTestPage
(3) applying pattern '^/seaside/files/(.*)$' to uri '/DonsTestPage'
(3) applying pattern '^/seaside/mmiki/(.*)$' to uri '/DonsTestPage'
(3) applying pattern '^/(.*)$' to uri '/DonsTestPage'
(4) RewriteCond: input='/home/web/mmiki//DonsTestPage' pattern='!-f' =>
matched
(2) rewrite /DonsTestPage ->
http://localhost:9999/seaside/mmiki/DonsTestPage
(2) forcing proxy-throughput with
http://localhost:9999/seaside/mmiki/DonsTestPage
(1) go-ahead with proxy request
proxy:http://localhost:9999/seaside/mmiki/DonsTestPage [OK]
(2) init rewrite engine with requested uri /seaside/mmiki/DonsTestPage
(3) applying pattern '^/seaside/files/(.*)$' to uri
'/seaside/mmiki/DonsTestPage'
(3) applying pattern '^/seaside/mmiki/(.*)$' to uri
'/seaside/mmiki/DonsTestPage'
(2) rewrite /seaside/mmiki/DonsTestPage ->
http://localhost:9999/DonsTestPage
(2) forcing proxy-throughput with http://localhost:9999/DonsTestPage
(1) go-ahead with proxy request proxy:http://localhost:9999/DonsTestPage
[OK]
*===TRACE 3===========*
But,of course seaside needs the path to the app.
If the rewrite rule is written to add the path for the timeout
It works fine. Except the URL in the browser adds the path
===============
ProxyPreserveHost On
RewriteEngine ON
RewriteRule ^/seaside/files/(.*)$ http://localhost:9999/seaside/files/$1
[proxy,last]
RewriteRule ^/seaside/mmiki/(.*)$ http://localhost:9999/seaside/mmiki/$1
[proxy,last]
RewriteCond /home/web/mmiki/%{REQUEST_FILENAME} !-f
RewriteRule ^/(.*)$ http://localhost:9999/seaside/mmiki/$1 [proxy,last]
Result: 2nd RewriteRule adds the correct path, but the URL the client
receives includes the path. Not pretty.
(2) init rewrite engine with requested uri /DonsTestPage
(3) applying pattern '^/seaside/files/(.*)$' to uri '/DonsTestPage'
(3) applying pattern '^/seaside/mmiki/(.*)$' to uri '/DonsTestPage'
(3) applying pattern '^/(.*)$' to uri '/DonsTestPage'
(4) RewriteCond: input='/home/web/mmiki//DonsTestPage' pattern='!-f' =>
matched
(2) rewrite /DonsTestPage ->
http://localhost:9999/seaside/mmiki/DonsTestPage
(2) forcing proxy-throughput with
http://localhost:9999/seaside/mmiki/DonsTestPage
(1) go-ahead with proxy request
proxy:http://localhost:9999/seaside/mmiki/DonsTestPage [OK]
(2) init rewrite engine with requested uri /seaside/mmiki/DonsTestPage
(3) applying pattern '^/seaside/files/(.*)$' to uri
'/seaside/mmiki/DonsTestPage'
(3) applying pattern '^/seaside/mmiki/(.*)$' to uri
'/seaside/mmiki/DonsTestPage'
(2) rewrite /seaside/mmiki/DonsTestPage ->
http://localhost:9999/seaside/mmiki/DonsTestPage
(2) forcing proxy-throughput with
http://localhost:9999/seaside/mmiki/DonsTestPage
(1) go-ahead with proxy request
proxy:http://localhost:9999/seaside/mmiki/DonsTestPage [OK]
This is the desired path, but the URL in the client browser is incorrect:
It is:
http://igor:8080/seaside/mmiki/DonsTestPage?command=PRViewCommand&view=…
It should not have the "/seaside/mmiki" path, And, actually, this
doesn't work when you want to go back to the top in Pier after timeout.
Actually, one
would think that the solution above would work, but
in my
case it does not. In fact, sometimes I get the path repeated 3 times!
That's strange this never occurred to me.
6:39 a.m.
http://cmsbox.netstyle.ch/ seems to exhibit a problem too when it times out.
Although, it looks more like it uses ProxyPass instead of Rewrite rules.
24 Mar
24 Mar
8:14 a.m.
http://cmsbox.netstyle.ch/ seems to exhibit a problem
too when it
times out. Although, it looks more like it uses ProxyPass instead
of Rewrite rules.
Thanks, this is fixed now.
No, it uses RewriteRules. It is basically the same setup everywhere.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
11:20 p.m.
Lukas Renggli wrote:
Can you tell me how you fixed it. I STILL have the same problems as
before. I cannot figure i out.
--
brad fuller
http://www.Sonaural.com/
+1 (408) 799-6124
http://cmsbox.netstyle.ch/ seems to exhibit a problem too when it
times out. Although, it looks more like it uses ProxyPass instead
of Rewrite rules.
Thanks, this is fixed now.
No, it uses RewriteRules. It is basically the same setup everywhere.
26 Mar
26 Mar
9:16 a.m.
http://cmsbox.netstyle.ch/ seems to exhibit a problem
too when it
times out. Although, it looks more like it uses ProxyPass instead
of Rewrite rules.
Thanks, this is fixed now.
No, it uses RewriteRules. It is basically the same setup everywhere.
28 Mar
28 Mar
12:48 a.m.
Lukas Renggli wrote:
Can you tell me how you fixed it. I STILL have the same problems as
before. I cannot figure i out.
I applied this rewrite rule as the first one:
RewriteRule ^/seaside/pier(.*)$ http://www.lukas-renggli.ch$1 [R,L]
Thanks Lukas, that seems to work.
The difference is the [R] from before to redirecting it back to the
domain name once again.
Again, thanks! What a headache that was!
brad
--
brad fuller
http://www.Sonaural.com/
+1 (408) 799-6124
http://cmsbox.netstyle.ch/ seems to exhibit a problem too when it
times out. Although, it looks more like it uses ProxyPass instead
of Rewrite rules.
Thanks, this is fixed now.
No, it uses RewriteRules. It is basically the same setup everywhere.
6239
days inactive
6250
days old
12 comments
2 participants
participants (2)
-
Brad Fuller -
Lukas Renggli