Modify

Opened 10 years ago

Closed 10 years ago

Last modified 10 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 by Don-vip, 10 years ago

Keywords: api changeset added
Milestone: 14.08

in reply to:  description ; comment:2 by Don-vip, 10 years ago

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 by Don-vip, 10 years ago

Resolution: fixed
Status: newclosed

In 7466/josm:

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

in reply to:  2 comment:4 by pnorman, 10 years ago

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 by Don-vip, 10 years ago

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 by Don-vip, 10 years ago

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. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.