204 No Content responses have Content-Length specified

Bug #1537811 reported by Radoslaw Zarzynski
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Object Storage (swift)
In Progress
Low
Unassigned

Bug Description

Swift appends Content-Length HTTP header with 0 value even in
a 204 No Content response. However, RFC 7230 clearly states [1]:

    "A server MUST NOT send a Content-Length header field in any
    response with a status code of 1xx (Informational) or 204 (No
    Content)."

[1] Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and
    Routing, section 3.2.2., page 30.
    https://tools.ietf.org/html/rfc7230#section-3.3.2

Revision history for this message
György Szombathelyi (gyurco) wrote :

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.

Revision history for this message
clayg (clay-gerrard) wrote :

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

Revision history for this message
clayg (clay-gerrard) wrote :

$ 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

Changed in swift:
status: New → Confirmed
importance: Undecided → Low
tags: added: low-hanging-fruit
Revision history for this message
György Szombathelyi (gyurco) wrote :

Added a tempest change to test the RFC conformance:

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

Revision history for this message
clayg (clay-gerrard) wrote :

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!

Changed in swift:
assignee: nobody → Trevor McCasland (twm2016)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to swift (master)

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

Changed in swift:
status: Confirmed → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on swift (master)

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.

Revision history for this message
György Szombathelyi (gyurco) wrote :

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

Revision history for this message
clayg (clay-gerrard) wrote :

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

Revision history for this message
clayg (clay-gerrard) wrote :

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

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

Changed in swift:
assignee: Trevor McCasland (twm2016) → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.