[wp-trac] [WordPress Trac] #41712: canonical infinite redirect bug

[WordPress Trac]

#41712: canonical infinite redirect bug
--------------------------+------------------------------
 Reporter:  yprince       |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Canonical     |     Version:
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------

Comment (by sanchothefat):

 Hi, I've hit essentially the same problem while using Batcache for page
 caching.

 In situations where `redirect_canonical()` finds a `$redirect_url` (such
 as when you have a static page set for the home page) and you have a query
 string then the query string will be removed, processed and rebuilt.

 When the query string contains values that are not URL encoded, or have a
 trailing `=` such as `?foo=&bar=abc[xyz]` a redirect will occur to
 `?foo&bar=abc%5Bxyz%5D`.

 This is mostly benign as the end result for the application will be the
 same however the redirect is unnecessary. It becomes problematic in the
 case of Batcache because it generates cache keys based on the query
 parameters passed to it. Because it can cache redirects it does not
 differentiate between the 2 versions of the query string and will keep
 returning the cached redirect resulting in and endless loop.

 For a real world example of query strings being used outside of the
 applications' control marketing and adtech tools often append a bunch of
 query string parameters used for tracking and personalisation, for
 example: `example.org/?utm_campaign=aaa&hsa_content=&gclid=bbbb`.

 It would be great if `redirect_canonical()` could compare the query string
 before and after preprocessing to determine if the URL truly is different.

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