Get socket parameters in Client or Server

[njaard]

When a Client makes a request, it may connect to one of many hosts associated with the URL.

I would like to have a way to access the IP address associated with the remote host. This is accessible from tokio via NetSocket::peer_addr().

Logically, one should also be able to access the local address with local_addr(), and so it makes sense to support access to many of the apis made available on the socket-level from tokio.

[seanmonstar]

I agree there are cases where this is desirable, but there are also reasons it doesn't exist yet. These are properties specific to TCP, whereas hyper (and HTTP even) don't require the underlying transport to be TCP (Unix domain sockets don't have a concept of addresses, for example).

It'd probably need some sort of middleware between when a transport is chosen ready to use and when a Response is given back to the user, but there isn't currently anything to really do that. For now, you'd probably need a custom Connect implementation that stores the relevant socket information in something that you can check outside of hyper.

[seanmonstar]

When would one expect to be able to receive this information? You generally give a Request to the Client, and don't know what connection it will use at that point. If it's fine that this information is received on the Response, we could optionally put this information in the Response::extensions.

If we went that way, I'd think that instead of exposing exactly that the type is in extensions, some sort of ConnectionInfo type could exist that can be get and set on the Response (and similar info could be useful on the incoming server Request).

A possible API:

pub struct ConnectionInfo {
    local_addr: Option<SocketAddr>,
    remote_addr: Option<SocketAddr>,
    // maybe new fields in the future
}

impl ConnectionInfo {
    pub fn get(res: &Response) -> ConnectionInfo {
        // fetch an internal type from `extensions()`,
        // fill in whatever info was possible
    }
    
    pub fn set(&self, res: &mut Response) {
        
    }
}

[njaard]

Sometimes you want to write logs and include the remote host in the log.

[seanmonstar]

Yes, of course. I was asking at what point would it be expected to access the remote info? Is it fine as a property of the response?

[njaard]

I guess you could also want it even earlier than that: you establish a TCP connection, log the remote host and then SSL auth fails.