At first sight, this sounds like a regression from https://github.com/wikimedia/hyperswitch/pull/51. However, looking at that code, the dynamic basePath generation ought to still work as it did before.

@mobrovac, for clarification: Is this about the basePath in memory, or the basePath as returned from ?spec requests?

In T142366#2533613, @GWicke wrote:

@mobrovac, for clarification: Is this about the basePath in memory, or the basePath as returned from ?spec requests?

The former:

A node's specRoot.basePath always points to the domain that is first processed in the list.

So, yeah, likely a regression from PR #51

I see. Why is this an issue, considering that it is dynamically set for spec responses?

Edit: It has always been like that, and is the consequence of spec sharing. There was no change to that behavior recently.

Because of this check a request to localhost:7231/{domain}/v1/ returns the JSON listing instead of the swagger-ui HTML for any domain but the first one specified in the list of domains in the configuration file regardless of the Accept header.

@mobrovac: I see. That test is indeed new, and looks faulty.

That's expected, isn't it? The intention is to only return HTML at spec roots, which would be / and /en.wp.org/v1/, but not /en.wp.org/.

@GWicke No, localhost:7231/en.wp.org/ should return an HTML listing like this one: https://rest.wikimedia.org since it's above the specRoot level.

What is the use case for returning a HTML listing below the domain? It's below the root spec, but above the API spec level. And it's not publicly accessible in production.

@GWicke After we remove rest.wikimedia.org it will indeed be unaccessible.

PR #647 makes RESTBase explicitly depend on HyperSwitch v0.6.3 and removes the test that will become inaccessible on 2016-09-01.