Connection Close on 204 No Content

[sschepens]

I have an issue where a webserver is returning a 204 response with Connection: keep-alive, but fasthttp sets Connection: close and closes the connection, this does not happen with curl or net/http.

This is the response according to fasthttp:

HTTP/1.1 204 No Content
Server: fasthttp
Date: Tue, 12 Jan 2016 16:34:26 GMT
Content-Type: text/plain; charset=utf-8
X-Powered-By: Express
Etag: W/"2-2745614147"
Date: Tue, 12 Jan 2016 16:34:30 GMT
Connection: keep-alive
Transfer-Encoding: identity
Connection: close

This is the response according to net/http:

&{Status:204 No Content StatusCode:204 Proto:HTTP/1.1 ProtoMajor:1 ProtoMinor:1 Header:map[X-Powered-By:[Express] Etag:[W/"2-2745614147"] Date:[Tue, 12 Jan 2016 16:34:30 GMT] Connection:[keep-alive]] Body:0xc8200de580 ContentLength:0 TransferEncoding:[] Close:false Trailer:map[] Request:0xc820112000 TLS:<nil>}

And this is according to curl:

< HTTP/1.1 204 No Content
< X-Powered-By: Express
< ETag: W/"2-2745614147"
< Date: Tue, 12 Jan 2016 16:35:39 GMT
< Connection: keep-alive
< 
* Connection #0 to host xxx left intact

This is the code i'm using:

    req := fasthttp.AcquireRequest()
    res := fasthttp.AcquireResponse()
    defer fasthttp.ReleaseRequest(req)
    defer fasthttp.ReleaseResponse(res)
    req.SetRequestURI("URL")
    req.Header.SetMethod("GET")
    req.Header.Set("Accept", "application/json")
    err := fasthttp.DoTimeout(req, res, 1*time.Second)

Am I doing something wrong or is it a bad behavior of fasthttp?

[sschepens]

Apparently it has to do with with fasthttp detecting Transfer-Encoding: identity as default when no Content-Length is set and forcing connection close.
Its curious though that the server is responding a 204 which should skip body according to spec.
This is true when reading body, but not considered when parsing headers:
https://github.com/valyala/fasthttp/blob/master/header.go#L1421
https://github.com/valyala/fasthttp/blob/master/header.go#L1469

Changing default content-length to 0 fixes this issue, and seems to be the default behavior of other http clients.

Also, as per [rfc7230)(https://tools.ietf.org/html/rfc7230):

The "identity" transfer coding token has been removed.

A server MUST NOT send a Content-Length header field in any response
with a status code of 1xx (Informational) or 204 (No Content). A
server MUST NOT send a Content-Length header field in any 2xx
(Successful) response to a CONNECT request (Section 4.3.6 of
[RFC7231]).

[valyala]

Thanks for the bug report and the patch. I'll look into it tomorrow.