Re: [discovery] Adding CORS to NSD API - proposal and issues

On Sat, Oct 5, 2013 at 3:18 AM, Rich Tibbett <richt@opera.com> wrote:
> On Sat, Oct 5, 2013 at 2:14 AM, Giuseppe Pascale <giuseppep@opera.com> wrote:
>>
>> On Thu, Oct 3, 2013 at 1:22 PM, Rich Tibbett <richt@opera.com> wrote:
>>>
>>> Alternative Proposal:
>>>
>>> Instead of introducing the dissonance discussed above we could instead
>>> rely on issuing tentative preflight requests [3] to networked service
>>> endpoint URLs once the network service discovery process has been
>>> completed as normal (without services needing to opt-in at the
>>> discovery stage). This approach has the benefit of actually ensuring
>>> CORS is properly supported since we are feature-detecting CORS
>>> directly on actual network service URLs rather than trusting a
>>> corsEnabled directive during discovery that assues us that CORS is
>>> supported on any corresponding network service URLs.
>>>

>>> ---
>>>
>>> Alternative Proposal Issues:
>>>
>>> The major problem with adopting this alternative approach is that the
>>> root of a networked service endpoint URL is not always configured to
>>> return 200 OK responses (some networked services may provide access
>>> only in sub-directories or non-standard root locations which can
>>> differ per network service type). CORS preflight requests abort if the
>>> HTTP response is not 200 OK, in which case this approach would fail to
>>> capture legitimate CORS-enabled networked services during this
>>> process.
>>>
>>
>> not sure I get this, can you give a concrete example?
>
> If a network service's control URL is resolved during the discovery
> process to be http://192.168.1.2:3333/myservice and we then want to
> tentatively check if CORS is enabled then the user agent would then
> immediately issue a tentative CORS preflight request to that URL (A
> HTTP OPTIONS request to the root service endpoint URL as described in
> [3]). That service MUST respond with a 200 OK from that URL with a
> 'Access-Control-Allow-Origin: *' response header provided for that
> service to be considered CORS-enabled and therefore for that service
> to be accessible to web pages (pending prior user authorization via
> browser chrome before any sharing taking place of course).
>
> My initial concern was whether _all_ service root URLs would be set up
> to respond to that tentative CORS preflight request or whether some
> service endpoints are only configured to work on sub-paths of that
> root URL. e.g. if my service only responds to CORS requests at
> http://192.168.1.2:3333/myservice/mymethod then it would fail the CORS
> preflight check and not be offered up to users to share with web
> pages.
>
> On second thoughts that may be a non-issue since we do not have any
> legacy CORS support in any of the network services we are looking at
> sharing. Perhaps the original alternative proposal is better since it
> requires no changes at the discovery protocol level.
>

So the alternative proposal (or 'Proposal #2') breaks down to the user
agent performing the following steps:

1. Perform the service discovery mechanisms in the current network as
they are currently defined in the spec.
2. For any service discovered in the current network, immediately
issue a HTTP CORS preflight request (the 'CORS-enabled check') toward
that service's advertised control URL.
3. If the service's response to the CORS preflight request is a 200 OK
and contains a 'Access-Control-Allow-Origin: *' header, then allow
this service to be a candidate for sharing with web pages and skip the
remaining steps.
4. If the service's type token is contained within the 'network
services whitelist' then allow this service to be a candidate for
sharing with web pages (where we will simulate CORS support for this
service in the user agent) and skip the remaining step.
5. Otherwise, discard this service as not being a suitable candidate
for sharing with web pages.

This is just the general strawman proposal so will need further work,
particularly around CORS terminology used.

>>
>>> ---
>>>
>>> [1]
>>> http://lists.w3.org/Archives/Public/public-device-apis/2013Sep/0040.html
>>>
>>> [2] http://tools.ietf.org/html/rfc6763#section-6
>>>
>>> [3] http://www.w3.org/TR/cors/#preflight-request
>>>
>>

Received on Friday, 4 October 2013 17:47:31 UTC