Unexpected redirect when query param has trailing slash

[LGUG2Z]

• I have looked for existing issues (including closed) about this

Bug Report

Version

❯ cargo tree | grep axum
├── axum v0.6.11
│   ├── axum-core v0.3.3
├── axum-auth v0.4.0
│   ├── axum-core v0.3.3 (*)

Platform

❯ uname -a
Linux nixos 6.1.16 #1-NixOS SMP PREEMPT_DYNAMIC Fri Mar 10 08:34:34 UTC 2023 x86_64 GNU/Linux

Description

I will share a minimal reproduction repository for this when I have a bit more time, but essentially this is a bug with unexpected redirects when query parameters include a trailing slash:

#[derive(Deserialize)]
pub struct ItemGetQuery {
    url: String,
}

pub async fn item_get(
    query: Query<ItemGetQuery>,
) -> Result<Json<ItemGetResponse>, ApiError> {
    // some logic
}

// over in the main fn ...

let app = Router::new()
    .route("/v1/item", routing::get(item_get));

When the query parameter is a URL string with a trailing slash, the Axum trailing slash redirect behaviour (which based on reading issues in this repo, should have been disabled by default now?) kicks in leading to unexpected/undefined behaviour.

For example, this curl request:

curl 'http://localhost:1234/v1/item?url=https://blog.alexellis.io/docker-is-deleting-open-source-images/'

Will result in an unexpected 308 redirect to this location:

location: /item?url=https://blog.alexellis.io/docker-is-deleting-open-source-images/

Which will then of course ultimately lead to a 404 response.

[jplatte]

Can you please provide a minimal reproducible example?

[davidpdrsn]

Is http://localhost:1234/v1/item?url=https://blog.alexellis.io/docker-is-deleting-open-source-images/ even a valid uri? I would have guessed you need to escape the /s

[jplatte]

I don't think the /s need to be escaped, c.f. https://url.spec.whatwg.org/#query-percent-encode-set

[LGUG2Z]

I must embarrassingly admit that when putting together the isolated reproduction for this issue, I realized that this was a case of overzealous reverse-proxy caching in the browser where this bug had previously occurred and the response with that behaviour was being served again and again as a cached 308 response.

Apologies for the false alarm, closing this issue !:ok_hand: