Of all the optimizations out there this seems like the least interesting and more disruptive than necessary. The (current) whole of rpc.js is 6285 Jun 8 13:28 ./features/target/classes/features/rpc/rpc.opt.js
Making this 6k private instead of CDN cacheable would mean that I would have to find another 6k to move onto the CDN to insure that I (and others) hit our cold-cache numbers for loading profile / home pages. Do you mind sharing your goals here? What kind of byte-savings are you expecting? Is it not possible to have the browser send a filtering parameter along with the request? The getRelayChannel() function figures out your capabilities based on what the browser can do, not the value of it's UA. For example there are some people that change their User-Agent to (mostly) Internet Explorer to get around server restrictions. These people would get broken nix. I just wonder if there are other ways to achieve the wanted byte savings? On Tue, Jun 9, 2009 at 2:18 PM, John Hjelmstad <[email protected]> wrote: > I'm sold, relying on Cache-Control: private is the better option. > This behavior does affect IFRAME rendering paths as well, though doesn't > necessarily need to. Container-side rpc can be optimized without > gadget-side > rpc, since gadgets.rpc(function getRelayChannel()) will return the same > value on each side. > > As Brian mentions, every code path in GadgetRenderingServlet sets > Cache-Control: private[,*] (except nocache=1, not an issue), so the > potential effects are limited to JsServlet. > > So 1. Admittedly, any given deployment will likely see higher JsServlet > traffic if choosing to opt into this feature; 2. this suggests that > JsLibrary field isBrowserSpecific should be added, with JsServlet signaling > noProxy behavior in caching headers when this bit is true for any library > it > emits. > > John > > On Tue, Jun 9, 2009 at 1:53 PM, Brian Eaton <[email protected]> wrote: > > > I don't trust the vary header any farther than I can spit. > > > > For example, at least one version of IE interprets a Vary header with > > any value other than user-agent to mean "OMG, I don't understand, > > don't cache this": > > http://marc.info/?l=apache-modgzip&m=103958533520502&w=2 > > > > In a comment to Mark's blog post, he mentions other implementation > issues: > > > > "More complex situations -- e.g., with multiple Vary headers and > > multiple request headers -- caused problems on a number of > > implementations (i.e., they'd return the wrong thing)." > > > > IMHO, we should stick to "cache-control: private." > > > > We need that on most iframes anyway, so this keeps the cache-control > > changes from rippling out quite so far. > > > > On Tue, Jun 9, 2009 at 1:44 PM, John Panzer<[email protected]> wrote: > > > This seems relevant: http://www.mnot.net/blog/2007/06/20/proxy_caching > > > (It appears that Vary: is fairly safe in the sense that caches that > don't > > > deal with it nicely -- e.g., caching variants -- will just mark the > > content > > > as uncacheable. Though I don't think this was rigorously tested.) > > > > > > -- > > > John Panzer / Blogger > > > [email protected] / abstractioneer.org < > http://www.abstractioneer.org/> > > / > > > @jpanzer > > > > > > > > > > > > On Tue, Jun 9, 2009 at 1:25 PM, <[email protected]> wrote: > > > > > >> Hi Paul: > > >> > > >> You're absolutely right. Vary: User-Agent; is preferable to me. Do you > > >> have any reason in mind for why Cache-Control: private in addition to > or > > >> instead of Vary would be preferable? Ie. common support by various > CDNs. > > >> > > >> I've been thinking how best to link service of custom rpc to setting > > >> this header. Ultimately JsServlet or a Filter needs to do so. Thoughts > > >> on this? The best idea I had was to add something like > > >> isBrowserSpecific() to JsLibrary so that the relevant output code > > >> (gadget rendering, js servlet) could act accordingly. > > >> > > >> Kevin - re: StringBuffer, comment isn't particularly prescriptive so > > >> I'll assume the complaint is use of StringBuffer rather than > > >> StringBuilder. If so, fixed. If not, let me know. > > >> > > >> > > >> http://codereview.appspot.com/63210 > > >> > > > > > >
