Personally, I suspect this is due to request.go#741 , the ReadAll() may affect later requests. Perhaps there need add a missing header.get("Content-Length"). However, I haven't looked into the server implementation thoroughly.

I think it is not due to the implementation of parsePostForm but rather to the bogus \r\n you have added after the message body of the POST query. See https://www.ietf.org/rfc/rfc2616.txt section 4.1

It says:

In the interest of robustness, servers SHOULD ignore any empty
line(s) received where a Request-Line is expected. In other words, if
the server is reading the protocol stream at the beginning of a
message and receives a CRLF first, it should ignore the CRLF.

Certain buggy HTTP/1.0 client implementations generate extra CRLF's
after a POST request. To restate what is explicitly forbidden by the
BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an
extra CRLF.

The Go http package SHOULD ignore the CRLF, but does not. The Go implementation could be made more robust by ignoring those CRLF, but what it currently does is still correct.

Yes, you're right, the correct request (which Go server will now accept) is

printf "\
POST / HTTP/1.1\r\n\
Host: localhost\r\n\
Connection: keep-alive\r\n\
Content-Type: application/x-www-form-urlencoded\r\n\
Content-Length: 7\r\n\
\r\n\
A=a&B=bGET / HTTP/1.1\r\n\
Host: localhost\r\n\
Connection: keep-alive\r\n\
\r\n\
GET / HTTP/1.1\r\n\
Host: localhost\r\n\
Connection: keep-alive\r\n\
\r\n\
" | nc localhost 8080

Still, please consider ignoring the carriage return (as it'll be much more convenient for sending request over command prompt).

Probably, @bradfitz to decide.

Mailing a CL in case he wants it.

Please refer http://tools.ietf.org/html/rfc7230#section-3 instead of obsoleted RFC 2616.

CL https://golang.org/cl/10170 mentions this issue.

Ah yes, sorry. In RFC 7230, this recommendation is in section 3.5.
http://tools.ietf.org/html/rfc7230#section-3.5
Updating the CL.

My previous HTTP load balancer (https://github.com/perlbal/Perlbal) ignored that extra \r\n after a POST, but I thought that one buggy browser (Netscape Navigator something) died out 10+ years ago.

Is there an actual HTTP client which still is broken like this?

I would really rather be strict unless it would actually help an important client.

Or we could at least detect it and return an error message informing the user that their HTTP client is buggy and old.

CL https://golang.org/cl/11491 mentions this issue.