On Fri, Aug 26, 2016 at 7:10 AM, Ruediger Pluem <rpl...@apache.org> wrote: > > > 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. >
+1
