Opened 5 years ago
Last modified 15 months ago
#34353 reopened defect (bug)
redirect_canonical() – Undefined indexes 'host' and 'scheme'
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | normal | Version: | 4.3.1 |
Component: | Canonical | Keywords: | needs-patch needs-unit-tests |
Focuses: | Cc: |
Description
Hello,
We have a problem on our Blog (http://blog.mila.com). Since over half a year, we get these notifications on top of our wordpress blog:
Notice: Undefined index: HTTP_HOST in /opt/wordpress/wp-includes/canonical.php on line 66
Notice: Undefined index: HTTP_HOST in /opt/wordpress/wp-includes/nav-menu-template.php on line 558
The notifications come and go, so i don't know what the problem is..
This is line 66 in the canonical file:
<?php $requested_url .= $_SERVER['HTTP_HOST'];
And this is line 558 in nav-menu-template.php:
<?php $current_url = set_url_scheme( 'http://' . $_SERVER['HTTP_HOST'] . $_root_relative_current );
We know that the notification is shown because the variable HTTP_HOST is not set, but we don't know how to fix that. It would be great if you could help
Attachments (2)
Change History (23)
#1
@
5 years ago
- Milestone Awaiting Review deleted
- Resolution set to duplicate
- Status changed from new to closed
Duplicate of #32229. This is fixed in 4.4.
#3
@
5 years ago
- Resolution duplicate deleted
- Status changed from closed to reopened
I have inserted the lines from issue 32229 now i get this error:
Notice: Undefined index: host in /opt/wordpress/wp-includes/canonical.php on line 424 Notice: Undefined index: host in /opt/wordpress/wp-includes/canonical.php on line 425 Notice: Undefined index: host in /opt/wordpress/wp-includes/canonical.php on line 425 Notice: Undefined index: host in /opt/wordpress/wp-includes/canonical.php on line 426 Notice: Undefined index: host in /opt/wordpress/wp-includes/canonical.php on line 428 Notice: Undefined index: scheme in /opt/wordpress/wp-includes/canonical.php on line 445 Notice: Undefined index: host in /opt/wordpress/wp-includes/canonical.php on line 424 Notice: Undefined index: host in /opt/wordpress/wp-includes/canonical.php on line 425 Notice: Undefined index: host in /opt/wordpress/wp-includes/canonical.php on line 425 Notice: Undefined index: host in /opt/wordpress/wp-includes/canonical.php on line 426 Notice: Undefined index: host in /opt/wordpress/wp-includes/canonical.php on line 428 Notice: Undefined index: scheme in /opt/wordpress/wp-includes/canonical.php on line 445
#4
@
5 years ago
- Keywords needs-patch added
- Milestone set to Awaiting Review
- Summary changed from Notifications on top of the page for canonical.php and nav-menu-template.php to redirect_canonical() – Undefined indexes 'host' and 'scheme'
Looks like $redirect['scheme']
and $original['host']
are not correctly set. Those two arrays are returned by parse_url
, so it's certainly possible that those keys aren't set.
#5
@
4 years ago
I have same warnings and found that it was produced by "HEAD" requests. "GET" and "POST" requests doesn't give the warning.
This ticket was mentioned in Slack in #core by flixos90. View the logs.
4 years ago
#10
@
3 years ago
This bug is still littering the log files in v4.9.4, out of the box. Spent time tracking down the cause and was going to report it, now realizing this is a known issue.
In my case, problem is that several times daily, redirect_canonical() is called with $_SERVER[HOST
] empty and $_SERVER [URI
] = '/'.
As a result $original[host
] is never set and the code will eventually fail starting at lines 461 - 463:
<?php if ( strtolower($original['host']) == strtolower($redirect['host']) || ( strtolower($original['host']) != 'www.' . strtolower($redirect['host']) && 'www.' . strtolower($original['host']) != strtolower($redirect['host']) ) ) $redirect['host'] = $original['host'];
It should be trivial to fix at lines 70-73, currently:
<?php $original = @parse_url($requested_url); if ( false === $original ) { // <-- this line requires a fix! return; }
by simply validating that a 'host' was actually set, since the code does expect one later:
<?php if ( false === $original or !isset( $original['host'] ) ) {
#11
in reply to:
↑ 7
@
3 years ago
- Keywords has-patch added; needs-patch removed
I have confirmed that my proposed fix for 4.9.4 does address this problem. There was no recurrence in the past 4 days, and no ill effects!
Now that a confirmed fix is available, may I suggest moving it from some "future release" milestone to the next update, so that this may be closed after 2 years.
#13
@
3 years ago
While we're waiting for this fix, I'm also seeing a similar issue in wp-includes/class-wp-http-ixr-client.php
.
ErrorException: Undefined index: host #7 wp-includes/class-wp-http-ixr-client.php(27): handleError #6 wp-includes/class-wp-http-ixr-client.php(27): __construct #5 wp-includes/comment.php(2652): pingback #4 wp-includes/comment.php(2486): do_all_pings #3 wp-includes/class-wp-hook.php(286): apply_filters #2 wp-includes/class-wp-hook.php(310): do_action #1 wp-includes/plugin.php(515): do_action_ref_array #0 wp-cron.php(126): null
Same for
Undefined index: scheme
Examining the $bits
variable, I see this:
bits { path: /wordpress/xmlrpc.php }
The function this happens in:
<?php public function __construct($server, $path = false, $port = false, $timeout = 15) { if ( ! $path ) { // Assume we have been given a URL instead $bits = parse_url($server); $this->scheme = $bits['scheme']; $this->server = $bits['host']; $this->port = isset($bits['port']) ? $bits['port'] : $port; $this->path = !empty($bits['path']) ? $bits['path'] : '/';
All such errors are caused by wordpress/wp-cron.php?doing_wp_cron
.
Perhaps the fix here can also be applied to class-wp-http-ixr-client.php
?
Thank you.
#14
@
2 years ago
Not sure if this is completely related or just sounds very similar (involving path, not host or scheme) but I'll share it here as it may help in testing. I've encountered the following on a clean install of WP 4.9.8 with default theme and no plugins activated.
- Turn WP_DEBUG is on (obviously)
- Set permalinks to Numeric
- Visit a non-existent feed by it's plain URL, for example /?feed=sitemap
Notices shown:
PHP Notice: Undefined index: path in /var/www/html/wp-includes/canonical.php on line 393 PHP Notice: Undefined index: path in /var/www/html/wp-includes/canonical.php on line 393 PHP Notice: Undefined index: path in /var/www/html/wp-includes/canonical.php on line 465
You may ask: Why bother with non-existent feeds? Answer: Plugin developers (as I) may add custom feed URLs and will encounter this notice during development (like I did) ... and waste a lot of time trying to find out what is going on ;)
#17
@
2 years ago
- Keywords needs-patch needs-unit-tests added; has-patch removed
- Milestone changed from 5.1 to Future Release
This ticket needs a patch and tests.
#18
@
21 months ago
Unfortunately this is still an issue in WP 5.1.1 and currently littering our Sentry logs.
As of 5.1.1, line 504 of /wp/wp-includes/canonical.php is throwing the "Undefined index: host" error.
Corresponding code:
// Ignore differences in host capitalization, as this can lead to infinite redirects // Only redirect no-www <=> yes-www >>> if ( strtolower( $original['host'] ) == strtolower( $redirect['host'] ) || ( strtolower( $original['host'] ) != 'www.' . strtolower( $redirect['host'] ) && 'www.' . strtolower( $original['host'] ) != strtolower( $redirect['host'] ) ) ) { $redirect['host'] = $original['host']; }
#19
@
21 months ago
FYI, I am running Wordpress 5.2, PHP 7.2. I am seeing this error display just below the body tag.
Notice: Undefined index: path in /wp-includes/canonical.php on line 419
#20
@
18 months ago
The reason for these notices are probably the same as I've found for multisites. See #47733 (Undefined index HTTP_HOST in wp-includes/ms-settings.php)
If this is true a more general handling of the HTTP server variables may be needed during the bootstrap/load process.
#21
@
15 months ago
This notice happens because HTTP/1.0 doesn't fill the HTTP_HOST
index in $_SERVER
. HTTP/1.1 and higher do support that index. Alas, around the world, archaic browsers and servers are still using HTTP/1.0.
Because of that, $requested_url
isn't populated, and $original = @ parse_url( $requested_url );
won't have anything useful to parse, and won't fill in the host
index. Ergo, three notices will pop up when trying to call $original['host']
.
I think we can polyfill the $_SERVER['HTTP_HOST']
index early. Doing so would also address #47733. Be mindful of virtual hosts.
canonical.php file