-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
David,
On 4/16/14, 12:42 PM, David Wall wrote:
> I am running Tomcat 7.0.47 and it occasionally returns HTTP status
> codes of 400, such as the following from my access log.
>
> A 400 suggests a malformed request, but many of these are simple
> GET requests on an image, so it seems odd they are malformed.
> We're not positive, but it seems that as these occur on JSP
> requests, we appear to be able to process a request though we get
> 'null' for various things like request.getRequestURI(),
> request.getScheme(), etc.
>
> I read something about these and perhaps character set encoding,
> and we do have code like this at the beginning of our page
> processing (though the cannot be directly tied as our JSP/servlets
> don't process images and javascript requests):
>
> try { if ( request.getCharacterEncoding() == null )
> request.setCharacterEncoding(CHARSET_UTF_8);
> response.setCharacterEncoding(CHARSET_UTF_8); } catch(
> UnsupportedEncodingException e ) { app.warning("PageBean.init() -
> Failed to set request/response to UTF-8 encoding."); }
>
>
> Here's our access log of some recent 400s:
>
> 199.231.xx.xxx - - [16/Apr/2014:12:16:31 -0400] "GET
> /XXX/esfapp/images/esignFormsPlain.gif HTTP/1.1" 400 - 0
> Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64;
> Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET
> CLR 3.0.30729; Media Center PC 6.0; MS-RTC LM 8; .NET4.0C;
> .NET4.0E) 199.231.xx.xxx - - [16/Apr/2014:12:16:33 -0400] "GET
> /XXX/esfapp/scripts/sorttable.js HTTP/1.1" 400 - 0 Mozilla/4.0
> (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2;
> .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media
> Center PC 6.0; MS-RTC LM 8; .NET4.0C; .NET4.0E) 199.231.xx.xxx - -
> [16/Apr/2014:12:16:33 -0400] "GET /XXX/esfapp/scripts/sorttable.js
> HTTP/1.1" 400 - 4 - 199.231.xx.xxx - - [16/Apr/2014:12:16:33 -0400]
> "GET /XXX/esfapp/images/calendar20x14.gif HTTP/1.1" 400 - 0
> Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64;
> Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET
> CLR 3.0.30729; Media Center PC 6.0; MS-RTC LM 8; .NET4.0C;
> .NET4.0E)
>
> 160.109.NN.NN - - [16/Apr/2014:12:17:18 -0400] "GET
> /NNNN/images/logoR.gif HTTP/1.1" 400 - 2 Mozilla/4.0 (compatible;
> MSIE 8.0; Windows NT 5.1; Trident/4.0; InfoPath.2; .NET CLR
> 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR
> 3.5.30729; .NET4.0C) 160.109.NN.NN - - [16/Apr/2014:12:17:18 -0400]
> "GET /NNNN/images/logoR.gif HTTP/1.1" 400 - 0 Mozilla/4.0
> (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; InfoPath.2;
> .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET
> CLR 3.5.30729; .NET4.0C)
>
> 71.220.ZZZ.ZZZ - - [16/Apr/2014:12:28:44 -0400] "GET
> /ZZ/leaserenewal/js/form-functions.js HTTP/1.1" 400 - 0
> Mozilla/5.0 (Windows NT 5.1; rv:28.0) Gecko/20100101 Firefox/28.0
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTTwGUAAoJEBzwKT+lPKRYNG8P/RqIbJ0BpHZXhaCQT/hwUbpG
u4R6rlCf3LVmKYBiTNLGzr93gWw985iHCE+i6XDw+xUZlHIKeXHCNdtu0TCaOZ4P
s4qH1cOU8JDea9z/7OmM8lI1+DWxT1lsIrBLuDrg5lUTWHvV5LGNVWTQ3664q4kR
ewiM5+ayLdfOezyo/LDkLNPG9V5Xluzbnm5BGIFco7Djzq9ygmGlggCzRsryM1iM
tOBuO3a4cvYH3wNwtCANVjqYCKg0Af9+1g/teCBc7Wq3ulVOsMr1kvqGzD4eMtYo
DD5LO8RYOTwzTuKaGORJRX/JeIGm4iurCNbDW3VqPK56nxNwIlpBCyNH0xiOqhvF
JQmRjpigLEPv/UCdkDji++jgiqxJeFn+/HO4aZPtqT/KtSAqqwI6QsLjewdxdq9E
z1ddm0p+ee+XI8vpQHgHP+pJaGEaBLrzck0WrT/rCnOzMmozYmlEJL4Saq6v65Km
5h3NCPOg4v3SsL3Gu1nGLwpOU0fjKoysdVyl/ceEAA6LXZVaS0A5ylRZpG1zHtgq
LVMU3BVQZKecQidPrM7XtRF+WPe6twciVyJ/H+LouSaUyRTvvFTrbotLE4QjfZYv
8lX5lkgoSkN0lxzDkanZIGa4dGgxkGR6QyA/lirSaSxMvHSuuy8XWh/LA/mdJdj7
5zdb2kJ0T+QlGh5uiAm0
=zgV9
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
