Hi, This is very similar to an issue I encountered with Glance. For some unknown reason, we were adding a Location header for 200 responses.
When served behind apache+mod_fcgid, the module saw the Location header and has a hard coded conversion to 302 Redirect. This caused glanceclient to follow the redirect loop continually. As you can imagine, the stealthy changing was a real oddity to debug. More details are here: https://bugs.launchpad.net/glance/+bug/1299095 Standardisation with standards helps avoid non-standard behaviour. :) -- Kind Regards, Dave Walker On 2 July 2014 03:48, Robert Collins <robe...@robertcollins.net> 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. > > -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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
