Bug 60783

Summary: HttpProtocolOptions Directive' option Unsafe does not allow legacy request formats
Product: Apache httpd-2 Reporter: reichl.pavel
Component: CoreAssignee: Apache HTTPD Bugs Mailing List <bugs>
Status: RESOLVED INVALID    
Severity: normal CC: michal.babacek
Priority: P2    
Version: 2.4.25   
Target Milestone: ---   
Hardware: PC   
OS: Linux   

Description reichl.pavel 2017-02-28 12:04:54 UTC
Hello,

In 2.4.23 among others it was legal to use tabs as separator in request line, or to have SP or TAB between header name and colon. Neither of these works in 2.4.25 even with HttpProtocolOptions set to Unsafe.

Docs say:
...
Due to legacy modules, applications or custom user-agents which must be 
deprecated the Unsafe option has been added to revert to the legacy behaviors.

So it would seem that we should get fully legacy behavior with this directive, or should not we?

Thanks!
Comment 1 Eric Covener 2017-02-28 12:08:19 UTC
(In reply to reichl.pavel from comment #0)
> Hello,
> 
> In 2.4.23 among others it was legal to use tabs as separator in request
> line, or to have SP or TAB between header name and colon. Neither of these
> works in 2.4.25 even with HttpProtocolOptions set to Unsafe.
> 
> Docs say:
> ...
> Due to legacy modules, applications or custom user-agents which must be 
> deprecated the Unsafe option has been added to revert to the legacy
> behaviors.
> 
> So it would seem that we should get fully legacy behavior with this
> directive, or should not we?
> 

No. It looks like the docs may have been reworded, but the design is not to preserve all of the legacy parsing even under unsafe.
Comment 2 William A. Rowe Jr. 2017-09-13 14:25:26 UTC
See 3.2.4 paragraph 2 of http://www.rfc-base.org/txt/rfc-7230.txt - we have no choice but to reject whitespace in the header prior to the ':' delimiter, irrespective of configuration.

W.R.T. tabs in the request line, I proposed such a tweak and was overruled by the development team; the spec has always called for SP and only single SP characters since day one of HTTP, so there's no particular reason for an HTTP server to recognize anything else.

The reason for strictly returning 400 responses, is to ensure we do not propagate a bad request to an unsuspecting back-end origin server, or fulfill the request of a too-trusting-but-faulty proxy client.