On Wed, May 5, 2010 at 4:05 PM, Marcos Caceres <[email protected]> wrote: > On Wed, May 5, 2010 at 3:59 PM, Scott Wilson > <[email protected]> wrote: >> On 5 May 2010, at 10:40, Robin Berjon wrote: >> >>> On May 4, 2010, at 19:29 , Scott Wilson wrote: >>>> I've just been reading through the WARP spec again, and in particular this >>>> stood out: >>>> >>>> In the default policy, a user agent must deny access to network resources >>>> external to the widget by default, whether this access is requested >>>> through APIs (e.g. XMLHttpRequest) or through markup (e.g. iframe, script, >>>> img). >>>> >>>> I'm not sure if this statement is actually helpful here. While it makes >>>> sense that WARP defines policies that widen access beyond whatever the >>>> UA's default policy may be, is it strictly necessary to define the default >>>> policy? >>> >>> Well, if you think about it a little bit further, is it really necessary to >>> have a way of defining a network access policy, and if so is the content >>> you're distributing the best place to do so? I personally have a somewhat >>> reserved judgement about whether WARP is useful at all. A rather large >>> number of people expressed this requirement, so it was delivered, and it's >>> quite possible that they were right. But it's also possible that they're >>> not which is why I'm happy that it's not part of P+C. >>> >>> If you noticed this because you're working on it for Wookie, I'm not sure >>> that's it's worth the (minimal) effort. WARP makes no sense in a Web >>> context. >> >> We use it to feed the whitelist our server-side proxy service uses; I've >> already implemented it for this admittedly limited purpose in Wookie and it >> seems to work fine. But for the most part access policy is dealt with by >> the browser security model, which is moving towards making such workarounds >> unnecessary in the long run. However, right now we still have a limited UC >> for WARP. >> > > Right: so WARP on the Web is a band-aid solution that requires a > server-side proxy to retrieve content a browser would not normally be > able to access (because of cross-origin restrictions). WARP should not > be used where CORS is available (and WARP through a proxy should be > used with extreme caution on the Web).
Maybe we need a note (or as part of the intro) more clearly explaining the use case for WARP. -- Marcos Caceres Opera Software ASA, http://www.opera.com/ http://datadriven.com.au
