net/http: treat HEAD requests like GET requests

A response to a HEAD request is supposed to look the same as a
response to a GET request, just without a body.

HEAD requests are incredibly rare in the wild.

The Go net/http package has so far treated HEAD requests
specially: a Write on our default ResponseWriter returned
ErrBodyNotAllowed, telling handlers that something was wrong.
This was to optimize the fast path for HEAD requests, but:

1) because HEAD requests are incredibly rare, they're not
   worth having a fast path for.

2) Letting the http.Handler handle but do nop Writes is still
   very fast.

3) this forces ugly error handling into the application.
   e.g. https://code.google.com/p/go/source/detail?r=6f596be7a31e
   and related.

4) The net/http package nowadays does Content-Type sniffing,
   but you don't get that for HEAD.

5) The net/http package nowadays does Content-Length counting
   for small (few KB) responses, but not for HEAD.

6) ErrBodyNotAllowed was useless. By the time you received it,
   you had probably already done all your heavy computation
   and I/O to calculate what to write.

So, this change makes HEAD requests like GET requests.

We now count content-length and sniff content-type for HEAD
requests. If you Write, it doesn't return an error.

If you want a fast-path in your code for HEAD, you have to do
it early and set all the response headers yourself. Just like
before. If you choose not to Write in HEAD requests, be sure
to set Content-Length if you know it. We won't write
"Content-Length: 0" because you might've just chosen to not
write (or you don't know your Content-Length in advance).

Fixes issue 5454

R=golang-dev, dsymonds
CC=golang-dev
https://codereview.appspot.com/12583043
net/http: do not send redundant Connection: close header in HTTP/1.0 responses

HTTP/1.0 connections are closed implicitly, unless otherwise specified.

Note that this change does not test or fix "request too large" responses.
Reasoning: (a) it complicates tests and fixes, (b) they should be rare,
and (c) this is just a minor wire optimization, and thus not really worth worrying
about in this context.

Fixes issue 5955.

R=golang-dev, bradfitz
CC=golang-dev
https://codereview.appspot.com/12435043

Committer: Brad Fitzpatrick <bradfitz@golang.org>