[wp-trac] [WordPress Trac] #33821: redirect_canonical does not consider port in $compare_original

WordPress Trac noreply at wordpress.org
Mon Jun 16 22:39:15 UTC 2025


#33821: redirect_canonical does not consider port in $compare_original
-------------------------------------------------+-------------------------
 Reporter:  willshouse                           |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  Canonical                            |     Version:  2.3
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-unit-tests changes-  |     Focuses:
  requested                                      |
-------------------------------------------------+-------------------------

Comment (by SirLouen):

 Replying to [comment:37 wojtekn]:
 > What do you think?

 I find that this is still problematic

 I've been playing around a bit with all this. [https://theboroer.github.io
 /localtunnel-www/ I've found this service], very simple to configure,
 similar to ngrok with the peculiarity, that they provide a domain without
 HSTS, which means, that I can access directly to the HTTP version, without
 redirect.

 Exactly as I was expecting
 {{{
 > curl -I http://localhost:8889
 HTTP/1.1 301 Moved Permanently
 Server: nginx/1.27.5
 Date: Mon, 16 Jun 2025 22:29:41 GMT
 Content-Type: text/html; charset=UTF-8
 Connection: keep-alive
 X-Powered-By: PHP/8.2.28
 X-Redirect-By: WordPress
 Location: http://localhost/
 }}}

 The redirection is there, but it works perfectly without the patch. It
 seems that the problem is exclusively in the scheme not in the host. I
 have not really inspected what its going under the hood.

 > Yes, I'm testing with clean wordpress-develop.

 I was asking, because your ports look rare to me, wondering why you are
 not using standard 8889 for `wordpres-develop`?

 Now lets move back into Ngrok.

 If I run `ngrok http 8889`

 And I define:

 {{{
 define( 'WP_SITEURL', 'http://2eaa-80-102-99-22.ngrok-free.app' );
 define( 'WP_HOME', 'http://2eaa-80-102-99-22.ngrok-free.app' );
 }}}

 It goes well (although pretty useless because all assets are being served
 over http, while the HSTS upgrade to HTTPS render them unusable). As I
 said ideall, testing with the other service without HSTS it makes a lot of
 sense because it avoids the HTTPS upgrade, hence, everything looks as it
 should (no downgraded assets)

 But on the bright side I can say that technicall it works well (without
 styles or anything like that)

 Now the problem comes when I define

 {{{
 define( 'WP_SITEURL', 'https://a7d6-80-102-99-22.ngrok-free.app' );
 define( 'WP_HOME', 'https://a7d6-80-102-99-22.ngrok-free.app' );
 }}}

 In this scenario, if I move into `https://a7d6-80-102-99-22.ngrok-free.app
 /wp-admin/`, [https://i.imgur.com/Ho3gU5y.png it creates a full 302 loop]

 The interesting thing is that with your patch, all these reproduction
 steps are completely identical.

 Nothing changes for me. Basically, what I can say is that all those
 changes in `canonical.php` are not doing a thing regarding this topic (yes
 in CURL i can see the changes but not in the Firefox/Chrome incognito
 mode). You could argue that its a problem of cache, but as I say, I'm
 using incognito mode for everything.

 I can't really see a change.

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


More information about the wp-trac mailing list