On 08/25/2016 08:02 PM, William A Rowe Jr wrote:
A couple key questions now that the full refactoring of legacy vs.
strict is mostly complete (there remain potential issues with some of
the 3-4 yr old changes on trunk which I'll raise in other posts.) But
speaking only to the request line and request header parsing...
1. Does it make sense to emit these parsing failures at the info level?
Or debug level (or in trunk/2.4, only at the trace level?) Granted some
legitimate internal diagnostics may be required, so it needs to have
some potential visibility, but the vast majority of such traffic is
abusive and doesn't need a place in most error logs.
Debug.
2. Should we ban \r\n\v\f unequivocally from request and request header
fields altogether, or is there a legitimate need to support these? Or
should these follow the UnsafeWhitespace toggle and be permitted?
No opinion.
3. Do we need multiple layers of 'Strict'ness, or should there be a
single toggle, or no toggle, no tolerant input at all in the next
2.2/2.4 releases?
Multiple, at the very least to separate discouraged-but-conformant
behavior from nonconformant behavior. (I know having multiple options is
messy, and having too many knobs is already a problem. But I think that
exposing only one, loosely defined, "allow a bunch of stuff" setting
will just mean it becomes the next cargo-cult directive in everyone's
configurations.)
4. Should the next 2.4/2.2 releases default to Strict at all? Or remain
permissive (Unsafe) and allow the user to toggle these to Strict(...
Whitespace... URI)?
Strict by default.
--Jacob
