On Wed, Aug 3, 2016 at 6:51 PM, Eric Covener <cove...@gmail.com> wrote:
> 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. That requires additional CPU, and significantly more code complexity. In fact, I wonder whether such 'logging-only' behavior shouldn't simply be a no-choice default? I also wonder if those tools or others such as mod_security won't already provide such an option and we can wash our hands of this 'extra effort'? > 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. > Well, is there any point of detailing the specific offending field names? The bad text received? To the consumer in the response error message, or strictly to the logs? We should log (once) the cause of a 400, but are the details interesting? Or is it enough to report that a bad field name, a bad header value etc caused the fault without any sprintf() style processing?
