files from their local filesystem that consume the endpoint. Hence we needed to support cross-origin resource sharing (CORS) to interact with the OData endpoint.
CORS response header Access-Control-Expose-Headers from our server and datajs relying on the DataServiceVersion response header (with value 3.0) to enable the code path for parsing JSON light.
The missing Access-Control-Expose-Headers response header prevented datajs to access the DataServiceVersion header. The DataServiceVersion header is read by datajs (along with other headers it supports) and checked. Its inaccessibility caused the expected handler
not to trigger, even worse no handler was triggered at all (hence the 'no handler found for data' exception message).
Note that with datajs v1.0.3. the Accept-header on the request contained something like 'odata=verbose', triggering the non-JSONlight processing of OData before v3. Hence the issue was not observed. However datajs v1.1.0 and by default include in the Accept-header
something like 'odata=fullmetadata' which triggers OData v3 JSON light, but requires the DataServiceVersion response header too!
After some experimenting with CORS headers accepted by and sent from the server, we could solve the issue. In our case we used the CORS extensions for Web API (and OWIN; see
CORS in Web API
). It was configured to accept all origins, all headers, all methods on requests and exposed the OData specific headers on responses.
Did anyone else experience similar problems? Moreover if you did a similar root cause analysis like we did, do you think it is in part a problem of the datajs implementation?