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. 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? 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? 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)? Real world direct observation especially appreciated from actual deployments.
