RE: Regarding context.xml changes impact other web service not deployed

[S Abirami]

Hi Mark Thomas,

Thanks a lot for the information.
Answers for your question

In which context.xml file? The global one, the host one or a web application 
specific one?
I have changed in global context.xml which is located in conf/context.xml.

Regards,
Abirami.S
-Original Message-
From: Mark Thomas  
Sent: Tuesday, June 9, 2020 1:50 PM
To: users@tomcat.apache.org
Subject: Re: Regarding context.xml changes impact other web service not deployed

On 09/06/2020 06:59, S Abirami wrote:
> Hi Team,
> 
>  In our product to address security vulnerability in context.xml, 
> we have introduced following entry
> 
>  

In which context.xml file? The global one, the host one or a web application 
specific one?

> After introducing the above line, I noticed few rest service which is not 
> deployed in that Tomcat also getting impact.

I'd guess not a web application specific one the

> Deployment Details
> 
> Deployed :RHEL
> Tomcat Installation format :  tar.gz
> 
> Hence,  interested to know about the internal implementation of the context 
> in Tomcat to understand the impact.

Global web.xml provides defaults for all web applications.

Host level provides defaults for all web applications in a given host.

Web application provides settings for just that web application.

Don't add  elements to server.xml

Settings in more specific files take priority.

Mark

-
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: Regarding context.xml changes impact other web service not deployed

[S Abirami]

Hi Luis,

Thanks for the information.

My question is mainly whether the changes in context.xml will impact the web 
application, which is not deployed in the Tomcat.

From Mark reply, I understood that the changes in context.xml will impact the 
web application even though it is not deployed in Tomcat.

Regards,
Abirami.S

-Original Message-
From: Luis Rodríguez Fernández  
Sent: Tuesday, June 9, 2020 12:33 PM
To: Tomcat Users List 
Subject: Re: Regarding context.xml changes impact other web service not deployed

Hello Abirami,

Well, strict does what it promises, so if those third-party rest services were 
expecting some cookies that now are not being sent by the browser, it is normal 
that they do not work as expected.

Internal implementation: sure! You can always have a look at the code of the 
different CookieProcessors [1] & [2]

Hope it helps,

Luis

[1]
https://protect2.fireeye.com/v1/url?k=05de6036-5b7ea273-05de20ad-86b568293eb5-4944602a8cd168fc=1=1f87817f-d293-4635-8855-bd59ff97ee4b=https%3A%2F%2Fgithub.com%2Fapache%2Ftomcat%2Fblob%2Ff3c9fdd40bdbc3dc22b512596954e2bc6d424d5a%2Fjava%2Forg%2Fapache%2Ftomcat%2Futil%2Fhttp%2FRfc6265CookieProcessor.java
[2]
https://protect2.fireeye.com/v1/url?k=1f48aa13-41e86856-1f48ea88-86b568293eb5-6b24c935f0126d6d=1=1f87817f-d293-4635-8855-bd59ff97ee4b=https%3A%2F%2Fgithub.com%2Fapache%2Ftomcat%2Fblob%2F623b2c9d0997481f1c5229135fa2f92e24303e47%2Fjava%2Forg%2Fapache%2Ftomcat%2Futil%2Fhttp%2FLegacyCookieProcessor.java



El mar., 9 jun. 2020 a las 7:59, S Abirami ()
escribió:

> Hi Team,
>
>  In our product to address security vulnerability in context.xml, 
> we have introduced following entry
>
>  
>
>
> After introducing the above line, I noticed few rest service which is 
> not deployed in that Tomcat also getting impact.
>
> Deployment Details
>
> Deployed :RHEL
> Tomcat Installation format :  tar.gz
>
> Hence,  interested to know about the internal implementation of the 
> context in Tomcat to understand the impact.
>
> Thanks in advance for the support.
>
> Regards,
> Abirami.S
>
>
>
>
>
>

-- 

"Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better."

- Samuel Beckett

Re: Should Tomcat 10 enable response compression by default?

[Manuel Dominguez Sarmiento]

I would not change this default. GZIP (or other kinds) of response 
compression are better addressed as servlet filters. Having the Tomcat 
feature is good, but IMHO it should only be enabled by those who need it.


At least in our case we have our own code to deal with this, considering 
proxying, CDN, buggy browsers, etc.


*Manuel Dominguez Sarmiento*

On 09/06/2020 17:20, Mark Thomas wrote:

Hi all,

An enhancement has been opened to enable response compression by default:
https://bz.apache.org/bugzilla/show_bug.cgi?id=64431

In short, the proposal is to change the default for the Connector's
compression attribute from "off" to "on".

This would be for Tomcat 10 onwards only.

The following would be unchanged:
- compressibleMimeType
- compressionMinSize
- noCompressionStrongETag

It would be helpful to know what the range of views of the user
community are on this proposal.

So, thoughts?

Mark

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

Should Tomcat 10 enable response compression by default?

[Mark Thomas]

Hi all,

An enhancement has been opened to enable response compression by default:
https://bz.apache.org/bugzilla/show_bug.cgi?id=64431

In short, the proposal is to change the default for the Connector's
compression attribute from "off" to "on".

This would be for Tomcat 10 onwards only.

The following would be unchanged:
- compressibleMimeType
- compressionMinSize
- noCompressionStrongETag

It would be helpful to know what the range of views of the user
community are on this proposal.

So, thoughts?

Mark

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

Re: Tomcat 9.0.0 multiple thread issue

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ripu,

On 6/9/20 08:03, Ripu Daman wrote:
> Hello everyone,
>
> I work in an IT firm as a software engineer. I don't know whether
> it's a right platform to ask questions based on personal projects
> but i believe i will get some help from here.
>
> We are facing an issue regarding multiple threads being created for
> a servlet execution running in tomcat 9.0.0
>
> Servlet's job is to publish customer leads to salesforce via soap
> protocol. The logic has been designed in such a way that in a
> single thread it can publish multiple leads to salesforce one by
> one. However we recently migrated our java application to
> kubernetes adopting containerized approach. Post this we are facing
> an issue in which, when the process starts publishing leads to
> salesforce one by one, after a few uploads a new thread gets
> created and it starts the whole process from beginning and then
> after a few seconds another thread kicks off repeating the whole
> process. It keeps going on until session timeout exceeds and we get
> a 504 error. But the upload process keeps going on in the
> background and stops after 2-3 threads.

Where is your queue stored?

> Before moving to kubernetes, the process was working fine. In order
> to serve multiple requests at the same time, servlet is not
> designed to be thread safe.

It's NOT designed to be thread-safe? I hope you meant it IS designed
to be thread-safe.

> But now we are facing this issue and unable to identify the root
> cause.
>
> Here's a sample of threads from the logs : [http-nio-8080-exec-9]
> INFO [http-nio-8080-exec-9] INFO [http-nio-8080-exec-9] INFO
> [http-nio-8080-exec-7] INFO [http-nio-8080-exec-7] INFO
> [http-nio-8080-exec-9] INFO [http-nio-8080-exec-9] INFO
>
> [http-nio-8080-exec-7] INFO [http-nio-8080-exec-7] INFO
> [http-nio-8080-exec-7] INFO [http-nio-8080-exec-3] INFO
> [http-nio-8080-exec-7] INFO [http-nio-8080-exec-3] INFO

These are request-processing threads, so something is making HTTP
requests to Tomcat to do that work.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7fvbEACgkQHPApP6U8
pFi9Uw/+O9Be+Bp7n8co6Rz7gkvtXZbKT5KlxpWtT3gVNluN4Lt824Hgb5C7wmMd
AjZfvFO0yn1rIJsY+G0r/25lsdIVLZZW3ehM28eRgc+Up3sI66w8zvnOGhly7E6f
CKvSKkINLrS9+BQ0HrLkqHxn+U4y2Ts8yfRZOelC8dGtFfj+U3cSsc75LGMUiREM
SlYabv4dDzemfBqG/08zXfQ+laQStg9Cf+rY//ZZGnLWR74obJJB/rlhrNMAzND0
qR5Z0LebYXGQEt6nElYtDtAosJlnlpX30fLX6aVwwIXfgPqeIgBF9PskIfwx1NU5
sF3nIHO4wE+KsMqM22fqMOU6keBR/Ac8ktMEws/d6PEL1oXUhcsXMTulh6RrxHWA
ImTlksYyIp54flIw3cwiooVW1VrgYQisIIucsWPzLSw7QsE9CyZADqYYm6N7Eo60
VpdHAOLTX4zfJoMlf7NWuMdK8dFI8wkLUmCURxYkWysWx+MJ55BDgDy9kTw3QZoa
lBZs9bPirGU8r7qmjbrj5L/Q0lpeqQSSj9ixBzAJKGBAYzYJHKWPpOcI2NW1hn6F
vUi01xB67zXboH1EcLVHqMc9srA5UjaDKzwnCcwde1kBaxRbwHFIOq1s+BflXdEc
69gaaPqifMnp1pLaJoonPDyZ3QszSAm5SiUi6lKmofF0UBqTzYs=
=SxID
-END PGP SIGNATURE-

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

Re: File access error on Windows Server 2019 after upgrading to Tomcat 8.5.45

[Bill Stewart]

On Tue, Jun 9, 2020 at 9:56 AM calder wrote:

> A bit off-topic, but wanted to jump in and clear this up, as the Java
> error messages are somewhat misleading.

Thanks for the clarification.

Regards

Bill

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

RE: File access error on Windows Server 2019 after upgrading to Tomcat 8.5.45

[jonmcalexander]

Mark,

Was the change with 8.5.44 implemented when you run the service.bat file?

Thanks,


Dream * Excel * Explore * Inspire
Jon McAlexander
Asst Vice President

Middleware Product Engineering
Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com


This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.


-Original Message-
From: Mark Thomas  
Sent: Tuesday, June 9, 2020 8:46 AM
To: users@tomcat.apache.org
Subject: Re: File access error on Windows Server 2019 after upgrading to Tomcat 
8.5.45

On 08/06/2020 22:54, BOSECKER Nancy wrote:
> I've been tasked with upgrading Tomcat from 8.5.41, but have run into a 
> problem that begins with release 8.5.45. Hopefully someone here can help.

What was the last version where this worked? 8.5.43? I ask as 8.5.44 was not 
formally released.

> I have a servlet that tries to update a file that was previously written by a 
> separate servlet. Prior to 8.5.45, this works as expected and the file is 
> updated.
> 
> In 8.5.45, I get the Java error: File not Found exception - Access is denied. 
> The file exists and is readable, but must be being held onto by some unknown 
> process. I've tried Windows process manager and resource manager, but neither 
> of these can tell me what is holding the file handle. I can open the file in 
> an editor with no error. I can also delete the file without any error.
> 
> Note that the error occurs on Windows Server 2019. When I run the same code 
> on Windows 10 there is no error.

This might be related to the user Tomcat is running under. As of 8.5.44 the 
default user is LocalService rather than LocalSystem. LocalService has fewer 
privileges.

Mark

-
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: File access error on Windows Server 2019 after upgrading to Tomcat 8.5.45

[BOSECKER Nancy]

> I've been tasked with upgrading Tomcat from 8.5.41, but have run into a 
> problem that begins with release 8.5.45. Hopefully someone here can help.
>>What was the last version where this worked? 8.5.43? I ask as 8.5.44 was not 
>>formally released.

8.5.43 worked, 8.5.45 does not.

>>This might be related to the user Tomcat is running under. As of 8.5.44 the 
>>default user is LocalService rather than LocalSystem. LocalService has fewer 
>>privileges.

Great, I didn't realize this changed, and it seems likely to be my problem. 
Thank you very much!

This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential and/or 
privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email 
and all attachments,

(iii) Dassault Systèmes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.


Please be informed that your personal data are processed according to our data 
privacy policy as described on our website. Should you have any questions 
related to personal data protection, please contact 3DS Data Protection Officer 
at 3ds.compliance-priv...@3ds.com


For other languages, go to https://www.3ds.com/terms/email-disclaimer

RE: File access error on Windows Server 2019 after upgrading to Tomcat 8.5.45

[BOSECKER Nancy]

>> Also, "file not found" is not the same as "access denied". You should
>> post the exact error line(s) from your log.

>A bit off-topic, but wanted to jump in and clear this up, as the Java error 
>messages are somewhat misleading.
>If I write a class to open a read-only file with java.io.FileOutputStream, I 
>will see this stack trace

>calder@stimpy:~/bin> ./jdk180-221/bin/java AccessDenied
>java.io.FileNotFoundException: tester.txt (Permission denied)
at java.io.FileOutputStream.open0(Native Method) ...
>calder@stimpy:~/bin> ls -l tester.txt
>-r--r--r-- 1 calder users 0 Jun  9 10:12 tester.txt

>FileOutputStream ctors and methods throw the FileNotFoundException and the 
>more specific error [in this case] is "Permission denied".
>So yea, it's confusing.

>If you check the source code for FileNotFoundException, we even see a comment 
>related to this [quote] This exception will be thrown by the {@link 
>FileInputStream}, {@link  FileOutputStream}, and {@link RandomAccessFile} 
>constructors when a file  with the >specified pathname does not exist.  It 
>will also be thrown by these  constructors if the file does exist but for some 
>reason is inaccessible, for  example when an attempt is made to open a 
>read-only file for writing.
>[/quote]

I agree it is confusing. In my case, the error thrown from Java 'new 
FileOutputStream(file)' is:
java.io.FileNotFoundException:  (Access is denied)

Since the file exists and is readable (per Java checks), I assumed the 'for 
some reason is inaccessible' meant the file was opened somewhere else. But it 
seems it may actually be the default Tomcat user having less privileges.
This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential and/or 
privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email 
and all attachments,

(iii) Dassault Systèmes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.


Please be informed that your personal data are processed according to our data 
privacy policy as described on our website. Should you have any questions 
related to personal data protection, please contact 3DS Data Protection Officer 
at 3ds.compliance-priv...@3ds.com


For other languages, go to https://www.3ds.com/terms/email-disclaimer

Re: File access error on Windows Server 2019 after upgrading to Tomcat 8.5.45

[calder]

On Tue, Jun 9, 2020 at 8:08 AM Bill Stewart  wrote:
[ snip ]
> Also, "file not found" is not the same as "access denied". You should
> post the exact error line(s) from your log.

A bit off-topic, but wanted to jump in and clear this up, as the Java
error messages are somewhat misleading.
If I write a class to open a read-only file with
java.io.FileOutputStream, I will see this stack trace

calder@stimpy:~/bin> ./jdk180-221/bin/java AccessDenied
java.io.FileNotFoundException: tester.txt (Permission denied)
at java.io.FileOutputStream.open0(Native Method)
...
calder@stimpy:~/bin> ls -l tester.txt
-r--r--r-- 1 calder users 0 Jun  9 10:12 tester.txt

FileOutputStream ctors and methods throw the FileNotFoundException and
the more specific error [in this case] is "Permission denied".
So yea, it's confusing.

If you check the source code for FileNotFoundException, we even see a
comment related to this
[quote]
This exception will be thrown by the {@link FileInputStream}, {@link
 FileOutputStream}, and {@link RandomAccessFile} constructors when a file
 with the specified pathname does not exist.  It will also be thrown by these
 constructors if the file does exist but for some reason is inaccessible, for
 example when an attempt is made to open a read-only file for writing.
[/quote]

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

Re: rewrite.config don't work as expected after Tomcat 8.5.53 to 8.5.55 update

[Mark Thomas]

On 09/06/2020 15:51, Ziarko Jakub wrote:
> Hi,
> 
> 
> After the Tomcat update (below) rewrite.config doesn't seem to be working. If 
> no one knows the answer maybe at least can provide me how to enable login for 
> RewriteValve.

There is a regression in 8.5.55. Update to 8.5.56.

Mark


> 
> Last rewrite command instead of redirecting all requests to index.html 
> (angular app) it search in path files and returns the 404. When I reinstall 
> the 8.5.53 this works perfectly.
> 
> Tomcat is installed on windows machine.
> RewriteRule ^/value/assets/value.json$ /config/value_config.json [L]
> 
> RewriteCond %{SERVLET_PATH} !-f
> RewriteRule ^/angular/(.*)$ /angular/index.html [L]
> 
> 
> BR
> Kuba Ziarko
> 


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

rewrite.config don't work as expected after Tomcat 8.5.53 to 8.5.55 update

[Ziarko Jakub]

Hi,


After the Tomcat update (below) rewrite.config doesn't seem to be working. If 
no one knows the answer maybe at least can provide me how to enable login for 
RewriteValve.

Last rewrite command instead of redirecting all requests to index.html (angular 
app) it search in path files and returns the 404. When I reinstall the 8.5.53 
this works perfectly.

Tomcat is installed on windows machine.
RewriteRule ^/value/assets/value.json$ /config/value_config.json [L]

RewriteCond %{SERVLET_PATH} !-f
RewriteRule ^/angular/(.*)$ /angular/index.html [L]


BR
Kuba Ziarko

Re: File access error on Windows Server 2019 after upgrading to Tomcat 8.5.45

[Mark Thomas]

On 08/06/2020 22:54, BOSECKER Nancy wrote:
> I've been tasked with upgrading Tomcat from 8.5.41, but have run into a 
> problem that begins with release 8.5.45. Hopefully someone here can help.

What was the last version where this worked? 8.5.43? I ask as 8.5.44 was
not formally released.

> I have a servlet that tries to update a file that was previously written by a 
> separate servlet. Prior to 8.5.45, this works as expected and the file is 
> updated.
> 
> In 8.5.45, I get the Java error: File not Found exception - Access is denied. 
> The file exists and is readable, but must be being held onto by some unknown 
> process. I've tried Windows process manager and resource manager, but neither 
> of these can tell me what is holding the file handle. I can open the file in 
> an editor with no error. I can also delete the file without any error.
> 
> Note that the error occurs on Windows Server 2019. When I run the same code 
> on Windows 10 there is no error.

This might be related to the user Tomcat is running under. As of 8.5.44
the default user is LocalService rather than LocalSystem. LocalService
has fewer privileges.

Mark

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

Re: File access error on Windows Server 2019 after upgrading to Tomcat 8.5.45

[Bill Stewart]

On Mon, Jun 8, 2020 at 3:54 PM BOSECKER Nancy wrote:

> In 8.5.45, I get the Java error: File not Found exception -
> Access is denied. The file exists and is readable, but must be
> being held onto by some unknown process. I've tried Windows
> process manager and resource manager, but neither of these can
> tell me what is holding the file handle. I can open the file in
> an editor with no error. I can also delete the file without any
> error.

Your assumption that the file is being held open by an unknown process
may not be correct.

The ability to write/update/delete files is based on the account being
used to run Tomcat.

Also, "file not found" is not the same as "access denied". You should
post the exact error line(s) from your log.

Bill

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

Re: Tomcat 9.0.0 multiple thread issue

[Paul Carter-Brown]

I assume a servlet request is kicking off this process? If this is correct
then are you 100% sure that something is not calling the servlet more than
once? Perhaps a retry after a timeout or something?

Turn your access log on and look at what requests are coming in to the
server

Paul


On Tue, Jun 9, 2020 at 2:04 PM Ripu Daman  wrote:

> Hello everyone,
>
> I work in an IT firm as a software engineer. I don't know whether it's a
> right platform to ask questions based on personal projects but i believe i
> will get some help from here.
>
> We are facing an issue regarding multiple threads being created for a
> servlet execution running in tomcat 9.0.0
>
> Servlet's job is to publish customer leads to salesforce via soap protocol.
> The logic has been designed in such a way that in a single thread it can
> publish multiple leads to salesforce one by one. However we recently
> migrated our java application to kubernetes adopting containerized
> approach.
> Post this we are facing an issue in which, when the process starts
> publishing leads to salesforce one by one, after a few uploads a new thread
> gets created and it starts the whole process from beginning and then after
> a few seconds another thread kicks off repeating the whole process. It
> keeps going on until session timeout exceeds and we get a 504 error. But
> the upload process keeps going on in the background and stops after 2-3
> threads.
>
> Before moving to kubernetes, the process was working fine. In order to
> serve multiple requests at the same time, servlet is not designed to be
> thread safe.
>
> But now we are facing this issue and unable to identify the root cause.
>
> Here's a sample of threads from the logs :
>  [http-nio-8080-exec-9] INFO
>  [http-nio-8080-exec-9] INFO
>  [http-nio-8080-exec-9] INFO
>  [http-nio-8080-exec-7] INFO
>  [http-nio-8080-exec-7] INFO
>  [http-nio-8080-exec-9] INFO
>  [http-nio-8080-exec-9] INFO
>
>  [http-nio-8080-exec-7] INFO
>  [http-nio-8080-exec-7] INFO
>  [http-nio-8080-exec-7] INFO
>  [http-nio-8080-exec-3] INFO
>  [http-nio-8080-exec-7] INFO
>  [http-nio-8080-exec-3] INFO
>
> The configurations for tomcat remains same as default. Session timeout is
> set as 30 min (default).
>
> For more info please let me know.
>
> Hope will get some help from here.
>
> Thanks!
>
> regards,
> Ripu daman
>

Tomcat 9.0.0 multiple thread issue

[Ripu Daman]

Hello everyone,

I work in an IT firm as a software engineer. I don't know whether it's a
right platform to ask questions based on personal projects but i believe i
will get some help from here.

We are facing an issue regarding multiple threads being created for a
servlet execution running in tomcat 9.0.0

Servlet's job is to publish customer leads to salesforce via soap protocol.
The logic has been designed in such a way that in a single thread it can
publish multiple leads to salesforce one by one. However we recently
migrated our java application to kubernetes adopting containerized
approach.
Post this we are facing an issue in which, when the process starts
publishing leads to salesforce one by one, after a few uploads a new thread
gets created and it starts the whole process from beginning and then after
a few seconds another thread kicks off repeating the whole process. It
keeps going on until session timeout exceeds and we get a 504 error. But
the upload process keeps going on in the background and stops after 2-3
threads.

Before moving to kubernetes, the process was working fine. In order to
serve multiple requests at the same time, servlet is not designed to be
thread safe.

But now we are facing this issue and unable to identify the root cause.

Here's a sample of threads from the logs :
 [http-nio-8080-exec-9] INFO
 [http-nio-8080-exec-9] INFO
 [http-nio-8080-exec-9] INFO
 [http-nio-8080-exec-7] INFO
 [http-nio-8080-exec-7] INFO
 [http-nio-8080-exec-9] INFO
 [http-nio-8080-exec-9] INFO

 [http-nio-8080-exec-7] INFO
 [http-nio-8080-exec-7] INFO
 [http-nio-8080-exec-7] INFO
 [http-nio-8080-exec-3] INFO
 [http-nio-8080-exec-7] INFO
 [http-nio-8080-exec-3] INFO

The configurations for tomcat remains same as default. Session timeout is
set as 30 min (default).

For more info please let me know.

Hope will get some help from here.

Thanks!

regards,
Ripu daman

Re: Mitigating slow HTTP headers vulnerability

[Mark Thomas]

On 09/06/2020 07:19, Amit Pande wrote:
> (My apologies if this has been discussed already.)
> 
> Slow HTTP headers vulnerability was reported by scanner tool, on Tomcat 
> 8.5.54.
> 
> There might be not any perfect solution to address this issue, but wanted to 
> understand some of the best practices to mitigate this vulnerability.

Use the Servlet Async and non-blocking I/O API to read the POST. That
way no (well very few) server resources are used unless there is data to
be read. If you wish you can add checks to your code for abuse (e.g.
check upload speed) and drop potentially abusive connections.

If you want a purely Tomcat configuration based approach then reducing
timeouts is about all you can do.

Mark

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

Re: Regarding context.xml changes impact other web service not deployed

[Mark Thomas]

On 09/06/2020 06:59, S Abirami wrote:
> Hi Team,
> 
>  In our product to address security vulnerability in context.xml, we have 
> introduced following entry
> 
>  

In which context.xml file? The global one, the host one or a web
application specific one?

> After introducing the above line, I noticed few rest service which is not 
> deployed in that Tomcat also getting impact.

I'd guess not a web application specific one the

> Deployment Details
> 
> Deployed :RHEL
> Tomcat Installation format :  tar.gz
> 
> Hence,  interested to know about the internal implementation of the context 
> in Tomcat to understand the impact.

Global web.xml provides defaults for all web applications.

Host level provides defaults for all web applications in a given host.

Web application provides settings for just that web application.

Don't add  elements to server.xml

Settings in more specific files take priority.

Mark

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

Re: Regarding context.xml changes impact other web service not deployed

[Luis Rodríguez Fernández]

Hello Abirami,

Well, strict does what it promises, so if those third-party rest services
were expecting some cookies that now are not being sent by the browser, it
is normal that they do not work as expected.

Internal implementation: sure! You can always have a look at the code of
the different CookieProcessors [1] & [2]

Hope it helps,

Luis

[1]
https://github.com/apache/tomcat/blob/f3c9fdd40bdbc3dc22b512596954e2bc6d424d5a/java/org/apache/tomcat/util/http/Rfc6265CookieProcessor.java
[2]
https://github.com/apache/tomcat/blob/623b2c9d0997481f1c5229135fa2f92e24303e47/java/org/apache/tomcat/util/http/LegacyCookieProcessor.java



El mar., 9 jun. 2020 a las 7:59, S Abirami ()
escribió:

> Hi Team,
>
>  In our product to address security vulnerability in context.xml, we
> have introduced following entry
>
>  
>
>
> After introducing the above line, I noticed few rest service which is not
> deployed in that Tomcat also getting impact.
>
> Deployment Details
>
> Deployed :RHEL
> Tomcat Installation format :  tar.gz
>
> Hence,  interested to know about the internal implementation of the
> context in Tomcat to understand the impact.
>
> Thanks in advance for the support.
>
> Regards,
> Abirami.S
>
>
>
>
>
>

-- 

"Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better."

- Samuel Beckett

Mitigating slow HTTP headers vulnerability

[Amit Pande]

(My apologies if this has been discussed already.)

Slow HTTP headers vulnerability was reported by scanner tool, on Tomcat 8.5.54.

There might be not any perfect solution to address this issue, but wanted to 
understand some of the best practices to mitigate this vulnerability.

https://stackoverflow.com/questions/49442855/mitigating-slow-http-post-vulnerability-on-tomcat-8

Some recommendations from above link seem reasonable ("We reduced the 
connectionTimeout="8000" and scan is passed" - This didn't sound very 
convincing, though).  Is there anything more than can be done to address this?

We're trying to avoid putting reverse proxy in front of Tomcat as we do have 
our own pass-through proxy but it doesn't have any special capabilities to 
avoid this vulnerability like some reverse proxies (e.g. ngnix) have.

Appreciate the inputs here.

Thanks,
Amit

Regarding context.xml changes impact other web service not deployed

[S Abirami]

Hi Team,

 In our product to address security vulnerability in context.xml, we have 
introduced following entry

 


After introducing the above line, I noticed few rest service which is not 
deployed in that Tomcat also getting impact.

Deployment Details

Deployed :RHEL
Tomcat Installation format :  tar.gz

Hence,  interested to know about the internal implementation of the context in 
Tomcat to understand the impact.

Thanks in advance for the support.

Regards,
Abirami.S