Cors errors are usually printed in the web browser (they are validated by client software). So this looks like your browser must have updated and changed its’ default behavior. Sharing the output from the browser console would be helpful. Is it also possible for you to share the link, where the issue happens so I can investigate it myself?
Looks like you are for some reason trying to send authorization header credentials to search API. This gets blocked by CORS in the browser. Solution: don’t send authorization header for search (I don’t think it needs one). This is most likely some authorization credentials leakage.
It’s ok because it works if I do the request directly in a web browser or postman for instance. I think my issue comes from the headers send by my client web service (service is done with flutter framework).
@NorthCrab, yes it seems to be something like that. But I don’t see any authorization header in the browser debugger terminal (I had share the headers in first post). That’s why I’m troubled by the behaviour here. I thought error means nominatim service expect authorization header that are missing in the request (CORS missing authorization header).
I’m still investigated on what is my problem. Thanks for your help so far.
Beside there is another change, before response was encoded in utf-8, it seems that it’s now encoded in iso. And if I try to set an ‘content-encoding’ header I have the same error as when I put content-type one, meaning a cors error :
Access to XMLHttpRequest at 'https://nominatim.openstreetmap.org/search?format=jsonv2&q=rez%C3%A9' from origin 'http://localhost:53365' has been blocked by CORS policy: Request header field content-encoding is not allowed by Access-Control-Allow-Headers in preflight response.
I’ll find a workaround, but by any chance is there a way to precise to the api the charset we want ?
It seems not by reading the documentation here : Search - Nominatim 4.2.3
Similar goes to accept vs. content-type when talking about GET requests.
I don’t think that your content-type issues have anything to do with our servers. We indeed don’t send ‘Access-Control-Allow-Headers’ in the OPTIONS response but if that’s what’s tripping your browser, then it has never worked. Nothing has changed with respect to those headers.
The JSON responses are still in UTF-8. If you are referring to the fact that the charset is no longer explicitly specified in the content-type header of the response, then this is not strictly necessary because UTF-8 is the default for JSON according to RFC 7159. Won’t hurt either, so I might just add it back.