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!
(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.
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.