OpenStack Identity (keystone)

GET / returns 300 Multiple Choice without a preference in the Location header

Bug #1230927 reported by Haneef Ali on 2013-09-25

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	OpenStack Identity (keystone)	Fix Released	Wishlist	Morgan Fainberg	OpenStack Identity (keystone) stein-2

Bug Description

GET versions returns 300 Multile choices. But it doesn't return any choices. 300 is used if the client can pick and choose from the choices. Since it is not returning any choices in location header, it is better to simply return 200 OK

Revision history for this message

Dolph Mathews (dolph) wrote on 2013-09-25:

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).

Changed in keystone:
importance:	Undecided → Wishlist
status:	New → Triaged
summary:	- GET versions returns 300. Should return 200 OK, unless multiple choices - are provided + GET / returns 300 Multiple Choice without a preference in the Location + header

Revision history for this message

Haneef Ali (haneef) wrote on 2013-09-25:

I now understand the origin of 300 status code.

http://docs.openstack.org/api/openstack-compute/2/content/Versions-d1e1193.html

Originaly it was intended as choice, so it made sense. In current implementaton it is just a json It is not different from other JSON. That's why I asked why do we need to return the special status code 300.

Some of the status code doesn't fit REST API. IMO 300 is one of them. Normally 300 returns a html list and the browser presents that to the user and user selects one of the option.

If the intention is auto discovery then it makes sense

Revision history for this message

Dolph Mathews (dolph) wrote on 2013-09-26:

The intention is auto-discovery, we're just not completely there yet :)

Returning a Location header with a preferred versioned endpoint sounds like an easy step towards that goal.

Revision history for this message

OpenStack Infra (hudson-openstack) wrote on 2018-10-26: Fix proposed to keystone (master)

Fix proposed to branch: master
Review: https://review.openstack.org/613633

Changed in keystone:
assignee:	nobody → Morgan Fainberg (mdrnstm)
status:	Triaged → In Progress

Revision history for this message

OpenStack Infra (hudson-openstack) wrote on 2018-11-09: Fix merged to keystone (master)

Reviewed: https://review.openstack.org/613633
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=50e3fe5c945c3d3241f4607a57a0e67a3f55b21d
Submitter: Zuul
Branch: master

commit 50e3fe5c945c3d3241f4607a57a0e67a3f55b21d
Author: Morgan Fainberg <email address hidden>
Date: Fri Oct 26 09:19:57 2018 -0700

Provide a Location on HTTP 300

    To best adhere to the RFC2616, we should emit a Location header when
    issuing an HTTP 300 to point to the preferred version. While we only
    have a single version active it is 'v3'. In the future it should
    always be the most recent set of CRUD. This location is strictly for
    CRUD purposes and will lean on the WWW-Authentication URI to point
    to the most correct AUTH uri.

Change-Id: Ibdd53f236a3c51d1aa23eac35dd595e2dae79ba6
closes-bug: #1230927