Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]

[Rahul Singh]

Hi André Warnier,

its 64 bit (OS and JVM)


From: André Warnier (tomcat) 
Sent: Wednesday, January 13, 2016 2:17 PM
To: users@tomcat.apache.org
Subject: Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 
Struts: 2.3.24 JAVA: openJDK 1.7.79]

maybe a stupid question nowadays, but : is the platform on which you are 
running this
32-bit, or 64-bit ? (OS and JVM)

On 13.01.2016 04:56, Rahul Singh wrote:
> Hi,
>
>> Define "Not successful"?  Exceptions thrown?  File truncated?  Upload
>> never starts?  Never finishes?
>
> Not successful :
>
> Request Never finishes, we have trace the HttpServlet request object and 
> request.getContentLength return 0 in case when file size is >=2GB,
>
> No exception thrown, as well as when file size is less than 2GB, then 
> request.getContentLength return the correct value of file size in byte.
>
>
> Regards,
> Rahul Kumar Singh
> 
> From: David kerber 
> Sent: Tuesday, January 12, 2016 6:07 PM
> To: Tomcat Users List
> Subject: Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 
> Struts: 2.3.24 JAVA: openJDK 1.7.79]
>
> On 1/12/2016 12:01 AM, Rahul Singh wrote:
>>
>> Hello Apache Tomcat team,
>>
>> Sending again with some corrections,
>>
>> File upload in my  application(Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 
>> 1.7.79) is not successful for greater than 2 gb. After previous discussion 
>> here on previous thread, I migrated my application to struts 2.3.24 as the 
>> only possible solution in form of jakarta-stream parser for large size 
>> uploads (greater than 2gb).
>> But after successfully migrating to struts 2.3.24 from 2.1.8, file upload 
>> greater than 2 gb still not supported. I want to use jakarta-streams for 
>> this purpose.Following is the code
>> snippet:
>>
>>
>> In struts.xml:
>> 
>>
>> 
>> 
>>
>> In JSP:
>> ===
>>
>> > namespace="xyz"   validateFields="false" method="post"
>> enctype="multipart/form-data">
>>
>>
>> Alongwith with configuring server.xml with maxPostSize element and 
>> mutipart-config in web.xml But still the file upload request for greater 
>> than 2 gb not successful.
>
> Define "Not successful"?  Exceptions thrown?  File truncated?  Upload
> never starts?  Never finishes?
>
>
> -
> 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

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

Tomcat 8 Application dispatcherServlet Stats

[Theo Sweeny]

Hello - at the moment stats can be found for Tomcat 8 web services using the 
manager UI /manager/status/all

Is the "Processing time" metric found under dispatcherServlet [ / ] subsection, 
the total time take to serve all requests, including the response time for each 
request?

Regards,

Theo
Avios Group (AGL) Ltd is a limited company registered in England (registered 
number 2260073 and VAT number 512566754) whose registered address is Astral 
Towers, Betts Way, London Road, Crawley, West Sussex RH10 9XY . Avios Group 
(AGL) Limited is part of the IAG group of companies This email and any files 
transmitted with it are confidential and intended solely for the use of the 
individual or entity to whom they are addressed. If you have received this 
email in error please notify the system manager.

Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]

[tomcat]

maybe a stupid question nowadays, but : is the platform on which you are running this 
32-bit, or 64-bit ? (OS and JVM)


On 13.01.2016 04:56, Rahul Singh wrote:

Hi,


Define "Not successful"?  Exceptions thrown?  File truncated?  Upload
never starts?  Never finishes?


Not successful :

Request Never finishes, we have trace the HttpServlet request object and 
request.getContentLength return 0 in case when file size is >=2GB,

No exception thrown, as well as when file size is less than 2GB, then 
request.getContentLength return the correct value of file size in byte.


Regards,
Rahul Kumar Singh

From: David kerber 
Sent: Tuesday, January 12, 2016 6:07 PM
To: Tomcat Users List
Subject: Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 
Struts: 2.3.24 JAVA: openJDK 1.7.79]

On 1/12/2016 12:01 AM, Rahul Singh wrote:


Hello Apache Tomcat team,

Sending again with some corrections,

File upload in my  application(Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 
1.7.79) is not successful for greater than 2 gb. After previous discussion here 
on previous thread, I migrated my application to struts 2.3.24 as the only 
possible solution in form of jakarta-stream parser for large size uploads 
(greater than 2gb).
But after successfully migrating to struts 2.3.24 from 2.1.8, file upload 
greater than 2 gb still not supported. I want to use jakarta-streams for this 
purpose.Following is the code
snippet:


In struts.xml:





In JSP:
===




Alongwith with configuring server.xml with maxPostSize element and mutipart-config 
in web.xml But still the file upload request for greater than 2 gb not 
successful.


Define "Not successful"?  Exceptions thrown?  File truncated?  Upload
never starts?  Never finishes?


-
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: Tomcat 8.0.30 Session lost

[Thomas Scheffler]

Am 12.01.16 um 13:24 schrieb Mark Thomas:

On 12/01/2016 11:06, Thomas Scheffler wrote:

Am 11.01.16 um 22:05 schrieb Mark Thomas:




Found on
http://www.tomcatexpert.com/blog/2011/04/25/session-fixation-protection
the description how to switch the "feature" off.

I will file two bugs soon describing the issues I had. Hopefully they
will be fixed.

1.) if using HttpServetRequest.login(String, String) further request in
the session are loosing the users Principal.

2.) After changing sessionId, old sessionIds should still be valid for a
short period of time of to the same client.


The second request will get closed as INVALID on security grounds. If
the old ID is valid for any period of time it makes a session fixation
attack possible. You might as well disable changing the session ID on
authentication.

For the first the description above isn't clear enough to be sure
exactly what you are asking for. However, based on the second request
and what I have read of this thread I suspect that request will get
closed as INVALID or WONTFIX.


Hi Mark,

if you choose to use login() and this modifies the session ID. Further
calls to login() should either:

1.) are not required as every request belonging to the same session are
already authenticated. After login() other request of the same session
will not return 'null' on getRemoteUser() or getUserPrincipal()

2.) are not required, as authenticate() use the information provided by
the first login() call.

3.) do not modify the session ID as the same user was authenticated
before and the session is therefor safe to session fixation attacks


Those 3 all boil down to essentially the same requirement.

Requests are populated with cached authentication information from the
session at the start of the request (if the authenticator is configured
to do so - all but DIGEST are by default).


Hi,

"all but DIGEST are by default" was my case.

As I walked through the code I found most of the features I requested 
are already in place. There is already the tracking of the Principal in 
the session. To use the values of login() later in authenticate() in 
Tomcat 8.0.30 I had to insert "/foo" as my login page and "/bar" as my 
login-error-page. I think any value will do here ;-)



FORM
Restricted

/foo
/bar



This activates the FormAuthenticator which correctly does, what I was 
hoping for.


I think every authenticator can/should use the information stored by 
login() if it is available.


kind regards

Thomas

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

RE: [EXTERNAL] Re: Problem starting Tomcat 7.0.59 as a Windows Service

[McDermott, Becky]

My problem has been solved.  In the tomcat7w.exe, I had to add the following to 
the Java Options:

-Djava.library.path=C:\PROGRA~1\IBM\JazzTeamServer_601\server\tomcat\lib

I also had to remove:
-Xgc:preferredHeapBase=0x1

With the removal of -Xgc and the addition of the -Djava.library.path, the 
service successfully started.

-Original Message-
From: Terence M. Bandoian [mailto:tere...@tmbsw.com] 
Sent: Tuesday, January 12, 2016 6:46 PM
To: Tomcat Users List
Subject: RE: [EXTERNAL] Re: Problem starting Tomcat 7.0.59 as a Windows Service

On 1/12/2016 10:04 AM, McDermott, Becky wrote:
> I used the Java options provided by IBM.  Since Tomcat will successfully 
> start using the startup batch files, I assume that these settings are fine.  
> I've tried playing with the settings and cannot get it to work either.  I 
> seems like it's some sort of weird Windows thing.
>
> I have successfully configured these services before with prior version of 
> IBM's CLM.  The difference in those previous versions was that Tomcat came 
> bundled with t heir product.  For this latest IBM version, Tomcat was not 
> bundled and they provided instructions for downloading it from Apache and 
> instructions for where to install it.
>
> I have escalated the issue with IBM's support and since they are providing 
> the JVM, it is probably their issue but wanted to put it out to the larger 
> community to see if anyone has ever had this issue before.  A user on the 
> user forums said that the memory error in the Tomcat log file is a red 
> herring and that it is giving that memory allocation error because the JVM 
> didn't actually start.  So, the issue seems more connected to the error in 
> the Windows Event viewer ("cannot open file").


Hi, Becky-

Have you tried the Tomcat Windows Service Installer available on the download 
page (http://tomcat.apache.org/download-70.cgi)?  In my experience, it makes it 
much easier to get Tomcat up and running as a Windows service.  In addition, a 
configuration app is included which further simplifies the process.

With your current setup, I'd start by checking the Log On settings of the 
service and the permissions of the Tomcat files and folders.

-Terence Bandoian


>
> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Tuesday, January 12, 2016 8:59 AM
> To: Tomcat Users List
> Subject: [EXTERNAL] Re: Problem starting Tomcat 7.0.59 as a Windows 
> Service
>
> Becky,
>
> On 1/12/16 10:42 AM, McDermott, Becky wrote:
>> >I am integrating Tomcat with the IBM CLM 6.0.1 collaboration tools.  Per 
>> >IBM's installation instructions, I downloaded and extracted Tomcat 7.0.59 
>> >to my server.
>> >
>> >I am successfully able to start the Tomcat server from the command line 
>> >using the batch files provided by the IBM application (C:\Program 
>> >Files\IBM\JazzTeamServer_601\server\server.startup.bat).  Tomcat starts as 
>> >well as all of the IBM CLM applications.
>> >
>> >The problem I'm having is when I try to configure tomcat to run as a 
>> >Windows service.  I have followed the instructions provided by IBM:
>> >
>> >
>> >1.   Set the environment variable CATALINA_HOME to C:\Program 
>> >Files\IBM\JazzTeamServer_601\server\tomcat
>> >
>> >2.   Deleted existing tomcat7 services using:  sc delete tomcat7
>> >
>> >3.   Re-booted the machine
> Note that, depending upon how you set the CATALINA_HOME environment variable, 
> rebooting will lose this value. I'm not sure the reboot was necessary.
>
>> >4.   Installed the new tomcat service from the Tomcat bin directory:  
>> >service.bat install tomcat7
>> >
>> >5.   Configured the service using:  tomcat7w.exe
>> >
>> >1.   Clicked "Java" tab
>> >
>> >2.   Cleared "Use default" checkbox
>> >
>> >3.   Added the following path to the Java Virtual machine:  C:\Program 
>> >Files\IBM\JazzTeamServer_601\server\jre\bin\j9vm\jvm.dll
>> >
>> >4.   Added the following lines to the end of the java Options text 
>> >field:
>> >-DJAZZ_HOME=file:///C:/PROGRA~1/IBM/JazzTeamServer_601/server/conf
>> >-Djava.awt.headless=true
>> >-Dorg.eclipse.emf.ecore.plugin.EcorePlugin.doNotLoadResourcesPlugin=
>> >tr ue -Dcom.ibm.team.repository.tempDir=C:\Program
>> >Files\IBM\JazzTeamServer_601\server\tomcat\temp
>> >-Djazz.connector.sslEnabledProtocols=TLSv1.2
>> >-Djazz.connector.algorithm=IbmX509
>> >-Dlog4j.configuration=file:///C:/PROGRA~1/IBM/JazzTeamServer_601/ser
>> >ve
>> >r/conf/startup_log4j.properties
>> >-Xgcpolicy:gencon
>> >-Xcompressedrefs
>> >-Xgc:preferredHeapBase=0x1
>> >-XX:MaxDirectMemorySize=1G
> That's a BIG buffer. Do you need 1G NIO buffers? A web-based video-editing 
> application?
>
>> >-Xmx4G
>> >-Xms4G
>> >-Xmn1g
> What is -Xmn? It's probably not a problem, but I thought I'd point-out 
> something that looks weird.
>
>> >-DORACLE_JDBC_DRIVER_FILE=C:\Program
>> >Files\IBM\JazzTeamServer_601\server\Oracle\ojdb6.jar
>> >
>> >5.   

Client TLS 1.2 error for APR

[Harrie Robins]

Hi!

I'm running Tomcat 7.0.65 with APR connector over port 443. I'm experiencing
trouble with users that connect with IE11 over SSL. Connecting and browsing
works fine, but sometimes a white screen with this error pops up. Once they
disable TLS 1.2 everything works fine:

 

This page can't be displayed

Turn on TLS 1.0, TLS1.1 and TLS 1.2 in Advanced settings and try connecting
to https://sub.example.com again. If this error persists, contact your site
administrator.

 

Right now I'm using SHA-2 encryption (we moved from SHA-1) with A+ rating on
SSLLabs, without any error's.

 

Server.xml configuration. Ciphers following latest intermediate from Mozilla
openssl config:

 



 

Does anyone have a pointer about what could be wrong with this
configuration?

 

Kind regards,

 

Harrie

Re: Tomcat 8.0.30 Session lost

[Christopher Schultz]

Thomas,

On 1/13/16 1:04 PM, Thomas Scheffler wrote:
> Am 13.01.16 um 15:48 schrieb Christopher Schultz:
>> Thomas,
>>
>> On 1/13/16 8:31 AM, Thomas Scheffler wrote:
>>> Am 12.01.16 um 13:24 schrieb Mark Thomas:
 On 12/01/2016 11:06, Thomas Scheffler wrote:
> Am 11.01.16 um 22:05 schrieb Mark Thomas:
>>>
>>> >> className="org.apache.catalina.authenticator.BasicAuthenticator"
>>>  changeSessionIdOnAuthentication="false" />
>>>
>>> Found on
>>> http://www.tomcatexpert.com/blog/2011/04/25/session-fixation-protection
>>>
>>>
>>> the description how to switch the "feature" off.
>>>
>>> I will file two bugs soon describing the issues I had. Hopefully
>>> they
>>> will be fixed.
>>>
>>> 1.) if using HttpServetRequest.login(String, String) further
>>> request in
>>> the session are loosing the users Principal.
>>>
>>> 2.) After changing sessionId, old sessionIds should still be valid
>>> for a
>>> short period of time of to the same client.
>>
>> The second request will get closed as INVALID on security grounds. If
>> the old ID is valid for any period of time it makes a session
>> fixation
>> attack possible. You might as well disable changing the session ID on
>> authentication.
>>
>> For the first the description above isn't clear enough to be sure
>> exactly what you are asking for. However, based on the second request
>> and what I have read of this thread I suspect that request will get
>> closed as INVALID or WONTFIX.
>
> Hi Mark,
>
> if you choose to use login() and this modifies the session ID. Further
> calls to login() should either:
>
> 1.) are not required as every request belonging to the same session
> are
> already authenticated. After login() other request of the same session
> will not return 'null' on getRemoteUser() or getUserPrincipal()
>
> 2.) are not required, as authenticate() use the information
> provided by
> the first login() call.
>
> 3.) do not modify the session ID as the same user was authenticated
> before and the session is therefor safe to session fixation attacks

 Those 3 all boil down to essentially the same requirement.

 Requests are populated with cached authentication information from the
 session at the start of the request (if the authenticator is configured
 to do so - all but DIGEST are by default).
>>>
>>> Hi,
>>>
>>> "all but DIGEST are by default" was my case.
>>>
>>> As I walked through the code I found most of the features I requested
>>> are already in place. There is already the tracking of the Principal in
>>> the session. To use the values of login() later in authenticate() in
>>> Tomcat 8.0.30 I had to insert "/foo" as my login page and "/bar" as my
>>> login-error-page. I think any value will do here ;-)
>>>
>>> 
>>> FORM
>>> Restricted
>>> 
>>> /foo
>>> /bar
>>> 
>>> 
>>>
>>> This activates the FormAuthenticator which correctly does, what I was
>>> hoping for.
>>>
>>> I think every authenticator can/should use the information stored by
>>> login() if it is available.
>>
>> Which argument to login() carries the server-generated nonce used for
>> login? Which argument includes the realm name?
>>
>> https://en.wikipedia.org/wiki/Digest_access_authentication
> 
> Hi Chris,
> 
> the login() method gets the username and the password. It has nothing to
> do with configured auth-method in the web.xml.

I'm familiar with this method and how it works.

> Tomcat uses a generic
> method[1] located in a super class do perform the login. The Principal
> is stored in the session, if caching is enabled and a session is present
> or created.
> Depending on the configured auth-method the Principal is used later, if
> found or not. My suggestion was to always use it, when it is stored in
> the session.

Tomcat can't verify that the incoming credentials match those
credentials that were used in a previous login. How could Tomcat decide
if new credentials were being used if Tomcat doesn't actually try to use
them?

Then, if Tomcat uses the credentials and they are valid, the session id
must be changed for session-fixation prevention.

If there is a difference between the BasicAuthenticator and the
DigestAuthenticator, then that gap should probably be closed.

-chris

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

Re: Parameter handling on forward

[Christopher Schultz]

All,

On 1/11/16 9:21 PM, Mark Olsson wrote:
> Adding = to a parameter does cause it to be available to the destination
> servlet, but that doesn't seem like a particularly good solution.  A
> parameter without a value is technically a keyless value, not the other way
> around.  But I'll stick to the servlet terminology of calling them
> parameter names and values since request.getParameterNames and
> getParameterMap both return them as "Names" and not a value without a
> name.  Parameters without a value (keyless value) are widely used and
> within spec without having to add the =.
> 
> I wrote a couple of servlets and have been able to narrow down the problem
> to take form POST data out of the equation, but not been able to find a
> solution yet.  I'm even more convinced that
> getRequestDispatcher().forward() or the receiving servlet are borking the
> parameters.
> 
> This works:
> Directly access /page1?a=1=3
> The request arrives at the servlet with all 4 parameters, a and c have
> values, b and d don't but are in the parameter names list.
> 
> This doesn't work:
> request.getRequestDispatcher("/page1?a=1=3").forward(request,
> response);
> The request arrives at the servlet with only the parameters a and c, not b
> and d.  All 4 parameters are in the query string, but b and d are not in
> the parameter names list or map.
> 
> Seems to me that if the exact same servlet can accept parameters without a
> value on a direct request, but fails on only some parameters when it's from
> a request dispatcher that something is wrong where the parameters are
> gathered the second time, or somewhere before they are made available to
> the destination.

For the benefit of the archives:
https://bz.apache.org/bugzilla/show_bug.cgi?id=58836

This issue was raised in BZ and will be fixed in Tomcat 8.0.31 as well
as others. See the bug for details.

Thanks, Mark, for the bug report and the test case.

-chris

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

Re: troughput difference

[Rafael Oliveira de Mattos]

Ok,

Sorry for taking so long to answer, we are using this versions in a production 
enviroment (one server, to just selected users).

So we solved our problem, we changed the jsp-api that tomcat uses, we are using 
the jsp-api 2.2 from glassfish (we are still studying the side effects from 
that change). After we profile, our thread dumps showed that 60% of the time of 
the request were spended in tag.service methods. At first we thought that the 
error was in our code, but we didnt change anything in the jsp's. So after 
searching for the problem, we find this bug report 
https://bz.apache.org/bugzilla/show_bug.cgi?id=57583. With the glassfish 
version we are faster then ever, but we afraid of the side effects this can 
have.







- Mensagem original -
De: "Christopher Schultz" 
Para: "Tomcat Users List" 
Enviadas: Quinta-feira, 24 de dezembro de 2015 15:28:49
Assunto: Re: troughput difference

Aurélien,

On 12/24/15 4:17 AM, Aurélien Terrestris wrote:
> probably this won't solve your problem but I notice that the random seems
> slow :
> Creation of SecureRandom instance for session ID generation using
> [SHA1PRNG] took [9,870] milliseconds.
> 
> Maybe should you then start by fixing this, it has been discussed many
> times on the mailing list ( securerandom.source=file:/dev/./urandom )

Once Tomcat starts up, it should go fairly quickly. I don't know how
often SecureRandom re-seeds itself (or even if it does), but you only
need entropy during the seeding process. It shouldn't have any effect on
the throughput of a few thousand requests.

> Maybe are there some tests to do to understand if your Tomcat 6 seems fast
> because it uses some caching somewhere, or on the contrary if your Tomcat 8
> is slow because there is a bottleneck.
> I would try one scenario with one small HTML page requested thousands of
> times, and one very big file requested just 2 or 3 times, and compare
> results.
> 
> One thing which could help in understanding, have a look at the status
> servlet which gives statistics (
> http://tomcat.apache.org/tomcat-7.0-doc/apr.html )

Rafael, I'm curious: what is your testing procedure?

-chris

-
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: Client TLS 1.2 error for APR

[Mark Thomas]

On 13/01/2016 18:36, Harrie Robins wrote:
> Hi!
> 
> I'm running Tomcat 7.0.65 with APR connector over port 443.

Tomcat version - tick
Connector config - tick
Tomcat-Native version ... ?

Mark

> I'm experiencing
> trouble with users that connect with IE11 over SSL. Connecting and browsing
> works fine, but sometimes a white screen with this error pops up. Once they
> disable TLS 1.2 everything works fine:
> 
>  
> 
> This page can't be displayed
> 
> Turn on TLS 1.0, TLS1.1 and TLS 1.2 in Advanced settings and try connecting
> to https://sub.example.com again. If this error persists, contact your site
> administrator.
> 
>  
> 
> Right now I'm using SHA-2 encryption (we moved from SHA-1) with A+ rating on
> SSLLabs, without any error's.
> 
>  
> 
> Server.xml configuration. Ciphers following latest intermediate from Mozilla
> openssl config:
> 
>  
> 
>  
> protocol="org.apache.coyote.http11.Http11AprProtocol"
> 
> connectionTimeout="6000"
> 
> maxThreads="500"
> 
> maxKeepAliveRequests="-1"
> 
> acceptCount="200"
> 
> SSLEnabled="true"
> 
> scheme="https"
> 
> secure="true"
> 
> clientAuth="false"
> 
> enableLookups="false"
> 
> SSLCertificateFile="C:\server\ssl\server.crt"
> 
> SSLCertificateKeyFile="C: \server\ssl\private.key"
> 
> SSLCACertificateFile="C: \server\ssl\intermediate.crt"
> 
> SSLPassword="passw"
> 
> SSLProtocol="all -SSLv2-SSLv3"
> 
> SSLHonorCipherOrder="true"
> SSLCipherSuite="ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:EC
> DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-S
> HA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-EC
> DSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES2
> 56-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-
> SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-A
> ES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-
> GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DE
> S-CBC3-SHA:TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA:TLS_ECDHE_RSA_WITH_AES_128_CBC
> _SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:
> !EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!DHE:!EDH"
> 
> />
> 
>  
> 
> Does anyone have a pointer about what could be wrong with this
> configuration?
> 
>  
> 
> Kind regards,
> 
>  
> 
> Harrie
> 
> 


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

Re: Tomcat 8 Application dispatcherServlet Stats

[Kyohei Nakamura]

Hello

The "Processing time" metric represents the execution time of
StandardWrapperValve#invoke().
This is the execution time of the servlet and filters.
This value of "Processing time" is the total time of each request execution
time.

What is the dispatcherServlet?
If dispatcherServlet accept all request as a front controller(like Spring's
DispatcherServlet), then this value is the total execution time of all
request that the context receive.


2016-01-13 20:19 GMT+09:00 Theo Sweeny :

> Hello - at the moment stats can be found for Tomcat 8 web services using
> the manager UI /manager/status/all
>
> Is the "Processing time" metric found under dispatcherServlet [ / ]
> subsection, the total time take to serve all requests, including the
> response time for each request?
>
> Regards,
>
> Theo
> Avios Group (AGL) Ltd is a limited company registered in England
> (registered number 2260073 and VAT number 512566754) whose registered
> address is Astral Towers, Betts Way, London Road, Crawley, West Sussex RH10
> 9XY . Avios Group (AGL) Limited is part of the IAG group of companies This
> email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the system manager.
>

Re: Parameter handling on forward

[Mark Olsson]

On Wed, Jan 13, 2016 at 12:20 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> All,
> For the benefit of the archives:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=58836
>
> This issue was raised in BZ and will be fixed in Tomcat 8.0.31 as well
> as others. See the bug for details.
>
> Thanks, Mark, for the bug report and the test case.
>
> -chris
>
>
I'm relieved it was a real bug and not me doing something embarrassingly
stupid.

RE: Client TLS 1.2 error for APR

[Harrie Robins]

Hi Markt,

Sorry, I did not include this since I'm using standard in release (1.1.33).
I know of the more recent releases, but I can't just update (production),
and in release note's I did  not find anything that might help.

Thanks,

Harrie

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: woensdag 13 januari 2016 20:59
To: Tomcat Users List 
Subject: Re: Client TLS 1.2 error for APR

On 13/01/2016 18:36, Harrie Robins wrote:
> Hi!
> 
> I'm running Tomcat 7.0.65 with APR connector over port 443.

Tomcat version - tick
Connector config - tick
Tomcat-Native version ... ?

Mark

> I'm experiencing
> trouble with users that connect with IE11 over SSL. Connecting and 
> browsing works fine, but sometimes a white screen with this error pops 
> up. Once they disable TLS 1.2 everything works fine:
> 
>  
> 
> This page can't be displayed
> 
> Turn on TLS 1.0, TLS1.1 and TLS 1.2 in Advanced settings and try 
> connecting to https://sub.example.com again. If this error persists, 
> contact your site administrator.
> 
>  
> 
> Right now I'm using SHA-2 encryption (we moved from SHA-1) with A+ 
> rating on SSLLabs, without any error's.
> 
>  
> 
> Server.xml configuration. Ciphers following latest intermediate from 
> Mozilla openssl config:
> 
>  
> 
>  
> protocol="org.apache.coyote.http11.Http11AprProtocol"
> 
> connectionTimeout="6000"
> 
> maxThreads="500"
> 
> maxKeepAliveRequests="-1"
> 
> acceptCount="200"
> 
> SSLEnabled="true"
> 
> scheme="https"
> 
> secure="true"
> 
> clientAuth="false"
> 
> enableLookups="false"
> 
> SSLCertificateFile="C:\server\ssl\server.crt"
> 
> SSLCertificateKeyFile="C: \server\ssl\private.key"
> 
> SSLCACertificateFile="C: \server\ssl\intermediate.crt"
> 
> SSLPassword="passw"
> 
> SSLProtocol="all -SSLv2-SSLv3"
> 
> SSLHonorCipherOrder="true"
> SSLCipherSuite="ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA
> 256:EC 
> DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128
> -GCM-S 
> HA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:EC
> DHE-EC
> DSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RS
> A-AES2
> 56-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-A
> ES256- 
> SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE
> -RSA-A
> ES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:A
> ES256- 
> GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMEL
> LIA:DE 
> S-CBC3-SHA:TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA:TLS_ECDHE_RSA_WITH_AES_1
> 28_CBC
>
_SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:
> !EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!DHE:!EDH"
> 
> />
> 
>  
> 
> Does anyone have a pointer about what could be wrong with this 
> configuration?
> 
>  
> 
> Kind regards,
> 
>  
> 
> Harrie
> 
> 


-
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: Error deploying WAR

[George Sexton]

Chris,

On 1/12/2016 10:26 AM, Christopher Schultz wrote:

Mark,

On 1/12/16 12:03 PM, Mark Thomas wrote:

On 12/01/2016 16:40, George Sexton wrote:

I'm hitting an error, and I'm not sure how to fix it. The environment is:

Check the JARs in WEB-INF/lib for any javax.servlet classes. There
should not be any. You might as well check WEB-INF/classes while you are
at it.

If any JARs have been added to $CATALINA_BASE/lib then check them too.

I see these problems when using Eclipse and extracting .class files
while Eclipse is trying to figure out something like a new .jar file
being added or something that requires a complete rebuild.


Thanks. You were right on. In the Eclipse project, there were some kind 
of strange errors. I googled, did the "right click and select Quick Fix" 
thing and that got it I'm not really an Eclipse person. I use an editor 
call SlickEdit (windows and Linux) with ant to build things, so it was 
kind of new to me.






Eclipse, rather than failing to create a .class file, will instead
create a .class file that has a static initializer that looks something
like this:

static {
throw new Error("Can't compile class: [errors]");
}

So you have a valid .class file but it will bomb every time.

Reasonable people can disagree over whether this is good or bad behavior
(but I say it's bad).

George, the upshot is that you will almost certainly have to re-build
your WAR. Try doing a completely clean build if your application and try
again with a fresh WAR.

-chris


OS: Ubuntu Linux
Tomcat: 6.0.44
JVM: Sun 1.6.0.22
CATALINA_HOME/CATALINA_BASE configuration


The client reports that this system has worked in the past. Their
original production system was running 6.0.18 using a distribution
specific installation of tomcat, so I made a clean install of tomcat
6.0.44 using downloaded binaries and made a new, minimalist
CATALINA_HOME/CATALINA_BASE.

I admit, I'm not an expert on Spring, so I'm mystified as to why it's
not going. I've searched the internet for relevant things but all I can
find are articles that talk about eclipse and adding servlet-api.jar to
the compilation path.

Help!



INFO: Initializing Spring FrameworkServlet 'freightrates'
Jan 12, 2016 9:27:17 AM org.apache.catalina.core.ApplicationContext log
SEVERE: StandardWrapper.Throwable
org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'urlMapping' defined in ServletContext resource
[/WEB-INF/freightrates-servlet.xml]: Initialization of bean failed;
nested exception is
org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'freightRates' defined in ServletContext resource
[/WEB-INF/freightrates-servlet.xml]: Instantiation of bean failed;
nested exception is
org.springframework.beans.BeanInstantiationException: Could not
instantiate bean class
[com.xxx.freight.web.controller.FreightRatesController]: Constructor
threw exception; nested exception is java.lang.Error: Unresolved
compilation problems:
 The import javax.servlet.http.HttpServletRequest cannot be resolved
 The import javax.servlet.http.HttpServletResponse cannot be
resolved
 The method onSubmit(HttpServletRequest, HttpServletResponse,
Object, BindException) of type FreightRatesController must override or
implement a supertype method
 HttpServletRequest cannot be resolved to a type
 HttpServletResponse cannot be resolved to a type
 HttpServletRequest cannot be resolved to a type
 HttpServletRequest cannot be resolved to a type
 HttpServletRequest cannot be resolved to a type
 The method showForm(HttpServletRequest, HttpServletResponse,
BindException, Map) of type FreightRatesController must override or
implement a supertype method
 HttpServletRequest cannot be resolved to a type
 HttpServletResponse cannot be resolved to a type
 The method referenceData(HttpServletRequest, Object, Errors) of
type FreightRatesController must override or implement a supertype method
 HttpServletRequest cannot be resolved to a type
 The method isFormChangeRequest(HttpServletRequest, Object) of
type FreightRatesController must override or implement a supertype method
 HttpServletRequest cannot be resolved to a type
 The method onFormChange(HttpServletRequest, HttpServletResponse,
Object, BindException) of type FreightRatesController must override or
implement a supertype method
 HttpServletRequest cannot be resolved to a type
 HttpServletResponse cannot be resolved to a type

 at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:480)

 at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:409)




-
To unsubscribe, e-mail: 

Re: First DB Pool connection returns stale data?

[Christopher Schultz]

Brian,

On 1/11/16 5:14 PM, Tieman,Brian wrote:
> I¹ve got a REST service that¹s backed by Hibernate calling MYSQL and using
> org.apache.tomcat.jdbc.pool.DataSourceFactory for DB connections.  The
> connection pool is created with:
> 
>username=³me" password=³my password"
>   factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
>   name=³jdbc/MyDB"
>   type="javax.sql.DataSource"
>   url="jdbc:mysql://my.database.net"
>   validationQuery="select 1"
>   validationQueryTimeout="60"
>   testOnBorrow="true"
>   testWhileIdle="true"
>   removeAbandoned="true"
>   removeAbandonedTimeout="30"
>   suspectTimeout="15"
>   logAbandoned="true"
>   timeBetweenEvictionRunsMillis="5000"
>   minEvictableIdleTimeMillis="6"
>   validationInterval="3"
>   />

Hibernate is not involved in the above configuration. Is that what you
were expecting?

> It looks like the first record retrieved from the service is being stored
> somehow.

tomcat-jdbc definitely does not cache records.

> I can alter the data retrieved by the first select but I¹ll
> occasionally get the initial data back on a subsequent selects.  After
> much troubleshooting, it feels like the stale data is returned only when
> my select is performed with the same connection (from the pool) as the
> first select since the service started.  I don¹t know how to tell for sure
> that the initial connection is the one holding onto old data but the old
> data is always the first data I¹ve read and it will be returned seemingly
> randomly although the data in the underlying database is correct and we
> have no caching turned on in hibernate.

What happens if you issue a raw JDBC SELECT from a pooled connection
without using hibernate?

> My test procedure has been:
> 
> 1) Start service
> 2) Read record
> 3) Change record
> 4) Read record
> 5) Repeat 4
> 
> 
> If nothing else is hitting the service (no concurrency) I never see stale
> data.  It¹s only when other clients are hitting the service that I
> randomly get stale data returned.  The stale data is always the first
> record read and is only returned when attempting to read that record again.
> 
> Has anyone ever seen anything like this?  Ideas on where to troubleshoot?

I've never seen anything like this, but I've never used hibernate. My
knee-jerk reaction is that this is Hibernate-related, but you could also
be using Hibernate incorrectly. What's the smallest test case you can
built that still demonstrates this behavior?

-chris

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

Re: property replacement in WEB-INF/web.xml

[Christopher Schultz]

André,

On 1/13/16 9:36 AM, André Warnier (tomcat) wrote:
> Hi gurus.
> 
> Under tomcat 8 and Linux, I am deploying an externally-provided web
> application, which in its web.xml configuration file, has a parameter
> like this :
> 
> 
>   logroot
>   /var/log/tomcat8
> 
> 
> This works, but I would like to make this more "generic", and would like
> to replace the above param-value by something like this :
> 
> 
>   logroot
>   ${CATALINA_BASE}/logs
> 
> 
> with CATALINA_BASE being the well-known environment value set prior to
> starting (the JVM which runs) Tomcat (and "${CATALINA_BASE}/logs" being
> actually a link which points to "/var/log/tomcat8" in this case).
> 
> Can I do this ? and if yes, what is the exact way to do this right ?
> 
> (In a log4j configuration file, I can use "${env:CATALINA_BASE}" for
> this, but this is not available under Tomcat, or is it ?)

I think you want to use the system property version of that value, which is:


  logroot
  

Re: Tomcat 8.0.30 Session lost

[Christopher Schultz]

Thomas,

On 1/13/16 8:31 AM, Thomas Scheffler wrote:
> Am 12.01.16 um 13:24 schrieb Mark Thomas:
>> On 12/01/2016 11:06, Thomas Scheffler wrote:
>>> Am 11.01.16 um 22:05 schrieb Mark Thomas:
>
>  className="org.apache.catalina.authenticator.BasicAuthenticator"
> changeSessionIdOnAuthentication="false" />
>
> Found on
> http://www.tomcatexpert.com/blog/2011/04/25/session-fixation-protection
>
> the description how to switch the "feature" off.
>
> I will file two bugs soon describing the issues I had. Hopefully they
> will be fixed.
>
> 1.) if using HttpServetRequest.login(String, String) further
> request in
> the session are loosing the users Principal.
>
> 2.) After changing sessionId, old sessionIds should still be valid
> for a
> short period of time of to the same client.

 The second request will get closed as INVALID on security grounds. If
 the old ID is valid for any period of time it makes a session fixation
 attack possible. You might as well disable changing the session ID on
 authentication.

 For the first the description above isn't clear enough to be sure
 exactly what you are asking for. However, based on the second request
 and what I have read of this thread I suspect that request will get
 closed as INVALID or WONTFIX.
>>>
>>> Hi Mark,
>>>
>>> if you choose to use login() and this modifies the session ID. Further
>>> calls to login() should either:
>>>
>>> 1.) are not required as every request belonging to the same session are
>>> already authenticated. After login() other request of the same session
>>> will not return 'null' on getRemoteUser() or getUserPrincipal()
>>>
>>> 2.) are not required, as authenticate() use the information provided by
>>> the first login() call.
>>>
>>> 3.) do not modify the session ID as the same user was authenticated
>>> before and the session is therefor safe to session fixation attacks
>>
>> Those 3 all boil down to essentially the same requirement.
>>
>> Requests are populated with cached authentication information from the
>> session at the start of the request (if the authenticator is configured
>> to do so - all but DIGEST are by default).
> 
> Hi,
> 
> "all but DIGEST are by default" was my case.
> 
> As I walked through the code I found most of the features I requested
> are already in place. There is already the tracking of the Principal in
> the session. To use the values of login() later in authenticate() in
> Tomcat 8.0.30 I had to insert "/foo" as my login page and "/bar" as my
> login-error-page. I think any value will do here ;-)
> 
> 
> FORM
> Restricted
> 
> /foo
> /bar
> 
> 
> 
> This activates the FormAuthenticator which correctly does, what I was
> hoping for.
> 
> I think every authenticator can/should use the information stored by
> login() if it is available.

Which argument to login() carries the server-generated nonce used for
login? Which argument includes the realm name?

https://en.wikipedia.org/wiki/Digest_access_authentication

-chris

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

Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]

[Christopher Schultz]

Rahul,

On 1/12/16 10:56 PM, Rahul Singh wrote:
> Hi,
> 
>> Define "Not successful"?  Exceptions thrown?  File truncated?  Upload
>> never starts?  Never finishes?
> 
> Not successful :
> 
> Request Never finishes, we have trace the HttpServlet request object
> and request.getContentLength return 0 in case when file size is >=2GB,
> 
> No exception thrown, as well as when file size is less than 2GB, then
> request.getContentLength return the correct value of file size in
> byte.

ServletRequest.getContentLength is declared to return an int value (32-bit):

* Integer.MAX_VALUE  = 2^31 - 1 = 2147483647
* 2GiB = 2 * 1024 * 1024 * 1024 = 2147483648
* 2147483648 > 2147483647

Therefore, request.getContentLength cannot be used to fetch
content-lengths over 2GiB - 1byte. You have to use
ServletRequest.getContentLengthLong (new in servlet 3.1) or call
HttpServletRequest.getHeader("Content-Length") as a String and parse it
yourself.

-chris

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

property replacement in WEB-INF/web.xml

[tomcat]

Hi gurus.

Under tomcat 8 and Linux, I am deploying an externally-provided web application, which in 
its web.xml configuration file, has a parameter like this :



  logroot
  /var/log/tomcat8


This works, but I would like to make this more "generic", and would like to replace the 
above param-value by something like this :



  logroot
  ${CATALINA_BASE}/logs


with CATALINA_BASE being the well-known environment value set prior to starting (the JVM 
which runs) Tomcat (and "${CATALINA_BASE}/logs" being actually a link which points to 
"/var/log/tomcat8" in this case).


Can I do this ? and if yes, what is the exact way to do this right ?

(In a log4j configuration file, I can use "${env:CATALINA_BASE}" for this, but this is not 
available under Tomcat, or is it ?)



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

Re: Tomcat 8.0.30 Session lost

[Thomas Scheffler]

Am 13.01.16 um 15:48 schrieb Christopher Schultz:

Thomas,

On 1/13/16 8:31 AM, Thomas Scheffler wrote:

Am 12.01.16 um 13:24 schrieb Mark Thomas:

On 12/01/2016 11:06, Thomas Scheffler wrote:

Am 11.01.16 um 22:05 schrieb Mark Thomas:




Found on
http://www.tomcatexpert.com/blog/2011/04/25/session-fixation-protection

the description how to switch the "feature" off.

I will file two bugs soon describing the issues I had. Hopefully they
will be fixed.

1.) if using HttpServetRequest.login(String, String) further
request in
the session are loosing the users Principal.

2.) After changing sessionId, old sessionIds should still be valid
for a
short period of time of to the same client.


The second request will get closed as INVALID on security grounds. If
the old ID is valid for any period of time it makes a session fixation
attack possible. You might as well disable changing the session ID on
authentication.

For the first the description above isn't clear enough to be sure
exactly what you are asking for. However, based on the second request
and what I have read of this thread I suspect that request will get
closed as INVALID or WONTFIX.


Hi Mark,

if you choose to use login() and this modifies the session ID. Further
calls to login() should either:

1.) are not required as every request belonging to the same session are
already authenticated. After login() other request of the same session
will not return 'null' on getRemoteUser() or getUserPrincipal()

2.) are not required, as authenticate() use the information provided by
the first login() call.

3.) do not modify the session ID as the same user was authenticated
before and the session is therefor safe to session fixation attacks


Those 3 all boil down to essentially the same requirement.

Requests are populated with cached authentication information from the
session at the start of the request (if the authenticator is configured
to do so - all but DIGEST are by default).


Hi,

"all but DIGEST are by default" was my case.

As I walked through the code I found most of the features I requested
are already in place. There is already the tracking of the Principal in
the session. To use the values of login() later in authenticate() in
Tomcat 8.0.30 I had to insert "/foo" as my login page and "/bar" as my
login-error-page. I think any value will do here ;-)


FORM
Restricted

/foo
/bar



This activates the FormAuthenticator which correctly does, what I was
hoping for.

I think every authenticator can/should use the information stored by
login() if it is available.


Which argument to login() carries the server-generated nonce used for
login? Which argument includes the realm name?

https://en.wikipedia.org/wiki/Digest_access_authentication


Hi Chris,

the login() method gets the username and the password. It has nothing to 
do with configured auth-method in the web.xml. Tomcat uses a generic 
method[1] located in a super class do perform the login. The Principal 
is stored in the session, if caching is enabled and a session is present 
or created.
Depending on the configured auth-method the Principal is used later, if 
found or not. My suggestion was to always use it, when it is stored in 
the session.

Hope this clarifies my summary.

Thomas

[1] org.apache.catalina.authenticator.AuthenticatorBase.doLogin(Request, 
String, String)


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