Serving static resources

Some of my applications use the same css and images files.
Rather than include them in the war of every application I think it is
better to serve them by apache for example.
So I’ve created a ‘css’ dir and a ‘img’ dir under apache document root
and put my css and images files.
How can I call them from my applications?

Create a symbolic links in $RAILS_ROOT/public.

On 31 December 2010 20:32, Hirotsugu A. [email protected] wrote:

Create a symbolic links in $RAILS_ROOT/public.

I don’t like this solution.
I think it is better to call the static resources directly using
stylesheet html tag.
It seems that rails stylesheet_link_tag doesn’t allow to call external
resources, for example http://myhost/static.

On 31 December 2010 21:09, Hassan S. [email protected]
wrote:

On Fri, Dec 31, 2010 at 11:40 AM, Mauro [email protected] wrote:

It seems that rails stylesheet_link_tag doesn’t allow to call external
resources, for example http://myhost/static.

Why would you think that? The API docs even show it used that way.

I see, I have to use stylesheet_path too.
Now my question is: is it better to serve common static files by a web
server, apache for example, or share a directory?

On Fri, Dec 31, 2010 at 11:40 AM, Mauro [email protected] wrote:

It seems that rails stylesheet_link_tag doesn’t allow to call external
resources, for example http://myhost/static.

Why would you think that? The API docs even show it used that way.


Hassan S. ------------------------ [email protected]
twitter: @hassan

On Fri, Dec 31, 2010 at 12:29 PM, Mauro [email protected] wrote:

I see, I have to use stylesheet_path too.

Sorry, I don’t understand that comment, but…

Now my question is: is it better to serve common static files by a web
server, apache for example, or share a directory?

? “better” in what sense? performance, scaling, deployment, ______?

And have you thought about just using an ‘asset host’?


Hassan S. ------------------------ [email protected]
twitter: @hassan

On Fri, Dec 31, 2010 at 1:55 PM, Mauro [email protected] wrote:

Now my question is: is it better to serve common static files by a web
server, apache for example, or share a directory?

? “better” in what sense? performance, scaling, deployment, ______?

Performance and scaling

Do you believe, because you have actual evidence, that users of
your app are being negatively impacted by serving these static files
in the default way? (cf. “premature optimization” )

If so, set up a virtual ‘asset host’ on your current system and test.
If you still have problems, move it to a separate system, or systems.
If you still have problems, bust out the checkbook and use a CDN. :slight_smile:

FWIW,

Hassan S. ------------------------ [email protected]
twitter: @hassan

On 31 December 2010 23:24, Hassan S. [email protected]
wrote:

your app are being negatively impacted by serving these static files
in the default way? (cf. “premature optimization” )

There is no evidence of poor performance but I’ve the same css and
images files used in various applications so I’ve to duplicate all
these files.
I prefer to have a single point of access for my common files.

p.s. sorry for my bad english

On 31 December 2010 21:44, Hassan S. [email protected]
wrote:

On Fri, Dec 31, 2010 at 12:29 PM, Mauro [email protected] wrote:

I see, I have to use stylesheet_path too.

Sorry, I don’t understand that comment, but…

Now my question is: is it better to serve common static files by a web
server, apache for example, or share a directory?

? “better” in what sense? performance, scaling, deployment, ______?

Performance and scaling

On 31 December 2010 23:41, jeffContext [email protected]
wrote:

Consider setting up an app dedicated to serving your common assets. I recommend
the jammit gem. http://documentcloud.github.com/jammit/

It will merge and compress the javascript files that you specify, which you can
then include in your other apps with a single html script tag. Similarly for css.

Merging assets is very good for client-side performance. Jammit also has some
features for server side performance. (e.g., helping you manage browser caching,
pre-caching a gzipped version, etc.)

But what’s wrong serving these common files by a web server like apache?
I have tomcat anche apache in the same server.

Consider setting up an app dedicated to serving your common assets. I
recommend the jammit gem. http://documentcloud.github.com/jammit/

It will merge and compress the javascript files that you specify, which
you can then include in your other apps with a single html script tag.
Similarly for css.

Merging assets is very good for client-side performance. Jammit also has
some features for server side performance. (e.g., helping you manage
browser caching, pre-caching a gzipped version, etc.)

On Fri, Dec 31, 2010 at 2:33 PM, Mauro [email protected] wrote:

There is no evidence of poor performance but I’ve the same css and
images files used in various applications so I’ve to duplicate all
these files.
I prefer to have a single point of access for my common files.

Then why not just use the Rails standard ‘asset host’ capability?

Simple to set up; serve it via Tomcat, Apache httpd, nginx, whatever
suits you.


Hassan S. ------------------------ [email protected]
twitter: @hassan

On Fri, Dec 31, 2010 at 3:09 PM, Mauro [email protected] wrote:

There is no evidence of poor performance but I’ve the same css and
images files used in various applications so I’ve to duplicate all
these files.
I prefer to have a single point of access for my common files.

Then your actual reason relates to deployment, rather than either
performance or scaling, right?

Then why not just use the Rails standard ‘asset host’ capability?

Because I didn’t know asset host.
Now I know :slight_smile:

Cool. Best of luck, an happy new year :slight_smile:


Hassan S. ------------------------ [email protected]
twitter: @hassan

On 1 January 2011 00:45, Hassan S. [email protected]
wrote:

Then why not just use the Rails standard ‘asset host’ capability?

Because I didn’t know asset host.
Now I know :slight_smile:

Cool. Best of luck, an happy new year :slight_smile:

A problem:
if I put, for example, ActionController::Base.asset_host =
assets.example.com”, I link all of my assets to assets.example.com.
So my css and my images files are taken from http://assets.example.com/.
But if I want some taken from assets.example.com and some taken from
my standard public directory?
I want take the common files from assets.example.com and application
specific files from the standard public directory.

On 1 January 2011 00:06, Hassan S. [email protected]
wrote:

On Fri, Dec 31, 2010 at 2:33 PM, Mauro [email protected] wrote:

There is no evidence of poor performance but I’ve the same css and
images files used in various applications so I’ve to duplicate all
these files.
I prefer to have a single point of access for my common files.

Then why not just use the Rails standard ‘asset host’ capability?

Because I didn’t know asset host.
Now I know :slight_smile:

On 1 January 2011 11:46, Mauro [email protected] wrote:

So my css and my images files are taken from http://assets.example.com/.
But if I want some taken from assets.example.com and some taken from
my standard public directory?
I want take the common files from assets.example.com and application
specific files from the standard public directory.

Perhaps the solution is:

ActionController::Base.asset_host = Proc.new { |source|
if source.starts_with?(‘/images’)

Hi all!

A bit late in the discussion, but I FINALLY found how to combine apache
with modproxy+modrewrite to server our needs.

The goal is to have apache in front on port 80, and have one or more
instances for an application in the back serving dynamic content. The
application may have page caching enabled, resulting in generated
“static” files, that may be expired (deleted) periodically or by an
observer. In out cases, all the static files have been located in the
same place, but our solution allows for static content to be in several
locations.

You need to enable modproxy and modrewrite in apache2. Here is our
config file to be placed in sites-available and linked from
sites-enabled, or put in conf.d in the apache config directory.

The two RewriteCond+RewriteRule lines can be repeated for every location
of static files you want to serve.

<VirtualHost *:80>
ServerName example.com
ServerAlias www.example.com
ServerAdmin [email protected]
DocumentRoot /usr/local/example_application/public
CustomLog /var/log/apache2/example_application-access.log combined
ErrorLog /var/log/apache2/example_application-error.log

ProxyRequests off

<proxy *>
Order deny,allow
Allow from all

RewriteEngine on

RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_URI} -f
RewriteRule ^(.+) %{DOCUMENT_ROOT}/$1 [L]

ProxyPass / http://localhost:3000/
ProxyPassReverse / http://localhost:3000/

On 2010-12-31, at 20:23, Mauro wrote:

http://xircles.codehaus.org/manage_email


With kind regards
Uwe K.
Kubosch Consulting
[email protected]