RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1500031 - HTTPD - 400 BAD REQUEST - RFC 2616 HOSTNAME HEADER
Summary: HTTPD - 400 BAD REQUEST - RFC 2616 HOSTNAME HEADER
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: httpd
Version: 6.9
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Luboš Uhliarik
QA Contact: BaseOS QE - Apps
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-10-09 17:20 UTC by Tiago Domingues
Modified: 2017-10-10 15:50 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-10-10 13:33:39 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Tiago Domingues 2017-10-09 17:20:45 UTC 
Description of problem:
new vesion of httpd demands hostname header giving the following error:
"[error] [client xxx.xxx.xxx.xxx] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23):" 

Version-Release number of selected component (if applicable):
httpd-2.2.15-60.el6

How reproducible:
Update from httpd-2.2.15-59.el6 to httpd-2.2.15-60.el6

Steps to Reproduce:
1. yum update httpd
2. send requests to httpd as:

"GET /monitoring/health.svc HTTP/1.1" = 400 BAD REQUEST

Actual results:
"[error] [client xxx.xxx.xxx.xxx] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23):" 

Expected results:
No error

Additional info:
By just downgrading / rollback to httpd-2.2.15-59.el6 solve the issue!
Comment 2 Tiago Domingues 2017-10-09 18:44:57 UTC 
Additional Info on Version: httpd-2.2.15-60.el6.centos.5.x86_64 (August 2017)
Comment 3 Luboš Uhliarik 2017-10-10 09:39:42 UTC 
Dear Tiago,

From RFC2616 section 14.23:

   A client MUST include a Host header field in all HTTP/1.1 request
   messages . If the requested URI does not include an Internet host
   name for the service being requested, then the Host header field MUST
   be given with an empty value. An HTTP/1.1 proxy MUST ensure that any
   request message it forwards does contain an appropriate Host header
   field that identifies the service being requested by the proxy. All
   Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request)
   status code to any HTTP/1.1 request message which lacks a Host header
   field.

I also tried to reproduce your issue with httpd-2.2.15-59.el6 and the behavior is exactly same. 

# rpm -qa httpd
httpd-2.2.15-59.el6.x86_64
# /etc/init.d/httpd start
Starting httpd:                                            [  OK  ]
[root@qeos-175 ~]# telnet localhost 80
Trying ::1...
Connected to localhost.
Escape character is '^]'.
GET / HTTP/1.1

HTTP/1.1 400 Bad Request
Date: Tue, 10 Oct 2017 09:19:12 GMT
Server: Apache/2.2.15 (Red Hat)
Content-Length: 325
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
</p>
<hr>
</body></html>
Connection closed by foreign host.

# tail -n 1 /var/log/httpd/error_log 
[Tue Oct 10 05:19:12 2017] [error] [client ::1] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /

Release .60 is fixing CVE-2016-8743, you can try to set httpd directive HttpProtocolOptions to Unsafe:

HttpProtocolOptions Unsafe

Please see https://httpd.apache.org/docs/2.4/mod/core.html#httpprotocoloptions
Comment 4 Tiago Domingues 2017-10-10 12:47:15 UTC 
Hi Lubos,

Thanks for your quick reply, we do have an F5 in front of our HTTPD servers and version 2.2.15.60 is breaking our monitoring calls something that does not happen with version 2.2.15.59 and probably related to the fix CVE-2016-8743 as you just mentioned.

We probably need to change our calls (send string + required host header) or create a specific VH while using the unsafe approach.

Thanks for your time & support
Tiago
Comment 5 Tiago Domingues 2017-10-10 13:05:47 UTC 
Just as an addition info from F5:

“Note: HTTP/1.1 requires the Host header to be present in the request but does not require the header to contain a value. If you do not have a specific host name on your server, a value of Host: <space> suffices in most cases. A null value is valid unless the HTTP server requires them for virtual hosting.”

This is the full call:

GET /monitoring/health.svc HTTP/1.1\r\nHost: \r\nConnection: Close\r\n\r\n

It seems .60 fix just strict it.

Thanks again
Tiago
Comment 6 Luboš Uhliarik 2017-10-10 13:33:39 UTC 
Hi Tiago,

yes, CVE-2016-8743 changed the way, how whitespace charactes are parsed. You can either use HttpProtocolOptions Unsafe or set Host header to some value.

Since this is not a bug, but feature, I'm closing this bug.
Comment 7 Tiago Domingues 2017-10-10 15:50:37 UTC 
Thanks Lubos for the info.
Note You need to log in before you can comment on or make changes to this bug.