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: Mon, 7 Oct 2013 19:52:30 +1100
Message-ID: <CAAsrAZDt2VCV=+=Mfw8J-LK_X0mE_Lury=WFk0YczKe-z1Knvg@mail.gmail.com>
To: FABLET Youenn <Youenn.Fablet@crf.canon.fr>
Cc: Device APIs Working Group <public-device-apis@w3.org>
Hi Youenn,

On Mon, Oct 7, 2013 at 7:34 PM, FABLET Youenn
<Youenn.Fablet@crf.canon.fr> wrote:
> Two questions after scheming through the CORS preflight check:
> 1. Why setting the source origin to the public IP address of the current machine and not to the script origin?

It is because the timing of service discovery can occur in the
background and therefore a CORS preflight check as defined in the spec
would not have a specific script origin at that time.

The reason public IP address of the current machine is used is because
it is highly unlikely that a network service will provide access to
specific hosts in what is a highly dynamic, NAT-based home
environment. Therefore, the choice of source origin selection is
actually intentionally arbitrary. What we are really looking for is
wildcard CORS support i.e. 'Access-Control-Allow-Origin: *'. That
therefore doesn't really allow for granular CORS support in network
services but is a trade-off with the flexibility available to
implementers in service discovery mechanism timing. Perhaps it depends
on which consideration is more important to have (flexible network
discovery timing or granular CORS support for services).

>
> 2. Which HTTP methods should actually be checked in advance? GET only? POST? More?
> Depending on the particular service implementation of CORS, this initial check may not always be sufficient.
> Web apps may anyway need to discover what is authorized by itself.

It would be the default method, GET, that is checked since this method
is the most likely to succeed. The response would contain all the HTTP
methods on which CORS is enabled (in the
'Access-Control-Allow-Methods' response header). That is the current
design given the implied constraints of checking for CORS support
without knowing all of the method(s) required during service
interaction up-front.

Best regards,

Rich

>
> Regards,
>         Youenn
>
>> -----Original Message-----
>> From: Rich Tibbett [mailto:richt@opera.com]
>> Sent: lundi 7 octobre 2013 05:19
>> To: Device APIs Working Group
>> Subject: [discovery-api] CORS support added to NSD API Editor's Draft
>>
>> I have added an initial version of CORS support to the Editor's Draft of the
>> Network Service Discovery API spec.
>>
>> The ED version of the spec is in the usual place:
>>
>> https://dvcs.w3.org/hg/dap/raw-file/tip/discovery-api/Overview.html
>>
>> A diff is available with all CORS-related updates is at:
>>
>> https://dvcs.w3.org/hg/dap/diff/f3ea6558ffe1/discovery-
>> api/Overview.src.html
>>
>> This update is as per the 'alternative' CORS proposal previously introduced
>> and discussed in [1] (including the resolved issues in that thread). I believe we
>> still need to review and update the Security and Privacy Considerations
>> Section further related to security concerns that have been raised elsewhere
>> on the mailing list [2].
>>
>> Best regards,
>>
>> Rich
>>
>> [1] http://lists.w3.org/Archives/Public/public-device-
>> apis/2013Oct/0014.html
>>
>> [2] http://lists.w3.org/Archives/Public/public-device-
>> apis/2013Oct/0033.html
>> (in reply to: http://lists.w3.org/Archives/Public/public-device-
>> apis/2013Oct/0010.html)
>
Received on Monday, 7 October 2013 08:53:02 UTC

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