Designate returns non-zero Content-Length on some HTTP 204's
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Designate |
Fix Released
|
Undecided
|
Tim Simmons | ||
Mitaka |
Fix Committed
|
Undecided
|
Tim Simmons | ||
Newton |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
It appears that some calls that return an HTTP 204 No Content status, Designate returns a non-zero content-length:
curl -v -X POST http://
* Hostname was NOT found in DNS cache
* Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 9001 (#0)
> POST /v2/zones/
> User-Agent: curl/7.38.0
> Host: localhost
> Accept: */*
>
< HTTP/1.1 204 No Content
< Content-Length: 2
< X-Openstack-
< Date: Mon, 13 Jun 2016 19:19:54 GMT
<
* Connection #0 to host localhost left intact
On deletes, this can be a problem:
curl -v -X DELETE localhost/
* Hostname was NOT found in DNS cache
* Trying ::1...
* connect to ::1 port 80 failed: Connection refused
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 80 (#0)
> DELETE /v2/zones/
> User-Agent: curl/7.38.0
> Host: localhost
> Accept: */*
>
< HTTP/1.1 204 No Content
< Content-Length: 2
< X-Openstack-
< Date: Mon, 13 Jun 2016 20:01:11 GMT
<
* Excess found in a non pipelined read: excess = 2 url = /v2/zones/
* Connection #0 to host localhost left intact
Having a body here, and thus a content-length is incorrect:
"The 204 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields."
https:/
Clients that assume no body, and thus don't continue reading from the socket can run into issues when, on the next read of continued connection, those N number of bytes are sitting there.
The affected calls appear to be:
DELETE /v2/zones/
DELETE /v2/zones/
POST /v2/zones/
Changed in designate: | |
milestone: | none → newton-2 |
Fix proposed to branch: master /review. openstack. org/329175
Review: https:/