Open Stack

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 nkinder at redhat.com
Reply: OpenStack Development Mailing List (not for usage questions) openstack-dev at lists.openstack.org
Date: July 1, 2014 at 20:02:45
To: openstack-dev at lists.openstack.org openstack-dev at 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 at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
>  
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>