Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide access to remote IP address in incoming server requests #1650

Closed
klausi opened this issue Sep 7, 2018 · 5 comments
Closed

Provide access to remote IP address in incoming server requests #1650

klausi opened this issue Sep 7, 2018 · 5 comments
Labels
A-server Area: server. B-upstream Blocked: needs a change in a dependency or the compiler. C-feature Category: feature. This is adding a new feature.

Comments

@klausi
Copy link
Contributor

klausi commented Sep 7, 2018

When writing a server in Hyper I should be able to retrieve the remote IP address from the request.

@seanmonstar mentioned in #1410 that an API similar to the client (#1402) might be relevant?

API usage could then look like this:

fn respond_with_sender_ip(request: Request<Body>) -> BoxFut {
    let remote_address = request
        .extensions()
        .get::<HttpInfo>()
        .expect("something something sets HttpInfo")
        .remote_addr();

    Box::new(future::ok(Response::new(Body::from(remote_address))))
}

(Please edit this to make the proposed API usage correct :-)

@rainchen
Copy link

+1 for this request, ip address info is very useful for a network service

@miquels
Copy link

miquels commented Sep 25, 2018

See also carllerche/tower-web#71

@seanmonstar
Copy link
Member

The idea of passing an argument to the NewService is being explored here: tower-rs/tower#108

If that change is done, we could pass &Incoming::Item or something, and then the NewService could grab the remote address and anything else it wants (like TLS context info) to then be used in the constructed Services.

@seanmonstar seanmonstar added A-server Area: server. B-upstream Blocked: needs a change in a dependency or the compiler. C-feature Category: feature. This is adding a new feature. labels Oct 16, 2018
@seanmonstar
Copy link
Member

I did some exploration of converting NewService to MakeService<Ctx>, such that you can access the transport when creating a Service. The WIP is here: 94cc806

Here's how the API worked out (mostly so as to not be a breaking change for NewService):

let server = Server::bind(&addr)
    .serve(make_service_fn(|conn: &AddrStream| {
        let remote_addr = conn.remote_addr();
        service_fn_ok(move |_: Request<Body>| {
            Response::new(Body::from(format!("Hello, {}", remote_addr)))
        })
    }))

@felipenoris
Copy link

I'm working on a reverse proxy using hyper (new version for https://github.com/brendanzab/hyper-reverse-proxy), and this is quite useful to implement x-forwarded-for header. The former version was hooked directly to TcpListener, which is quite low level.

seanmonstar added a commit that referenced this issue Nov 1, 2018
…ntext

This adjusts the way `Service`s are created for a `hyper::Server`. The
`MakeService` trait allows receiving an argument when creating a
`Service`. The implementation for `hyper::Server` expects to pass a
reference to the accepted transport (so, `&Incoming::Item`). The user
can inspect the transport before making a `Service`.

In practice, this allows for things like getting the remote socket
address, or the TLS certification, or similar.

To prevent a breaking change, there is a blanket implementation of
`MakeService` for any `NewService`. Besides implementing `MakeService`
directly, there is also added `hyper::service::make_service_fn`.

Closes #1650
seanmonstar added a commit that referenced this issue Nov 1, 2018
…ntext

This adjusts the way `Service`s are created for a `hyper::Server`. The
`MakeService` trait allows receiving an argument when creating a
`Service`. The implementation for `hyper::Server` expects to pass a
reference to the accepted transport (so, `&Incoming::Item`). The user
can inspect the transport before making a `Service`.

In practice, this allows for things like getting the remote socket
address, or the TLS certification, or similar.

To prevent a breaking change, there is a blanket implementation of
`MakeService` for any `NewService`. Besides implementing `MakeService`
directly, there is also added `hyper::service::make_service_fn`.

Closes #1650
seanmonstar added a commit that referenced this issue Nov 2, 2018
…ntext

This adjusts the way `Service`s are created for a `hyper::Server`. The
`MakeService` trait allows receiving an argument when creating a
`Service`. The implementation for `hyper::Server` expects to pass a
reference to the accepted transport (so, `&Incoming::Item`). The user
can inspect the transport before making a `Service`.

In practice, this allows for things like getting the remote socket
address, or the TLS certification, or similar.

To prevent a breaking change, there is a blanket implementation of
`MakeService` for any `NewService`. Besides implementing `MakeService`
directly, there is also added `hyper::service::make_service_fn`.

Closes #1650
seanmonstar added a commit that referenced this issue Nov 2, 2018
…ntext

This adjusts the way `Service`s are created for a `hyper::Server`. The
`MakeService` trait allows receiving an argument when creating a
`Service`. The implementation for `hyper::Server` expects to pass a
reference to the accepted transport (so, `&Incoming::Item`). The user
can inspect the transport before making a `Service`.

In practice, this allows for things like getting the remote socket
address, or the TLS certification, or similar.

To prevent a breaking change, there is a blanket implementation of
`MakeService` for any `NewService`. Besides implementing `MakeService`
directly, there is also added `hyper::service::make_service_fn`.

Closes #1650
seanmonstar added a commit that referenced this issue Nov 16, 2018
…ntext

This adjusts the way `Service`s are created for a `hyper::Server`. The
`MakeService` trait allows receiving an argument when creating a
`Service`. The implementation for `hyper::Server` expects to pass a
reference to the accepted transport (so, `&Incoming::Item`). The user
can inspect the transport before making a `Service`.

In practice, this allows for things like getting the remote socket
address, or the TLS certification, or similar.

To prevent a breaking change, there is a blanket implementation of
`MakeService` for any `NewService`. Besides implementing `MakeService`
directly, there is also added `hyper::service::make_service_fn`.

Closes #1650
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-server Area: server. B-upstream Blocked: needs a change in a dependency or the compiler. C-feature Category: feature. This is adding a new feature.
Projects
None yet
Development

No branches or pull requests

5 participants