cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <>
Subject Re: [TIPS] Basic configurations of Apache 2.0 for Cocoon 2
Date Wed, 19 Mar 2003 16:22:19 GMT
"Niclas Hedhman" <> wrote:

> On Wednesday 19 March 2003 04:14, Tony Collen wrote:
>> Reading this great article [1] (Thanks Pier!), I realized that the
>> mod_rewrite stuff could possibly be worked around using virtualhosts.  I'm
>> not too familliar with Apache HTTPD 2, but I assume setting up vhosts is
>> not much different.  Would it not make sense to create a
>> host (if you have the access and resources), and serve up all of your
>> images and resources out of there?
>> This would allow you to totally ignore the mod_rewrite nastiness.  The
>> only problem I could see is having to directly reference static resources
>> with the full domain, for example:
>> <img src=""/>
>> Then again, it's not all that much different than
>> <img src="/static/foo.png"/>
>> Since they are both absolute paths. Any thoughts on best practices?
> I, personally, don't like having related content on separate hostnames (I
> don't like rewrites for same reason).
> The links becomes more prone to errors, especially in a mixed environment. If
> I don't have hosts (or depending on rewrites) in the links, I can setup
> offline environments which works (at least to a great degree), improving
> testability by the author.

Sometimes you can't actually avoid it... When you think about huge loads and
static-content geographic distribution... We're testing (for example) Akamai
for our images, and some of our bigger content is already going through

Unfortunately/fortunately, this implies the use of a different hostname,

For our JSPs (right now yes, we use JSPs, aaarrrggghhh), we have a custom
tag rewriting the "src" attribute of <vnu:img src="....">. Depending on the
environment, the server, the client, the image gets rewritten accordingly,
then all our content is synced over onto different machines (local and
remote), so that anyhow, anywhere, this will (should) work transparently for
the author...

Once we move to Cocoon, we'll have to achieve the same functionality...


View raw message