[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