I've been using Quart with quart-schema and quart-cors for some time, and since the latest version of quart-schema provides some updates I can use, I upgraded the Quart packages with pip.
It all works fine, except the front-end now throws CORS errors at me:
Access to fetch at 'http://abc.ai/api/blogs/' (redirected from 'http://localhost:5173/api/blogs') from origin 'http://localhost:5173' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
There are no errors in the back-end.
I configured it in a very basic way (the app in question is still in development), per the readme (https://pypi.org/project/quart-cors/):
app = Quart(__name__)
app = cors(app, allow_origin="*")
That worked fine before I updated the packages, and should do the trick, since the entire app is providing the necessary 'Access-Control-Allow-Origin' header in the most permissive way.
I'm not sure why it stopped working. According to the readme, the configuration is exactly the same as it used to be (I only upgraded from version 0.6.0 to 0.7.0). Perhaps it has something to do with the Hypercorn server I'm using and also updated (from 0.14.4 to 0.16.0), but that's just guessing, as I have no error messages from the API/server, only the CORS error from the front-end.
Am I missing something here? What could there not be working properly?
The problem turned out to be not directly related to Quart, but aggressive caching by Google Chrome.
I first tried several things with Quart/quart-cors, like changing the settings and completely removing quart-cors. This made no difference.
Next, I tried changing my nginx config, to provide headers from the web server. This also had no effect.
So then I took a look at the Developer Tools in Chrome. There is no mention of caching in the request/response. Also, after clearing site data, the result remains the same.
But then I checked 'Disable cache' from the 'Network' tab, reloaded, and now I got a proper response!
When you search for 'Chrome CORS cache' there are several articles/posts (like here) about Chrome aggressively caching, which is pretty opaque even from the Developer Tools. If you delve into Chrome internals and do a NetLog dump, you can find cache being accessed, but there are no details about this cache.
Therefore, it's not quite clear to me how this mechanism works. But I don't want to spend much more time on this and do a thorough investigation, suffice it to say that CORS issues after server updates may be solved by disabling/refreshing browser cache.