On 08/26/2016 05:02 AM, 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? We should ban it unequivocally. > > 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? Only a single toggle. > > 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)? Default should be strict. > > Real world direct observation especially appreciated from actual deployments. > > > Regards Rüdiger
