Le vendredi 20 septembre 2013 à 17:28 +1000, Rich Tibbett a écrit : > So there are a number of directions we could take this in: > > 1. Focus the specification around a CORS-only solution. CORS is an > accepted mechanism to allow cross-origin communication on the web and > could work well in the local network environment also. The problem > with adopting a CORS-only approach is we have zero devices currently > ready to step in to this brave new world with us. A specification that > allows you to connect with precisely zero network services will not be > useful. I think that no matter what, the spec should support a CORS-based approach. > 2. Support whitelisting of specific local network services in the user > agent, at the user's request to enable communication with those > services. Even if we went with a CORS-only approach (see (1.) above), > this could be a practical fallback to support existing/legacy network > services. This would provide non-CORS-enabled services with the same > privileges as CORS-enabled services from the user agent without the > service itself needing to support CORS implicitly (as also proposed in > the current NSD API specification). I support the idea (at least in theory — it would remain to be seen whether any user agent would feel confident to support such a whitelist); but given that this is an exception mechanism, I'm not even sure it needs to be specified — since the user agent is ultimately responsible for managing the same origin policy, user-specified exceptions to that policy (which such a whitelist would be) seem beyond what we need to define for interoperability. Or did you have in mind some specific aspects that would need to be spec-d here? DomReceived on Friday, 20 September 2013 08:19:08 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:58 UTC