- From: Rich Tibbett <richt@opera.com>
- Date: Mon, 7 Oct 2013 19:52:30 +1100
- 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