How can we improve WCF Data Services?

CORS support

Spec: <>

This suggestion is about full support for CORS in WCF Data Services to (1) eliminate the need for custom WCF service hosts and WCF message inspectors and (2) make it as easy as possible to define a policy.

101 votes
Sign in
Sign in with: facebook google
Signed in as (Sign out)
You have left! (?) (thinking…)
tne shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: facebook google
Signed in as (Sign out)
  • tne commented  ·   ·  Flag as inappropriate

    Another concrete way of adding CORS functionality would be indirectly by supporting OWIN[1][2] APIs, which are increasingly popular and for which CORS implementations are already available[3].


  • tne commented  ·   ·  Flag as inappropriate

    A few additional notes:

    - OData is probably the most complete technology to date to provide a data-access layer in a systematic yet RESTful way. Since web clients don't have access to SQL interfaces without explicit WebSockets support from the DBMS, OData is one of the best solutions currently available for thick web clients that don't necessitate a process-oriented service-layer on the server-side.

    - Because of this, it makes a lot of sense to support web clients as prime targets in the WCF Data Services project (that is, in addition to .NET and other types of clients that run in less restrictive environments).

    - The datajs library already goes a long way in enabling these applications to work nicely with OData, and is used successfully in large frameworks like JayData and Breeze.

    - Because of that popularity, the CORS issue comes up more and more often, and this trend should be expected to continue as the need for CORS and its adoption spreads.

    - The only guidance available regarding CORS in the context of WCF Data Services is a few blog posts and buried discussion threads with untested sample code for incomplete implementations of CORS support via WCF service hosts and message inspectors.

    - This requires every developer to reimplement the same code, typically partially, where CORS should really be an infrastructure detail. By partial, I mean that often no policy management of any kind is implemented, and instead all origins are systematically allowed. Many such implementations also rely on hacks and work-arounds. To summarize, current practices are not ideal and sometimes result in downright insecure software.

    - As a result, WCF Data Services is losing users on the web platform to other implementations with solid CORS support, simply because of the annoyance factor and regardless of the fact that WCF Data Services might be more appropriate than these other implementations for the application at hand.

    Example: User investigating a switch to ASP.NET Web API with OData extensions for CORS support <>.

    If no direct support for CORS in WCF Data Services can be reasonably achieved in medium-term (what with all the work required for OData 4.0 and EF6 support), I'd like to suggest the sanctioning of a community implementation (through WCF service hosts and message inspectors or other more appropriate extension points) that everyone can refer to. If the coordination of such a project seems difficult, maybe asking for help to the Outercurve Foundation <> would be a good idea.

    Thanks a bunch for considering these suggestions.

Feedback and Knowledge Base