I can't quite figure out what the resolution of this issue was. Did we decide on anything? Are there any proposals on the table?
- Cassie On Wed, Feb 27, 2008 at 12:17 PM, Reinoud Elhorst <[EMAIL PROTECTED]> wrote: > 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 > > >
