204 No Content responses have Content-Length specified

Also some proxy (like Apache mod_proxy) strips content-length when it sees a 204 response, so tempest tests fail with this kind of proxy.

I'd probably look to see if this could be fixed in common.swob

$ curl -H "x-auth-token: $OS_AUTH_TOKEN" $OS_STORAGE_URL/foo -v
* Hostname was NOT found in DNS cache
* Trying 127.0.1.1...
* Connected to saio (127.0.1.1) port 8080 (#0)
> GET /v1/AUTH_test/foo HTTP/1.1
> User-Agent: curl/7.35.0
> Host: saio:8080
> Accept: */*
> x-auth-token: AUTH_XXX
>
< HTTP/1.1 204 No Content
< Content-Length: 0
< X-Container-Object-Count: 0
< Accept-Ranges: bytes
< X-Storage-Policy: default
< X-Container-Bytes-Used: 0
< X-Timestamp: 1453849919.83459
< Content-Type: text/html; charset=UTF-8
< X-Trans-Id: txd3c1ae214ee3488b8ae36-0056b10860
< Date: Tue, 02 Feb 2016 19:49:52 GMT
<
* Connection #0 to host saio left intact

Added a tempest change to test the RFC conformance:

https://review.openstack.org/#/c/275652/

I find this all terribly fascinating - I'm hoping I'll get some interesting responses on the ML:

http://markmail.org/message/ti2odjcu5ky5zdbn

^ totally not trolling, genuinely curious!

Fix proposed to branch: master
Review: https://review.openstack.org/291461

Change abandoned by Trevor McCasland (<email address hidden>) on branch: master
Review: https://review.openstack.org/291461
Reason: Abandoning due to the potential harm this could do that was mentioned in the comments.

If tempest will allow a missing content-length:
https://bugs.launchpad.net/tempest/+bug/1536251

Then what is the potential harm?

Also:
- radosgw already removed the content-length for 204 (See: https://github.com/ceph/ceph/commit/4e5921dbc7d1c51feb4cc5c03aa59a432742765e )
- mod_proxy in Apache removes content-length for 204

You know it's funny, i looked at the bug filed on radowsgw [1] and the example they used was a DELETE request:

vagrant@saio:~$ curl -H 'x-auth-token: AUTH_tkc89814ea435e47849296bf9269f31e12' http://saio:8080/v1/AUTH_test/test/test -XDELETE -v
* Hostname was NOT found in DNS cache
* Trying 127.0.0.1...
* Connected to saio (127.0.0.1) port 8080 (#0)
> DELETE /v1/AUTH_test/test/test HTTP/1.1
> User-Agent: curl/7.35.0
> Host: saio:8080
> Accept: */*
> x-auth-token: AUTH_tkc89814ea435e47849296bf9269f31e12
>
< HTTP/1.1 204 No Content
< Content-Length: 0
< Content-Type: text/html; charset=UTF-8
< X-Trans-Id: tx0bb6d13f4f084b6b94f4f-0057aa065b
< Date: Tue, 09 Aug 2016 16:35:39 GMT
<
* Connection #0 to host saio left intact

I'm not sure what the referenced issue was with Varnish? [1]

1. http://tracker.ceph.com/issues/13582

I did a bit more digging, I think the Varnish regression that triggered all of this was https://www.varnish-cache.org/trac/ticket/1826

Which they had to fix it because Apache and bunch of other webservers invented back before RFC 7230 also do this. The comment was ~ "We shouldn't be more catholic than the Pope" lol

Change abandoned by Trevor McCasland (<email address hidden>) on branch: master
Review: https://review.openstack.org/291461