Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
net/http: HTTP Server messed up pipelined HTTP requests after POST request #10876
By default, Go's HTTP server (from package net/http) supports HTTP/1.1 pipelined requests (Connection: keep-alive) and will dispatch each request to a new handler Go-routine (before encountering any POST requests).
However, after the first POST request encountered in a pipeline, the Go HTTP server failed to parse the following requests, either GET or POST, and will reply with a "400 Bad Request".
A simple demo for this misbehavior: (assume we already launched the server on port 8080)
Version&architecture:I observed this phenomenon on "go version go1.4.2 windows/amd64"; the architecture shouldn't be important though. Similar behavior appears in Mac version also. This should be a package's bug.
Expected result: Other traditional HTTP servers (including Nginx/Apache, and default server in Node.js) all handled this correctly. The expected result should be three consecutive "HTTP/1.1 200 OK"s (with contents respectively).
Observed result: using the example minimal net/http server as seen in go ducument's "Writing Web Applications", the response to above pipelined requests is:
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
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
Still, please consider ignoring the carriage return (as it'll be much more convenient for sending request over command prompt).
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.