On 4/16/2014 3:17 PM, Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
The access log of course does not give the whole story. It's possible
that the client sent for example a badly-formed HTTP header value. In
those cases, the request-line (shown in the access log) can be read
and the target context determined, but the headers can fail.
Can you narrow-down the types of requests that cause this to occur at
all? If so, you could enable a request dumper and set it to match
those requests (I think you have to write a Valve to sniff the request
and place an attribute in the request in order to trigger the request
dumper to dump the request). I wouldn't recommend using the
request-dumper on all requests: it would slow everything to a crawl
and likely represent a privacy problem as well).
- -chris
Chris,
Thanks for the reply. We're not sure about the status 400s -- like
today, we show 349 of them, but yesterday it was 157, and on Monday
122. The prior Wednesday, there were 0.
Some appear to be hack attempts or the like with requests like this:
62.210.114.138 - - [10/Apr/2014:04:02:28 -0400] "GET
/w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 - 0 -
62.210.114.138 - - [10/Apr/2014:04:02:28 -0400] "GET
/w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 - 0 -
But most seem to be a combination of images and JSPs that are on our
system. Even the user agent strings appear to be highly varied and
requests come throughout the day.
I've never done a request dumper before, but is there a way to trigger
it only if Tomcat is going to issue a 400?
We run the same sort of software on other servers that seem to have
these only rarely, and the access logs make them appear like they are
hacker/sniffers perhaps:
107.152.128.226 - - [31/Dec/1969:16:00:00 -0800] "-" 400 - 0 -
107.152.128.226 - - [31/Dec/1969:16:00:00 -0800] "-" 400 - 0 -
188.95.234.6 - - [16/Apr/2014:04:59:58 -0700] "HEAD / HTTP/1.1" 400 - 0 -
But the ones originally mentioned seem to be more likely coming from
regular users. What is odd is we've never had any reports of users
complaining, but you'd think those 400s would cause someone to grumble.
Because they appear to have valid URLs in the access logs, often
containing the unique 20 random characters that are used by our
application to identify a specific resource, it seems unlikely they are
also hacker types. The links otherwise work if we enter them into our
browser and they should be impossible for others to guess.
David
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
