Wishlist bug for what net/http would look like if we could make backwards-incompatible
changes.
Anything goes.
I'll start:
* Handler (http://golang.org/pkg/net/http/#Handler) currently takes a pointer to a 208
byte Request struct.
* The Request struct (http://golang.org/pkg/net/http/#Request) has all its fields
publicly exposed, most of which require memory allocation:
-- Method
-- URL (itself 104 bytes, with a bunch of strings requiring allocation)
-- Header map + slices + strings (even if never accessed)
-- TransferEncoding slice (even if not accessed)
-- Host string (even if not accessed)
-- RemoteAddr string (even if not accessed)
-- RequestURI (even if not accessed)
-- TLS state struct (even if not accessed)
For a lightweight handler that doesn't touch anything (say, serves some static content
from memory), this means we can't do any better than generating ~1KB of garbage per
request.
I'd prefer to make a ServerRequest interface with accessor methods which can generate
needed data on demand.
This would also simplify our docs on our doubly-abused-in-different-ways *Request, which
contains documentation gems like:
// PostForm contains the parsed form data from POST or PUT
// body parameters.
// This field is only available after ParseForm is called.
// The HTTP client ignores PostForm and uses Body instead.
PostForm url.Values
If we had byte views (issue #5376), I would also say that most fields in the
ServerRequest, URL, Header, and FormValues are all byte views with validity scoped to
the duration of the http.Handler call, instead of strings.
