[Seaside] apache + seaside

Ross Boylan RossBoylan at stanfordalumni.org
Sat Nov 26 07:38:30 CET 2005


On Fri, Nov 25, 2005 at 04:04:37PM -0500, David Shaffer wrote:
> Ross Boylan wrote:
> 
> >On Fri, Nov 25, 2005 at 08:36:15AM +0100, Cees De Groot wrote:
> >  
> >
> >>On 11/25/05, Ross Boylan <RossBoylan at stanfordalumni.org> wrote:
> >>    
> >>
> >>>When I enter the first URL I see my application.  However, when I hit
> >>>a button on the form, my browser shows
> >>>http://www.betterworld.us:81/seaside/test and I get the error that the
> >>>URL is not found.
> >>>      
...
> With
> seaside+apache as a proxy you have these options out of the box  (that I
> know of):
> 
>     1) have apache rewrite all URL's coming and going from your
> application (the link that I sent you describes how to do that)
...
> 
> I almost always use 1 since I like to be able to hit the seaside server
> without having to go through the proxy.  In practice I have a separate
> space for seaside apps so the "/seaside" path works just fine for me. 
> It's just a matter of proxying to the right port # (and from SSL to
> non-SSL).  I use this to switch between two production images as well. 
> There is an article floating around on using rewrites to load balance
> with session affinity...I use this basic technique to switch between
> production images (not for load balancing, just to move new sessions to
> a newer version of my software).  If you really want more flexibility
> with URL mappings then you're probably going to have to struggle a bit
> to get there.  Keep us posted ;-)
> 
> David
> 
I've been trying this approach, but without much success.  I can get
the initial screen, but when I hit the form button, I end up with a
URL like http://www.betterworld.us:81/seaside/test (sometimes with
additional stuff tacked on) in the browser and a Not Found error.

I've tried to follow the instructions at the link you indicated, and
have played around with many variants.  I enabled debug logging and
ProxyHTMLLogVerbose, but it didn't help much.  It showed that mod_html
was rewriting stuff in the initial page.

My current variation is (with some other tries commented out)
<VirtualHost 198.144.201.14:81>
	DocumentRoot /var/www/
	ServerName www.betterworld.us

	<Proxy *>
	Order deny,allow
	Allow from all
	</Proxy>
#	LogLevel debug
#	ProxyHTMLLogVerbose On
#	ProxyPass /upj http://localhost:9090/seaside/test
#	ProxyHTMLURLMap http://localhost:9090/seaside/test /upj

	ProxyPass /upj/ http://localhost:9090/seaside/test/
	ProxyHTMLURLMap http://localhost:9090/seaside/test /upj
	<Location /upj/>
	   ProxyPassReverse http://localhost:9090/seaside/test/
	   SetOutputFilter proxy-html
	   ProxyHTMLURLMap /seaside/test/ /upj/
#	   RequestHeader unset Accept-Encoding
	</Location>

#	ProxyPassReverse /upj http://localhost:9090/seaside/test
</VirtualHost>

A couple of points in particular have been unclear to me.  Should I
include the port number at various spots?  And should I use a trailing
slash or not?  For the rules above I entered "upj/" at the end of the
line in my browser.

Enabled modules: proxy, proxy_http, proxy_html, various cache,
headers.  I note that caching was explicitly outside the scope of the
reference you cited; Debian turns it on when proxying is requested.
ProxyRequests are off and ProxyVia is on globally.

If I could capture the traffic going between different spots
(browser-apache-seaside) I think things would be a lot clearer, but
I'm not sure how to do that.

Any ideas, either for how to debug this or how to solve it?

Ross


More information about the Seaside mailing list