Open Stack

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 <morgan.fainberg at gmail.com> 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
> 
> 
>