Back on the original discussion: I think the proxy-ing Shindig server should behave just like a proxy, including using the HTTP/1.1 proxy headers, at least for the simple (non-oAuth) makeRequests. As Kevin stated before, nothing in the spec says that makeRequest should be proxied or sent through any Sindig/proxy server; I may want to implement it on my container through Flash/ActiveX/browser extension. Adding extra mystery headers that gadget developers come to rely on is therefor bad (or, at least, should be part of the spec, not a Shindig implementation).
So +1 for Paul's: I do like the idea of using correct proxy cache headers. I suggest mandating HTTP/1.1 Via: headers, and highly recommending X-Forwarded-For: On 2/26/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > On Tue, Feb 26, 2008 at 10:21 AM, Kevin Brown <[EMAIL PROTECTED]> wrote: > > Yeah, but not allowing images is pretty much out of the question. You > may as > > well not render gadgets :) > > > I just want to point out that there is a possible distinction that may > or may not be useful, based on your point about the rewriting proxy: > > A gadget may ask, at compile time, for the right to load certain > images. The container could then pre-load these all (or not, or load > them randomly, or whatever), in which case loading the image cannot be > used as a wall-banging channel to the outside world. > > A completely different authority is the authority to load any > arbitrary image from a URL composed at run time, in which case this > constitutes a much more serious outbound channel. > > Ihab > > > -- > Ihab A.B. Awad, Palo Alto, CA >
