W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2019

Taking responsibility for CORS on the server side

From: Ruben Verborgh (UGent-imec) <Ruben.Verborgh@UGent.be>
Date: Fri, 8 Mar 2019 15:48:30 +0000
To: "public-webapps@w3.org" <public-webapps@w3.org>
CC: "Pieter Colpaert (UGent-imec)" <pieter.colpaert@ugent.be>
Message-ID: <F86D45E5-A83D-4A44-A636-4A6A9C9B18A0@ugent.be>
Dear all,

Recently, we had a very unpleasant surprise when one of our Web apps, which had been running fine for years, suddenly broke.
It happened because our app accesses resources from public APIs at different origins. Those origins have CORS enabled.
However, the fetch specification suddenly decided that valid HTTP headers above a certain length need explicit approval (we use a long Accept header).
The only solution is to fix this on the server side.
So servers that were correctly configured, suddenly have to change—without any guarantee that they will keep on working.

This is bad news for the many Open Data APIs, public APIs, and authenticated APIs, out there,
and the Web apps using them, which rely on cross-origin requests.

Therefore, in addition to the very granular and complex CORS mechanism, we want a solution in which a server can simply state:
“it’s okay, I am accepting full control of protecting cross-origin requests” (because I publish open data, or have my own authentication mechanism).

Such a proposal is clearly advantageous for client and server developers, but the browser builders are the ones we have to convince.
Therefore, if you also want a Web where public APIs are guaranteed to keep on working, please vote for our issue at

Your feedback is most welcome.

Thanks in advance,

Ruben Verborgh
Professor of Semantic Web Technology
IDLab, Ghent University – imec
https://ruben.verborgh.org/ – @RubenVerborgh
Received on Friday, 8 March 2019 15:49:15 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 13 March 2019 19:09:55 UTC