Application signalled from 'HbbTV-DSM-CC-Prio' fails XHR CORS policy enforcement
Closed this issue · 6 comments
The 'HbbTV-DSM-CC-Prio' service signals an AUTOSTART application signalled w/ both HTTP and OC transport types. When using AIT order for transport protocol preference, the application is loaded from the OC and issues an XHR request which fails as follows:
XMLHttpRequest cannot load http://itv.ard.de/ardstart/check.php. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'dvb://1.ff03.139c.14' is therefore not allowed access.
Prior to errata 3, ETSI TS 102 796 v1.2.1 did require implementers to consider an application boundary as part of its origin: "For files requested with XMLHttpRequest, the Same-Origin Policy shall be extended using the application boundary i.e. any origin in the application boundary will be considered of same origin."
However w/ HbbTV CR https://www.hbbtv.org/redmine/attachments/download/1715/hbbtv-cr-2309r2-broadcast-application-origin-errata.doc, this requirement was removed from errata 3. So the application boundary can no longer be accounted for as part of the same-origin, which here is 'dvb://1.ff03.139c.14'. The UA CORS policy enforcement will deny access unless the target server replies w/ a 'Access-Control-Allow-Origin' header allowing access to the requested resource. No such header is currently returned by the server, hence the failure.
As an additional reference, the same kind of problem is discussed in the HbbTV redmine issue #2312.
@mitxp any feedback about this issue ? thanks :)
Hi, sorry for my late reply.
Yes, you are right, this won't work with same-origin changes. Two things, though:
- This (and other) HTTP request is not relevant for running the application. So no immediate action is required in my point of view. Please tell me if you think that some of the application is not working as expected.
- We will still change it, but as this is part of an "on air" application, we need to follow a deployment plan, and this will take some time. I'll notify you when the changes are made.
Thanks for your reply. FYI, the failing XHR request described above is causing the application to incorrectly believe it's currently offline and therefore doesn't operate as it normally would: trying to access EPG, Mediatek, etc... pops up a message that explains the selected service cannot be accessed w/o an internet connection.
The cors headers should be available now.
Seems the CORS header was not added to http://itv.ard.de/ardstart/check.php:
Cache-Control:max-age=0, no-cache, no-store
Connection:keep-alive
Content-Length:1
Content-Type:text/plain;charset=UTF-8
Date:Mon, 30 Oct 2017 09:31:26 GMT
Pragma:no-cache
Server:Apache/2.2.15 (CentOS)
X-Powered-By:PHP/5.3.3
Hi,
sorry for this. It is fixed now.