Bug #12993
closedRGW/Swift sends an extra byte on error
0%
Description
I'm going to save this problem here because I have no time to look right now.
To reproduce, authenticate in Swift with our built-in v1.0 authenticator, then:
curl -v -H "X-Auth-Token: AUTH_rgwtk0b00000070726f64723a70726f6431fcc55a6e649a6534dbbaef55c3bc71129e06c879f5bb95d74916b6bfc0289e122adaa6bf" http://simbelmyne.zaitcev.lan:8080/swift/v1< HTTP/1.1 404 Not Found
< X-Timestamp: 1441688737.85909
< X-Account-Container-Count: 0
< X-Account-Object-Count: 0
< X-Account-Bytes-Used: 0
< X-Account-Bytes-Used-Actual: 0
< X-Trans-Id: tx000000000000000000011-0055ee6ca1-a02e6-default
< Content-Length: 9
< Accept-Ranges: bytes
< Content-type: text/plain; charset=utf-8
< Date: Tue, 08 Sep 2015 05:05:37 GMT
<
- Excess found in a non pipelined read: excess = 1, size = 9, maxdownload = 9, bytecount = 0
- Connection #0 to host simbelmyne.zaitcev.lan left intact
NoSuchKey
<========== length of "NoSuchKey" is 9, so maybe a newline or zero.
Updated by Pete Zaitcev over 8 years ago
(this obviously has nothing to do with Ceph Devops...)
Updated by Marcus Watts over 8 years ago
I'm looking at a similar problem with sts. If this is the same problem, then you are pretty-printing either json or xml. Both write a newline each time flush is called, which isn't counted into content-length. When curl reads this, there is a timing race. civetweb writes out the headers & the content as 2 sendto's. Curl reads the headers using a 16384 byte buffer, and then if that doesn't contain the content, does an additional read to fetch any remaining content. So if the 2nd sendto from civetweb happens fast enough, curl reads it all in at once, and objects to the extra newline from flush. If the 2nd sendto is slower, then the 2nd read will fetch the exact contents and the extra newline is never seen.