Re: SocketException when using localhost

2014-01-10 Thread Nancee Riehl
Hi Chris,

thank you for your reply!
On the tomcat everything works fine, I can see that the client certificate
is checked via my JSSE-Implementation in both cases!

This is the stacktrace from my test:

java.net.SocketException: Software caused connection abort: socket write
error
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:113)
at java.net.SocketOutputStream.write(SocketOutputStream.java:159)
at sun.security.ssl.OutputRecord.writeBuffer(OutputRecord.java:377)
at sun.security.ssl.OutputRecord.write(OutputRecord.java:363)
at
sun.security.ssl.SSLSocketImpl.writeRecordInternal(SSLSocketImpl.java:830)
at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:801)
at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:672)
at sun.security.ssl.Handshaker.sendChangeCipherSpec(Handshaker.java:966)
at
sun.security.ssl.ClientHandshaker.sendChangeCipherAndFinish(ClientHandshaker.java:1087)
at
sun.security.ssl.ClientHandshaker.serverHelloDone(ClientHandshaker.java:1006)
at
sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:285)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:868)
at sun.security.ssl.Handshaker.process_record(Handshaker.java:804)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1016)
at
sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312)
at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:702)
at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:122)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
at
org.apache.commons.httpclient.methods.StringRequestEntity.writeRequest(StringRequestEntity.java:146)
at
org.apache.commons.httpclient.methods.EntityEnclosingMethod.writeRequestBody(EntityEnclosingMethod.java:499)
at
org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:2114)
at
org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1096)
at
org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398)
at
org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
at sendAndReceiveMessageFromVsddWithTLS(OCSPTestUtil.java:186)
at testTLSCorruptedClientCert(TLSOcspTest.java:653)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at
org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:74)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at
org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:83)
at
org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:72)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:231)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:46)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at
org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at
org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:71)
at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:174)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:242)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:137)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at 

RE: Packet misses in Tomcat

2014-01-10 Thread Divyaprakash Y


-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: 10 January 2014 03:46
To: Tomcat Users List
Subject: Re: Packet misses in Tomcat

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Divyaprakash,

On 1/8/14, 4:06 AM, Divyaprakash Y wrote:
 -Original Message- From: André Warnier [mailto:a...@ice-sa.com]
 Sent: 08 January 2014 02:52 To: Tomcat Users List Subject: Re: Packet
 misses in Tomcat

 Christopher,

 Christopher Schultz wrote:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256

 André,

 On 1/7/14, 5:09 AM, André Warnier wrote:
 I do not pretend to know your system, nor your application, nor that
 the following is a definite explanation.  But on the base of the
 currently available data, I would say : - it is quite unlikely that
 Tomcat 7 is randomly dropping requests. If it was, then I would
 imagine that this list would be overflowing with cries for help.
 There is quite a bit of traffic on this list related to Tomcat 7,
 but I don't recall seeing any significant number of issues
 mentioning dropped requests. - it also doesn't seem, from your
 wireshark-related observations, that the requests are being lost
 outside of Tomcat. - so I would say at this point, that the most
 likely place for requests to disappear is in your own application.

 It seems that Tomcat is not logging the request in its access log, so
 it's more likely that the request is either malformed to such an
 extent that Tomcat rejects the request altogether or that the request
 never reaches Tomcat.

 ... Hi. Of course I am going essentially by what the OP provided
 earlier as information, and he has not provided much details on the
 disappearing requests themselves, or on the channel through which
 these requests were reaching Tomcat. But one thing that he did
 mention, is that these requests are similar - and even in general the
 same - as other requests which do get processed normally. As per his
 own words :

 For the query regarding All requests, all requests do not
 disappear. More importantly, sometimes all requests  reach the
 application when I POST same set of requests. To give a rough picture,
 1-2 requests fail in a set of 45-50 requests and this behaviour varies
 [The request which failed in my one test cycle succeeds in another
 cycle].

 If we take this at face value, then it should not be so that these
 requests are so malformed that Tomcat discards them without further
 ado. Also - but maybe I'm wrong there - I would expect, if Tomcat
 discards a request for being malformed - that something would appear
 in the Tomcat error log.  But according to the OP it doesn't. Finally
 - and there is a bit of an assumption on my part here - I assume that
 when the OP says that he sees the request with Wireshark (prior to it
 disappearing in Tomcat), he was running Wireshark on the Tomcat host
 itself.  That would make it unlikely that another external component
 is at play.

 All of the above led me to suspect that something in the application
 itself may be playing a role here.

 Of course, that all does not necessarily prove that some other
 component than Tomcat is not dropping some packets/requests.

 --

 Clarifications for the missed information:

(I have re-ordered some of your responses so they make more logical sense to 
me):

 - There are 2 machines (LAN) where client and servers are installed.
 Client is used to send the requests to Server. - Wireshark runs on the
 same machine where Tomcat runs - Tomcat will be accessed directly via
 HTTP

 - This issue occurs even if I use loopback address/localhost instead
of Server IP Address in the request URL (Install both client and server in the 
same machine).

 - A war file with a servlet to POST the requests.

What is the client?

Is it possible that this is something simple like the TCP backlog queue 
filling-up and the OS is just discarding requests?



Christopher,

The client is nothing but a SOAP client which sends the SOAP packets at an 
interval of 30 seconds to the server. Looks like the situation of TCP backlog 
queue filling-up won't arise.

FYI, the issue arises only when I use APR connector whereas default BIO 
connector works fine (both HTTP and HTTPS). I have not verified with NIO 
connector.

Any pointer?


-
DISCLAIMER: This electronic message and any attachments to this electronic 
message is intended for the exclusive use of the addressee(s) named herein and 
may contain legally privileged and confidential information. It is the property 
of Celstream Systems Private Limited. If you are not the intended recipient, 
you are hereby strictly notified not to copy, forward, distribute or use this 
message or any attachments thereto. If you have received this message in error, 
please delete it and all copies thereof, from your system and notify the sender 
at Celstream Systems or 

Re: SocketException when using localhost

2014-01-10 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Nancee,

On 1/10/14, 5:28 AM, Nancee Riehl wrote:
 thank you for your reply! On the tomcat everything works fine, I
 can see that the client certificate is checked via my
 JSSE-Implementation in both cases!
 
 This is the stacktrace from my test:
 
 java.net.SocketException: Software caused connection abort: socket
 write error at java.net.SocketOutputStream.socketWrite0(Native
 Method) at
 java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:113)

 
at java.net.SocketOutputStream.write(SocketOutputStream.java:159)
 at
 sun.security.ssl.OutputRecord.writeBuffer(OutputRecord.java:377) at
 sun.security.ssl.OutputRecord.write(OutputRecord.java:363) at 
 sun.security.ssl.SSLSocketImpl.writeRecordInternal(SSLSocketImpl.java:830)

 
at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:801)
 at
 sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:672) 
 at
 sun.security.ssl.Handshaker.sendChangeCipherSpec(Handshaker.java:966)

 
at
 sun.security.ssl.ClientHandshaker.sendChangeCipherAndFinish(ClientHandshaker.java:1087)

 
at
 sun.security.ssl.ClientHandshaker.serverHelloDone(ClientHandshaker.java:1006)

 
at
 sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:285)

 
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:868)
 at sun.security.ssl.Handshaker.process_record(Handshaker.java:804) 
 at
 sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1016) 
 at 
 sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312)

 
at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:702)
 at
 sun.security.ssl.AppOutputStream.write(AppOutputStream.java:122) at
 java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)

 
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
 at 
 org.apache.commons.httpclient.methods.StringRequestEntity.writeRequest(StringRequestEntity.java:146)

 
at
 org.apache.commons.httpclient.methods.EntityEnclosingMethod.writeRequestBody(EntityEnclosingMethod.java:499)

 
at
 org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:2114)

 
at
 org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1096)

 
at
 org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398)

 
at
 org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)

 
at
 org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)

 
at
 org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)

 
at sendAndReceiveMessageFromVsddWithTLS(OCSPTestUtil.java:186)
 at testTLSCorruptedClientCert(TLSOcspTest.java:653)

You might want to try asking the commons folks who will likely have
better answers than here. Perhaps HttpClient is doing something that
may cause an error, or mask the real error?

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJS0BODAAoJEBzwKT+lPKRYfvEP/RyAJ9etdPH0sA60gDW+Jh7F
yQlNf3h7nNsAI/fYwdTYyY2Vre+H5QS0GYwy7dz/uAh3THx7X8RR7cN7qGI60Mmb
M6b5BzqZdr41cLVupBP5eY/zEZ1CwP4sfvu7iLzmIXVtarUnR9R0+Y14FoZwWlKW
YhihVPuGR51jNNQuLkuee4cQTwDEvtor8VxzwM9fSw5v6EzYKkq7hV32r6ju4Rih
XHDPbDj8kwfBATqT0u9J6GIei206iAZweGQfXSNQVeVpqycTK3gswnzB8yUJEPU3
Z46KyL7DzB1ksQ7bZ7k7gp+8gPmu9LADPl+DmegpY4N5Zdkor12QQszrDGk8gs6N
71ii2LlSotfE2zQPNcKQaFGMFG2p49xn2gT3ip2OcXEB+vdhjcPKf6RS2p3a1AuI
qTOCHmPtOY9Q/VJWVAaMZCoTLOZB4MDskOKHNMiZb1u3UWeuYr19fFh4Ko0Esff2
49TH9qKas7hqYKTaO6VkpN1WJnvF7ipWM128NMgmI82B1WLYYLULKxWpYsS4AgRD
oD1QvlmxCpUAC6ypLsXUxNcChVXe8POfQwdHx5a0ihwKGDlQM3bi+C7/Wm8F8g7b
MAEBvqZkX0THurSWlt+wrAALvwcdj+VjUQYlGzFPP1lTnGDpAWmzx1oe6ZNUVB2/
LjI/UrNlS+0aNkVv/Frc
=Ea2c
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Getting 404 before the container starts all servlets

2014-01-10 Thread Adrian Tarau
I tried with bindOnInit=false and bindOnInit=true, it makes no 
difference. I'm using tomcat 7.0.34, would this option be available in 
7.0.34?


Thanks,
Adrian Tarau.

On 01/09/2014 11:19 PM, Caldarale, Charles R wrote:

From: Adrian Tarau [mailto:mailingl...@adrian.tarau.org]
Subject: Getting 404 before the container starts all servlets
After upgrading Tomcat from 6.X to 7.X, our AJAX client receives 404 for
10-15 seconds right after startup. I presume the request is accepted and
processed before all servlet are initialized, which is not what you
would expect.
Is this behavior normal for 7.X? Is there a way to configure 7.x to
behave like 6.x?

Look at the bindOnInit attribute for Connector elements:
http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Standard_Implementation

But be aware of the side effects as discussed in these threads:
http://marc.info/?l=tomcat-userm=136386106909331w=2
http://marc.info/?l=tomcat-userm=130549517506701w=2

  - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Packet misses in Tomcat

2014-01-10 Thread Stefan Mayr

Hi

Am 09.01.2014 14:21, schrieb Divyaprakash Y:



-Original Message-
From: Divyaprakash Y
Sent: 08 January 2014 14:35
To: Tomcat Users List
Subject: RE: Packet misses in Tomcat

-Original Message-
From: André Warnier [mailto:a...@ice-sa.com]
Sent: 08 January 2014 02:52
To: Tomcat Users List
Subject: Re: Packet misses in Tomcat

Christopher,

Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

André,

On 1/7/14, 5:09 AM, André Warnier wrote:

I do not pretend to know your system, nor your application, nor that
the following is a definite explanation.  But on the base of the
currently available data, I would say : - it is quite unlikely that
Tomcat 7 is randomly dropping requests. If it was, then I would
imagine that this list would be overflowing with cries for help.
There is quite a bit of traffic on this list related to Tomcat 7, but
I don't recall seeing any significant number of issues mentioning
dropped requests. - it also doesn't seem, from your
wireshark-related observations, that the requests are being lost
outside of Tomcat. - so I would say at this point, that the most
likely place for requests to disappear is in your own application.



...

Strange that this is happening only to me.
Looks like something similar was reported on the dev list when voting 
for Tomcat 7.0.50

..

Thanks.




I tried same setup today with the BIO connector, everything worked flawlessly. 
Will there be any issue with the APR connector(earlier setup) or are there any 
extra configurations which I missed in my server.xml?


This might be the issue seen in 
https://issues.apache.org/bugzilla/show_bug.cgi?id=55976 . Looks like 
Mark fixed it today for 7.0.51 (not released yet)


- Stefan

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



RE: Getting 404 before the container starts all servlets

2014-01-10 Thread Caldarale, Charles R
 From: Adrian Tarau [mailto:mailingl...@adrian.tarau.org] 
 Subject: Re: Getting 404 before the container starts all servlets

 I tried with bindOnInit=false and bindOnInit=true, it makes no 
 difference. I'm using tomcat 7.0.34, would this option be available in 
 7.0.34?

It should be.  Note that the Tomcat you're using is over a year old, so you 
might want to consider upgrading, regardless.  Lots of things fixed since then.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



RE: Question on SSL and Pragma in 7.x

2014-01-10 Thread Jeffrey Janner
 -Original Message-
 From: Mark Thomas [mailto:ma...@apache.org]
 Sent: Thursday, January 09, 2014 4:08 PM
 To: Tomcat Users List
 Subject: Re: Question on SSL and Pragma in 7.x
 
 On 09/01/2014 18:22, Jeffrey Janner wrote:
  I'd like to verify something I think I'm seeing in Tomcat 7.x.
 
 snip/
 
  Am I interpreting all that correctly?
 
 See http://markmail.org/message/2kkq4yxgacgbrwht
 
  If I wanted to add a section that did use Tomcat Auth, would I
  need/want to add the appropriate Authenticator valve back to the
 context.xml?
 
 Only if you need to change the configuration of the Authenticator.
 Tomcat adds the correct Authenticator automatically based on the auth-
 method defined in web.xml
 
 Mark
 

Thanks Mark.  I will keep that in mind, but it looks like the defaults will do 
it from now on.
However, any idea about the last section of my post?
Specifically, why the SSlAuthenticator was kicking in when the auth method was 
defined as Basic?  (note, no SSL auth method was configured in the web.xml, but 
the SSLAuthenticator was configured in the context.xml.)  Just curious about 
that.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Would a developer please add this mime type to the distro?

2014-01-10 Thread Jeffrey Janner
Tomcat 7 did a good job of collecting all the new Microsoft mime types into the 
standard web.xml file, but missed the mapping for the .one file type for 
OneNote, even though that's fully documented on the Microsoft Mime Types page.  
 The entry is:

  mime-mapping
extensionone/extension
mime-typeapplication/onenote/mime-type
  /mime-mapping

I know I can always add it to my local web.xml, but it's now the only one I 
need and I figured that others might like to have it available as a default as 
well.

Jeffrey Janner


Mod_jk error

2014-01-10 Thread Alex Lucard
.
On Jan 10, 2014 5:00 PM, Alex Lucard priest.luc...@gmail.com wrote:

 I am running CentOS 6.5 and tomcat 7
 I cannot get the mod_jk to work
 I have a JSP page on this server and if you go to localhost:8080/Hello it
 will work but if I just go to localhost/Hello The requested URL /Hello was
 not found on this server.

 I have apache2 and tomcat 7 install both work.
 Here is the part I added to the httpd.conf file

 # Load the mod_jk module.
 LoadModule jk_module /usr/lib64/httpd/modules/mod_jk.so
 JkWorkersFile /etc/httpd/conf/workers.properties
 jkLogFile /var/log/mod_jk.log
 JkLogLevellevel
 JkLogStampFormat [%a %b %d %H:%M:%S %Y] 

 My workers.properties file at /etc/httpd/conf/workers.properties
 worker.list=worker1
 worker.worker1.type=ajp13
 worker.worker1.port=8009
 worker.worker1.host=localhost
 #worker.worker1.lbfactor=1


 My error log file /var/log/mod_jk.log
 [Fri Jan 10 15:19:22 2014] [1854:140509786134496] [info] init_jk::mod_jk.c
 (3365): mod_jk/1.2.37 initialized
 [Fri Jan 10 15:19:23 2014] [1855:140509786134496] [error]
 ajp_validate::jk_ajp_common.c (2696): worker worker1 can't resolve tomcat
 address localhost
 [Fri Jan 10 15:19:23 2014] [1855:140509786134496] [info] init_jk::mod_jk.c
 (3365): mod_jk/1.2.37 initialized



Re: Mod_jk error

2014-01-10 Thread Mark Eggers

On 1/10/2014 2:53 PM, Alex Lucard wrote:

.
On Jan 10, 2014 5:00 PM, Alex Lucard priest.luc...@gmail.com wrote:


I am running CentOS 6.5 and tomcat 7
I cannot get the mod_jk to work
I have a JSP page on this server and if you go to localhost:8080/Hello it
will work but if I just go to localhost/Hello The requested URL /Hello was
not found on this server.

I have apache2 and tomcat 7 install both work.
Here is the part I added to the httpd.conf file

# Load the mod_jk module.
LoadModule jk_module /usr/lib64/httpd/modules/mod_jk.so
JkWorkersFile /etc/httpd/conf/workers.properties
jkLogFile /var/log/mod_jk.log
JkLogLevellevel
JkLogStampFormat [%a %b %d %H:%M:%S %Y] 

My workers.properties file at /etc/httpd/conf/workers.properties
worker.list=worker1
worker.worker1.type=ajp13
worker.worker1.port=8009
worker.worker1.host=localhost
#worker.worker1.lbfactor=1


My error log file /var/log/mod_jk.log
[Fri Jan 10 15:19:22 2014] [1854:140509786134496] [info] init_jk::mod_jk.c
(3365): mod_jk/1.2.37 initialized
[Fri Jan 10 15:19:23 2014] [1855:140509786134496] [error]
ajp_validate::jk_ajp_common.c (2696): worker worker1 can't resolve tomcat
address localhost
[Fri Jan 10 15:19:23 2014] [1855:140509786134496] [info] init_jk::mod_jk.c
(3365): mod_jk/1.2.37 initialized





What happens when you type the following from the command line:

dig localhost

As a workaround, replace localhost with 127.0.0.1.

. . . . just my two cents
/mde/

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Getting 404 before the container starts all servlets

2014-01-10 Thread Adrian Tarau
I tried with 7.0.47 and I still get 404 regardless of the the state of 
bindOnInit.


/Connector port=8080 protocol=HTTP/1.1//
//   connectionTimeout=2//
//   redirectPort=8443 bindOnInit=false/true//

On 01/10/2014 01:38 PM, Caldarale, Charles R wrote:

From: Adrian Tarau [mailto:mailingl...@adrian.tarau.org]
Subject: Re: Getting 404 before the container starts all servlets
I tried with bindOnInit=false and bindOnInit=true, it makes no
difference. I'm using tomcat 7.0.34, would this option be available in
7.0.34?

It should be.  Note that the Tomcat you're using is over a year old, so you 
might want to consider upgrading, regardless.  Lots of things fixed since then.

  - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org





“exception-message” header reveals path to document root in 404 response.

2014-01-10 Thread August Kleimo
I'm failing a PCI compliance scan because my Tomcat Version 7.0.20 server
is revealing the path to the document web root in an exception-message
header when a missing page is requested.

Does anyone know of way to get rid of this header from the response?

Note: I'm running Railo 4.1.2 on top of Tomcat ... but I think this header
is coming from Tomcat.

$ curl -I http://mydomain.com/this-page-does-not-exist.html

HTTP/1.1 404 Not Found
Date: Fri, 10 Jan 2014 23:23:22 GMT
Server: Apache-Coyote/1.1
exception-message: Page
/this-page-does-not-exist.html [/var/www/html/this-page-does-not-exist.html]
not found
Content-Type: text/html;charset=UTF-8
Content-Length: 44
Set-Cookie: cfid=686ea13b-ef35-43c3-b6e4-08270bbb4718;Path=/;Expires=Sun,
10-Jan-2044 07:14:52 GMT;HTTPOnly
Set-Cookie: cftoken=0;Path=/;Expires=Sun, 10-Jan-2044 07:14:52 GMT;HTTPOnly
Connection: close


Re: “exception-message” header reveals path to document root in 404 response.

2014-01-10 Thread Mark Eggers

On 1/10/2014 3:28 PM, August Kleimo wrote:

I'm failing a PCI compliance scan because my Tomcat Version 7.0.20 server
is revealing the path to the document web root in an exception-message
header when a missing page is requested.

Does anyone know of way to get rid of this header from the response?

Note: I'm running Railo 4.1.2 on top of Tomcat ... but I think this header
is coming from Tomcat.

$ curl -I http://mydomain.com/this-page-does-not-exist.html

HTTP/1.1 404 Not Found
Date: Fri, 10 Jan 2014 23:23:22 GMT
Server: Apache-Coyote/1.1
exception-message: Page
/this-page-does-not-exist.html [/var/www/html/this-page-does-not-exist.html]
not found
Content-Type: text/html;charset=UTF-8
Content-Length: 44
Set-Cookie: cfid=686ea13b-ef35-43c3-b6e4-08270bbb4718;Path=/;Expires=Sun,
10-Jan-2044 07:14:52 GMT;HTTPOnly
Set-Cookie: cftoken=0;Path=/;Expires=Sun, 10-Jan-2044 07:14:52 GMT;HTTPOnly
Connection: close


From Tomcat 7.0.42 / APR Native on Fedora 20 with jre 1.7.0_45:

curl -I http://localhost:8080/this-does-not-exist.html
HTTP/1.1 404 Not Found
Server: Apache-Coyote/1.1
Content-Type: text/html;charset=utf-8
Content-Length: 999
Date: Fri, 10 Jan 2014 23:46:44 GMT

A quick grep of the Tomcat 7 trunk code does not reveal the string 
'exception-message' anywhere.


I didn't see anything in the change log concerning this, either.

. . . . just my (waiting for testing to be done) two cents
/mde/



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



RE: exception-message header reveals path to document root in 404 response.

2014-01-10 Thread Caldarale, Charles R
 From: August Kleimo [mailto:aug...@kleimo.com] 
 Subject: exception-message header reveals path to document root in 404 
 response.

 I'm failing a PCI compliance scan because my Tomcat Version 7.0.20 server
 is revealing the path to the document web root in an exception-message
 header when a missing page is requested.

If you were really worried about security, you wouldn't be running a version of 
Tomcat that's 2.5 years old.  Seriously, upgrade.

 Does anyone know of way to get rid of this header from the response?

Use your own custom error page.

 Note: I'm running Railo 4.1.2 on top of Tomcat ... but I think this header
 is coming from Tomcat.

Nope.  Here's Tomcat's standard 404 response:

HTTP/1.1 404 Not Found
Server: Apache-Coyote/1.1
Content-Type: text/html;charset=utf-8
Content-Length: 1027
Date: Fri, 10 Jan 2014 23:59:34 GMT

Most likely Railo is using a friendly error page.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: “exception-message” header reveals path to document root in 404 response.

2014-01-10 Thread August Kleimo
Thanks, Perhaps it's coming from Railo then.  I'll investigate down that
path.


On Fri, Jan 10, 2014 at 3:56 PM, Mark Eggers its_toas...@yahoo.com wrote:

 On 1/10/2014 3:28 PM, August Kleimo wrote:

 I'm failing a PCI compliance scan because my Tomcat Version 7.0.20 server
 is revealing the path to the document web root in an exception-message
 header when a missing page is requested.

 Does anyone know of way to get rid of this header from the response?

 Note: I'm running Railo 4.1.2 on top of Tomcat ... but I think this header
 is coming from Tomcat.

 $ curl -I http://mydomain.com/this-page-does-not-exist.html

 HTTP/1.1 404 Not Found
 Date: Fri, 10 Jan 2014 23:23:22 GMT
 Server: Apache-Coyote/1.1
 exception-message: Page
 /this-page-does-not-exist.html [/var/www/html/this-page-does-
 not-exist.html]
 not found
 Content-Type: text/html;charset=UTF-8
 Content-Length: 44
 Set-Cookie: cfid=686ea13b-ef35-43c3-b6e4-08270bbb4718;Path=/;Expires=Sun,
 10-Jan-2044 07:14:52 GMT;HTTPOnly
 Set-Cookie: cftoken=0;Path=/;Expires=Sun, 10-Jan-2044 07:14:52
 GMT;HTTPOnly
 Connection: close

  From Tomcat 7.0.42 / APR Native on Fedora 20 with jre 1.7.0_45:

 curl -I http://localhost:8080/this-does-not-exist.html
 HTTP/1.1 404 Not Found
 Server: Apache-Coyote/1.1
 Content-Type: text/html;charset=utf-8
 Content-Length: 999
 Date: Fri, 10 Jan 2014 23:46:44 GMT

 A quick grep of the Tomcat 7 trunk code does not reveal the string
 'exception-message' anywhere.

 I didn't see anything in the change log concerning this, either.

 . . . . just my (waiting for testing to be done) two cents
 /mde/



 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org




Re: exception-message header reveals path to document root in 404 response.

2014-01-10 Thread Jordan Michaels
Although I suppose it's possible, I don't think it has to do with Railo. 
The Railo servlet doesn't handle requests for .html files... those are 
handled by Tomcat's default servlet.


Here are the default (suggested) handlers for a Railo install:

servlet-mapping
servlet-nameCFMLServlet/servlet-name
url-pattern*.cfm/url-pattern
url-pattern*.cfml/url-pattern
url-pattern*.cfc/url-pattern
!-- Basic SES Mappings --
url-pattern/index.cfc/*/url-pattern
url-pattern/index.cfm/*/url-pattern
url-pattern/index.cfml/*/url-pattern
/servlet-mapping

!-- Mapping for Flex Gateway Servlet --
servlet-mapping
servlet-nameMessageBrokerServlet/servlet-name
url-pattern/flex2gateway/*/url-pattern
url-pattern/flashservices/gateway/*/url-pattern
url-pattern/messagebroker/*/url-pattern
/servlet-mapping

!-- mapping for Railo's REST servlet --
servlet-mapping
servlet-nameRestServlet/servlet-name
url-pattern/rest/*/url-pattern
/servlet-mapping

August, can you describe you're install a bit more? How did you install 
Railo? Did you start with a Vanilla Tomcat install and install a Railo 
war? Have you customized your install at all or added any custom configs?


Warm Regards,
Jordan Michaels

On 01/10/2014 04:02 PM, Caldarale, Charles R wrote:

From: August Kleimo [mailto:aug...@kleimo.com]
Subject: exception-message header reveals path to document root in 404 
response.



I'm failing a PCI compliance scan because my Tomcat Version 7.0.20 server
is revealing the path to the document web root in an exception-message
header when a missing page is requested.


If you were really worried about security, you wouldn't be running a version of 
Tomcat that's 2.5 years old.  Seriously, upgrade.


Does anyone know of way to get rid of this header from the response?


Use your own custom error page.


Note: I'm running Railo 4.1.2 on top of Tomcat ... but I think this header
is coming from Tomcat.


Nope.  Here's Tomcat's standard 404 response:

HTTP/1.1 404 Not Found
Server: Apache-Coyote/1.1
Content-Type: text/html;charset=utf-8
Content-Length: 1027
Date: Fri, 10 Jan 2014 23:59:34 GMT

Most likely Railo is using a friendly error page.

  - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: exception-message header reveals path to document root in 404 response.

2014-01-10 Thread Jordan Michaels
It may also be useful to know if you get this same exception-message 
header when you get a 404 from the Railo servlet (from a request for a 
.cfm file).


It may help determine if Railo is involved or not.

Warm Regards,
Jordan Michaels

On 01/10/2014 04:02 PM, Caldarale, Charles R wrote:

From: August Kleimo [mailto:aug...@kleimo.com]
Subject: exception-message header reveals path to document root in 404 
response.



I'm failing a PCI compliance scan because my Tomcat Version 7.0.20 server
is revealing the path to the document web root in an exception-message
header when a missing page is requested.


If you were really worried about security, you wouldn't be running a version of 
Tomcat that's 2.5 years old.  Seriously, upgrade.


Does anyone know of way to get rid of this header from the response?


Use your own custom error page.


Note: I'm running Railo 4.1.2 on top of Tomcat ... but I think this header
is coming from Tomcat.


Nope.  Here's Tomcat's standard 404 response:

HTTP/1.1 404 Not Found
Server: Apache-Coyote/1.1
Content-Type: text/html;charset=utf-8
Content-Length: 1027
Date: Fri, 10 Jan 2014 23:59:34 GMT

Most likely Railo is using a friendly error page.

  - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: exception-message header reveals path to document root in 404 response.

2014-01-10 Thread August Kleimo
Hi All,  Thanks for all your replies.  Turns out it was in fact Railo.  I
searched the Railo repo on GitHub and found a reference to that header.  I
was able to overwrite it with a blank string using this line of code.

cfset getPageContext().getResponse().setHeader(exception-message,)




On Fri, Jan 10, 2014 at 4:36 PM, Jordan Michaels jor...@viviotech.netwrote:

 It may also be useful to know if you get this same exception-message
 header when you get a 404 from the Railo servlet (from a request for a .cfm
 file).

 It may help determine if Railo is involved or not.


 Warm Regards,
 Jordan Michaels

 On 01/10/2014 04:02 PM, Caldarale, Charles R wrote:

 From: August Kleimo [mailto:aug...@kleimo.com]
 Subject: exception-message header reveals path to document root in 404
 response.


  I'm failing a PCI compliance scan because my Tomcat Version 7.0.20 server
 is revealing the path to the document web root in an exception-message
 header when a missing page is requested.


 If you were really worried about security, you wouldn't be running a
 version of Tomcat that's 2.5 years old.  Seriously, upgrade.

  Does anyone know of way to get rid of this header from the response?


 Use your own custom error page.

  Note: I'm running Railo 4.1.2 on top of Tomcat ... but I think this
 header
 is coming from Tomcat.


 Nope.  Here's Tomcat's standard 404 response:

 HTTP/1.1 404 Not Found
 Server: Apache-Coyote/1.1
 Content-Type: text/html;charset=utf-8
 Content-Length: 1027
 Date: Fri, 10 Jan 2014 23:59:34 GMT

 Most likely Railo is using a friendly error page.

   - Chuck


 THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
 MATERIAL and is thus for use only by the intended recipient. If you
 received this in error, please contact the sender and delete the e-mail and
 its attachments from all computers.


 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org


 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org




Re: exception-message header reveals path to document root in 404 response.

2014-01-10 Thread Jordan Michaels

Thanks August, good to know.

Warm Regards,
Jordan Michaels

On 01/10/2014 04:48 PM, August Kleimo wrote:

Hi All,  Thanks for all your replies.  Turns out it was in fact Railo.  I
searched the Railo repo on GitHub and found a reference to that header.  I
was able to overwrite it with a blank string using this line of code.

cfset getPageContext().getResponse().setHeader(exception-message,)




On Fri, Jan 10, 2014 at 4:36 PM, Jordan Michaels jor...@viviotech.netwrote:


It may also be useful to know if you get this same exception-message
header when you get a 404 from the Railo servlet (from a request for a .cfm
file).

It may help determine if Railo is involved or not.


Warm Regards,
Jordan Michaels

On 01/10/2014 04:02 PM, Caldarale, Charles R wrote:


From: August Kleimo [mailto:aug...@kleimo.com]

Subject: exception-message header reveals path to document root in 404
response.



  I'm failing a PCI compliance scan because my Tomcat Version 7.0.20 server

is revealing the path to the document web root in an exception-message
header when a missing page is requested.



If you were really worried about security, you wouldn't be running a
version of Tomcat that's 2.5 years old.  Seriously, upgrade.

  Does anyone know of way to get rid of this header from the response?




Use your own custom error page.

  Note: I'm running Railo 4.1.2 on top of Tomcat ... but I think this

header
is coming from Tomcat.



Nope.  Here's Tomcat's standard 404 response:

HTTP/1.1 404 Not Found
Server: Apache-Coyote/1.1
Content-Type: text/html;charset=utf-8
Content-Length: 1027
Date: Fri, 10 Jan 2014 23:59:34 GMT

Most likely Railo is using a friendly error page.

   - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail and
its attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org






-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Would a developer please add this mime type to the distro?

2014-01-10 Thread Konstantin Kolinko
2014/1/11 Jeffrey Janner jeffrey.jan...@polydyne.com:
 Tomcat 7 did a good job of collecting all the new Microsoft mime types into 
 the standard web.xml file, but missed the mapping for the .one file type 
 for OneNote, even though that's fully documented on the Microsoft Mime Types 
 page.

1. What page, exactly?

   The entry is:

   mime-mapping
 extensionone/extension
 mime-typeapplication/onenote/mime-type
   /mime-mapping

 I know I can always add it to my local web.xml, but it's now the only one I 
 need and I figured that others might like to have it available as a default 
 as well.

2. The list of mime types in Tomcat is kept in sync with the similar
list in Apache HTTPD.

If I look at HTTPD trunk, that mime-type is mapped to extensions
onetoc onetoc2 onetmp onepkg.

http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/conf/mime.types?view=markup#l159

3. IMHO application/onenote is not a valid mime type on the Internet,
as it is not registered with IANA.

http://www.iana.org/assignments/media-types/media-types.xhtml#application

4. Formally, a way to go is to file an enhancement request.



Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org