<pre class="notranslate">The strconv package's ParseFloat / ParseInt only take string.

To reduce allocations, I need to parse an int from a []byte.

I attempted to convert strconv's Parse internals to use []byte instead, and then make
the existing string versions make an unsafe []byte of the string's memory using
reflect.SliceHeader / reflect.StringHeader, but the reflect package already depends on
strconv, so there's an import loop.</pre>
<pre class="notranslate">From golang-dev:

"""
Matthew Endsley:

I was testing the go1.3rc1 release on our codebase and found it failed one of our test
cases involving http responses.

It appears that in some cases, http.Response.Write will emit 2 Content-Length headers. A
short example the reproduces the behavior can be found here:
<a href="http://play.golang.org/p/qsH1MeVSHu" rel="nofollow">http://play.golang.org/p/qsH1MeVSHu</a>

In go 1.2 this generated the following output:
HTTP/1.1 200 OK
Content-Length: 0

In go1.3rc1 I'm getting the following:
HTTP/1.1 200 OK
Content-Length: 0
Content-Length: 0

For reference, on current tip (087e446f2c41) I see the same output as go1.3rc1

As a side note, this issue only occurs if response.Request.Method is "POST".
If the request method is "GET" the duplicate Content-Length is not emitted.
"""



The problem was introduced in revision b2ebbbcfc615 for fixing <a href="https://golang.org/issue/5381" rel="nofollow">issue #5381</a>. The net/http
Server doesn't use this code, but it is a regression from 1.2.  In the earlier fix, I
didn't take care of the case where PUT/POST were special-cased in transfer.go ages ago
in revision 4d792b5bea35 for HTTP Requests, but the transfer code deals with both
Requests and Responses, so a Content-Length of length 0 was always being sent for
Responses too.  That code deserves a second look in Go 1.4, but will fix minimally for
now.</pre>