Open Stack

On Thu, Jul 3, 2014 at 4:18 PM, Brant Knudson <blk at acm.org> wrote:

>
> On Thu, Jul 3, 2014 at 3:48 PM, David Kranz <dkranz at redhat.com> wrote:
>
>> While moving success response code checking in tempest to the client, I
>> noticed that exactly one of the calls to list users for a tenant checked
>> for 200 or 203. Looking at http://docs.openstack.org/api/
>> openstack-identity-service/2.0/content/, it seems that most of the list
>> apis can return 203. But given that almost all of the tempest tests only
>> pass on getting 200, I am guessing that 203 is not actually ever being
>> returned. Is the doc just wrong? If not, what kind of call would trigger a
>> 203 response?
>>
>>  -David
>>
>
> I can't find anyplace where Keystone returns a 203, and if it did it would
> be a strange thing to do.
>
> From the HTTP 1.1 spec, a client could get 203 Non-Authoritative
> Information to any request if the request went through a proxy and the
> proxy decided to muck with the headers. Since we can't stop someone from
> putting a proxy in front of Keystone, I don't think it's wrong to list it
> as a possible successful response. I think it's redundant to list it though
> since this applies to any HTTP request... just it's redundant to list 500
> and 503 as a possible error response.
>
>
Hi Brant,
Yes, I found that 203 could be returned from a cached proxy depending on
the cloud provider. It is a possible successful response.



> I looked into trying to correct this in the docs once but couldn't figure
> out the wadls -- https://review.openstack.org/#/c/89291/
>
>
I'll take a look at this, sorry that we didn't realize the difficulty
sooner. I can amend your patch if you un-abandon it.
Anne


>  - Brant
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140703/1c6ef3a1/attachment.html>