[openstack-dev] [tempest][swift][radosgw] Can we please merge the fix for the RFC 7230 violation issue?
email at daviey.com
Mon Aug 8 21:27:21 UTC 2016
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  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
> 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
> Tempest has been validating this behaviour even though it is a violation
> of RFC 7230:
> 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:
> 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
> Thanks very much!
>  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:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev