follow_redirect: expose previous and next request methods by lucab · Pull Request #559 · tower-rs/tower-http

lucab · 2025-04-17T14:23:00Z

This augments follow-redirect Attempt in order to expose two relevant HTTP methods during redirects:

the method for the original/previous request
the method to be performed on the next request upon following a redirection

This allows consumers to write policies based on both previous and next requests methods.

lucab · 2025-04-17T14:23:25Z

For context:

This is a re-spin of client/redirect: expose previous and next request methods seanmonstar/reqwest#2430
The original usecase is described in HTTP method changed after redirect seanmonstar/reqwest#1777 (comment)

jlizen

Sorry for the slow review @lucab . Looks good! The lifetimes on the methods need fixing, and the rest are nits.

Might be nice to have a module example like, detecting cycles:

if attempt.previous_method() != attempt.method() { }

jlizen · 2026-05-04T22:48:48Z

    }

+    /// Returns the method for the next request, after applying redirection logic.
+    pub fn next_method(&self) -> &Method {


should return 'a lifetime

jlizen · 2026-05-04T22:48:52Z

    }

+    /// Returns the method for the previous request, before redirection.
+    pub fn previous_method(&self) -> &Method {


should return 'a lifetime

jlizen · 2026-05-04T22:50:00Z

    }

+    /// Returns the method for the next request, after applying redirection logic.
+    pub fn next_method(&self) -> &Method {


this should probably be method to match location

jlizen · 2026-05-04T22:58:05Z

@@ -33,7 +33,7 @@ impl<B, E> Policy<B, E> for SameOrigin {
 #[cfg(test)]


would be nice to throw in some simple assertions using these new accessors, if they fit into any existing tests

I've added a stops_post_redirect_get test to cover this.

lucab · 2026-05-05T07:49:07Z

@jlizen thanks for the review! I'll try to find some time in the next days to rebase and address your feedback, I'll ping you when this is ready for another pass.

Just one question on:

Might be nice to have a module example like, detecting cycles

There is already a cyclic-redirection example at https://docs.rs/tower-http/latest/tower_http/follow_redirect/policy/trait.Policy.html#example, maybe it would be better to tweak that to use a HashSet<(Uri, Method)>?

jlizen · 2026-05-05T15:06:48Z

I'll try to find some time in the next days to rebase and address your feedback

Sounds good! No rush.

cycle detection example

Yeah that sounds like a nice improvement, as long as we can capture cycles where it is flipping methods (which sounds like your HashSet idea would). Totally optional though. Just was thinking about an example that would realistically surface this new api's usage.

lucab · 2026-05-05T17:26:02Z

@jlizen updated, PTAL.

jlizen

Looks great! Couple more nits, then another one that's up to you.

jlizen · 2026-05-05T18:50:59Z

        self.status
    }

+    /// Returns the method for the next request, after applying redirection logic.


Suggested change

/// Returns the method for the next request, after applying redirection logic.

/// Returns the destination method of the redirection.

jlizen · 2026-05-05T18:51:54Z

        let mut res = ready!(this.future.as_mut().poll(cx)?);
        res.extensions_mut().insert(RequestUri(this.uri.clone()));

+        let previous_method = &this.method.clone();


Suggested change

let previous_method = &this.method.clone();

let previous_method = this.method.clone();

jlizen · 2026-05-05T18:52:09Z

            status: res.status(),
+            method: this.method,
            location: &location,
+            previous_method,


Suggested change

previous_method,

previous_method: &previous_method

jlizen · 2026-05-05T18:56:19Z

    }

+    #[tokio::test]
+    async fn stops_post_redirect_get() {


Optional: This is a good opportunity to flesh out our test coverage a bit, since we have new accessors. Up to you if you care to!

We could test:

307/308 POST preservation

303 POST -> GET

303 HEAD preservation

Probably is worth parameterizing a helper at that point.

That makes sense. I added a shared redirection handler and then dedicated tests to cover the following matrix:

301

POST -> GET

GET -> GET

302

POST -> GET

PUT -> PUT

HEAD -> HEAD

303

POST -> GET

PUT -> GET

HEAD -> HEAD

307/308

POST -> POST

This augments follow-redirect `Attempt` in order to expose two relevant HTTP methods during redirects: - the method for the original/previous request - the method to be performed on the next request upon following a redirection This allows consumers to write policies based on both previous and next requests methods.

jlizen

Looks good, thanks for the contribution!

This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [tower-http](https://github.com/tower-rs/tower-http) | workspace.dependencies | patch | `0.6.9` → `0.6.10` | --- ### Release Notes <details> <summary>tower-rs/tower-http (tower-http)</summary> ### [`v0.6.10`](https://github.com/tower-rs/tower-http/releases/tag/tower-http-0.6.10) [Compare Source](tower-rs/tower-http@tower-http-0.6.9...tower-http-0.6.10) #### Added - `follow-redirect`: expose `Attempt::method()` and `Attempt::previous_method()` so redirect policies can react to method changes across redirects (e.g. POST to GET on 301/303) ([#559]) #### Fixed - Restore `tokio` and `async-compression` as no-op features. These will be removed next breaking release ([#667]) [#559]: tower-rs/tower-http#559 [#667]: tower-rs/tower-http#667 #### What's Changed - fix: restore tokio and async-compression as no-op features by [@jlizen](https://github.com/jlizen) in [#667](tower-rs/tower-http#667) - fix gate-ing of atomic64 in tests by [@alexanderkjall](https://github.com/alexanderkjall) in [#607](tower-rs/tower-http#607) - follow\_redirect: expose previous and next request methods by [@lucab](https://github.com/lucab) in [#559](tower-rs/tower-http#559) - chore: release tower-http 0.6.10 by [@jlizen](https://github.com/jlizen) in [#669](tower-rs/tower-http#669) #### New Contributors - [@lucab](https://github.com/lucab) made their first contribution in [#559](tower-rs/tower-http#559) **Full Changelog**: <tower-rs/tower-http@tower-http-0.6.9...tower-http-0.6.10> </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).  Reviewed-on: https://git.erwanleboucher.dev/eleboucher/towonel/pulls/34

lucab marked this pull request as ready for review April 17, 2025 14:27

jlizen requested changes May 4, 2026

View reviewed changes

lucab force-pushed the ups/redirect-methods branch 3 times, most recently from e2189ad to 754d2a3 Compare May 5, 2026 16:39

jlizen requested changes May 5, 2026

View reviewed changes

This was referenced May 5, 2026

chore: release tower-http 0.6.9 #666

Merged

fix: restore tokio and async-compression as no-op features #667

Merged

lucab added 3 commits May 6, 2026 09:56

review-fix: tweak names, tests and docs

7868d6c

review-fix: minor tweaks and more tests

68fe5f0

lucab force-pushed the ups/redirect-methods branch from 754d2a3 to 68fe5f0 Compare May 6, 2026 09:45

lucab requested a review from jlizen May 6, 2026 13:21

jlizen approved these changes May 6, 2026

View reviewed changes

jlizen merged commit 8508cb2 into tower-rs:main May 6, 2026
12 checks passed

lucab deleted the ups/redirect-methods branch May 8, 2026 13:48

		@@ -33,7 +33,7 @@ impl<B, E> Policy<B, E> for SameOrigin {
		#[cfg(test)]

	/// Returns the method for the next request, after applying redirection logic.
	/// Returns the destination method of the redirection.

	let previous_method = &this.method.clone();
	let previous_method = this.method.clone();

Conversation

lucab commented Apr 17, 2025

Uh oh!

lucab commented Apr 17, 2025

Uh oh!

jlizen left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lucab commented May 5, 2026

Uh oh!

jlizen commented May 5, 2026

Uh oh!

lucab commented May 5, 2026

Uh oh!

jlizen left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jlizen left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants