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.
-Rob
On 2 July 2014 13:13, Morgan Fainberg <morgan.fainb...@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@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Robert Collins <rbtcoll...@hp.com>
Distinguished Technologist
HP Converged Cloud
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
