Modify

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#10441 closed defect (fixed)

No changesets causes API validation error

Reported by: pnorman Owned by: team
Priority: normal Milestone: 14.08
Component: Core Version:
Keywords: api changeset Cc:

Description

If inputting a custom API URL, JOSM makes a request to /api/0.6/changesets. If the API server in question has no changesets, it does not like the response, which is as below

<osm version="0.6" generator="OpenStreetMap server" copyright="OpenStreetMap and contributors" attribution="http://www.openstreetmap.org/copyright" license="http://opendatacommons.org/licenses/odbl/1-0/"/>

It remains possible to set the API in advanced preferences, which bypasses the check.

JOSM is also issuing the changesets call before a capabilities call, which seems the wrong way around.

Attachments (0)

Change History (6)

comment:1 Changed 5 years ago by Don-vip

Keywords: api changeset added
Milestone: 14.08

comment:2 in reply to:  description ; Changed 5 years ago by Don-vip

Replying to pnorman:

JOSM is also issuing the changesets call before a capabilities call, which seems the wrong way around.

This is intended:

Note: it fetches a list of changesets instead of the much smaller capabilities because - strangely enough -
an OSM server "https://x.y.y/api/0.6" not only responds to "https://x.y.y/api/0.6/capabilities" but also
to "https://x.y.y/api/0/capabilities" or "https://x.y.y/a/capabilities" with valid capabilities. If we get
valid capabilities with an URL we therefore can't be sure that the base URL is valid API URL.

comment:3 Changed 5 years ago by Don-vip

Resolution: fixed
Status: newclosed

In 7466/josm:

fix #10441 - wrong parsing of changesets list in API URL test task + fix EDT violations

comment:4 in reply to:  2 Changed 5 years ago by pnorman

This is intended:

Note: it fetches a list of changesets instead of the much smaller capabilities because - strangely enough -
an OSM server "https://x.y.y/api/0.6" not only responds to "https://x.y.y/api/0.6/capabilities" but also
to "https://x.y.y/api/0/capabilities" or "https://x.y.y/a/capabilities" with valid capabilities. If we get
valid capabilities with an URL we therefore can't be sure that the base URL is valid API URL.

This is incorrect - http://api.openstreetmap.org/api/0/capabilities returns a 404 error, and the same happens with the rails port runnign locally

comment:5 Changed 5 years ago by Don-vip

Exact. It was certainly true when it has been written but must have been fixed since. We could switch to simpler capabilities call, then.

comment:6 Changed 5 years ago by Don-vip

In 7473/josm:

see #10441 - send capabilities request instead of changesets request when testing API url

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.