Isochrones endpoint returns HTTP-406

openrouteservice isochrones
1

Hi,

Since a few days, if I try to use my javascript-code to get an isochrone, the server returns an http-406, with the following content:

{
  "error":
  {
    "code":3007,
    "message":"This response format is not supported"
  },
  "info":{"engine":{"build_date":"2024-03-21T13:55:54Z","version":"8.0.0"},"timestamp":1715245629980}}

The request is a POST to https://api.openrouteservice.org/v2/isochrones/driving-car/, the post body is the following Json:

{
  "locations":[[4.927085,52.891825]],
  "range":[1800],
  "range_type":"time"
}

If I try the post-body in the API Playground, I get the expected response, ie. an isochrone, so the problem does not seem to stem from the post-body. Since mozilla’s http error code documentation suggests this has to do with the Accept-headers, I thought I’d try a few things there.

I’ve tried the following Accept-headers (using both Chrome and Firefox):

xhr.setRequestHeader('Accept', 'application/geo+json');
xhr.setRequestHeader('Accept', 'application/json');
xhr.setRequestHeader('Accept', '');
xhr.setRequestHeader('Accept', 'text/plain');

and I’ve tried NOT setting any Accept-headers, in which case the browser sets it to Accept: /,
but all of those return the same http-406 with error-code 3007. 406 is not documented, 3007 IS documented, but not with a very helpful explanation:

3007 Unsupported export format.

As suggested by the mozilla documentation for 406, the body of the message should contain the list of the available representations of the resources, allowing the user to choose among them. But that is not the case, so I have no idea what should be in the Accept headers (note that browsers (at least Firefox) do not allow you to change the Accept-Encoding header…).

This only seems to happen with Isochrones, the route- and poi-implementations that I wrote (which use the same underlying code) still work without any problems. It’s only the isochrones that show this behavior.
What do I need to set in the Accept-headers in order to get a proper response, any ideas?

Edit: Had a look at the API playground headers that are being used. The Accept-header had as contents application/json, text/plain, */* , so I changed my Accept header to that: no difference. The only difference in headers is in the Origin and Referer headers for as far as I can see, so that shouldn’t make a difference I would think (at least, it shouldn’t cause the 406-3007…). And the exact same thing happens on Opera for Android as well, so it does not seem to be related to browsers or laptop.

2

Hi @Stefan,

the generated code example in the playground includes especially the Content-Type header :`

request.setRequestHeader('Accept', 'application/json, application/geo+json, application/gpx+xml, img/png; charset=utf-8');
request.setRequestHeader('Content-Type', 'application/json');
request.setRequestHeader('Authorization', 'your-api-key');

Also you could use our js lib :smiley:

But if you want to do native requests, try the above and see if it works.

Best regards

1 Like
3

Hi Amandus,

I already set Content-type correctly, and it would be very strange for that one to make a difference. Because Content-type in a request

tells the server what type of data is actually sent

For the record, this is what Firefox (and Chrome, with a slightly different user-agent) actually send as headers:

POST /v2/isochrones/driving-car/ HTTP/2
Host: api.openrouteservice.org
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:124.0) Gecko/20100101 Firefox/124.0
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Content-type: application/json
Authorization: $$$$$$$$$$
Content-Length: 71
Origin: $$$$$$$$$$
DNT: 1
Connection: keep-alive
Referer: $$$$$$$$$$
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site
Pragma: no-cache
Cache-Control: no-cache
TE: trailers

And these are the headers that are sent when I use the API playground from the same Firefox:

POST /v2/isochrones/driving-car HTTP/2
Host: api.openrouteservice.org
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:124.0) Gecko/20100101 Firefox/124.0
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Authorization: $$$$$$$$$$
Content-Type: application/json
Content-Length: 71
Origin: https://openrouteservice.org
DNT: 1
Connection: keep-alive
Referer: https://openrouteservice.org/
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-site
Pragma: no-cache
Cache-Control: no-cache
TE: trailers

Apart from (obviously) Referer, Origin and Sec-Fetch-Site (which I can’t and shouldn’t change!) I see no difference, so I’m having a hard time understanding why the 406-3007 response - it makes no sense to me. Even if the server would look at Content-type to see what it would need to return (which would be wrong), that’s still set to json… And if it’s caused by the XHR-nature of the request, the response shouldn’t be 406 and most definitely not 3007 - because that last one indicates to me that the server actually received the request and considered it outside of the HTTP-protocol.

There’s something weird going on here, and so far I can’t seem to figure out what. Add to that the fact that this exact same request has worked just fine before, and still does on the other endpoints that I use (directions, geocode, pois and elevation), I’m kind of flabbergasted at the moment…

4

OK, I just found it, after taking another long hard look at the headers I just posted. It’s not in the headers, but:

POST /v2/isochrones/driving-car/ HTTP/2

POST /v2/isochrones/driving-car HTTP/2

it’s in the request. Which makes the returned response really confusing imho, and possibly something that you should look into (to me that seems to be a rather obscure bug, but I’ll leave that to you to decide).
But my code works again :slight_smile:
(and I’ll check the rest of my code…)

Thanks for the reply though, that eventually did set me right!

5

Thanks for reporting. You are right, the error message is confusing. For the directions endpoint it makes sense because you can append /json, /gpx etc. to the URL as the desired response format. For endpoints not supporting multiple formats, the message makes no sense.

1 Like
6

Ah of course! Now I understand where it’s coming from. Never even thought of that since isochrones only return geojson.

PS. I always hate it if I can’t figure out the root cause of something going wrong, so even if I find a solution/workaround/way to deal with it, I want to know why :wink:
Thanks for clearing that up!

1 Like