<p dir="auto">by <strong><a href="mailto:ask@develooper.com">ask@develooper.com</a></strong>:</p>
<pre class="notranslate">Similar to the new TLS field with the tls.ConnectionState in the http.Response struct
it'd be useful to get access to some connection information.

For my use case I was missing the IP the client connected to (RemoteAddr); I am not sure
if there's other information in the current connection API that would be useful to
expose.</pre>
<pre class="notranslate">Wishlist bug for what net/http would look like if we could make backwards-incompatible
changes.

Anything goes.

I'll start:

* Handler (<a href="http://golang.org/pkg/net/http/#Handler)" rel="nofollow">http://golang.org/pkg/net/http/#Handler)</a> currently takes a pointer to a 208
byte Request struct.  

* The Request struct (<a href="http://golang.org/pkg/net/http/#Request)" rel="nofollow">http://golang.org/pkg/net/http/#Request)</a> 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 (<a href="https://golang.org/issue/5376" rel="nofollow">issue #5376</a>), 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.</pre>