httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Champion <champio...@gmail.com>
Subject Re: Backporting HttpProtocolOptions survey
Date Fri, 26 Aug 2016 17:12:48 GMT
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


Mime
View raw message