Bug 1420104

Summary: request contains solely FL on the end of the lines triggers bad request
Product: Red Hat Enterprise Linux 6 Reporter: Jan Houska <jhouska>
Component: httpdAssignee: Luboš Uhliarik <luhliari>
Status: CLOSED NOTABUG QA Contact: BaseOS QE - Apps <qe-baseos-apps>
Severity: high Docs Contact:
Priority: high    
Version: 6.9CC: jhouska, jorton, luhliari
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-02-07 20:39:05 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jan Houska 2017-02-07 20:22:51 UTC
Description of problem:
Previous httpd version accepted requests with only FL on the end of the lines, not mentioned in specification. The current version is now following the specification too tight. The response is now Bad Request, unlike accepted. 


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


How reproducible:
always

Steps to Reproduce:
1. create request containing "\n" not "\r\n" as end line mark. 
2. send the request to the httpd


Actual results:
Server is responding:
HTTP/1.1 400 Bad Request



Expected results:
Connection passing. Server response is sane...

Additional info:
Mentioned behaviour is a regression in behaviour. We assume that keeping the specification too tight now will generate too much problems to the customers.

Comment 1 Joe Orton 2017-02-07 20:39:05 UTC
Being relaxed in what is accepted here is a vulnerability, CVE-2016-8743, and hence that is being changed by default.

The option:

   HttpProtocolOptions unsafe 

has been added, which can be used to restore the old behaviour.

http://httpd.apache.org/docs/2.4/mod/core.html#httpprotocoloptions

Comment 2 Jan Houska 2019-02-15 15:55:38 UTC
Explanation is sufficient.