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
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
