This might have something to do with how serde tries type promotion and handles failures, but I thought it was worth reporting here first, at least because it's the actix_web::pipeline that creates the log message.
Something strange is going on with the type handling of Path<T>. With the following simple code, almost verbatim from docs:
#[macro_use] extern crate serde_derive;
extern crate actix_web;
extern crate env_logger;
use actix_web::{server, App, Path, Responder, http};
use actix_web::middleware::Logger;
#[derive(Deserialize)]
struct Coord {
x: i32,
y: i32,
}
fn greet(coord: Path<Coord>) -> impl Responder {
format!("Hello, over there at ({},{})!", coord.x, coord.y)
}
fn main() {
std::env::set_var("RUST_LOG", "actix_web=info");
env_logger::init();
server::new(|| {
App::new()
.middleware(Logger::default())
.middleware(Logger::new("%a %{User-Agent}i"))
.resource("/{x}/{y}", |r| r.method(http::Method::GET).with(greet))
})
.bind("127.0.0.1:6767")
.expect("Can not bind to port 6767")
.run();
}
Running this with RUST_BACKTRACE=1 RUST_LOG=actix_web=debug cargo run and doing a GET request to /1/3200000000, causes the following log entry:
WARN 2018-09-15T23:45:54Z: actix_web::pipeline: Error occured during request handling: can not parse "3200000000" to a i16
Note how the error is about an i16, yet it CAN parse 32-bit integer values successfully. So it's correctly using an i32 to parse them, but giving the wrong type in the WARN logging.
This might have something to do with how serde tries type promotion and handles failures, but I thought it was worth reporting here first, at least because it's the actix_web::pipeline that creates the log message.
Something strange is going on with the type handling of
Path<T>
. With the following simple code, almost verbatim from docs:Running this with
RUST_BACKTRACE=1 RUST_LOG=actix_web=debug cargo run
and doing aGET
request to/1/3200000000
, causes the following log entry:Note how the error is about an
i16
, yet it CAN parse 32-bit integer values successfully. So it's correctly using an i32 to parse them, but giving the wrong type in the WARN logging.