They aren’t doing ANYTHING when you use a browser. It’s the browser that’s doing this, not the API.
yes they are, they are serving the response. The response contains the response headers. access-control-allow-origin is a response header supplied by the server.
I’m afraid that is incorrect. It just doesn’t work like that. access-control-allow-origin is a response header. It is completely beyond my control to change it. I don’t really know how to be any clearer about what the problem is.
You put this
Access-Control-Allow-Origin: https://api.tfl.gov.uk
Access-Control-Allow-Methods: PUT,PATCH,DELETE
Access-Control-Allow-Headers: API-Key,Content-Type,If-Modified-Since,Cache-Control
Access-Control-Max-Age: 86400
On your server. This tells your browser it’s OK to communicate with the API through Ajax.
a) I don’t have a server. I know that if I did have a server I could bypass this problem by proxying the request. The point is I want to make this call from the client. I should be able to if tfl return the correct headers.
b) returning an access-control-allow-origin header from my own server with a value of “https://api.tfl.gov.uk” would make no sense. The origin refers to the origin of the request not the origin of the response.
This is not the solution
Hi @julianjelfs
We are setting that header in the response as you mentioned. If we weren’t you wouldn’t be able to call the API from anywhere but our domain.
This wildcard means that the we are not blocking the request depending on the referring domain. This practice is common for open APIs.
I can’t see your application, but I imagine the browser is not even making the request to https://api.tfl.gov.uk as it doesn’t match the referring domain. You should be able to see this in your dev tools network and console tab.
From the limited research I have done into this, it seems that the only option may be to create a proxy or utilise an existing backend in your website to request the API and then relay that to the front end. See this detail below:
Google & Apple have set the policy browser-side and we don’t have any control on what their browsers block by default and if they are against cross origin resource sharing, there’s not a lot we can do.
Thanks,
James
1 Like
Are you just running the web page from your local SSD? If so, the you can use apache and/or IIS to provide a server .
Thanks @jamesevans for the reply. It seems that from your screen shot you are using postman to call the api. This is similar to the case where we paste the query into the browser. Indeed, in that case I can see that the response from the server contains the correct acces-control-allow-origin headers.
What I am saying is that when the api is called via an XMLHttpRequest or via the fetch method, I do receive a response from your servers (http status 200), but that response does not contain the access-control-allow-origin header.
Another very easy way to demonstrate the issue is to open dev tools in the browser and paste this into the console:
fetch("https://api.tfl.gov.uk/StopPoint/490010849S/Arrivals?app_id=da7d2b38&app_key=6e41a466bf61c85ce50712c5622e12d1")
It will not work. Whereas if you paste this into the browser address bar and hit enter:
https://api.tfl.gov.uk/StopPoint/490010849S/Arrivals?app_id=da7d2b38&app_key=6e41a466bf61c85ce50712c5622e12d1
It will work.
It is as simple as that - all you have to do is try it and you will see that it doesn’t work. Until very recently it did work. This is annoying for me but not critical, and I don’t think there is anything more I can do to convince you that a problem has been introduced at the tfl end quite recently.
Proxying is not an acceptable answer for me, and I can’t believe that it is the intention that this api can no longer be consumed by an XMLHttpRequest or fetch from the client.
I’m in the same boat as @julianjelfs.
I’m fetching it from Javascript’s native fetch function.
It was working before, but it isn’t.
I tried using my own proxy and also this proxy (https://cors-anywhere.herokuapp.com/), but even that didn’t make it work fetching from Javascript’s native fetch function.
This issue is not very critical for me, but it is certainly important.
Thanks
It looks like this website is also affected by CORS as the console image below shows…
I have also attempted setting the headers (slight modification of @briantist’s code) on my webserver without success…
Header add Access-Control-Allow-Origin: "https://api.tfl.gov.uk"
Header add Access-Control-Allow-Methods: "GET,POST,OPTIONS,DELETE,PUT"
Header add Access-Control-Allow-Headers: "*"
Header add Access-Control-Max-Age: 86400
Could this have something to do with cloudfare cdn?
Again, appreciate the engagement guys 
@briantist, @julianjelfs, @jamesevans, @vitorbraga
I may have found something that might be responsible. I’m investigating further.
Thanks,
James
Really appreciate it! Thanks.
There is a Video by Google Developers that shows how the new “F12” Dev Tools in Chrome help with Cross Origin… (79 seconds in)
Hi guys, any updates on this issue?
Thanks 
Hi all, my name is Tom.
I’m a Tech Lead at Transport for London, and in charge of the CDN layer mentioned above. My best guess is that between the fact Browsers are becoming more strict about cross-site scripting (to prevent the majority of cases where it’s a very bad thing to allow), along with our own move between CDN providers, we lost some headers that allowed this functionality.
I know CORS well, and given I enjoy making hobby projects calling API’s in the browser, I’ve been stung by it often. I’ve updated our CDN layer to hopefully allow cross-site calls (tested here), and can only really apologise for not being more engaged and causing you all a headache and lost time.
Share and enjoy
Tom
2 Likes
Thanks very much Tom - I can confirm that my little site is now working again which is great!
1 Like
Welcome @TomBonner !
I’m pleased to say that the JavaScript version of the full-screen tube indicator Full Screen Tube Status 404 - #15 by briantist works again!
1 Like