Struct trillium_conn_id::ConnId

pub struct ConnId { /* private fields */ }

Trillium handler to set a identifier for every Conn.

By default, it will use an inbound x-request-id request header or if that is missing, populate a ten character random id. This handler will set an outbound x-request-id header as well by default. All of this behavior can be customized with ConnId::with_request_header, ConnId::with_response_header and ConnId::with_id_generator

Implementations

impl ConnId

pub fn new() -> Self

Constructs a new ConnId handler

let app = (ConnId::new().with_seed(1000), "ok"); // seeded for testing
assert_ok!(
    get("/").on(&app),
    "ok",
    "x-request-id" => "4fekClhof7"
);

assert_headers!(
    get("/")
        .with_request_header("x-request-id", "inbound")
        .on(&app),
    "x-request-id" => "inbound"
);

pub fn with_request_header( self, request_header: impl Into<HeaderName<'static>> ) -> Self

Specifies a request header to use. If this header is provided on the inbound request, the id will be used unmodified. To disable this behavior, see ConnId::without_request_header

let app = (
    ConnId::new().with_request_header("x-custom-id"),
    "ok"
);

assert_headers!(
    get("/")
        .with_request_header("x-custom-id", "inbound")
        .on(&app),
    "x-request-id" => "inbound"
);

pub fn without_request_header(self) -> Self

disables the default behavior of reusing an inbound header for the request id. If a ConnId is configured without_request_header, a new id will always be generated

pub fn with_response_header( self, response_header: impl Into<HeaderName<'static>> ) -> Self

Specifies a response header to set. To disable this behavior, see ConnId::without_response_header

let app = (
    ConnId::new()
        .with_seed(1000) // for testing
        .with_response_header("x-custom-header"),
    "ok"
);

assert_headers!(
    get("/").on(&app),
    "x-custom-header" => "4fekClhof7"
);

pub fn without_response_header(self) -> Self

Disables the default behavior of sending the conn id as a response header. A request id will be available within the application through use of ConnIdExt but will not be sent as part of the response.

pub fn with_id_generator<F>(self, id_generator: F) -> Self

where F: Fn() -> String + Send + Sync + 'static,

Provide an alternative generator function for ids. The default is a ten-character alphanumeric random sequence.

let app = (
    ConnId::new().with_id_generator(|| Uuid::new_v4().to_string()),
    "ok"
);

// assert that the id is a valid uuid, even if we can't assert a specific value
assert!(Uuid::parse_str(get("/").on(&app).headers_mut().get_str("x-request-id").unwrap()).is_ok());

pub fn with_seed(self, seed: u64) -> Self

seed a shared rng

this is primarily useful for tests

Trait Implementations

impl Debug for ConnId

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Default for ConnId

fn default() -> Self

Returns the “default value” for a type.

impl Handler for ConnId

fn run<'life0, 'async_trait>( &'life0 self, conn: Conn ) -> Pin<Box<dyn Future<Output = Conn> + Send + 'async_trait>>

where Self: 'async_trait, 'life0: 'async_trait,

Executes this handler, performing any modifications to the Conn that are desired.

fn init<'life0, 'life1, 'async_trait>( &'life0 mut self, _info: &'life1 mut Info ) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>

where 'life0: 'async_trait, 'life1: 'async_trait, Self: 'async_trait,

Performs one-time async set up on a mutable borrow of the Handler before the server starts accepting requests. This allows a Handler to be defined in synchronous code but perform async setup such as establishing a database connection or fetching some state from an external source. This is optional, and chances are high that you do not need this.

fn before_send<'life0, 'async_trait>( &'life0 self, conn: Conn ) -> Pin<Box<dyn Future<Output = Conn> + Send + 'async_trait>>

where 'life0: 'async_trait, Self: 'async_trait,

Performs any final modifications to this conn after all handlers have been run. Although this is a slight deviation from the simple conn->conn->conn chain represented by most Handlers, it provides an easy way for libraries to effectively inject a second handler into a response chain. This is useful for loggers that need to record information both before and after other handlers have run, as well as database transaction handlers and similar library code.

fn has_upgrade(&self, _upgrade: &Upgrade<BoxedTransport>) -> bool

predicate function answering the question of whether this Handler would like to take ownership of the negotiated Upgrade. If this returns true, you must implement [Handler::upgrade]. The first handler that responds true to this will receive ownership of the [trillium::Upgrade][crate::Upgrade] in a subsequent call to [Handler::upgrade]

fn upgrade<'life0, 'async_trait>( &'life0 self, _upgrade: Upgrade<BoxedTransport> ) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>

where 'life0: 'async_trait, Self: 'async_trait,

This will only be called if the handler reponds true to [Handler::has_upgrade] and will only be called once for this upgrade. There is no return value, and this function takes exclusive ownership of the underlying transport once this is called. You can downcast the transport to whatever the source transport type is and perform any non-http protocol communication that has been negotiated. You probably don’t want this unless you’re implementing something like websockets. Please note that for many transports such as TcpStreams, dropping the transport (and therefore the Upgrade) will hang up / disconnect.

fn name(&self) -> Cow<'static, str>

Customize the name of your handler. This is used in Debug implementations. The default is the type name of this handler.