On Fri, Aug 26, 2016 at 2:02 PM, Eric Covener <cove...@gmail.com> wrote: > 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
+1
