httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Covener <>
Subject Re: HTTP/1.1 strict ruleset
Date Wed, 03 Aug 2016 23:51:40 GMT
On Wed, Aug 3, 2016 at 7:33 PM, William A Rowe Jr <> wrote:
> So it seems pretty absurd we are coming back to this over
> three years later, but is there any reason to preserve pre-RFC 2068
> behaviors? I appreciate that Stefan was trying to avoid harming
> existing deployment scenarios, but even as I'm about to propose
> that we backport all of this to 2.4 and 2.2, I have several questions;
> 1. offer a logging-only option? Why? It seems like a simple
>    choice, follow the spec, or don't. If you want to see what's
>    going on, Wireshark, Fiddler and dozens of other tools let
>    you inspect the conversation.

I see a lot of value in logging when not applying the strict parsing,
so you can passively assess your traffic for a day/week/month.

> 2. leave the default as 'not-strict'? Seems we should most
>    strongly recommend that the server observe RFC's 2068,
>    2616 and 723x, and not tolerate ancient behavior by default
>    unless the admin insists on being foolish.

I am with you on default-to-strict in 2.4 and up.  I'm hesitant about 2.2.

> 3. retain these legacy faulty behaviors in httpd
>    Seems that once we agree on a backport, the ancient
>    side of this logic should all just disappear from trunk.

I don't see a good reason to keep the behavior in current trunk, but
preserving the merge-ability sounds worthwhile.

> 4. detail the error to the error log? Again, there are inspection
>    tools, but more importantly, no visual user-agent is going
>    to send this garbage, and automated requests are going
>    to discard the 400 response. Seems we can save a lot of
>    code throwing away the details that just don't help, and
>    are generally the product of abusive traffic.

I don't have a good understanding of the savings or where the line
would be drawn on depth, but i think it's important to log (or stash
where it can be logged) a high level reason that the core/http_filters
ditched a request based on syntax.

View raw message