httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Covener <cove...@gmail.com>
Subject Re: Backporting HttpProtocolOptions survey
Date Fri, 26 Aug 2016 12:02:05 GMT
On Fri, Aug 26, 2016 at 7:10 AM, Ruediger Pluem <rpluem@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

Mime
View raw message