On Wed, Aug 3, 2016 at 7:33 PM, William A Rowe Jr <wr...@rowe-clan.net> 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 2.next/3.0? > 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.
