W3C home > Mailing lists > Public > public-device-apis@w3.org > October 2013

Re: [discovery-api] CORS support added to NSD API Editor's Draft

From: Rich Tibbett <richt@opera.com>
Date: Tue, 8 Oct 2013 16:13:15 +1100
Message-ID: <CAAsrAZCtV7iryuffZ7jFAcbqbtnVU+Gi5FmfyUH0sJ2qtjXVSA@mail.gmail.com>
To: "Cathy.Chan@nokia.com" <Cathy.Chan@nokia.com>
Cc: Tatsuya.Igarashi@jp.sony.com, FABLET Youenn <Youenn.Fablet@crf.canon.fr>, Device APIs Working Group <public-device-apis@w3.org>
On Tue, Oct 8, 2013 at 8:49 AM,  <Cathy.Chan@nokia.com> wrote:
>
>> -----Original Message-----
>> From: ext Igarashi, Tatsuya [mailto:Tatsuya.Igarashi@jp.sony.com]
>> Sent: Monday, October 07, 2013 8:41 AM
>> To: Rich Tibbett; FABLET Youenn
>> Cc: Device APIs Working Group
>> Subject: RE: [discovery-api] CORS support added to NSD API Editor's Draft
>>
>> About the source origin value of pre-flight, the empty should be used just to
>> determine if the device support CORS.
>
> Agreed that the primary purpose of the preflight request should be to determine if CORS is supported. As a bonus, if the result comes back as a wild-card, the UA knows that any web app would be allowed to talk to that service (upon user permission).
>
> But using an empty origin might cause the UA to incorrectly interpret a server that supports CORS but allows only a specific list of origins as not supporting CORS. An alternative is to use the target service's own origin instead in the preflight request. The result would be one of the following:
> 1. The request fails -> the target service does not support CORS. In this case, the UA must not include this service in its list of services.
> 2. The request succeeds with "Access-Control-Allow-Origin: *" -> the target service supports CORS and accepts requests from any origin. In this case, the UA includes this service in its list of services. The service will be presented to the user as is.
> 3. The request succeeds with "Access-Control-Allow-Origin: target service's origin" -> the target service supports CORS but only accepts requests from certain origins (such as its own). In this case, the UA still records this service in its list of services, but marks it as "conditional".

Yes, this is exactly how it should work.

I'm still not sure exactly what source origin should be used. At this
point of the algorithm we are only interested in what the cross-origin
response headers say rather than ensuring a match to the preflight
request's origin so largely it shouldn't matter what we set the source
origin as.

> Upon receiving a getNetworkServices request from a web page (where this service matches a requested type), the UA issues another preflight request with the web page's origin to determine whether that web page would be allowed access, and use the result to decide whether the service can be presented to the user. The UA may also store this information for future use (until expiration).

Wasn't that allowed origin already provided in the original preflight
check 'Access-Control-Allow-Origin' response header? In that case we
may not need to perform another preflight check before presenting this
service to the user when getNetworkServices() is called from script
running on this allowed origin.

I will update the spec accordingly.

br/ Rich
Received on Tuesday, 8 October 2013 05:13:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:33:01 UTC