On Wed, Jun 17, 2009 at 3:42 PM, Ian Hickson<i...@hixie.ch> wrote: > On Wed, 17 Jun 2009, Tyler Close wrote: >> >> For those at work, watching the show, here's the beast we're looking >> for: >> >> 1. A firewalled intranet, where servers behind the firewall have >> routable IP addresses (ie: not 10.*, or 192.168.*) >> 2. *and* where servers on the Internet are *not* accessed via an HTTP proxy >> 3. *and* there is a resource on a server behind the firewall that >> depends solely on connectivity for authentication (if you can get >> packets to me you're allowed to use me) >> 4. *and* where this resource does *not* treat GET and POST as equivalent >> methods >> 5. *and* where this resource checks that the Content-Type header on a >> POST request is either "application/x-www-form-urlencoded" or >> "text/plain" >> >> If you find a resource that meets the above criteria, then you've got a >> resource that may be secure under CORS, but not under my alternate >> proposal. Do we have any winners? > > I believe we have such services at Google, though for obvious reasons I > wouldn't want to elaborate on that.
Wow, if you could just confirm their existence, that would do fine. So this resource acts on PUT or DELETE, or POST of a Content-Type other than "application/x-www-form-urlencoded" or "text/plain"? And it checks the Content-Type header? And it doesn't require any user credentials at all? Connectivity is good enough. Is there any way a browser could tell a request is being sent to a server behind your firewall, and not a server on the open Internet? > Is this the propoal to which you refer?: > > http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1011.html Yes. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html