Re: http status 400 question
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? Sorry for replying to my own posting, but for JSP urls, we do seem to know that request.getScheme() for example returns null when things are bad, though I'm not sure how a bad request even makes it to my JSP if it's truly malformed. Could I use that somehow so do the request dumper aspect? I need a few pointers for doing it, but it sounds like I need to install some code that would check for the scheme being null and then do something else to cause the request to dump. Is that right? Is that a possible approach I should take? The issue is this is a customer system so we cannot make changes but in the evenings when they are not using it and then it probably will have to run all day before it can be removed later. Thanks for any tips! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: http status 400 question
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
Re: JNDI initialization since Tomcat 8.0.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 David, On 4/16/14, 10:44 AM, David Landis wrote: > On Sun, Apr 13, 2014 at 4:02 PM, Konstantin Kolinko > wrote: >> >> >> By the way, there exists an Apache project implementing the JPA >> specification, http://openjpa.apache.org/ > > > It does not really work with Tomcat though does it? See this > issue: https://issues.apache.org/jira/browse/OPENJPA-1590 > > or others. Also the build-time enhancement is a mess people > shouldn't have to deal with. I was disappointed by this myself, not > to mention that nobody seems to update the openjpa website anymore > nor do they support jpa 2.1. Stalled project. You'd better not tell the TomEE project that OpenJPA doesn't work with Tomcat. They might have to stop claiming they are doing it. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTTwMZAAoJEBzwKT+lPKRYMmQQAJLG2tVwJQ5lvHF94cdt5mh/ z2x+LaQ/SlOlF4stw8BEpxo5z/rbKDIigUfvaJST5d/Z7llPdWRfMo5C1lJjJvcg LvFHj4ivyrwBYLxhHRjj2/0HpR+HElSDBC0LmfqbJAeViR8LgtKPYcVrxv0CyWyH unO7+6RR8sx+MSxlNruGdkZQzryDIrrsohswZCzTY5LlM7smtcRKBZqcZKa2OoVz EFwp3AUlWw2VA8Lu9wEnkph9TFlp8zRy9O2I8MUCq6caE7tEhNBIe1VatO6pYLpI VlPNVchTbgz6LisfSTLPE3nLE69dHi5ejG6Je6tqsXX0I2kcgvAVNEIHXlhGUolK ea/RV/6mipIbhXZDudDsKdNW8HFW+x916oCxJvPwaQcx2v2wuHiuEizCarWg+ZVR aCOTP3klP+BocfaHVrpe4JvfTb3uMXD4vgbD3Hbs3k/PtI9bmJ1Bj86/JDMqI+XY 8Kz+P+ItPkEPldr9/jSDCot4JlDhOWLoaCAsuQF3UN5+ZLbtXFjYkWt1y5ugqUiM bfoBJubrHapIYd5c66jo1jf9dylI8+BlvwU5mXGSPSoqnrpVj9nn956NlJ7E5a0H MzBULsMy1tbFF+NBPKFzpG9OicHbMKvL3EKQLj+d0F+DBmwwcXYsjYJJ+j87LdGL 1PM2wDFrorUnFJs2F+Xy =vTHo -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: http status 400 question
-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
> //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 //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
Re: Patching Tomcat for Heartbleed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Greg, On 4/16/14, 2:28 PM, Cormier, Greg wrote: >> -Original Message- From: Konstantin Kolinko >> [mailto:knst.koli...@gmail.com] Sent: April-16-14 2:12 PM To: >> Tomcat Users List Subject: Re: Patching Tomcat for Heartbleed >> >> 2014-04-16 21:44 GMT+04:00 Cormier, Greg >> : >>> I have a Tomcat 7.0.30 server I'm trying to patch to resolve >>> the heartbleed >> exploit. >>> >>> I shut down the server and overwrite tcnative-1.dll with the >>> recently >> released version. >>> >>> When I restart tomcat, I get errors about the Java Key Store. >>> >>> Apr 16, 2014 9:36:07 AM >>> org.apache.catalina.core.AprLifecycleListener init INFO: The >>> APR based Apache Tomcat Native library which allows optimal >> performance in production environments was not found on the >> java.library.path: D:\Tomcat >> 7.0\bin;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;C:\Wi >> >> ndows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\S >> ystem32\WindowsPowerShell\v1.0\;C:\OpenSSL-Win32\bin;;. >> >> The above means that tcnative-1.dll was not found in the >> directories listed above. >> >> I would guess that you used a wrong DLL. It must match the CPU >> architecture of JRE/JDK that you are using. >> >> Is tcnative-1.dll file readable? > > Hmm, I think this might be the case - I may have snagged the 32 bit > version instead of 64 bit! I will try this after business hours so > I can take Tomcat offline and let you know! If you bounced Tomcat and got the above error, then your connector is dead anyway. Unless you rolled-back to the prior configuration, you are already down. If you are pretty sure you are not down even with the above errors, then perhaps you don't need that connector at all. Is Tomcat terminating SSL for you? No web server or SSL-terminating load-balancer in front of Tomcat? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTTwBPAAoJEBzwKT+lPKRYBDgP/1yTjd/FIq4QHp2Ozvif+PP7 JW2knwVsk7A/63AmmZqzGPMoZrq7XrGTuhoinfTNCzQn6nlPNi8w/Fw+/btdPisp LHDcgVThsYJJLhmPq8T3IiH9A9QY9hAugVs4OlGuetHtoZf5J5W7P1qMmrj8/3Cc ejgKr4/a5/qzIVTsXfY5aNzjQicxC1yJgUwP0kuPojh4yc8ZQ6JO0jEmFCycfrmy 7fHwKosUoWOs4O5+wkzNMnhiEY5hGHDUujY5oQTY9RFdjbGJDzEfxGs2EEiH6S4v A1pV/Srn/aNdT9PKkP5tH8ZgCJr4W4XRqr60UEe5Q27Ghii5ZzYYHWZ99FZF1TmE slzL5ZQXEs7wjXt5nwxWOa0zuiP7oTGD02qHiyN76oVcq039x4NXc0JtiZbLJFlG eR2HstrpRs3eFRXieuPfiFPEdbvn6uzgJi2A4mm+s1XOzyb5x8MGwNaUy3RnANem OAf9h3BOVEV2wUfHmPhY896uia/cwpVuX0NAOehkJWqQF1UJ7wCeE0bRUjK+B62d Qm1/j8vgcqNDjRatAFXig+/kLuHsRj+SA1PjoGLdU7UZ03qt075EIGxC/2YjbyKI 0AxJznTMRh0aPAAkyrkdsJIRZdNDWReOFmDAtp3fnsXvSZNjmr54pHK1SQFPvDzP vwBJAPdIIeeb+G1MPz5+ =Dwd1 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Configuration question
On Apr 16, 2014, at 1:42 PM, Mark Murphy wrote: > How do I prevent Tomcat 6 from responding to a request to an IP address, > that is I only want my Tomcat server to respond to requests to > www.mydomain.com vs. 10.1.1.1. Just an idea, but you could probably do this with a filter or a valve. You could try looking at request.getServerName() (or just the host header) and using that to approve or deny the request. Tomcat has a valve that you can sub class to make this easier (if you go with a valve). http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/valves/RequestFilterValve.java?view=markup an example of this is the RemoteHostValve. http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/valves/RemoteHostValve.java?view=markup > > Is this possible? > > The problem is that our web security scanner is reporting "Web Server Uses > Basic Authentication Without HTTPS”, Is basic auth enabled (look through your application’s web.xml files for "auth-method” set to “BASIC”)? If so, is disabling it an option? If not, you should look at setting a "transport-guarantee” of “CONFIDENTIAL” in web.xml so that the application will redirect to HTTPS (or worst case use a filter like the UrlRewriteFilter to force HTTPS). > and the infrastructure guys think it is because Tomcat allows connection to > the IP address. I not sure how this is expected to help. I suppose if the scanner was sending requests using the IP address and not the host, you could filter and block those requests. That might trick the scanner into thinking the server is not accepting basic authentication. I’m not sure how it would address the issue mentioned by the scanner though (assuming the scanner is not at fault here). Dan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Patching Tomcat for Heartbleed
> -Original Message- > From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] > Sent: April-16-14 2:12 PM > To: Tomcat Users List > Subject: Re: Patching Tomcat for Heartbleed > > 2014-04-16 21:44 GMT+04:00 Cormier, Greg : > > I have a Tomcat 7.0.30 server I'm trying to patch to resolve the heartbleed > exploit. > > > > I shut down the server and overwrite tcnative-1.dll with the recently > released version. > > > > When I restart tomcat, I get errors about the Java Key Store. > > > > Apr 16, 2014 9:36:07 AM org.apache.catalina.core.AprLifecycleListener init > > INFO: The APR based Apache Tomcat Native library which allows optimal > performance in production environments was not found on the > java.library.path: D:\Tomcat > 7.0\bin;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;C:\Wi > ndows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\S > ystem32\WindowsPowerShell\v1.0\;C:\OpenSSL-Win32\bin;;. > > The above means that tcnative-1.dll was not found in the directories > listed above. > > I would guess that you used a wrong DLL. > It must match the CPU architecture of JRE/JDK that you are using. > > Is tcnative-1.dll file readable? Hmm, I think this might be the case - I may have snagged the 32 bit version instead of 64 bit! I will try this after business hours so I can take Tomcat offline and let you know! > > > > Apr 16, 2014 9:36:11 AM org.apache.coyote.AbstractProtocol init > > INFO: Initializing ProtocolHandler ["http-bio-443"] > > > > Apr 16, 2014 9:36:12 AM org.apache.tomcat.util.net.jsse.JSSESocketFactory > getStore > > SEVERE: Failed to load keystore type JKS with path C:\/.keystore due to > C:\.keystore (The system cannot find the file specified) > > java.io.FileNotFoundException: C:\.keystore (The system cannot find the > file specified) > > at java.io.FileInputStream.open(Native Method) > > at java.io.FileInputStream.(Unknown Source) > > at > org.apache.tomcat.util.net.jsse.JSSESocketFactory.getStore(JSSESocketFacto > ry.java:400) > > ... > > > > > > I don't understand why I'm getting these, as I'm 99% sure I'm using APR and > not JSSE. > > > > > > > Replace protocol="HTTP/1.1" with explicit > protocol="org.apache.coyote.http11.Http11AprProtocol" > > The former auto-switches between BIO and APR. > The latter explicitly uses the APR implementation. Thanks! I will change the config file as well! > > > maxThreads="150" scheme="https" secure="true" > > clientAuth="false" sslProtocol="TLS" > > SSLPassword="xxx" > > SSLCertificateFile="xxx/server.crt" > > SSLCertificateKeyFile="xxx/privkey.pem" > > SSLCACertificateFile="xxx/server.crt" > > SSLCertificateChainFile="xxx/server.crt" > > Compression="on"/> > > > > I haven't setup any keystore, as I'm not using the Java Key store for > > this... > I'm not sure why the new version is trying to find a keystore despite this > fact. > > > > Best regards, > Konstantin Kolinko > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Patching Tomcat for Heartbleed
2014-04-16 21:44 GMT+04:00 Cormier, Greg : > I have a Tomcat 7.0.30 server I'm trying to patch to resolve the heartbleed > exploit. > > I shut down the server and overwrite tcnative-1.dll with the recently > released version. > > When I restart tomcat, I get errors about the Java Key Store. > > Apr 16, 2014 9:36:07 AM org.apache.catalina.core.AprLifecycleListener init > INFO: The APR based Apache Tomcat Native library which allows optimal > performance in production environments was not found on the > java.library.path: D:\Tomcat > 7.0\bin;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\OpenSSL-Win32\bin;;. The above means that tcnative-1.dll was not found in the directories listed above. I would guess that you used a wrong DLL. It must match the CPU architecture of JRE/JDK that you are using. Is tcnative-1.dll file readable? > Apr 16, 2014 9:36:11 AM org.apache.coyote.AbstractProtocol init > INFO: Initializing ProtocolHandler ["http-bio-443"] > > Apr 16, 2014 9:36:12 AM org.apache.tomcat.util.net.jsse.JSSESocketFactory > getStore > SEVERE: Failed to load keystore type JKS with path C:\/.keystore due to > C:\.keystore (The system cannot find the file specified) > java.io.FileNotFoundException: C:\.keystore (The system cannot find the file > specified) > at java.io.FileInputStream.open(Native Method) > at java.io.FileInputStream.(Unknown Source) > at > org.apache.tomcat.util.net.jsse.JSSESocketFactory.getStore(JSSESocketFactory.java:400) > ... > > > I don't understand why I'm getting these, as I'm 99% sure I'm using APR and > not JSSE. > > > maxThreads="150" scheme="https" secure="true" > clientAuth="false" sslProtocol="TLS" > SSLPassword="xxx" > SSLCertificateFile="xxx/server.crt" > SSLCertificateKeyFile="xxx/privkey.pem" > SSLCACertificateFile="xxx/server.crt" > SSLCertificateChainFile="xxx/server.crt" > Compression="on"/> > > I haven't setup any keystore, as I'm not using the Java Key store for this... > I'm not sure why the new version is trying to find a keystore despite this > fact. > Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Patching Tomcat for Heartbleed
I have a Tomcat 7.0.30 server I'm trying to patch to resolve the heartbleed exploit. I shut down the server and overwrite tcnative-1.dll with the recently released version. When I restart tomcat, I get errors about the Java Key Store. Apr 16, 2014 9:36:07 AM org.apache.catalina.core.AprLifecycleListener init INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: D:\Tomcat 7.0\bin;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\OpenSSL-Win32\bin;;. Apr 16, 2014 9:36:11 AM org.apache.coyote.AbstractProtocol init INFO: Initializing ProtocolHandler ["http-bio-443"] Apr 16, 2014 9:36:12 AM org.apache.tomcat.util.net.jsse.JSSESocketFactory getStore SEVERE: Failed to load keystore type JKS with path C:\/.keystore due to C:\.keystore (The system cannot find the file specified) java.io.FileNotFoundException: C:\.keystore (The system cannot find the file specified) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.(Unknown Source) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.getStore(JSSESocketFactory.java:400) ... I don't understand why I'm getting these, as I'm 99% sure I'm using APR and not JSSE. I haven't setup any keystore, as I'm not using the Java Key store for this... I'm not sure why the new version is trying to find a keystore despite this fact. Thanks, Greg - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Configuration question
How do I prevent Tomcat 6 from responding to a request to an IP address, that is I only want my Tomcat server to respond to requests to www.mydomain.com vs. 10.1.1.1. Is this possible? The problem is that our web security scanner is reporting "Web Server Uses Basic Authentication Without HTTPS", and the infrastructure guys think it is because Tomcat allows connection to the IP address. Does this make sense?
http status 400 question
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
//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
//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
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JNDI initialization since Tomcat 8.0.1
On Sun, Apr 13, 2014 at 4:02 PM, Konstantin Kolinko wrote: > > > By the way, there exists an Apache project implementing the JPA > specification, > http://openjpa.apache.org/ It does not really work with Tomcat though does it? See this issue: https://issues.apache.org/jira/browse/OPENJPA-1590 or others. Also the build-time enhancement is a mess people shouldn't have to deal with. I was disappointed by this myself, not to mention that nobody seems to update the openjpa website anymore nor do they support jpa 2.1. Stalled project.
RE: Tomcat logging with Log4j
I was able to get one of our developers and it was simple for them to add the logging for our app to the logback we are using a file and add logging rotation. My issue is resolved. Thanks for the help though. -Original Message- From: Scott Bailey [mailto:sbai...@donlen.com] Sent: Tuesday, April 15, 2014 3:15 PM To: Tomcat Users List Subject: RE: Tomcat logging with Log4j Hello Christopher, > What steps did you actually take? Steps on this site: http://mrhaki.blogspot.com/2011/02/configure-log4j-on-tomcat.html Downloaded new jars from "extras" for tomcat. tomcat-juli.jar and tomcat-juli-adapters.jar. Placed the tomcat-juli.jar file in our $CATALINA_BASE/bin directory. The file tomcat-juli-adapters.jar is copied to our $CATALINA_BASE/lib directory. Downloaded the latest log4j 1.2 library from the download page and copied to the $CATALIN_BASE/lib directory. Added the Log4j configuration file as it is on the link above. Disable the old Tomcat JUL logging configuration by deleting logging.properties Placed the Log4j configuration file. In the $CATALINA_BASE/lib directory I am not a java person but I believe we are using logback is what our java developers say, we do not state what files to log to but what to log and I think Tomcat logged it to the log file. Thanks! -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Tuesday, April 15, 2014 2:22 PM To: Tomcat Users List Subject: Re: Tomcat logging with Log4j -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Scott, On 4/15/14, 2:50 PM, Scott Bailey wrote: > We need to add log rotation and log size management to tomcat 7. > Tried converting to Log4j steps from tomcat website > (http://tomcat.apache.org/tomcat-7.0-doc/logging.html) but did not > work, was able to get it to work from > (http://mrhaki.blogspot.com/2011/02/configure-log4j-on-tomcat.html). > > It seems we are not getting any logging from our webapp though, and > prior to this change it was getting logged in stdout and stderr. What steps did you actually take? > Does something need to be changed in log4j.properties to still capture > stdout and stderr to log file with Log4j? How are you logging from within your application? ServletContext.log()? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTTYbNAAoJEBzwKT+lPKRYHB4P/RUlDHyT2wQTt41S0YB/VbCR leQxOtDJYeO3WZ3qERNP1yzmX3GW2xKfxy8+5yXAgmPugO4LXbW2sj7a4VEDuR3D l5a/AkjqvsEdJFvWAB/77NFzWvcbOfiBT5Iw8AdkoprzaitdsD7UelLA7OlLbSCr EnLp1ZQmVJHEdAaFc0Rr2tH7SY1oSFZM19wmihBPTFZsOfnssiEnDnO6zhxgl9kG IlvNNuadefd0TxUiaNsncNYQatGjNsWHsjf6miYcEuJ2ZEz8x0YBzZv60MP0qiVi U/YvkvQCwGJU9wYvK9SjKpmJrunnB2dt3zKL724+qCw4D8h7qcccq6yytBXGRDha x4847oIbkvG7fqtljQTjfefuh8fFKalEVR8LP3huQtHqkpT4YRnRhJifFwZQmz1E aj7h/dz91F5pWmN673Fs8aO5LAM8qvsk7sT89QtBle0REeFZFEGPqGwBsDDV4sgE Shnr4JuR+xVyGCInHzV/zMDJ4EtVZVHRNFUnG9zS9Q5+FWfiOVc4cqxb4s6NgRKg mVhC8qharbzt/3I0nLNtMIxbz8c7hB2zNGBgjaQHEZ8BNp0+p3MtEOz9fGywi0pR CEL+HtjWbfaV+O8d3HSLyQMqtT5/ZOm10ZBG0s1yFjhaoxwz3yUjLLu2G3TeGJeD rRzHvGKrkAwWRehs+Zgm =g0p8 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org DISCLAIMER: This electronic mail message and any attached files contain information intended for the exclusive use of the intended addressee and may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information may be subject to legal restriction or sanction. Please notify sender if you are an unintended recipient and delete the original message without making copies. Thank you. B CB [ X ܚX KK[XZ[ \ \ ][ X ܚX P X ] \X K ܙ B ܈Y][ۘ[ [X[ K[XZ[ \ \ Z[ X ] \X K ܙ B DISCLAIMER: This electronic mail message and any attached files contain information intended for the exclusive use of the intended addressee and may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information may be subject to legal restriction or sanction. Please notify sender if you are an unintended recipient and delete the original message without making copies. Thank you.
Re: How to programmatically get the disableURLRewriting context attribute value?
On 16/04/2014 09:31, lo lo wrote: > Tomcat version 6.0.x on Linux OS > > Hello all, > > Sorry to post my question again but I have no answer till now. http://wiki.apache.org/tomcat/FAQ/Tomcat_User#Q2 > Could anyone tell me if it would be better to post it to the tomcat-dev > mailing list? No, this should not be posted to the dev list. Mark > I don't think so, but maybe I'm wrong. > > For more details, please see the original question here: > > http://marc.info/?l=tomcat-user&m=139713494623287&w=2 > > Thanks in advance for your help, > > Regards, > > Lo > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Performance - Java Profiler, JVM instrmentation
Hi Shanti,
On 04/15/2014 09:56 PM, Shanti Suresh wrote:
[...]
I find Chris' example on writing filters to map to URL patterns for
response-time metrics relevant. I would also like stall counts,
concurrent invocations etc.
What is a stall-count? How would you record "concurrent invocations",
etc.?
So here is my understanding of these metrics:
So if a request for a servlet or JSP exceeds a given time interval, that
would be a stall. The interval may depend upon the application. In some
cases, 10 seconds would be considered a stall, some cases, 30 seconds would
be a stall.
This can be done enabling the access log and adding a %D on the log
format string, here's
what i add to server.xml in tomcat 6:
directory="logs"
prefix="access." suffix=".log" resolveHosts="false"
pattern='%h %u %t "%r" %s %b %I %D'
buffered="false" />
then you get another log file, in this case access.DATE.log where the
last entry is the time in milliseconds
it took to complete the request.
Than just do a:
cat access.DATE.log | awk '{ if ($NF > DURATION) { print $0 } }'
Hope you got the idea
Similarly, how many times a servlet is invoked in a given time period would
count as concurrent invocations. Intervals used for the reckoning here may
be shorter - like 5 seconds - to make it more meaningful for concurrency
values.
You can use the access log for this too
[..]
Frederik
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
How to programmatically get the disableURLRewriting context attribute value?
Tomcat version 6.0.x on Linux OS Hello all, Sorry to post my question again but I have no answer till now. Could anyone tell me if it would be better to post it to the tomcat-dev mailing list? I don't think so, but maybe I'm wrong. For more details, please see the original question here: http://marc.info/?l=tomcat-user&m=139713494623287&w=2 Thanks in advance for your help, Regards, Lo
Re: tomcat 7.0.53 error
On Wed, Apr 16, 2014 at 7:03 AM, Philippe Couas wrote: > Hi, I want migrate from tomcat 7.0.52 to 7.0.53. My tomcat is launched in > standalone mode from command line (linux level3)Currently i have a servlet > that create image to disk and only with last version i have following error > message"Exception in thread "http-bio-8080-exec-10" > java.lang.InternalError: Can't connect to X11 window server using ':0.0' as > the value of the DISPLAY variable."Same servlet running perfect with > previous version. RegardsPhil Hi Philippe, seems some [new] component wants to talk to the X server. Can you try to add "-Djava.awt.headless=true" to the JAVA_OPTS when starting Tomcat? We are using that to avoid dependence on X11 in our application. Cheers Martin -- -- Martin Knoblauch email: k n o b i AT knobisoft DOT de www: http://www.knobisoft.de
