The only things that might actually work through a CDN are calls to /js (not today, but after I apply the big patch this will be safe as long as you're using versioned urls). Calls to /ifr have poor cache performance characteristics unless there are no user prefs (and you'd also have to use cache busting here as well). There's a major security issue regarding /ifr caching as well that I'm not going to discuss on the public list; I believe you spoke with Brian Eaton about this a few weeks ago?
For JS, you can already configure the url. The stock CrossServletState should probably be modified to include support for a js-servlet-prefix config param. Alternatively, if you have a custom CrossServletState, you could just do this the way you want right now in getJsUrl() Within the next week or two, Orkut will be using www.orkut.gmodules.com/ig/js... to serve javascript. I suspect hi5 could do something similar, just substituting your CDN for the js prefix. Other potential CDN candidates: - Open proxy (kind of scary, might have to think about this one): - Static content (if you're actually using it in production) Definitely not CDN'able: - rpc_relay (requires same domain) - /proxy?output=js (requires same domain / usually POST requests) On Mon, Mar 10, 2008 at 5:45 PM, Paul Lindner <[EMAIL PROTECTED]> wrote: > Has anyone given thought to how to support cached vs. non cached requests > for a production environment. > > We want to route cacheable requests through our CDN and uncacheable > requests > direct to the origin servers. > > I assume that I can set document.domain to a common domain name and create > subdomains for cacheable and uncacheable hosts. > > *.cdn.hi5modules.com --> via cdn > *.direct.hi5modules.com --> direct > > So we¹d send post requests, etal via direct and iframe rendering and > cached > requests via the CDN. > > Thoughts? > > -- ~Kevin
