I think I am changing my mind, I am leaning towards 1.
There are cases where I think we can use the regular access log (where I
like solution 2).
But with solution 1. You can also log "oddness". Connections which
timeout, or never present a request, etc. So the format of the
CoyoteAdaptor lo
2010/4/29 Mark Thomas :
> 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.
Some requests are rejected by a connector, if it cannot
1.
We shouldn't dilute the access logs which is supposed to log valid HTTP
requests with blah.
Many companies run funky port scanners as part of their audit, these
would all end up in the access log if you used two.
The access log and its usage is pretty clear, and its not to log
incomplete HT
I like case 2.
In the case of the malformed request. We might not be able to determine
the host or the path (and therefore the appropriate webapp (or host))
In the common case (admin), I would hope that there is an AccessLog at
the EngineLevel. So we might be able to do the following ...
- C
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 th
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
