CODEWITHSUNDEEP
azure-mapshttp-accept-language
kevflood
kevflood

Reputation: 13

Error parsing accept-language header in "search/fuzzy/json" api

We've come across a strange issue with fuzzy search requests that have begun to start failing in some browsers.

Running the search from test page here works. If you view this request in the network tab, and copy it as CURL, you get something like:

curl 'https://atlas.microsoft.com/search/fuzzy/json?api-version=1.0&query=New%20York&radius=100000&view=Auto&subscription-key=tTk1JVEaeNvDkxxnxHm9cYaCvqlOq1u-fXTvyXn2XkA' \
  -H 'authority: atlas.microsoft.com' \
  -H 'dnt: 1' \
  -H 'accept-language: en-US' \
  -H 'content-type: application/json; charset=utf-8' \
  -H 'user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36' \
  -H 'ms-am-request-origin: ServiceModule' \
  -H 'map-agent: ServiceModule/2.0.5 (Web)' \
  -H 'accept: */*' \
  -H 'origin: https://azuremapscodesamples.azurewebsites.net' \
  -H 'sec-fetch-site: cross-site' \
  -H 'sec-fetch-mode: cors' \
  -H 'sec-fetch-dest: empty' \
  -H 'referer: https://azuremapscodesamples.azurewebsites.net/Services%20Module/Fuzzy%20Search%20using%20Services%20Module.html' \
  --compressed

If you right click on the search request and click "open in new tab", it fails with 400/Bad Request. If you copy this request as CURL, it will give you something like:

curl 'https://atlas.microsoft.com/search/fuzzy/json?api-version=1.0&query=New%20York&radius=100000&view=Auto&subscription-key=tTk1JVEaeNvDkxxnxHm9cYaCvqlOq1u-fXTvyXn2XkA' \
  -H 'authority: atlas.microsoft.com' \
  -H 'cache-control: max-age=0' \
  -H 'dnt: 1' \
  -H 'upgrade-insecure-requests: 1' \
  -H 'user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36' \
  -H 'accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9' \
  -H 'sec-fetch-site: none' \
  -H 'sec-fetch-mode: navigate' \
  -H 'sec-fetch-user: ?1' \
  -H 'sec-fetch-dest: document' \
  -H 'accept-language: en,nl;q=0.9,en-GB;q=0.8' \
  --compressed

which will fail. I've narrowed down the problem to the accept-language param 'en,nl;q=0.9,en-GB;q=0.8' which Chrome seems to have added as a default when I opened in the GET request in the new tab. Replacing this val with 'en-US' makes the request work again.

I've reproduced this on: Ubuntu 18.04.4 LTS, Chrome Version 81.0.4044.129 (Official Build) (64-bit) Windows Version 10.0.18362 Build 18362, Chrome Version 81.0.4044.138 (Official Build) (64-bit) and we've also had customers report it on Edge and Chrome.

So, assuming this default value for accept-language is valid, it seems there's a bug in the azure api parsing it.

A workaround for this problem is to chrome://settings/?search=language and set just one language.

Upvotes: 0

Views: 881

Answers (1)

rbrundritt
rbrundritt

Reputation: 17954

I believe the issue is that an invalid language parameter is being passed in. A list of supported languages can be found here: https://learn.microsoft.com/en-us/azure/azure-maps/supported-languages Passing anything other than one of these would result in an error. To address this issue, you can either override the accept-language header, or add a language parameter to the request "&language=en-US".

Upvotes: 1

Related Questions