Nuts - wrong mailing list.. I will resend on the spec one, please disregard shindig folks.
On Tue, Apr 1, 2008 at 2:12 PM, Cassie <[EMAIL PROTECTED]> wrote: > 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 > > > > > > >
