> Unless it was a HEAD request, the response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate.
This is how we enumerate choices to the client today. We don't support HEAD / today (just GET / ), so that bit isn't relevant.
> If the server has a preferred choice of representation, it SHOULD include the specific URI for that representation in the Location field user agents MAY use the Location field value for automatic redirection.
This is what you're referring to, and because it's simply SHOULD, this is not a bug, but a feature request. It'd be great if all services (not just keystone) returned a link to the latest stable API endpoint (and supported HEAD, to make the whole discovery process faster).
According to http:// www.w3. org/Protocols/ rfc2616/ rfc2616- sec10.html# sec10.3. 1 ...
> Unless it was a HEAD request, the response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate.
This is how we enumerate choices to the client today. We don't support HEAD / today (just GET / ), so that bit isn't relevant.
> If the server has a preferred choice of representation, it SHOULD include the specific URI for that representation in the Location field user agents MAY use the Location field value for automatic redirection.
This is what you're referring to, and because it's simply SHOULD, this is not a bug, but a feature request. It'd be great if all services (not just keystone) returned a link to the latest stable API endpoint (and supported HEAD, to make the whole discovery process faster).