[openstack-dev] [Keystone] HTTP Get and HEAD requests mismatch on resulting HTTP status (proposed REST API Response Status Changes)

2014-07-01 Thread Morgan Fainberg
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 20

Re: [openstack-dev] [Keystone] HTTP Get and HEAD requests mismatch on resulting HTTP status (proposed REST API Response Status Changes)

2014-07-01 Thread Robert Collins
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 wrote: > In the endeavor to move from the default deployment of Keystone being > eventlet (in de

Re: [openstack-dev] [Keystone] HTTP Get and HEAD requests mismatch on resulting HTTP status (proposed REST API Response Status Changes)

2014-07-01 Thread Nathan Kinder
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 met

Re: [openstack-dev] [Keystone] HTTP Get and HEAD requests mismatch on resulting HTTP status (proposed REST API Response Status Changes)

2014-07-03 Thread Morgan Fainberg
...@redhat.com Reply: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: July 1, 2014 at 20:02:45 To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org Subject:  Re: [openstack-dev] [Keystone] HTTP Get and HEAD requests mismatch on resulting

Re: [openstack-dev] [Keystone] HTTP Get and HEAD requests mismatch on resulting HTTP status (proposed REST API Response Status Changes)

2014-07-03 Thread Dave Walker
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 follo