Yes, this is exactly what I meant about using cache-control private, since Vary support can be spotty in some proxies and servlet containers. One question: does this per-browser behavior infect the iframe code path too? If that's the case then we'll have to add Vary headers all over the place.
If that's the case then I'd say this technique is a net-loss. The amount of JS code in question isn't *that* big. 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 > > >
