Here is the list of patches pending to resolve this issue (Keystone Master, Keystone Stable/Icehouse, and Tempest)
https://review.openstack.org/#/q/status:open+topic:bug/1334368,n,z — Morgan Fainberg ------------------------------------------------------ From: Nathan Kinder nkin...@redhat.com Reply: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: July 1, 2014 at 20:02:45 To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Keystone] HTTP Get and HEAD requests mismatch on resulting HTTP status (proposed REST API Response Status Changes) > > > On 07/01/2014 07:48 PM, Robert Collins wrote: > > Wearing my HTTP fanatic hat - I think this is actually an important > > change to do. Skew like this can cause all sorts of odd behaviours in > > client libraries. > > +1. The current behavior of inconsistent response codes between the two > recommended methods of deploying Keystone should definitely be > considered as a bug IMHO. Consistency in responses is important > regardless of how Keystone is deployed, and it seems obvious that we > should modify the responses that are out of spec to achieve consistency. > > -NGK > > > > -Rob > > > > On 2 July 2014 13:13, Morgan Fainberg wrote: > >> In the endeavor to move from the default deployment of Keystone being > >> eventlet (in > devstack) to Apache + mod_wsgi, I noticed that there was an odd mis-match on > a single set > of tempest tests relating to trusts. Under eventlet a HTTP 204 No Content was > being returned, > but under mod_wsgi an HTTP 200 OK was being returned. After some > investigation it turned > out that in some cases mod_wsgi will rewrite HEAD requests to GET requests > under the hood; > this is to ensure that the response from Apache is properly built when > dealing with filtering. > A number of wsgi applications just return nothing on a HEAD request, which is > incorrect, > so mod_wsgi tries to compensate. > >> > >> The HTTP spec states: "The HEAD method is identical to GET except that the > >> server must > not return any Entity-Body in the response. The metainformation contained in > the HTTP > headers in response to a HEAD request should be identical to the information > sent in response > to a GET request. This method can be used for obtaining metainformation about > the resource > identified by the Request-URI without transferring the Entity-Body itself. > This method > is often used for testing hypertext links for validity, accessibility, and > recent modification.” > >> > >> Keystone has 3 Routes where HEAD will result in a 204 and GET will result > >> in a 200. > >> > >> * /v3/auth/tokens > >> * /v2.0/tokens/{token_id} > >> * /OS-TRUST/trusts/{trust_id}/roles/{role_id} <--- This is the only one > >> tested > by Tempest. > >> > >> The easiest solution is to correct the case where we are out of line with > >> the HTTP spec > and ensure these cases return the same status code for GET and HEAD methods. > This however > changes the response status of a public REST API. Before we do this, I wanted > to ensure > the community, developers, and TC did not have an issue with this correction. > We are not > changing the class of status (e.g. 2xx to 4xx or vice-versa). This would > simply be returning > the same response between GET and HEAD requests. The fix for this would be to > modify the > 3 tempest tests in question to expect HTTP 200 instead of 204. > >> > >> There are a couple of other cases where Keystone registers a HEAD route > >> but no GET route > (these would be corrected at the same time, to ensure compatibility). The > final correction > is to enforce that Keystone would not send any data on HEAD requests (it is > possible to > do so, but we have not had it happen). > >> > >> You can see a proof-of-concept review that shows the tempest failures > >> here: https://review.openstack.org/#/c/104026 > >> > >> If this change (even though it is in violation of > >> https://wiki.openstack.org/wiki/APIChangeGuidelines#Generally_Not_Acceptable > >> > is acceptable, it will unblock the last of a very few things to have Keystone > default deploy > via devstack under Apache (and gate upon it). Please let me know if anyone > has significant > issues with this change / concerns as I would like to finish up this road to > mod_wsgi based > Keystone as early in the Juno cycle as possible. > >> > >> Cheers, > >> Morgan Fainberg > >> > >> > >> — > >> Morgan Fainberg > >> > >> > >> > >> _______________________________________________ > >> OpenStack-dev mailing list > >> OpenStack-dev@lists.openstack.org > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
