Closed pimarc closed 1 year ago
As shown in the screenshots, the Apiary proxy in the interactive documentation doesn't reflect the headers returned by the actual API. They keep those as open as possible because they don't know what might be on the other side.
The reason OPTIONS isn't included in those headers is that it's simply not implemented by any of the endpoints currently. Once implemented, it would automatically be included by the CORS middleware:
The change probably stems from a dependency update that has been held back for years which didn't have a test checking for it. As long as the OPTIONS method is flexible, it could probably be implemented at the base view here:
ok, thanks for your answer. But anyway, we have some issue until yesterday with no answer from the API. We didn't change anything on our side.
Here is the message we have when attempting to get a metar with the official URL Using the URL used on the API doc works correctly.
Did you change some configuration on your servers recently?
I am seeing similar issues @pimarc , no changes on my end but suddenly all requests are failing via REST.
The OPTIONS method and its associated data has been added back to each child resource endpoint via the core library. It's now deployed onto the main server.
I can confirm this has fixed it for me. Thank you!
I can confirm too. The Metar is back. Thank you very much.
Started October 30, there is a CORS issue in the official API link (https://avwx.rest/api/metar/) Tested with the URL used on the API doc works correctly (https://private-anon-93b4379efd-avwx.apiary-proxy.com/api/metar/)
After testing the response headers from both links, it looks like the OPTIONS is missing in the header access-control-allow-headers for the offical API link.
See attached images
Thanks for looking at that.
Best regards Pierre PMS50