yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #62996
[Bug 1680040] Re: Not all GET should have a correspondent HEAD, and vice-versa
HEAD calls should still be supported. It may not make sense for some
things, but it can be useful (someone can check content length, which
should be identical, or headers, or any number of things that aren't
what you'd expect).
Simply put, it costs us *nothing* to support it.
** Changed in: keystone
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1680040
Title:
Not all GET should have a correspondent HEAD, and vice-versa
Status in OpenStack Identity (keystone):
Invalid
Bug description:
Most of keystone implement GET and HEAD for the same operation.
This is okay when you are retrieving an entity or checking its
existence, for example:
GET /users/<id>
HEAD /users/<id>
However, there are some cases where having GET is obvious, but HEAD
does not make any sense:
GET /role_assignments
HEAD /role_assignments
GET /users/{user_id}/groups
HEAD /users/{user_id}/groups
The role assignments and groups will only be returned in those API,
there is nothing to be checked, you cannot even specify anything to be
checked.
And it happens on the other way around too:
HEAD /OS-EP-FILTER/projects/{project_id}/endpoints/{endpoint_id}
GET /OS-EP-FILTER/projects/{project_id}/endpoints/{endpoint_id}
The endpoint to project association is not an entity by itself,
performing a GET on it will not return anything, it will just check
its existence, as does the HEAD request.
This should be fixed, there is no need to maintain APIs that are not
useful.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1680040/+subscriptions
References