Perhaps more generic solution would be just to expose 'io'.
request.io.peeraddr.address

However this still remains OpenSSL as special-case, as it does not expose peeraddr, and it's obviously not nice to do something like
request.io.io.peeraddr.address after verifying that io is actually OpenSSL socket.

So maybe two things for clean solution
a) more generic/shared OpenSSL and normal socket
b) expose the generic socket

I'm not sure about this, because we are always requesting the addr and peeraddr, whatever happens, and we most likely will never need this information.

We won't expose the socket since request.io.addr would be fiddling with internal implementation details. We could memoize the socket then delegate addr and peeraddr to it... but we don't need to retain the socket once the request is built. Actually, we can build a Request that doesn't come from a socket at all, it can be manually built or parsed from a MemoryIO.

I'm not sure Request should expose the addr and peeraddr. You may retain the sockets and pass them along with the request if you really need them (or inherit/wrap HTTP::Request to expose these informations)

What is the downside of exposing them? If we just extract the IP, that's up-to 256bits of new data stored? Considering how long headers etc can be, and how much more useful SADDR of request is, than lot of the other data, isn't it justifiable?
I can understand why you might not want to expose objects, because they can't be GC'd, but what about exposing just the data?

I'm also thinking of doing something like this to retrieve to client's ip info though i was thinking of reading it from headers.

Any update on this?

Ping

We'll eventually do this, but not by adding this info to the Request object