I’m using nominatim search query since long time now. And since few days I receive a cors error. On my client side the code hasn’t change since few month, so I wonder what could happens.
I wonder if my client has been blocked ? But I don’t know if there is a specific contact to ask if my site was blocked and if so for which reason ?
Or maybe my request have missing headers ? I try to find solution in docs but for now I hae no solutions.
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?
I suspect you were hitting the server that has been updated to a new rewritten version of the frontend and I think @lonvia has already deployed a fix for CORS issues in the last few hours…
It seems that is the preflight request that fails like if server do not allows it. At least that is what I understand, but I’m not very good on the understanding of how CORS works.
@TomH, by any chance do you know if the fix is deployed ? I am still facing the issue today.
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.
My issue comes from the content type header in my headers content-type: application/json
I don’t know why I put it previously as the content type response is part af url parameters. I guess server was mess strict before on that contentType header and is now rejected.
So, by removing it everything is working good again.
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
Shouldn’t you send accept-encoding header instead? Client-based content-encoding is (almost) never supported by upstream servers. Anyway, accept-encoding should already be set automatically by your browser - it’s the one handling the encoding process, not your javascript.
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.
Sorry for the late response. I don’t really knows why but in any case my charset issue is no longer present, maybe you add back the content type in headers ?
