← Back to team overview

yahoo-eng-team team mailing list archive

[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