RE: Tomcat SSL stops working after an undetermined amount of time

[Mysore, Raghunath]

To track if BC is configured in your environment, you may want to assess if BC 
is listed as a "security.provider"  in the following "java.security" file



File :  /jre/lib/security/java.security

Check for record (example below) :

security.provider.10=org.bouncycastle.jce.provider.BouncyCastleProvider



Note the Number 10, above may be something different in your environment's 
"java.security" file (presuming BC is configured here)



-Original Message-
From: Christopher Schultz 
Sent: Wednesday, May 26, 2021 4:35 PM
To: users@tomcat.apache.org
Subject: Re: Tomcat SSL stops working after an undetermined amount of time



Ezsra,



On 5/26/21 18:11, Ezsra McDonald wrote:

> Well, I still have issues. I think it is the same thing hit by these guys:

> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjira

> .atlassian.com%2Fbrowse%2FBAM-21157data=04%7C01%7Crmysore%40visa.

> com%7C0235cf7ab3c7461705ba08d9209694da%7C38305e12e15d4ee888b9c4db1c477

> d76%7C0%7C0%7C637576653404214193%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL

> jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata

> =QnzOhDNvEy%2FVBRmUz0B2F0iqOlH9gpBUJBwqNzHwz%2F4%3Dreserved=0

> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstac

> koverflow.com%2Fquestions%2F65691480%2Fnullpointerexception-at-org-bou

> ncycastle-crypto-signers-psssigner-generatesignatdata=04%7C01%7Cr

> mysore%40visa.com%7C0235cf7ab3c7461705ba08d9209694da%7C38305e12e15d4ee

> 888b9c4db1c477d76%7C0%7C0%7C637576653404214193%7CUnknown%7CTWFpbGZsb3d

> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C

> 1000sdata=PtS%2BltOexMX3CmAFTFc11Gt%2B57LoHvUgPu2k0nxJQ2M%3D

> reserved=0

>

> I'll try their fix. My main concern is that I do not want to disable

> TLSv1.3.



If you don't want to disable TLSv1.3, then you want:







If BC is failing you, I'd want to find out if you really need BC.



That first link above seems to suggest that when using Tomcat you MUST disable 
TLSv1.3. That seems odd. What version of BC are you using?

Search for .jar files with names like "bouncy".



Do you have the option to downgrade Java?



Have you tried disabling the RSASSA-PSS algorithm as per their instructions? It 
seems ... far-fetched that would fix the problem, but ... okay.



Note that at some time in the past, Java 1.8 did not support TLSv1.3 and lots 
of people who were stuck on Java 1.8 decided to switch to BC which did have 
TLSv1.3 support. With that version of Java 1.8 (_281), you should have native 
JDK support for TLSv1.3. Perhaps BC is not necessary at all.



-chris



> On Tue, May 25, 2021 at 11:09 AM Ezsra McDonald

> mailto:ezsra.mcdon...@gmail.com>>

> wrote:

>

>> Lots of good information was provided.

>>

>> This afternoon I plan to test the "sslProtocol"  to "protocols"

>> change in our lower environments. I will reply back with any findings.

>>

>> Thank you everyone for your responses.

>>

>> regards,

>>

>> -- Ez

>>

>> On Tue, May 25, 2021 at 10:48 AM Mysore, Raghunath

>> mailto:rmys...@visa.com.invalid>> wrote:

>>

>>> Hi Chris,

>>>

>>> -Original Message-

>>> From: Christopher Schultz 
>>> mailto:ch...@christopherschultz.net>>

>>> Sent: Tuesday, May 25, 2021 9:10 AM

>>> To: users@tomcat.apache.org

>>> Subject: Re: Tomcat SSL stops working after an undetermined amount

>>> of time

>>>

>>> Ronald,

>>>

>>> On 5/25/21 09:31, Roskens, Ronald wrote:



> -Original Message-

> From: Christopher Schultz 
> mailto:ch...@christopherschultz.net>>

> Sent: Monday, May 24, 2021 1:56 PM

> To: users@tomcat.apache.org

> Subject: [EXTERNAL] Re: Tomcat SSL stops working after an

> undetermined amount of time

>

> CAUTION: This email originated from outside of the organization.

> DO NOT CLICK on links or open attachments unless you recognize the

> sender and know the content is safe.

>

> Ezsra,

>

> On 5/24/21 10:30, Ezsra McDonald wrote:

>> I am enabling SSL debugging this morning. I did catch this in the

>> log for an instance that started erroring out this morning. Seems

>> like it may be too generic to help solve my problem. Here it is:

>>

>> 24-May-2021 09:25:44.609 SEVERE [catalina-exec-51]

>> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun

>> java.lang.NullPointerException

>> at

>> org.bouncycastle.crypto.signers.PSSSigner.generateSignature(Unkno

>> wn

>> Source)

>> at org.bouncycastle.jce.provider.JDKPSSSigner.engineSign(Unknown

>> Source)

>

> Oh. You are using BouncyCastle. I've never tried to do that. I'm

> not sure how well BC will work with Tomcat. We don't officially

> support that configuration, but that doesn't mean we won't try to help.



 This isn't a Tomcat issue but an interoperability issue between

>>> 

Re: apache-tomcat-8.5.59 too many open files on Linux 8

[Christopher Schultz]

André,

On 5/26/21 05:12, André Warnier (tomcat/perl) wrote:
Maybe I am missing something, but at first sight it looks like lsof, 
inside the container, can also not get more information about these 
"sock" things.


I am running out of ideas.
If you search in Google for precisely this :

lsof "sock" and "protocol : TCP"

there are a lot of links which discuss similar issues, and this over 
many years.

(So it is not either a unique or a recent issue).

They all seem to boil down to this : some *application* is opening 
sockets, but then not really using them (and not closing them).


In your case, that probably means one of the webapps running under tomcat.


Maybe a database connection pool? Or a REST service that the server code 
is calling-out to? Or an SMTP connection? Or a JMS queue? Or, or, or..


It seems quite unlikely that this would be tomcat itself, because if 
that was the case, this tomcat users list would probably be swamped with 
requests such as yours; which it isn't.


+1

-chris


On 26.05.2021 00:03, Yeggy Javadi wrote:

Hi,
Below is the nsenter output:

# ps -ef | grep tomcat
root  165217   1  1 10:22 ?    00:05:33 
/usr/local/jre/bin/java 
-Djava.util.logging.config.file=/usr/local/apache-tomcat/conf/logging.properties 
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -d64 
-server -Xms1800m -Xmx8192m -XX:MaxMetaspaceSize=1800m 
-Djdk.tls.ephemeralDHKeySize=2048 
-Djava.protocol.handler.pkgs=org.apache.catalina.webresources 
-Dorg.apache.catalina.security.SecurityListener.UMASK=0027 
-Dignore.endorsed.dirs= -classpath 
/usr/local/apache-tomcat/bin/bootstrap.jar:/usr/local/apache-tomcat/bin/tomcat-juli.jar 
-Dcatalina.base=/usr/local/apache-tomcat 
-Dcatalina.home=/usr/local/apache-tomcat 
-Djava.io.tmpdir=/usr/local/apache-tomcat/temp 
org.apache.catalina.startup.Bootstrap start
root  167329  167268  0 18:00 pts/1    00:00:00 grep --color=auto 
tomcat


# nsenter -t 165217 --net lsof -n -p 165217 |less
COMMAND    PID USER   FD  TYPE DEVICE SIZE/OFF 
NODE NAME
java    165217 root  cwd   DIR    8,2 4096   
157664 /usr/local/freestor/bin

java    165217 root  rtd   DIR    8,3 4096    2 /
java    165217 root  txt   REG    8,2 8712 
8913 /usr/local/jdk/jre1.8.0_271/bin/java
java    165217 root  mem   REG    8,2   113371   
160881 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/hibernate-jpa-2.1-api-1.0.0.Final.jar 

java    165217 root  mem   REG    8,2   147874   
160802 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/activemq-protobuf-1.1.jar 

java    165217 root  mem   REG    8,2   391515   
160836 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/lucene-queryparser-4.10.4.jar 

java    165217 root  mem   REG    8,2   868615   
160813 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/spring-context-3.2.17.RELEASE.jar 

java    165217 root  mem   REG    8,2 9711   
160792 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/slf4j-log4j12-1.6.6.jar 

java    165217 root  mem   REG    8,2   196573   
160819 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/spring-expression-3.2.17.RELEASE.jar 

java    165217 root  mem   REG    8,2    97173   
160843 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/lucene-misc-4.10.4.jar 

java    165217 root  mem   REG    8,2    10074   
160872 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/batik-ext-1.11.jar 

java    165217 root  mem   REG    8,2    62983   
160861 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/activation-1.1.jar 

java    165217 root  mem   REG    8,2   371668   
160812 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/spring-security-core-3.2.9.RELEASE.jar 

java    165217 root  mem   REG    8,2   645914   
160754 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/hibernate-entitymanager-4.3.5.Final.jar 

java    165217 root  mem   REG    8,2   427030   
160753 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/hibernate-envers-4.3.5.Final.jar 

java    165217 root  mem   REG    8,2   256468   
160829 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/barcode4j-2.0.jar 

java    165217 root  mem   REG    8,2   489884   
160846 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/log4j-1.2.17.jar
java    165217 root  mem   REG    8,2    29257   
160798 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/slf4j-api-1.7.7.jar 

java    165217 root  mem   REG    8,2   422612   
160783 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/batik-awt-util-1.11.jar 

java    165217 root  mem   REG    8,2    16519   
160796 

Re: Tomcat SSL stops working after an undetermined amount of time

[Christopher Schultz]

Ezsra,

On 5/26/21 18:11, Ezsra McDonald wrote:

Well, I still have issues. I think it is the same thing hit by these guys:
https://jira.atlassian.com/browse/BAM-21157
https://stackoverflow.com/questions/65691480/nullpointerexception-at-org-bouncycastle-crypto-signers-psssigner-generatesignat

I'll try their fix. My main concern is that I do not want to disable
TLSv1.3.


If you don't want to disable TLSv1.3, then you want:



If BC is failing you, I'd want to find out if you really need BC.

That first link above seems to suggest that when using Tomcat you MUST 
disable TLSv1.3. That seems odd. What version of BC are you using? 
Search for .jar files with names like "bouncy".


Do you have the option to downgrade Java?

Have you tried disabling the RSASSA-PSS algorithm as per their 
instructions? It seems ... far-fetched that would fix the problem, but 
... okay.


Note that at some time in the past, Java 1.8 did not support TLSv1.3 and 
lots of people who were stuck on Java 1.8 decided to switch to BC which 
did have TLSv1.3 support. With that version of Java 1.8 (_281), you 
should have native JDK support for TLSv1.3. Perhaps BC is not necessary 
at all.


-chris


On Tue, May 25, 2021 at 11:09 AM Ezsra McDonald 
wrote:


Lots of good information was provided.

This afternoon I plan to test the "sslProtocol"  to "protocols" change in
our lower environments. I will reply back with any findings.

Thank you everyone for your responses.

regards,

-- Ez

On Tue, May 25, 2021 at 10:48 AM Mysore, Raghunath
 wrote:


Hi Chris,

-Original Message-
From: Christopher Schultz 
Sent: Tuesday, May 25, 2021 9:10 AM
To: users@tomcat.apache.org
Subject: Re: Tomcat SSL stops working after an undetermined amount of time

Ronald,

On 5/25/21 09:31, Roskens, Ronald wrote:



-Original Message-
From: Christopher Schultz 
Sent: Monday, May 24, 2021 1:56 PM
To: users@tomcat.apache.org
Subject: [EXTERNAL] Re: Tomcat SSL stops working after an
undetermined amount of time

CAUTION: This email originated from outside of the organization. DO
NOT CLICK on links or open attachments unless you recognize the
sender and know the content is safe.

Ezsra,

On 5/24/21 10:30, Ezsra McDonald wrote:

I am enabling SSL debugging this morning. I did catch this in the
log for an instance that started erroring out this morning. Seems
like it may be too generic to help solve my problem. Here it is:

24-May-2021 09:25:44.609 SEVERE [catalina-exec-51]
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun
java.lang.NullPointerException
at
org.bouncycastle.crypto.signers.PSSSigner.generateSignature(Unknown
Source)
at org.bouncycastle.jce.provider.JDKPSSSigner.engineSign(Unknown
Source)


Oh. You are using BouncyCastle. I've never tried to do that. I'm not
sure how well BC will work with Tomcat. We don't officially support
that configuration, but that doesn't mean we won't try to help.


This isn't a Tomcat issue but an interoperability issue between

BouncyCastle & OpenJDK.


*
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
ub.com%2Fbcgit%2Fbc-java%2Fissues%2F633data=04%7C01%7Crmysore%40v
isa.com%7C29de4f3283544be589d508d91f8f4728%7C38305e12e15d4ee888b9c4db1
c477d76%7C0%7C0%7C637575522499773346%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000s
data=VvFC5V57Cy3iWAqlqBwuXjbQOSpMN2EK9nbangoytsc%3Dreserved=0
*
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs
.openjdk.java.net%2Fbrowse%2FJDK-8216039data=04%7C01%7Crmysore%40
visa.com%7C29de4f3283544be589d508d91f8f4728%7C38305e12e15d4ee888b9c4db
1c477d76%7C0%7C0%7C637575522499773346%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000
sdata=rqFmFJWSb5zJDkd52jV0PU9FP9%2FNt0k1MInH6pcfBGk%3Dreserved=0


Oh, great. Looks like a BC upgrade will fix the NPE. But possibly
something downstream will still fail...

Just to add my 2 cents here :

Per the problem posed in the very first email, we see the SSL/TLS issue
between Oracle JDK 8 and Tomcat 8.5
Environment:
OS: CentOS 7
Apache: apache-tomcat-8.5.65
Java: jdk1.8.0_281

Note that the following link - talks about issues between OpenJDK 11 and
BC.
https://bugs.openjdk.java.net/browse/JDK-8216039.

This morning's suggestion (about changing from "sslProtocol"  to
"protocols" )  from Christopher Schultz, sounds  promising, in that the
interaction between the Browser-clients and Tomcat 8.5.x server, will be
limited only to TLS1.2
Making this change, will preclude other old protocols - like TLS 1, TLS
11 etc  in communication between the clients and the Tomcat server.
We will need tests after making the change to "protocols" attribute in
the HTTPS connector block.
In context of the above mentioned change -we may not need any editing of
"java.security" file contents (discussed last evening).

Thanks,
  -Raghu


-
To unsubscribe, e-mail: 

Re: Tomcat SSL stops working after an undetermined amount of time

[Ezsra McDonald]

Well, I still have issues. I think it is the same thing hit by these guys:
https://jira.atlassian.com/browse/BAM-21157
https://stackoverflow.com/questions/65691480/nullpointerexception-at-org-bouncycastle-crypto-signers-psssigner-generatesignat

I'll try their fix. My main concern is that I do not want to disable
TLSv1.3.

Any other suggestions?

--Ez

On Tue, May 25, 2021 at 11:09 AM Ezsra McDonald 
wrote:

> Lots of good information was provided.
>
> This afternoon I plan to test the "sslProtocol"  to "protocols" change in
> our lower environments. I will reply back with any findings.
>
> Thank you everyone for your responses.
>
> regards,
>
> -- Ez
>
> On Tue, May 25, 2021 at 10:48 AM Mysore, Raghunath
>  wrote:
>
>> Hi Chris,
>>
>> -Original Message-
>> From: Christopher Schultz 
>> Sent: Tuesday, May 25, 2021 9:10 AM
>> To: users@tomcat.apache.org
>> Subject: Re: Tomcat SSL stops working after an undetermined amount of time
>>
>> Ronald,
>>
>> On 5/25/21 09:31, Roskens, Ronald wrote:
>> >
>> >> -Original Message-
>> >> From: Christopher Schultz 
>> >> Sent: Monday, May 24, 2021 1:56 PM
>> >> To: users@tomcat.apache.org
>> >> Subject: [EXTERNAL] Re: Tomcat SSL stops working after an
>> >> undetermined amount of time
>> >>
>> >> CAUTION: This email originated from outside of the organization. DO
>> >> NOT CLICK on links or open attachments unless you recognize the
>> >> sender and know the content is safe.
>> >>
>> >> Ezsra,
>> >>
>> >> On 5/24/21 10:30, Ezsra McDonald wrote:
>> >>> I am enabling SSL debugging this morning. I did catch this in the
>> >>> log for an instance that started erroring out this morning. Seems
>> >>> like it may be too generic to help solve my problem. Here it is:
>> >>>
>> >>> 24-May-2021 09:25:44.609 SEVERE [catalina-exec-51]
>> >>> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun
>> >>> java.lang.NullPointerException
>> >>> at
>> >>> org.bouncycastle.crypto.signers.PSSSigner.generateSignature(Unknown
>> >>> Source)
>> >>> at org.bouncycastle.jce.provider.JDKPSSSigner.engineSign(Unknown
>> >>> Source)
>> >>
>> >> Oh. You are using BouncyCastle. I've never tried to do that. I'm not
>> >> sure how well BC will work with Tomcat. We don't officially support
>> >> that configuration, but that doesn't mean we won't try to help.
>> >
>> > This isn't a Tomcat issue but an interoperability issue between
>> BouncyCastle & OpenJDK.
>> >
>> > *
>> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
>> > ub.com%2Fbcgit%2Fbc-java%2Fissues%2F633data=04%7C01%7Crmysore%40v
>> > isa.com%7C29de4f3283544be589d508d91f8f4728%7C38305e12e15d4ee888b9c4db1
>> > c477d76%7C0%7C0%7C637575522499773346%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
>> > C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000s
>> > data=VvFC5V57Cy3iWAqlqBwuXjbQOSpMN2EK9nbangoytsc%3Dreserved=0
>> > *
>> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs
>> > .openjdk.java.net%2Fbrowse%2FJDK-8216039data=04%7C01%7Crmysore%40
>> > visa.com%7C29de4f3283544be589d508d91f8f4728%7C38305e12e15d4ee888b9c4db
>> > 1c477d76%7C0%7C0%7C637575522499773346%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
>> > MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000
>> > sdata=rqFmFJWSb5zJDkd52jV0PU9FP9%2FNt0k1MInH6pcfBGk%3Dreserved=0
>>
>> Oh, great. Looks like a BC upgrade will fix the NPE. But possibly
>> something downstream will still fail...
>>
>> Just to add my 2 cents here :
>>
>> Per the problem posed in the very first email, we see the SSL/TLS issue
>> between Oracle JDK 8 and Tomcat 8.5
>> Environment:
>> OS: CentOS 7
>> Apache: apache-tomcat-8.5.65
>> Java: jdk1.8.0_281
>>
>> Note that the following link - talks about issues between OpenJDK 11 and
>> BC.
>> https://bugs.openjdk.java.net/browse/JDK-8216039.
>>
>> This morning's suggestion (about changing from "sslProtocol"  to
>> "protocols" )  from Christopher Schultz, sounds  promising, in that the
>> interaction between the Browser-clients and Tomcat 8.5.x server, will be
>> limited only to TLS1.2
>> Making this change, will preclude other old protocols - like TLS 1, TLS
>> 11 etc  in communication between the clients and the Tomcat server.
>> We will need tests after making the change to "protocols" attribute in
>> the HTTPS connector block.
>> In context of the above mentioned change -we may not need any editing of
>> "java.security" file contents (discussed last evening).
>>
>> Thanks,
>>  -Raghu
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>

abandoned connections

[Rob Sargent]

I think I have all my calls for new connections in try/with blocks, but 
things went bump in the night at AWS/RDS yesterday and I'm wondering if 
I missed one or if the try/with isn't as safe as I thought.


   00:10:12.201 [https-jsse-nio-10.0.2.28-15002-exec-11] INFO
   edu.utah.camplab.jx.PayloadFromMux -
   bulk."rjs_GEV15_20_074d449b_c3ba_499f_83e3_f48427fe0156": Begin
   transfer from bulk to segment
   26-May-2021 00:10:55.092 WARNING [Tomcat JDBC Pool
   Cleaner[1731185718:1621976215058]]
   org.apache.tomcat.jdbc.pool.ConnectionPool.abandon Connection has
   been abandoned PooledConnection[org.postgresql.jdbc.PgConnection@2e\
   cd1168]:java.lang.Exception
    at
   
org.apache.tomcat.jdbc.pool.ConnectionPool.getThreadDump(ConnectionPool.java:1163)
    at
   
org.apache.tomcat.jdbc.pool.ConnectionPool.borrowConnection(ConnectionPool.java:816)
    at
   
org.apache.tomcat.jdbc.pool.ConnectionPool.borrowConnection(ConnectionPool.java:660)
    at
   
org.apache.tomcat.jdbc.pool.ConnectionPool.getConnection(ConnectionPool.java:198)
    at
   
org.apache.tomcat.jdbc.pool.DataSourceProxy.getConnection(DataSourceProxy.java:132)
    at
   
org.apache.tomcat.jdbc.pool.DataSourceProxy.getConnection(DataSourceProxy.java:90)
    at
   
edu.utah.camplab.servlet.AbstractSGSServlet.getDbConn(AbstractSGSServlet.java:123)
    at
   
edu.utah.camplab.servlet.AbstractSGSServlet.getDbConn(AbstractSGSServlet.java:105)
    at
   
edu.utah.camplab.servlet.PayloadSaveServlet.doPost(PayloadSaveServlet.java:50)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:652)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:733)

in my tomcat log.  I see *nothing* that matches this in the AWS/RDS log 
views.


And here's the getDbConn call in the doPost method (though I see it has 
a superfluous close() call):


  protected void doPost(HttpServletRequest req, HttpServletResponse
   resp) {
    //HashMap> pmap = getParameterMap(req);
    logger.error("payload save called");
    try (Connection copyConn = getDbConn(req, resp)) {
    ObjectMapper jsonMapper = JsonMapper.builder().addModule(new
   JavaTimeModule()).build();
    jsonMapper.setSerializationInclusion(Include.NON_NULL);

    AbstractPayload payload =
   jsonMapper.readValue(req.getInputStream(), AbstractPayload.class);
    logger.error("received payload");
    String redoUrl =
   String.format("jdbc:postgresql://%s:%d/%s", getDbHost(),
   getDbPort(), getDbName(req));
    payload.setConnection(copyConn);
    payload.setDbUrl(redoUrl);
    payload.write();
    logger.error("finished db write");
    resp.setContentType("plain/text");
    resp.setStatus(200);
    resp.getOutputStream().write("SGS_OK".getBytes());
    resp.getOutputStream().flush();
    resp.getOutputStream().close();
    copyConn.close();
  }
    catch
   (com.fasterxml.jackson.databind.exc.MismatchedInputException mie) {
  logger.error("transform failed: " + mie.getMessage());
  resp.setContentType("plain/text");
  resp.setStatus(461);
  sendBadNews(resp, mie, "json formatting issue, perhaps");
    }
    catch (IOException | SQLException ioe) {
  resp.setStatus(460);
  sendBadNews(resp, ioe, "database trouble, likely");
    }
  }

Re: Enhancement: Additional user attributes queried by (some) realms

[Mark Thomas]

On 26/05/2021 18:56, Mark Thomas wrote:

On 26/05/2021 12:00, Carsten Klein wrote:




Why does UserDatabaseRealm pass a userPrincipal of type 
UserDatabasePrincipal? Can't we just drop that and do it like 
JNDIRealm or DataSourceRealm?


I don't see any obvious reason. I'll do some digging in the source 
history to see if I can find out why. Absent a good reason, I'd say drop 
it.


There is a good reason for it, but I think it should be possible to drop it.

It is there because the UserDatabaseRealm supports the concepts of 
groups. Users can have roles assigned directly or users can be assigned 
to a group and inherit the roles of the group. This means hasRole() is a 
little more complicated and the UserDatabasePrincipal is used to 
determine if this additional processing is required.


I think this could be replaced by a 
"org.apache.catalina.realm.UserDatabaseRealm.groups" attribute which 
would remove the need for the dedicated UserDatabasePrincipal


Mark

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

Re: Enhancement: Additional user attributes queried by (some) realms

[Mark Thomas]

On 26/05/2021 12:00, Carsten Klein wrote:




1. How to access the Principal's new attributes

Simplest is to provide a getter method, that actually returns the map 
(optionally with a read-only parameter):


Given that the attributes may well be security related, you would need 
to make sure neither the Map nor any of the keys/values could be 
modified. Protecting the Map is easy. Protecting the keys/values is a 
little trickier. For that reason I'd lean towards the solution below.


However, in the jakarta.servlet classes, there are also some entities 
that have attributes. There, attributes are accessed by these methods:


Object getAttribute(String name);

Enumeration getAttributeNames();

void setAttribute(String name, Object o);

Would you, for the sake of uniformity, prefer using these more 
servlet-spec like methods?


Yes, but without setAttribute(). The attributes need to be provided at 
construction time and should be immutable from that point onwards.


2. Should I add attributes-related public methods to the TomcatPrincipal 
interface as well?


Yes. So far the only Tomcat specific extensions are for SPNEGO but this 
is in the same category. The other option would be a new interface but I 
don't see a need for that.



3. Class UserDatabasePrincipal in UserDatabaseRealm




Why does UserDatabaseRealm pass a userPrincipal of type 
UserDatabasePrincipal? Can't we just drop that and do it like JNDIRealm 
or DataSourceRealm?


I don't see any obvious reason. I'll do some digging in the source 
history to see if I can find out why. Absent a good reason, I'd say drop it.


Mark

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

Enhancement: Additional user attributes queried by (some) realms

[Carsten Klein]

Hi there,

as already discussed here:

http://mail-archives.apache.org/mod_mbox/tomcat-users/202104.mbox/ajax/%3Cb9a2a913-f00f-f5bf-ca05-8ea4f8663ca9%40datagis.com%3E

I'm implementing an enhancement for querying configurable extra user 
attributes through some of the Realm classes from the "user database" 
configured for that Realm.


Before starting off, I want do clarify some questions.

The implementation basically of consists two parts. One is to enable the 
GenericPrincipal class (and/or TomcatPrincipal interface) to hold these 
additional user attributes. The other part is to query these attributes 
from the Realm's configured user database an to store these in the newly 
created Principal instance.


The second part is quite clear and changes are only local to the Realm 
classes. But some decisions must be made for the first part.


The Principal's attributes will be stored in a Map hash 
map. Since attributes may come from various sources, using an 
Object-typed value seems appropriate to me. That map will also be added 
to internal class SerializablePrincipal in order to be persisted properly.


Now, my questions:

1. How to access the Principal's new attributes

Simplest is to provide a getter method, that actually returns the map 
(optionally with a read-only parameter):


/**
 * The set of additional attributes associated with the user represented
 * by this Principal.
 */
protected final Map attributes;

/**
 * Returns the user's additional attributes as a Map.
 *
 * @param readonly
 *if true, the returned map is an unmodifiable
 *view of the map; otherwise the underlying map is returned
 *unchanged
 * @return the user's additional attributes as an unmodifiable Map
 */
public Map getAttributes(boolean readonly) {
  if (readonly) {
return Collections.unmodifiableMap(attributes);
  }
  return attributes;
}

/**
 * Returns the user's additional attributes as an unmodifiable Map.
 *
 * @return the user's additional attributes as an unmodifiable Map
 */
public Map getAttributes() {
  return getAttributes(true);
}

However, in the jakarta.servlet classes, there are also some entities 
that have attributes. There, attributes are accessed by these methods:


Object getAttribute(String name);

Enumeration getAttributeNames();

void setAttribute(String name, Object o);


Would you, for the sake of uniformity, prefer using these more 
servlet-spec like methods?



2. Should I add attributes-related public methods to the TomcatPrincipal 
interface as well?


According to the documentation of TomcatPrincipal I likely should:

Defines additional methods implemented by {@link Principal}s created by
Tomcat's standard {@link Realm} implementations.

However, this interface seems only being used with GSS (most other 
instanceof tests are performed against GenericPrincipal).


So, I guess the attributes stuff should better NOT be added to 
TomcatPrincipal?



3. Class UserDatabasePrincipal in UserDatabaseRealm

Although neither documented nor used in Tomcat's shipped standard 
tomcat-users.xml, the UserDatabaseRealm supports the additional 
attribute "fullname" for a user entry. This makes this Realm a good 
candidate for supporting additional user attributes (actually, the 
authenticated user's display name was the initial intention for this 
enhancement).


The UserDatabaseRealm creates a Principal with an explicitly set 
userPrincipal (why? e.g. DataSourceRealm and JNDIRealm don't) of type 
UserDatabasePrincipal. The latter does not extend GenericPrincipal class 
and so, will not have the new attributes-related methods by default.


However, since Request.getUserPrincipal returns that "inner" 
userPrincipal by calling getUserPrincipal(), attributes should be 
available for that UserDatabasePrincipal as well.


My Questions:

Why does UserDatabaseRealm pass a userPrincipal of type 
UserDatabasePrincipal? Can't we just drop that and do it like JNDIRealm 
or DataSourceRealm?


If not, I need to add the attributes-related methods to the 
UserDatabasePrincipal as well.



Carsten

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

Re: apache-tomcat-8.5.59 too many open files on Linux 8

[tomcat/perl]

Addendum :

Maybe to debug this more efficiently, you could look at this issue from the 
opposite side :
Earlier in the thread of messages, you said this :

1. Did you upgrade anything recently (like Java VM)?
[YJ] To support Linux 8, only Postgres was upgraded from version 9.3 to 9.6.

Maybe when you did this, you also changed the driver which tomcat is using to communicate 
with Postgresql. And maybe the problem lies in that driver.
I mean that the driver is the piece of code which creates connections (using sockets) with 
Postgresql. And usually, that works and you have a number of ESTABLISHED connections 
(which are visible in the netstat output).
But what if, occasionally, the connection doesn't work, and the driver is not very clean 
in handling this failing socket ?


Or maybe the issue is in the code which uses these connections ?
Have a look at this :
https://stackoverflow.com/questions/2225221/closing-database-connections-in-java/2225275#2225275



On 26.05.2021 11:12, André Warnier (tomcat/perl) wrote:
Maybe I am missing something, but at first sight it looks like lsof, inside the container, 
can also not get more information about these "sock" things.


I am running out of ideas.
If you search in Google for precisely this :

lsof "sock" and "protocol : TCP"

there are a lot of links which discuss similar issues, and this over many years.
(So it is not either a unique or a recent issue).

They all seem to boil down to this : some *application* is opening sockets, but then not 
really using them (and not closing them).


In your case, that probably means one of the webapps running under tomcat.

It seems quite unlikely that this would be tomcat itself, because if that was the case, 
this tomcat users list would probably be swamped with requests such as yours; which it isn't.
It is worth noting also, that among all these messages found in Google, I have not so far 
seen a single one which provides another explanation for those "sock" things.


In your case, the problem is going to be in finding out *which* webapp does that, unless 
there are not many, and you can turn them off one-by-one selectively.
(The difficulty is in part due to the fact that, to the OS, the whole of the JVM, tomcat 
and all the webapps look like one single process; and to lsof also).


Maybe there is some type of logging available in tomcat, that would help finding out which 
application is creating sockets, and then never using or destroying them.

But my personal competences do not run that far, so maybe someone else can help 
you here.


On 26.05.2021 00:03, Yeggy Javadi wrote:

Hi,
Below is the nsenter output:

# ps -ef | grep tomcat
root  165217   1  1 10:22 ?    00:05:33 /usr/local/jre/bin/java 
-Djava.util.logging.config.file=/usr/local/apache-tomcat/conf/logging.properties 
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -d64 -server -Xms1800m 
-Xmx8192m -XX:MaxMetaspaceSize=1800m -Djdk.tls.ephemeralDHKeySize=2048 
-Djava.protocol.handler.pkgs=org.apache.catalina.webresources 
-Dorg.apache.catalina.security.SecurityListener.UMASK=0027 -Dignore.endorsed.dirs= 
-classpath 
/usr/local/apache-tomcat/bin/bootstrap.jar:/usr/local/apache-tomcat/bin/tomcat-juli.jar 
-Dcatalina.base=/usr/local/apache-tomcat -Dcatalina.home=/usr/local/apache-tomcat 
-Djava.io.tmpdir=/usr/local/apache-tomcat/temp org.apache.catalina.startup.Bootstrap start

root  167329  167268  0 18:00 pts/1    00:00:00 grep --color=auto tomcat

# nsenter -t 165217 --net lsof -n -p 165217 |less
COMMAND    PID USER   FD  TYPE DEVICE SIZE/OFF NODE NAME
java    165217 root  cwd   DIR    8,2 4096   157664 
/usr/local/freestor/bin

java    165217 root  rtd   DIR    8,3 4096    2 /
java    165217 root  txt   REG    8,2 8712 8913 
/usr/local/jdk/jre1.8.0_271/bin/java
java    165217 root  mem   REG    8,2   113371   160881 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/hibernate-jpa-2.1-api-1.0.0.Final.jar 

java    165217 root  mem   REG    8,2   147874   160802 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/activemq-protobuf-1.1.jar
java    165217 root  mem   REG    8,2   391515   160836 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/lucene-queryparser-4.10.4.jar
java    165217 root  mem   REG    8,2   868615   160813 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/spring-context-3.2.17.RELEASE.jar
java    165217 root  mem   REG    8,2 9711   160792 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/slf4j-log4j12-1.6.6.jar
java    165217 root  mem   REG    8,2   196573   160819 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/spring-expression-3.2.17.RELEASE.jar 

java    165217 root  mem   REG    8,2    97173   160843 

Re: apache-tomcat-8.5.59 too many open files on Linux 8

[tomcat/perl]

Maybe I am missing something, but at first sight it looks like lsof, inside the container, 
can also not get more information about these "sock" things.


I am running out of ideas.
If you search in Google for precisely this :

lsof "sock" and "protocol : TCP"

there are a lot of links which discuss similar issues, and this over many years.
(So it is not either a unique or a recent issue).

They all seem to boil down to this : some *application* is opening sockets, but then not 
really using them (and not closing them).


In your case, that probably means one of the webapps running under tomcat.

It seems quite unlikely that this would be tomcat itself, because if that was the case, 
this tomcat users list would probably be swamped with requests such as yours; which it isn't.
It is worth noting also, that among all these messages found in Google, I have not so far 
seen a single one which provides another explanation for those "sock" things.


In your case, the problem is going to be in finding out *which* webapp does that, unless 
there are not many, and you can turn them off one-by-one selectively.
(The difficulty is in part due to the fact that, to the OS, the whole of the JVM, tomcat 
and all the webapps look like one single process; and to lsof also).


Maybe there is some type of logging available in tomcat, that would help finding out which 
application is creating sockets, and then never using or destroying them.

But my personal competences do not run that far, so maybe someone else can help 
you here.


On 26.05.2021 00:03, Yeggy Javadi wrote:

Hi,
Below is the nsenter output:

# ps -ef | grep tomcat
root  165217   1  1 10:22 ?00:05:33 /usr/local/jre/bin/java 
-Djava.util.logging.config.file=/usr/local/apache-tomcat/conf/logging.properties
 -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -d64 -server 
-Xms1800m -Xmx8192m -XX:MaxMetaspaceSize=1800m 
-Djdk.tls.ephemeralDHKeySize=2048 
-Djava.protocol.handler.pkgs=org.apache.catalina.webresources 
-Dorg.apache.catalina.security.SecurityListener.UMASK=0027 
-Dignore.endorsed.dirs= -classpath 
/usr/local/apache-tomcat/bin/bootstrap.jar:/usr/local/apache-tomcat/bin/tomcat-juli.jar
 -Dcatalina.base=/usr/local/apache-tomcat 
-Dcatalina.home=/usr/local/apache-tomcat 
-Djava.io.tmpdir=/usr/local/apache-tomcat/temp 
org.apache.catalina.startup.Bootstrap start
root  167329  167268  0 18:00 pts/100:00:00 grep --color=auto tomcat

# nsenter -t 165217 --net lsof -n -p 165217 |less
COMMANDPID USER   FD  TYPE DEVICE SIZE/OFF NODE NAME
java165217 root  cwd   DIR8,2 4096   157664 
/usr/local/freestor/bin
java165217 root  rtd   DIR8,3 40962 /
java165217 root  txt   REG8,2 8712 8913 
/usr/local/jdk/jre1.8.0_271/bin/java
java165217 root  mem   REG8,2   113371   160881 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/hibernate-jpa-2.1-api-1.0.0.Final.jar
java165217 root  mem   REG8,2   147874   160802 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/activemq-protobuf-1.1.jar
java165217 root  mem   REG8,2   391515   160836 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/lucene-queryparser-4.10.4.jar
java165217 root  mem   REG8,2   868615   160813 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/spring-context-3.2.17.RELEASE.jar
java165217 root  mem   REG8,2 9711   160792 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/slf4j-log4j12-1.6.6.jar
java165217 root  mem   REG8,2   196573   160819 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/spring-expression-3.2.17.RELEASE.jar
java165217 root  mem   REG8,297173   160843 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/lucene-misc-4.10.4.jar
java165217 root  mem   REG8,210074   160872 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/batik-ext-1.11.jar
java165217 root  mem   REG8,262983   160861 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/activation-1.1.jar
java165217 root  mem   REG8,2   371668   160812 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/spring-security-core-3.2.9.RELEASE.jar
java165217 root  mem   REG8,2   645914   160754 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/hibernate-entitymanager-4.3.5.Final.jar
java165217 root  mem   REG8,2   427030   160753 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/hibernate-envers-4.3.5.Final.jar
java165217 root  mem   REG8,2   256468   160829 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/barcode4j-2.0.jar
java165217 root  mem   REG8,2   

Re: Tomcat8.5.53: HTTP requests parsing error

[Mark Thomas]

On 26/05/2021 09:47, Nada Mahmoud Ahmed Aboueata wrote:

Dear Mark,

Thanks for your reply,

I have tried to address the issue of invalid characters by adding 
relaxedQueryChars parameter in the connector placed in server.xml , but still I 
am getting this exception!!

relaxedQueryChars=""


You may want to look at relaxedPathChars as well.


Please note that we didn't face this issue with tomcat 7.x, and we start facing 
the issue with tomcat 8.x. Is this issue is addressed by current releases of 
Tomcat?


Which part of my previous reply was not clear?

This is NOT a Tomcat issue. Tomcat is doing exactly what it is meant to 
do - implementing the HTTP specifications.


The issue is that you have one or more broken clients that are sending 
invalid HTTP requests. The correct long term way to address this issue 
is to fix the broken clients.


Tomcat 7 implemented the same checks as Tomcat 8. They were introduced 
as part of the fix for CVE-2016-6816 in 7.0.73, 8.0.39, 8.5.8 and 
9.0.0.M13 with the option to relax the checks introduced in 7.0.87, 
8.0.52 and 8.5.31, 9.0.8.


Mark





-Original Message-
From: Mark Thomas 
Sent: Wednesday, May 26, 2021 11:10 AM
To: users@tomcat.apache.org
Subject: [ALERT: Non-QU Sender] Re: Tomcat8.5.53: HTTP requests parsing error

On 26/05/2021 09:02, Nada Mahmoud Ahmed Aboueata wrote:

Dear all,

We are using Tomcat 8.5.53, and I have been noticing the attached
below exceptions in my logs. After looking deeply what kind of
requests that caused these exception, I noticed that some request
include Null http protocol and some special characters that cannot be handled 
by Tomcat.
Also, we have noticed that these kind of requests might crash the web
server from time-time and caused OutOfMemoryError.


That is highly unlikely. When an invalid request is received, Tomcat responds 
with a 400 response and closes the connection. The opportunity for an OOME is 
slim to nonexistant.


I am not sure if this issue is a bug in Tomcat 8.x that it cannot
handle these requests, so could you please advise what’s recommended
to avoid these exceptions?


There error message is clear:

"Invalid character found in the request target. The valid characters are defined in 
RFC 7230 and RFC 3986."

The client is sending an invaild HTTP request and Tomcat is, correctly, 
rejecting it.

The recommended way to address isses such as this is to fix the broken clients 
that are sending invalid HTTP requests.

Mark




02-Mar-2021 01:33:04.846 INFO
[https-jsse-nio-185.37.108.150-8443-exec-31]
org.apache.coyote.http11.Http11Processor.service Error parsing HTTP
request header

Note: further occurrences of HTTP request parsing errors will be
logged at DEBUG level.

  java.lang.IllegalArgumentException: Invalid character found
in the HTTP protocol

  at
org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11Inpu
tBuffer.java:567)

  at
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:
502)

  at
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLigh
t.java:65)

  at
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractP
rotocol.java:818)

  at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoi
nt.java:1623)

  at
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase
.java:49)

  at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.j
ava:1149)

  at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.
java:624)

  at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThr
ead.java:61)

  at java.lang.Thread.run(Thread.java:748)

24-May-2021 23:04:00.693 INFO
[https-jsse-nio-185.37.108.150-8443-exec-309]
org.apache.coyote.http11.Http11Processor.service Error parsing HTTP
request header

Note: further occurrences of HTTP request parsing errors will be
logged at DEBUG level.

java.lang.IllegalArgumentException: Invalid character
found in the request target. The valid characters are defined in RFC
7230 and RFC 3986

   at
org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11Inpu
tBuffer.java:502)

   at
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:
502)

   at
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLigh
t.java:65)

   at
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractP
rotocol.java:818)

   at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoi
nt.java:1623)

   at
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase
.java:49)

   at

RE: [ALERT: Non-QU Sender] Re: Tomcat8.5.53: HTTP requests parsing error

[Nada Mahmoud Ahmed Aboueata]

Dear Mark,

Thanks for your reply,

I have tried to address the issue of invalid characters by adding 
relaxedQueryChars parameter in the connector placed in server.xml , but still I 
am getting this exception!!

relaxedQueryChars=""

Please note that we didn't face this issue with tomcat 7.x, and we start facing 
the issue with tomcat 8.x. Is this issue is addressed by current releases of 
Tomcat?


-Original Message-
From: Mark Thomas 
Sent: Wednesday, May 26, 2021 11:10 AM
To: users@tomcat.apache.org
Subject: [ALERT: Non-QU Sender] Re: Tomcat8.5.53: HTTP requests parsing error

On 26/05/2021 09:02, Nada Mahmoud Ahmed Aboueata wrote:
> Dear all,
>
> We are using Tomcat 8.5.53, and I have been noticing the attached
> below exceptions in my logs. After looking deeply what kind of
> requests that caused these exception, I noticed that some request
> include Null http protocol and some special characters that cannot be handled 
> by Tomcat.
> Also, we have noticed that these kind of requests might crash the web
> server from time-time and caused OutOfMemoryError.

That is highly unlikely. When an invalid request is received, Tomcat responds 
with a 400 response and closes the connection. The opportunity for an OOME is 
slim to nonexistant.

> I am not sure if this issue is a bug in Tomcat 8.x that it cannot
> handle these requests, so could you please advise what’s recommended
> to avoid these exceptions?

There error message is clear:

"Invalid character found in the request target. The valid characters are 
defined in RFC 7230 and RFC 3986."

The client is sending an invaild HTTP request and Tomcat is, correctly, 
rejecting it.

The recommended way to address isses such as this is to fix the broken clients 
that are sending invalid HTTP requests.

Mark


>
> 02-Mar-2021 01:33:04.846 INFO
> [https-jsse-nio-185.37.108.150-8443-exec-31]
> org.apache.coyote.http11.Http11Processor.service Error parsing HTTP
> request header
>
> Note: further occurrences of HTTP request parsing errors will be
> logged at DEBUG level.
>
>  java.lang.IllegalArgumentException: Invalid character found
> in the HTTP protocol
>
>  at
> org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11Inpu
> tBuffer.java:567)
>
>  at
> org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:
> 502)
>
>  at
> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLigh
> t.java:65)
>
>  at
> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractP
> rotocol.java:818)
>
>  at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoi
> nt.java:1623)
>
>  at
> org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase
> .java:49)
>
>  at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.j
> ava:1149)
>
>  at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.
> java:624)
>
>  at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThr
> ead.java:61)
>
>  at java.lang.Thread.run(Thread.java:748)
>
> 24-May-2021 23:04:00.693 INFO
> [https-jsse-nio-185.37.108.150-8443-exec-309]
> org.apache.coyote.http11.Http11Processor.service Error parsing HTTP
> request header
>
> Note: further occurrences of HTTP request parsing errors will be
> logged at DEBUG level.
>
>java.lang.IllegalArgumentException: Invalid character
> found in the request target. The valid characters are defined in RFC
> 7230 and RFC 3986
>
>   at
> org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11Inpu
> tBuffer.java:502)
>
>   at
> org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:
> 502)
>
>   at
> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLigh
> t.java:65)
>
>   at
> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractP
> rotocol.java:818)
>
>   at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoi
> nt.java:1623)
>
>   at
> org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase
> .java:49)
>
>   at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.j
> ava:1149)
>
>   at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.
> java:624)
>
>   at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThr
> ead.java:61)
>
>   at java.lang.Thread.run(Thread.java:748)
>
> Thanks!
>
> Nada Aboueata
>
>
>
> Nada Mahmoud Ahmed Aboueata
> Application Developer
> Information Technology Services Department
> Tel.: +974 4403 6369
> Fax: 

Re: Tomcat8.5.53: HTTP requests parsing error

[Mark Thomas]

On 26/05/2021 09:02, Nada Mahmoud Ahmed Aboueata wrote:

Dear all,

We are using Tomcat 8.5.53, and I have been noticing the attached below 
exceptions in my logs. After looking deeply what kind of requests that 
caused these exception, I noticed that some request include Null http 
protocol and some special characters that cannot be handled by Tomcat. 
Also, we have noticed that these kind of requests might crash the web 
server from time-time and caused OutOfMemoryError.


That is highly unlikely. When an invalid request is received, Tomcat 
responds with a 400 response and closes the connection. The opportunity 
for an OOME is slim to nonexistant.


I am not sure if this issue is a bug in Tomcat 8.x that it cannot handle 
these requests, so could you please advise what’s recommended to avoid 
these exceptions?


There error message is clear:

"Invalid character found in the request target. The valid characters are 
defined in RFC 7230 and RFC 3986."


The client is sending an invaild HTTP request and Tomcat is, correctly, 
rejecting it.


The recommended way to address isses such as this is to fix the broken 
clients that are sending invalid HTTP requests.


Mark




02-Mar-2021 01:33:04.846 INFO 
[https-jsse-nio-185.37.108.150-8443-exec-31] 
org.apache.coyote.http11.Http11Processor.service Error parsing HTTP 
request header


Note: further occurrences of HTTP request parsing errors will be logged 
at DEBUG level.


     java.lang.IllegalArgumentException: Invalid character found in 
the HTTP protocol


     at 
org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:567)


     at 
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:502)


     at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)


     at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:818)


     at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1623)


     at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)


     at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)


     at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)


     at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)


     at java.lang.Thread.run(Thread.java:748)

24-May-2021 23:04:00.693 INFO 
[https-jsse-nio-185.37.108.150-8443-exec-309] 
org.apache.coyote.http11.Http11Processor.service Error parsing HTTP 
request header


Note: further occurrences of HTTP request parsing errors will be logged 
at DEBUG level.


   java.lang.IllegalArgumentException: Invalid character 
found in the request target. The valid characters are defined in RFC 
7230 and RFC 3986


  at 
org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:502)


  at 
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:502)


  at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)


  at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:818)


  at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1623)


  at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)


  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)


  at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)


  at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)


  at java.lang.Thread.run(Thread.java:748)

Thanks!

Nada Aboueata



Nada Mahmoud Ahmed Aboueata
Application Developer
Information Technology Services Department
Tel.: +974 4403 6369
Fax: +974 4403 3401
Qatar University QU on Facebook 
 QU on Twitter 
 QU on YouTube 
 QU on LinkedIn 
 QU on Instagram 
 QU on Google+ 
 	


*Our Vision:* To be regionally recognized for distinctive excellence in 
education and research, an institution of choice for students and 
scholars and a catalyst for the sustainable socio-economic development 
of Qatar.


*رؤيتنا*: أن تعرف جامعة قطر إقليمياً بتميزها النوعي في التعليم والبحث 
وبكونها الخيار المفضل لطلبة العلم والباحثين ومحفزاً للتنمية 

Tomcat8.5.53: HTTP requests parsing error

[Nada Mahmoud Ahmed Aboueata]

Dear all,

We are using Tomcat 8.5.53, and I have been noticing the attached below 
exceptions in my logs. After looking deeply what kind of requests that caused 
these exception, I noticed that some request include Null http protocol and 
some special characters that cannot be handled by Tomcat. Also, we have noticed 
that these kind of requests might crash the web server from time-time and 
caused OutOfMemoryError.

I am not sure if this issue is a bug in Tomcat 8.x that it cannot handle these 
requests, so could you please advise what’s recommended to avoid these 
exceptions?

02-Mar-2021 01:33:04.846 INFO [https-jsse-nio-185.37.108.150-8443-exec-31] 
org.apache.coyote.http11.Http11Processor.service Error parsing HTTP request 
header
Note: further occurrences of HTTP request parsing errors will be logged at 
DEBUG level.
java.lang.IllegalArgumentException: Invalid character found in the HTTP 
protocol
at 
org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:567)
at 
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:502)
at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:818)
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1623)
at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)

24-May-2021 23:04:00.693 INFO [https-jsse-nio-185.37.108.150-8443-exec-309] 
org.apache.coyote.http11.Http11Processor.service Error parsing HTTP request 
header
Note: further occurrences of HTTP request parsing errors will be logged at 
DEBUG level.
  java.lang.IllegalArgumentException: Invalid character found in 
the request target. The valid characters are defined in RFC 7230 and RFC 3986
 at 
org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:502)
 at 
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:502)
 at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
 at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:818)
 at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1623)
 at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
 at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
 at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
 at java.lang.Thread.run(Thread.java:748)


Thanks!

Nada Aboueata



Nada Mahmoud Ahmed Aboueata
Application Developer
Information Technology Services Department
Tel.: +974 4403 6369
Fax: +974 4403 3401
[Qatar University][QU on 
Facebook] [QU on Twitter] 
  [QU on YouTube] 
  [QU on LinkedIn] 
  [QU on Instagram] 
  [QU on Google+] 


Our Vision: To be regionally recognized for distinctive excellence in education 
and research, an institution of choice for students and scholars and a catalyst 
for the sustainable socio-economic development of Qatar.

رؤيتنا: أن تعرف جامعة قطر إقليمياً بتميزها النوعي في التعليم والبحث وبكونها 
الخيار المفضل لطلبة العلم والباحثين ومحفزاً للتنمية الاقتصادية والاجتماعية 
المستدامة لدولة قطر.

RE: [External] Re: Zip file upload corruption on Linux

[Scott,Tim]

Hi Chris,

> Mine is coming up on 20 years old.
That's worthy of an extra slice of cake :-).

> The code you posted shows imports and then your interaction with the 
> fileupload library. Do you know what else happens before this line of code?

>  ServletRequestContext requestContext = new ServletRequestContext(/* 
> HttpServletRequest  */ request);

I've now reverted my changes to the latest SVN checkin from when I adjusted the 
code to avoid deprecated methods to try to remedy this problem and that line no 
longer exists.

> Can you reproduce this in a testing environment? I'll bet we can write a 
> Filter or Valve which can catch this bug red-handed.

I'd love to have the time to do this, but my motivation to do so has all but 
been killed by pragmatism.

I could send you the two Java classes off-list if you'd like to speculate 
further?

Thanks,
Tim


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