DataSteam
Datastream
while in kinderGarten I was informed
that the datastream or what is known in modern times as the URL is
divide up in three parts
HEAD contains destination and origin IP address
BODY contains the data index.html
TAIL checksum – the total number of bytes in the BODY. For
developer to checksum non got lost on the way.
TOR Network
The TOR a consumer protection programme works only with one part of
the URL.
The HEAD.
Once the URL arrives in the TOR network the origin IP address is
extracted and the local ip origin is replaced.
So then the website cannot track the origin of the IP.
Unless you are dumb enough to login into the website.
URL is then sent back to TOR because of IP address given to website
by TOR in URL
On return from website to TOR the IP is again replaced with its
local TOR ip
with the original IP so it can find itself back home.
Tomcat has been given access to the URL body but not the URL HEAD.
By IANA.org
For apache tomcat to give access to martha fockers like the pony tail
and his employers letsencrypt.org
and the longest troll.
is a clear violation and abuse of privilege and consumer protection.
That is what you are stand accused of what say you ?
How do you plead guilt or not guilty ?
Regards
backbutton.co.uk
Masters of Industrial Strength Software
p { margin-bottom: 0.25cm; line-height: 115%; background:
transparent }
Re: Query Related to org.apache.catalina.security.SecurityListener
Thanks Martin! If I will keep on commenting this line, then what will be the impact of the same on the application. Please let me know so that we can plan it accordingly. Regards Kushagra On Tue, May 19, 2020, 11:55 AM Martin Grigorov wrote: > Hi, > > On Mon, May 18, 2020 at 7:38 PM Kushagra Bindal > > wrote: > > > Hi, > > > > We are planning to upgrade from apache tomcat from 8.5.24 to 8.5.53 > > version. During this process I found that in catalina.sh file below line > > which was commented in 8.5.24 version > > > > # Uncomment the following line to make the umask available when using the > > # org.apache.catalina.security.SecurityListener > > #JAVA_OPTS="$JAVA_OPTS > > -Dorg.apache.catalina.security.SecurityListener.UMASK=`umask`" > > > > Has now been uncommented into 8.5.53 version. > > > > # Make the umask available when using the > > org.apache.catalina.security.SecurityListener > > JAVA_OPTS="$JAVA_OPTS > > -Dorg.apache.catalina.security.SecurityListener.UMASK=`umask`" > > > > Is there any specific reason behind this? > > > > > https://github.com/apache/tomcat/commit/b9a64cf7bd75e9c80d2913b818393ea89ec14ddc > This is the commit. > It is like this since 8.5.30 > > > > > > -- > > Regards, > > Kushagra > > >
Tomcat 8.5 appends null characters
Dear collective wisdom, as the EOL of Tomcat 7 is looming, we are migrating our legacy app from Tomcat 7.0 to Tomcat 8.5. We deploy exactly the same war in both versions. For some reason Tomcat 8.5 adds null characters to the end of JavaScript files. For instance, jQuery file served by Tomcat 8.5 ends with “})( window ); �” where five last characters are bytes 00. Tomcat 7.0 serves the same file correctly. In case it matters, the issue occurs in both windows 10 and windows server 2016 environments. I assume this has something to do with character encoding. Original js-file is cp1252. I have perused Tomcat 8 migration guide and Tomcat encoding FAQ and experimented with the various options but so far with no luck. Any advice is greatly appreciated. Tuukka
Re: Tomcat 8.5 appends null characters
Hi, On Tue, May 19, 2020 at 3:32 PM Tuukka Ilomäki wrote: > Dear collective wisdom, > as the EOL of Tomcat 7 is looming, we are migrating our legacy app from > Tomcat 7.0 to Tomcat 8.5. We deploy exactly the same war in both versions. > For some reason Tomcat 8.5 adds null characters to the end of JavaScript > files. For instance, jQuery file served by Tomcat 8.5 ends with “})( window > ); �” where five last characters are bytes 00. Tomcat 7.0 serves the > same file correctly. In case it matters, the issue occurs in both windows > 10 and windows server 2016 environments. > > I assume this has something to do with character encoding. Original > js-file is cp1252. I have perused Tomcat 8 migration guide and Tomcat > encoding FAQ and experimented with the various options but so far with no > luck. Any advice is greatly appreciated. > I'd advise you to convert your files to UTF-8. Or tell Tomcat to write responses in your preferred encoding. > > Tuukka > >
Re: Query Related to org.apache.catalina.security.SecurityListener
Hi Kushagra, On Tue, May 19, 2020 at 3:14 PM Kushagra Bindal wrote: > Thanks Martin! > > If I will keep on commenting this line, then what will be the impact of the > same on the application. > > Please let me know so that we can plan it accordingly. > Look at https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/security/SecurityListener.java It is used only at start time. If Tomcat starts fine then all is good! If it throws an Error then you will need to fix the issue. > > > Regards > Kushagra > > On Tue, May 19, 2020, 11:55 AM Martin Grigorov > wrote: > > > Hi, > > > > On Mon, May 18, 2020 at 7:38 PM Kushagra Bindal < > bindal.kusha...@gmail.com > > > > > wrote: > > > > > Hi, > > > > > > We are planning to upgrade from apache tomcat from 8.5.24 to 8.5.53 > > > version. During this process I found that in catalina.sh file below > line > > > which was commented in 8.5.24 version > > > > > > # Uncomment the following line to make the umask available when using > the > > > # org.apache.catalina.security.SecurityListener > > > #JAVA_OPTS="$JAVA_OPTS > > > -Dorg.apache.catalina.security.SecurityListener.UMASK=`umask`" > > > > > > Has now been uncommented into 8.5.53 version. > > > > > > # Make the umask available when using the > > > org.apache.catalina.security.SecurityListener > > > JAVA_OPTS="$JAVA_OPTS > > > -Dorg.apache.catalina.security.SecurityListener.UMASK=`umask`" > > > > > > Is there any specific reason behind this? > > > > > > > > > > https://github.com/apache/tomcat/commit/b9a64cf7bd75e9c80d2913b818393ea89ec14ddc > > This is the commit. > > It is like this since 8.5.30 > > > > > > > > > > -- > > > Regards, > > > Kushagra > > > > > >
Re: Tomcat 8.5 appends null characters
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Martin, On 5/19/20 09:50, Martin Grigorov wrote: > Hi, > > On Tue, May 19, 2020 at 3:32 PM Tuukka Ilomäki > wrote: > >> Dear collective wisdom, as the EOL of Tomcat 7 is looming, we are >> migrating our legacy app from Tomcat 7.0 to Tomcat 8.5. We deploy >> exactly the same war in both versions. For some reason Tomcat 8.5 >> adds null characters to the end of JavaScript files. For >> instance, jQuery file served by Tomcat 8.5 ends with “})( window >> ); �” where five last characters are bytes 00. Tomcat 7.0 >> serves the same file correctly. In case it matters, the issue >> occurs in both windows 10 and windows server 2016 environments. >> >> I assume this has something to do with character encoding. >> Original js-file is cp1252. I have perused Tomcat 8 migration >> guide and Tomcat encoding FAQ and experimented with the various >> options but so far with no luck. Any advice is greatly >> appreciated. >> > > I'd advise you to convert your files to UTF-8. Or tell Tomcat to > write responses in your preferred encoding. Tailing nulls might also be a misinterpreted chunked response. (I'm grasping at straws, here). Tuukka, is your client communicating directly with Tomcat, or through some kind of proxy or load balancer? I've been using the same product with Tomcat since the 4.1 series, and I upgraded through every single major version from there to 9.0. I've never seen anything like that. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7ESsgACgkQHPApP6U8 pFgreA//VI1lMAk/P9hnlx1WCU9Uz2Ccb/UYDZe3HVTO4FrjqUkPi3eOC5Zf5nu9 r0AfFRZVpdiih9z4DGPngarxsymqxi8VfIds2HJcGtbYtJ4Kxt1WBUBCB//EmzSr YU70a6LL3IzbWecV641497JvfASFTCc7LUTbO6D48RFezoPPD+g3tAhPLsUNtOr9 hBD8nINL+g4HTUb5uA0+N60Sjp81BXLlYbnX5FGzAwxicZtgLkGir/au0yqWEOTC kZ+ejPUKpYw4ingWrlv4iY6+3EPLsi2jiTu+nLkiHKmcVvcxVkWt3m+KpvVWef14 78WFHPMBeBhgt4vpX37+YSkeVUVqr+NyX2Fyp/6mW8cyXFgYIi7C4YAyLpF7zeNz 3xRll64nvGnKghD/jbiHUr1prqwECXUFNKfPBK2XBL7k1h1I7eRzUtkUIbmwWQ6T LwmwY3LXQ1+TLoISppQ5Cb27z3SfPVqi/2dFXbdqiLF2VOpCNKJl1qSDtlVEN5Az qMKInNfegUoHAvznFclJX/3pFEhdA1l+LWbpd1zVbOMfm9ZCAi0dUtW75NTuP/Ur 43NGSXbxiblrq0xhxY+qVbEs9lnz9vhK9wRApSdBfN7/errej1IAXhKk9lFgJx4K O5I3nIfT2BtHIKj5eDDTlYJfTlvRkkzAV4MPGPmBjVHdvAWmfsw= =JiQr -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Strange occurrence with Tomcat running on an AWS EC2 instance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 James, On 5/18/20 18:47, James H. H. Lampert wrote: > I'm hoping to get the one web server we still have on a cert we > have to pay for switched over to Let's Encrypt, and so I cloned the > server in question to a spot instance. > > The server in question is an EC2 instance running Amazon Linux > (not Amazon Linux 2), with a Bitnami Trac/SVN stack on it, and > Tomcat 8 installed independently of the Bitnami stack. > > To clone it, I created an AMI from the most recent backup snapshot, > and then launched a spot instance from that AMI. Presumably, this latest snapshot was working at the time of the snapshot ? > Once the test instance spun up, when I was finally able to connect > to the Tomcat server on it, I found that (1) it had been updated Updated to what? > (2) the ROOT context had been partially overwritten with the > default ROOT context, and (3) the manager context had been returned > to the "factory" disabled state. > > To coin a phrase, "What just happened?" Hmm. Any idea if that AMI tries to bootstrap itself in some way -- like for example trying to update software, deploy applications, etc.? If Tomcat was updated (probably with something heavy-handed, such as un-tarring the latest over time of /opt/tomcat or whatever), perhaps it overwrote the ROOT context? I don't think this is anything that Tomcat would ever do to itself, but we can maybe help you discover how your own AMI works and prevent it from doing that kind of thing again One initial recommendation I would have for you is to always have a "split installation" where Tomcat is installed one place, and your "deployment" (conf/, work/, logs/ and webapps/ directories) are all in a separate place. This way, if Tomcat is (unexpectedly) upgraded, you will not have to worry so much about your applications and/or configurations from being clobbered. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7ETEcACgkQHPApP6U8 pFixww/5AeUSvUOWLgqL2Jv9WQ7LYxIV/rCoZrNqFSu99/DXxq6/oBFALJtYz5Ze 6RhDyyMocmkOT+bngR+c4IUctwvmjyxAuHh6qdisL2Ftdzrra6wS5jscJgn7wHi/ NqToyDrgVzWknX0BYWflpO7KRVJBR4Y1yDMR8DD/LmFsTBbXBJKDjPycKcDnTtcJ HU+y2gXb+j7IMREJMRl95lznBKXqaBx0wV3zTPKrAOaIvbnpYiwX8YJXnx1oRpvB X4gtyPLWoYZU9WbKsZZj2djB8cbdUZQXmaE+FUg2Lx3TF/AzBHsXaplBP85KzbNY poUAf+Jld71ZSD1TW251Fnr8l04sF3ozb5R9EPTMpsu4Yj2SooTsU5wc2vb+3MvG GhiSTOZ+f+o5RBzkN83rADHIdXcPHKgrsCmrPHyqWRfmUuoU0CNObsC9llDHBDY2 vEqu/AyHRIbhzVMCO9fQ+2WY69uJ8yBr1UTLwmCKMcr05AeMWB5DTmNFubXcuaxw T2AeEe6WbX209U9TG/xYMxRTDtPD6bBj/Doa2/kKY/jaFNkx6xMkZ949PGR+32z1 ODxhaRrKfe+i/E78qvtRjpNRBIxjKp7YG8z6bpTFTO9n7N7pSfUhWfFxQZL+Wf8t sa3mZMiKloAX4IHtvmo8fGdM2s3ggmSaCWOMpEgexguxf2CNgg4= =flMV -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: RST on TCP level sent by Tomcat
Hi Team , 1.We are facing a problem where tomcat is closing the http2 connections silently without sending GOAWAY and FIN. Under what cases does this happen ? 2. What happens when maxkeepaliverequests reaches the configured limit, will it close connections silently? 3. What happens when max Connections is reached, will it close older connections? 4. Currently we see keepalive timeout is default 20 seconds, but the connection is not closed after that. For requests received after 3 hours also we are sending response .Is there any way to close idle-connections ? Embedded Tomcat : 9.0.22 Thanks and Regards Arshiya Shariff -Original Message- From: Arshiya Shariff Sent: Monday, May 18, 2020 4:45 PM To: Mark Thomas ; users@tomcat.apache.org Cc: M Venkata Pratap M Subject: RE: RST on TCP level sent by Tomcat Hi Mark, Thank you for the quick response. Please provide us a little more clarity on the 3rd query : 3. We see that RST is sent by tomcat on receiving http2 request, when does this happen ? >>> When things go wrong. E.g. when the client sends a request to a connection >>> that has been closed. Why does tomcat not send GOAWAY on connection close, upon next request from client it sends RST ? Also, Can you please send us the references to the timeout related fixes in 9.0.35 (since 9.0.22). Thanks and Regards Arshiya Shariff -Original Message- From: Mark Thomas Sent: Monday, May 18, 2020 4:17 PM To: users@tomcat.apache.org Subject: Re: RST on TCP level sent by Tomcat On 18/05/2020 11:01, Arshiya Shariff wrote: > Hi Team, > > Can you please help us with the below queries : There have been various timeout related fixes since 9.0.22. Please upgrade to 9.0.35 and re-test. > 1. When does a http2 connection close ? We see that the > keepAliveTimeout is > 20 seconds by default, but it is not closing the connection on > keepAliveTimeout. Please re-test with 9.0.35. > 2. How to keep the connections alive / How to enable ping frames to be > sent to the other end to keep the connection alive ? There is no standard API to send an HTTP/2 ping. If you want to keep the connections alive for longer, use a longer keep-alive setting. > 3. We see that RST is sent by tomcat on receiving http2 request, when > does this happen ? When things go wrong. E.g. when the client sends a request to a connection that has been closed. > 4. What are the recommended ipv4.tcp settings for these kind of scenarios ? There are no recommended settings. Mark > > > > Embedded Tomcat : 9.0.22 > > Java Version : 1.8.0.201 > > Hardware : Red Hat Enterprise Linux Server release > 7.4 > > > > Thanks and Regards > > Arshiya Shariff > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
