[Squeak-fr] Question relative a Seaside.

Cédrick Béler cbeler at enit.fr
Mer 26 Avr 10:52:34 UTC 2006


hello ;)

skweekml at freesurf.fr a écrit :

> Bonjour,
>
> J'ai envie de faire un petit projet avec Seaside, seulement je ne sais 
> pas si je peux utiliser le framework avec Apache.

si tu peux avec le mod_proxy je crois... et les rewriting rules...
mais en fait seaside utilise Kom (Comanche) et on peut se passer d'Apache...

J'ai joint 2 fichier ou je récupérais des info a ce sujet... désolé j 
'ai pas le temps de retrouver les liens réels ;)

bye

Cédrick
-------------- section suivante --------------
By the way, just in case this helps someone besides me (and since I wasn't able to find a complete answer to this
question on the list archives -- feel free to chastise me off-list if you think this was OT).. I finally got my reverse
proxy running perfectly with Seaside and thought I'd put my proxy settings out for anyone else that happens
to want to do this now or in the future.. Keep in mind that these settings are for use with Apache2 (not 1.x)
and would need work to be used on an older Apache server..  Hopefully someone will find this of interest..

############################################################
# Setup the Seaside Reverse Proxy
# derived from the following sites:
#    http://www.wlug.org.nz/ApacheReverseProxy
#    http://www.apacheweek.com/features/reverseproxies
############################################################
ProxyRequests                   off
ProxyPass                       /seaside        http://localhost:8008/seaside/go/myapp
ProxyHTMLURLMap                 http://www.yourdomain.com/seaside /seaside

<Location /seaside>
       ProxyPassReverse        http://localhost:8008/seaside/go/myapp/
       SetOutputFilter         proxy-html
       ProxyHTMLURLMap         /seaside/go/            /seaside/
       ProxyHTMLURLMap         /seaside/go/myapp/    /seaside/
       RequestHeader           unset Accept-Encoding
</Location>

#ProxyHTMLLogVerbose On
#       LogLevel Debug

So, with the above settings, if you visit http://www.yourdomain.com/seaside, you'll get a mapping
from your Apache webserver over to http://localhost:8008/seaside/go/myapp and all pages will
get their internal links rewritten to look something like :

http://www.yourdomain.com/seaside/myapp?4&_k=VrunGRvS&_s=SOPzHyEkmNFVrnJp

Now, obviously if you wanted to have multiple seaside apps running, you'd have to tailor this a bit.

Hope this helps... :-) 

--
Brad Fuller wrote:

> Thanks Rick, promises to be very helpful in the future for me.
> Are there any modules that need to be loaded as well? I try to keep them
> to the bare minimum.
>   

Here's my section from higher up in my apache2 httpd.conf file :

LoadModule headers_module       modules/mod_headers.so
LoadModule proxy_module         modules/mod_proxy.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
LoadModule proxy_ftp_module     modules/mod_proxy_ftp.so
LoadModule proxy_http_module    modules/mod_proxy_http.so
LoadFile    /usr/lib/libxml2.so
LoadModule proxy_html_module    modules/mod_proxy_html.so
LoadModule rewrite_module       modules/mod_rewrite.so
LoadModule php4_module          modules/libphp4.so

Lukas Renggli wrote:

> Interesting. Why do you use Apache to rewrite all the links inside the
> HTML and not let Seaside produce the actual URLs right from the
> beginning?
>
>   

I guess after reading through the various old posts on the Seaside list I was/am under the
impression that Seaside needs to use one of the built in webservers that are provided by
either Squeak or VW... If I can decouple Seaside and have it somehow talk to Apache
directly, I'm all for that, but am not sure if it's possible or how to do it..

Also, when I re-configure my Seaside application to change the Base Path to something other
than /seaside/go/myapp, it always jumps right back to that value and never seems to interested
in taking something else, so I've given up on fiddling with it..   Just keep in mind that I'm fairly
new to Seaside/Smalltalk and am likely to be doing something that may not make much sense
to someone else more familiar with this environment.  Please enlighten me if I'm barking down
the wrong tree...

-- Rick 
>either Squeak or VW... If I can decouple Seaside and have it somehow
>> talk to Apache
>> directly, I'm all for that, but am not sure if it's possible or how to
>> do it..


There is WAModList, but I don't know if it has ever been used.

Lukas


--------------------------------------------------------------------
>I'd beg to differ on the above comment about being "dead easy".. I tried
>> getting mod_proxy up and going last week under Apache2 and spent quite a
>> bit of time monkeying around with the proxy rules for the reverse
>> proxy.. I got it up and running
>> for the initial ping of a Seaside site, but URLs that map back to
>> Seaside are still broken, and I've given up trying to fix them
>> for now until I've got a working app up and going.  As usual, YMMV!


Did you enable "ProxyPreserveHost On" (it enabled Seaside to get
absolute-urls correctly)? Did you set the correct base-path in the
Seaside application configuration?

My rewrite-rule looks like:

	RewriteEngine On
	RewriteRule ^/(.*)$ http://localhost:8080/seaside/app/$1 [P,L]

Cheers,
Lukas


Nope.. no "ProxyPreserveHost on" is in my httpd.conf file.. I was actually trying to follow a document that
was suggested here (see link below) last year (if I recall) for getting a reverse proxy up and running to allow
Seaside to appear on an Apache served page/virtual host.. It looks like you're using mod-rewrite as
opposed to mod_proxy.. What's the general consensus on which is better/easier?  I'll argue that mod-proxy
is not very easy to setup in my opinion, but that may be due to the fact that I know as little Apache crud
as I need to know to get by.  If you don't mind, can you enlighten me (and hopefully others) on what settings
should be used to get Apache to serve Seaside pages with working self-referential links?

Thanks!

-- Rick 


>It looks like you're using mod-rewrite as opposed to mod_proxy..
>> What's the general consensus on which is better/easier?  I'll argue
>> that mod-proxy is not very easy to setup in my opinion,


I never used mod_proxy, so I can comment on this. However the rewrite
rule I gave as an example is also doing a proxying (i even think
internally it is using mod_proxy):

RewriteRule ^/(.*)$ http://localhost:8080/seaside/app/$1 [P,L]

^/(.*)$ is a regular expression matching the incoming request-url, in
this case it matches everything.

http://localhost:8080/seaside/app/$1 tells apache how to rewrite the
url, in this case it simply takes everything after the slash $1 and
appends it to http://localhost:8080/seaside/app/.

[P,L] tells apache what to do with the rewritten url. P(roxy) means it
should proxy the request to the generated url. L(ast) means it should
not try to apply any other rule, if this one matched.

For this example you need to go to the config-interface of your
application and set the base-path to "/". That's all.

This was a very simple example, where everything was passed to one
Seaside application in one Squeak image. You can also think of
something that passes different paths to different applications and
images (note the different ports):

RewriteRule ^/foo/(.*)$ http://localhost:8080/seaside/foo/$1 [P,L]
RewriteRule ^/bar/(.*)$ http://localhost:8080/seaside/bar/$1 [P,L]
RewriteRule ^/(.*)$ http://localhost:9090/seaside/zork/$1 [P,L]

For the above applications you need to set the base paths to "/foo",
"/bar" and "/".

You might also want to serve static files for certain sub-directories,
e.g. the first rule matches any URL starting with /resources/, leaves
it unmodifies - and is the last applied rule. So only request not
starting with /resources/ will be passed to the seaside application,
else they are handled by apache internally.

RewriteRule ^/resources/.*$ - [L]
RewriteRule ^/(.*)$ http://localhost:9090/seaside/zork/$1 [P,L]

Tell me if you need more examples.

Actually I prefer programming in Squeak than writing rewrite-scripts,
but it can be fun from time to time: as an example rewrite-maps can be
fun for mass-seaside-app hosting  ;-) 

Lukas

Lukas Renggli wrote:

> [ ... ]
> RewriteRule ^/foo/(.*)$ http://localhost:8080/seaside/foo/$1 [P,L]
> RewriteRule ^/bar/(.*)$ http://localhost:8080/seaside/bar/$1 [P,L]
> RewriteRule ^/(.*)$ http://localhost:9090/seaside/zork/$1 [P,L]
>   

Lukas,

Is it safe to assume that using the above rewrite rules won't get you past a setup where the Seaside webserver
(aka squeak) is hidden behind a firewall and not directly accessible to the public, and that is when you'd use a
reverse proxy setup which does the extra steps to be the go-between the user's browser session and the "other"
web server (in this case squeak's).. I believe that's ultimately the decision maker here (and perhaps slightly off topic)
on whether to use a reverse proxy or just rewriting rules like those above.  Please correct me if I'm wrong.. In the meantime
I'll continue looking for ways to fix my reverse proxy setup so it works for all links..

-- Rick 

>Is it safe to assume that using the above rewrite rules won't get you
>> past a setup where the Seaside webserver
>> (aka squeak) is hidden behind a firewall and not directly accessible to
>> the public, and that is when you'd use a
>> reverse proxy setup which does the extra steps to be the go-between the
>> user's browser session and the "other"
>> web server (in this case squeak's)..


Yes, that's the case, if your rewrite rules are not buggy and we
assume that there are no security holes in Apache. I mean the rewrite
rule hardcodes the target port, there is no way to change that from
the URL.

If have your firewall is blocking access to all ports except 80, your
images shouldn't be accessible directly but only trough apache.


>> I believe that's ultimately the
>> decision maker here (and perhaps slightly off topic)
>> on whether to use a reverse proxy or just rewriting rules like those
>> above.  Please correct me if I'm wrong.. In the meantime
>> I'll continue looking for ways to fix my reverse proxy setup so it works
>> for all links..


I don't see an advantage of not using rewrite rules, not even security
wise. However that question should maybe be answered by an Apache
expert (not an Apache user like I am).

Lukas

--

----
>
> I don't get it. If you want to do load balancing you need 1
> application running on multiple images, else I wouldn't call it load
> balancing, right?


I mean, I will use multiple servers (hardware, maybe order of 100  servers, current existing service uses almost 400 server cluster).  Per server, I asked which is better configuration. Multiple Image/ single server or Single Image/Single server. Sorry for my poor  english. T_T

>
>> What I want to write in Seaside is actually not for performance. But
>> I want to know general guideline for performance in seaside  application.
>
>
> What is your question then? I don't understand? Can you give an  example?


For example, general database based PHP application can process  several thousand of request per second(on linux with modern server  hardware) if properly configured(content caching middleware for  database and etc). I just want to know this kind of empirical  guideline for Seaside application. Maybe actual deployment case study  will help me very much.

Thanks in advance. 


--------------------------------------------------------------------


>Hi,
>> It works... but I have a strange behavior with IE6. When I submit the form, the file is uploaded, but the browser display a DNS error. Works well with firefox!
>> I use seaside for VW...
>> Any idea?
>> Thanks,
>> Luc


Is the application behind a apache reverse proxy? HTTP persistent
connections caused trouble for me with apache + reverse proxy +
windows + ie.
-------------- section suivante --------------
>I believe what you're talking about has to do with a reverse proxy... 
>> Basically using Apache as a front-end
>> to your Squeak (or VW) image running some form of a Seaside 
>> application.. I tried doing the Apache reverse proxy and had 
>> difficulty setting it up properly and after countless hours 
>> wasted debugging the issue, I resorted to using Squid as my 
>> reverse proxy instead and using a small Python script to 
>> re-write URL's on the fly.. It works great and I believe it 
>> completely negates the issue you mentioned above..
>> 
>> -- Rick


Well, other than this issue, it's working great, and I don't want to
start down another path, I like this approach, my basic setup I copied
from Lucas, he posted a while back, looks something like this...

<VirtualHost *:80>
	ServerAdmin ramon.leon at sentorsa.com
	ServerName scriptaculous.sentorsa.com
	RewriteEngine On
	RewriteRule ^/(.*)$
http://scriptaculous.sentorsa.com:94/seaside/scriptaculous/$1 [P,L]
</VirtualHost>

Lucas, if you're around, have an opinion?

---

We have a setup like this, but with an additional rule - something like

    ProxyPassReverse /seaside/scriptaculous/ http:// scriptaculous.sentorsa.com/

I'm not certain this is exactly what you need (especially in the  particulars - I cribbed this from one of our conf files), but  hopefully it is a good starting point.

(I also don't know if you need additional modules or the like.)

Hope this helps,
Ben Schroeder 

----




More information about the Squeak-fr mailing list