Opened 7 years ago
Closed 17 months ago
#47733 closed defect (bug) (fixed)
Undefined index HTTP_HOST in wp-includes/ms-settings.php on line 57
| Reported by: | JochenT | Owned by: | SergeyBiryukov |
|---|---|---|---|
| Priority: | normal | Milestone: | 6.9 |
| Component: | Bootstrap/Load | Version: | 5.2.2 |
| Severity: | minor | Keywords: | has-patch dev-feedback |
| Cc: | Focuses: | multisite |
Description
We get requests on our server of the form
175.143.12.??? - - [30/Jun/2019:10:22:45 +0200] "GET / HTTP/1.0" 500 73873 "-" "-" (dinse.eu)
This request uses HTTP/1.0 and results in a status code 500. The related entry in the PHP error log is
[30-Jun-2019 08:22:45 UTC] PHP Notice: Undefined index: HTTP_HOST in /usr/www/xxxx/wp-includes/ms-settings.php on line 57
- In ms-settings.php on line 57 it is not checked if
$_SERVER['HTTP_HOST']
is set. - Also I've found that in the case of this specific request
$_SERVER['SERVER_NAME']
is defined and not empty and can be used as a replacement.
My suggestion is to first check if
$_SERVER['HTTP_HOST']
is set else check if
$_SERVER['SERVER_NAME']
is set and if both are not set to implement a graceful error handling.
This may be related to #34353.
WP 5.2.2
PHP 5.6.40
Server: Apache/2.4.25 (Debian)
WP_DEBUG = true
Attachments (1)
Change History (14)
This ticket was mentioned in PR #195 on WordPress/wordpress-develop by Mte90.
7 years ago
#2
Trac ticket: https://core.trac.wordpress.org/ticket/47733
A simple patch just to test also the new GitHub environment for contribution :-)
#5
@
6 years ago
- Milestone 5.6 → Future Release
Feels a bit late to try this for 5.6 since we're into beta 3 and I worry about unforeseen side effects.
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)
Further info:
Apache sets HTTP_HOST to the correspondending value in the header of a HTTP request. As mentioned in the doc for the UseCanonicalName Directive ancient clients may do not provide a 'Host:...' header.
In such cases SERVER_NAME may be used to construct self-referential URLs. The question is if it still makes sense to support these ancient clients.
Nevertheless, in case HTTP_HOST is missing a convenient error handling should be added.