Open Stack

On 8 August 2016 at 17:50, Jay Pipes <jaypipes at gmail.com> wrote:

> Tempest devs,
>
> Let me please draw your attention to a LP bug that may not seem
> particularly high priority, but I believe could be resolved easily with a
> patch already proposed.
>
> LP bug 1536251 [1] accurately states that Tempest is actively verifying
> that an OpenStack API call violates RFC 7230.
>
> When a 204 No Content is received, the Content-Length header MUST NOT be
> present.
>
> However, Swift returns a Content-Length header and also an HTTP response
> code of 204 for a request to list containers of a new user (that has no
> containers).
>
> Tempest has been validating this behaviour even though it is a violation
> of RFC 7230:
>
> https://github.com/openstack/tempest/blob/master/tempest/api
> /object_storage/test_account_services.py#L81
>
> RadosGW provides a proxy API that attempts to match the OpenStack Object
> Storage API, backed by Ceph object storage. In order for RadosGW to pass
> RefStack's burden of compatibility, it must pass the Tempest OpenStack
> Object Storage API tests. It currently cannot do so because RadosGW does
> not violate RFC 7230.
>
> The RadosGW developer community does not wish to argue about whether or
> not to make Swift's API comply with RFC 7230. At the same time, they do not
> want to add a configuration option to RadosGW to force the proxy service to
> violate RFC 7230 just to satisfy the RefStack/Tempest API tests.
>
> Therefore, Radoslaw (cc'd) has proposed a patch to Tempest that would
> allow RadosGW's proxy API to meet the RefStack compatibility tests while
> also not violating RFC 7230 and not requiring any change of Swift:
>
> https://review.openstack.org/#/c/272062
>
> I ask Tempest devs to re-review the above patch and consider merging it
> for the sake of collaboration between the OpenStack and Ceph developer
> communities.
>
> Thanks very much!
> -jay
>
> [1] https://bugs.launchpad.net/tempest/+bug/1536251



These sorts of issues aren't just theoretical and following policy for the
sake of it..  Glance had 3 x areas where 200 responses that also included a
Location header (against RFC-2616 §14.30) which totally broke glance when
deployed behind apache+fcgid+flup (the presence of Location, that stack
rewrote it to a 302).

Fun bug btw:
https://bugs.launchpad.net/glance/+bug/1299095

--
Kind Regards,
Dave Walker
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160808/b92f2378/attachment.html>