[wp-trac] [WordPress Trac] #50422: Prevent Browser Caching From Getting Involved With wp_redirect and wp_safe_redirect (Leaving the Browser to Purely Honor the Redirect Code Used)

[WordPress Trac]

#50422: Prevent Browser Caching From Getting Involved With wp_redirect and
wp_safe_redirect (Leaving the Browser to Purely Honor the Redirect Code
Used)
-------------------------------------+------------------------------
 Reporter:  KZeni                    |       Owner:  (none)
     Type:  enhancement              |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  General                  |     Version:  5.4.2
 Severity:  normal                   |  Resolution:
 Keywords:  needs-testing has-patch  |     Focuses:
-------------------------------------+------------------------------

Comment (by KZeni):

 Replying to [comment:5 shoelaced]:
 > Is there a reason this fix hasn't been/can't be implemented? Developing
 a plugin and running into this issue. I'll use `nocache_headers()` but it
 seems like the redirect functions should simply incorporate that (and it
 would have saved me a lot of time).

 Good question. I did what I could in the time I had available, but it
 somehow never got the proper attention of WordPress maintainers in the 5+
 years since I reported it, gave a fix, gave updates, made sure it was
 properly represented in the GitHub issues as well, reached out again, etc.
 I'm surprised to hear this was just never addressed even from a different
 ticket, update, or anything (I had just made sure the plugins I use all
 implemented their own patch for this in the meantime.)

 It really appears to be such a simple & harmless streamlining of this
 function that only makes things more reliable (and in some potentially
 important ways like with different redirects that may need to vary on the
 user's current permissions or some other temporary condition where this
 not being fixed makes even 302 temporary redirects be saved to cache
 [while this fix should still allow 301 redirects to be permanent/"cached"
 when used accordingly and so on.])

 I guess they just kept relying on plugins to manually call the
 `nocache_headers();` function anytime a redirect might need to make
 WordPress' less-than-ideal handling of this actually more reliable &
 security conscious (and that's assuming the plugin developer even knows
 about this bug they need to avoid & isn't just leading to however many
 plugins having open bugs/issues from this unexpected behavior.)

 It really seems like the redirect status code one supplies when calling
 the redirect gives sufficient control over things that could assist with
 performance, if needed. Meanwhile, having WordPress potentially make
 something be saved & reused even though it was already told to be
 temporary doesn't seem like the correct way it should function. Though
 here I am going over potential concerns for a ticket/issue/patch awaiting
 review that just never got reviewed in these years for whatever reason.

 Better late than never if this gets traction, I suppose. I hope it
 actually does get addressed at some point since the way it is now just has
 some counterintuitive behavior that can/has/does lead to potentially
 severe bugs on a given site / web app (I still just don't get why it
 currently makes temporary redirects potentially not temporary unless given
 additional code [as if one needs to specify temporary more than once &
 also needs to know about this whole other `nocache_headers();` function to
 have it work as one would expect.])

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/50422#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform