dal.vosi: compute endpoint URLs by appending strings
dal.vosi's TablesMixin obtains the URL to read from like this:
try:
interfaces = next(
_ for _ in self.capabilities if _.standardid.startswith(
'ivo://ivoa.net/std/VOSI#tables')
).interfaces
accessurls = chain.from_iterable(_.accessurls for _ in interfaces)
tables_urls = (_.value for _ in accessurls)
except StopIteration:
tables_urls = [
'{}/tables'.format(self.baseurl),
url_sibling(self.baseurl, 'tables')
]
-- and it then goes on to try which of these work with the given authentication.
It shouldn't do this. Some similar thing was attempted in the run-up to TAP 1.1 (but the plan really has been to match up endpoints based on titles or something like that). It's been found that this, as planned, doesn't work, and fixing it would end up in an extremely painful system (more in Caproles, http://ivoa.net/documents/caproles/).
So, TAP (which at this point is the only protocol that really uses mechanisms of this type) has fallen back to the TAP 1.0 method of just adding "tables" to the base URL.
Hence, _tables should just be
tables_url = '{}/tables'.format(self.baseurl)
response = self._session.get(tables_url, stream=True)
response.raise_for_status()
return response.raw
If nobody protests, I can turn this into a PR (of course, if someone else relieves me of github clickery, I'd most appreciate it).
Are there notes from some recent InterOp that we could refer to about the decision to abandon the variably-named-endpoint features from /capabilities ? I.e., something that says that the "caproles" document you linked was accepted in some way?
On Wed, Mar 04, 2020 at 12:17:29PM -0800, gpdf wrote:
Are there notes from some recent InterOp that we could refer to about the decision to abandon the variably-named-endpoint features from
/capabilities?
No. No decisions as to how to go on have been passed. For TAP, that means that the TAP 1.0 method (appending strings) remains in action (formally, for vs:paramHTTP interfaces in TAP capabilities; the way we discover TAP services makes the code only see these, so that's no constraint).
Outside of TAP, there's still the broken VOSI 1.1 and DALI 1.1 in power. These would still suggest you'll get extra endpoints though capabilities. But I'm not aware of a protocol that actually needs or exercises that. If such a thing came up, I'd say that's the one to work out the way forward.
Until then, I can only point to caproles for a discussion of the issues involved, http://ivoa.net/documents/caproles/
-- Markus