Interesting.

1. sounds wrong to me because it would end up being an implementation just
like the existing AccessLogValve, but not one that the Tomcat administrator
configures?  Or, maybe each connector would/could own its own AccessLogValve
instance?  And, an admin can configure it like this if they wanted to
customize the default configuration?:

    <Connector port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443">
        <Valve className="org.apache.catalina.valves.AccessLogValve"
directory="logs"
                    prefix="localhost-8080_access_log." suffix=".txt"
pattern="common" resolveHosts="false"/>
    </Connector>

Right now the above config starts happily, though it doesn't log anything.

2. sounds better, but then you may have to try to parse more of the request
URI to figure out things such as if you know the host and context or not
(because those are things that AccessLogValve might try to log, depending on
the configuration of AccessLogValve).  I do think people would expect it to
log via any access loggers that are configured, potentially multiple.. and
that sounds like it would be unhelpful in a DDoS situation.  Still, if the
administrator configured it that way, then they want it logged.

Maybe in general the AccessLogValve should have a "but not in the case of a
DDoS" feature that is configurable but disabled by default.  Similar to how
the Linux kernel logs kernel messages to syslog, and sometimes it just says
"Last message repeated 3450 times."

--
Jason


On Wed, Apr 28, 2010 at 5:14 PM, Mark Thomas <ma...@apache.org> wrote:

> This was prompted by [1]. For a number of mal-formed requests, the
> CoyoteAdaptor will reject them before they reach the access log valve. There
> is currently no means of logging these rejected requests in Tomcat.
>
> There are obvious use cases for logging these requests in one form or
> another. As i see it the options are:
>
> 1. Add standard Tomcat logging for these requests to CoyoteAdaptor
> Pros: Quick & simple to implement
> Cons: Separate from access log
>
> 2. Provide hooks in access log valves to allow CoyoteAdaptor to log these
> rejections via the access log valve
> Pros: All access logs in one place
>      Could be used by other components
> Cons: More complex solution. CoyoteAdaptor would have to navigate container
> hierarchy to find access log. Probably need a new AccessLog interface to
> enable CoyoteAdaptor to work with multiple implementations.
>
> 3. Something else?
>
> I'm leaning towards 2. Thoughts?
>
> Mark
>
> [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=49099
>

Reply via email to