- From: FABLET Youenn <Youenn.Fablet@crf.canon.fr>
- Date: Mon, 7 Oct 2013 14:45:41 +0000
- To: "richt@opera.com" <richt@opera.com>
- CC: "public-device-apis@w3.org" <public-device-apis@w3.org>
- Message-ID: <ACC41E833067BD4FB8084DEBA2D866BE2F538BA2@ADELE.crf.canon.fr>
I looked a bit more at some of the proposed changes and have some additional questions. Related to the requirement below: "Only Local-networked Services that pass a CORS preflight check should be made available to web pages by a user agent." "Made available" is a vague term but I understand it as "the user agent communicates the URL of the service", nothing more. If that is correct, why is this rule mandatory? Is it to cope with a security issue? to ensure a good user experience? Would it not be better if the CORS check process be abstracted a bit in the spec? Details as provided could be put in implementer guidelines or appendix. Browsers could for instance have the option to gather CORS information based on the web app origin if that works best in their environments. That would also be an encouragement for local web services implementations to correctly handle all preflight requests and not just the NSD ones. I can see some benefits in having CORS information when the list of services is presented to the user. This allows the UI to graphically differentiate (based on CORS, whitelisting, web app origin and privileges) the services that the web app will probably be able to interact with from the services it will probably fail. This also enables the UI to select by default only the services for which XHR will probably work. As of gathering of CORS information ahead of time, using the public IP address of the machine seems a bit odd. Would it be an abuse to either use a fixed string or the origin of the service itself? Regards, youenn
Received on Monday, 7 October 2013 14:46:29 UTC