Re: Fwd: SSL Configuration Help :

Elavarasan, On 10/6/23 06:32, Elavarasan Pugazhendi wrote: Hi, I have a pfx certificate and am trying to import it into a keystore before configuring it within the tomcat but not able to add the pfx certificate. I followed the below steps but wasn't able to add the certificate Tomcat: 9.0.62

Re: Fwd: users Digest 17 Aug 2022 09:26:06 -0000 Issue 14393 - "BLANK" DIGEST MESSAGE ATTACHMENTS

On 9/8/2022 9:45 AM, Berneburg, Cris J. - US wrote: 2. Also, some digest messages are blank for me, but other folks' replies to them are not. It's often original messages from specific users. Maybe we can compare what we see. Not using multiple client apps, I don't know if the blankness is

RE: Fwd: users Digest 17 Aug 2022 09:26:06 -0000 Issue 14393 - "BLANK" DIGEST MESSAGE ATTACHMENTS

Terence > I created an issue for the blank digest messages: > https://issues.apache.org/jira/browse/INFRA-23675 > which appears to be due a missing CRLF sequence following > the header section. It's currently "WAITING FOR INFRA" so > I don't think anyone has had a chance to look at it. Thanks

Re: Fwd: users Digest 17 Aug 2022 09:26:06 -0000 Issue 14393 - "BLANK" DIGEST MESSAGE ATTACHMENTS

On 9/8/2022 8:55 AM, Berneburg, Cris J. - US wrote: Hi Terence I have similar issues. First, I was suddenly unable to send e-mail to the list using an e-mail address that I have used on the list since at least 2005, as mentioned above. I got around this by (re)subscribing to both users and

RE: Fwd: users Digest 17 Aug 2022 09:26:06 -0000 Issue 14393 - "BLANK" DIGEST MESSAGE ATTACHMENTS

> 2. Also, some digest messages are blank for me, but other > folks' replies to them are not. It's often original messages > from specific users. Maybe we can compare what we see. > Not using multiple client apps, I don't know if the blankness > is due to client app misinterpretation or if the

RE: Fwd: users Digest 17 Aug 2022 09:26:06 -0000 Issue 14393 - "BLANK" DIGEST MESSAGE ATTACHMENTS

Hi Terence I have similar issues. > First, I was suddenly unable to send e-mail to the list using an > e-mail address that I have used on the list since at least 2005, > as mentioned above. I got around this by (re)subscribing to both > users and users-digest. This may be why you found my e-mail

Re: Fwd: users Digest 17 Aug 2022 09:26:06 -0000 Issue 14393 - "BLANK" DIGEST MESSAGE ATTACHMENTS

On 9/7/2022 1:35 AM, Mark Thomas wrote: On 07/09/2022 04:22, Terence M. Bandoian wrote: It looks like there's something going on with the CRLF sequence that should separate the header section from the body in digest attachments. However, it's difficult to tell where it's happening.  From

Re: Fwd: users Digest 17 Aug 2022 09:26:06 -0000 Issue 14393 - "BLANK" DIGEST MESSAGE ATTACHMENTS

On 07/09/2022 04:22, Terence M. Bandoian wrote: It looks like there's something going on with the CRLF sequence that should separate the header section from the body in digest attachments. However, it's difficult to tell where it's happening. From RFC 5322:    A message consists of header

Re: Fwd: users Digest 17 Aug 2022 09:26:06 -0000 Issue 14393 - "BLANK" DIGEST MESSAGE ATTACHMENTS

On 9/6/2022 6:00 PM, Terence M. Bandoian wrote: On 8/23/2022 1:47 AM, Mark Thomas wrote: On 23/08/2022 02:45, Terence M. Bandoian wrote: Recently, message attachments that appear blank in my e-mail client have been included in the Tomcat users mailing list digest.  Some users' messages are

Re: Fwd: users Digest 17 Aug 2022 09:26:06 -0000 Issue 14393 - "BLANK" DIGEST MESSAGE ATTACHMENTS

On 8/23/2022 1:47 AM, Mark Thomas wrote: On 23/08/2022 02:45, Terence M. Bandoian wrote: Recently, message attachments that appear blank in my e-mail client have been included in the Tomcat users mailing list digest.  Some users' messages are normally not blank (e.g. Tomcat committers and

Re: Fwd: users Digest 17 Aug 2022 09:26:06 -0000 Issue 14393 - "BLANK" DIGEST MESSAGE ATTACHMENTS

On 23/08/2022 02:45, Terence M. Bandoian wrote: Recently, message attachments that appear blank in my e-mail client have been included in the Tomcat users mailing list digest.  Some users' messages are normally not blank (e.g. Tomcat committers and others). Messages from other users are. 

Re: Fwd: tomcat 9.50 - rewrite rule question

Rupali, On 3/25/22 11:28, rupali singh wrote: hi chris, Apologies for typo mistakes. business user are using url : https://xyz.ae/apex/f?p=1001 to login into apex application and login is working fine. xyz.ae is published in our F5 which is pointing to

Re: Fwd: tomcat 9.50 - rewrite rule question

hi chris, Apologies for typo mistakes. business user are using url : https://xyz.ae/apex/f?p=1001 to login into apex application and login is working fine. xyz.ae is published in our F5 which is pointing to tomcat server on port 8080 hence im not worried

Re: Fwd: tomcat 9.50 - rewrite rule question

Rupali, This has gone around in circles for a while with no progress. Can you please: 1. Show examples of what you would like. Specific examples, like: "I expect that when requesting http://xyz.ae/apex/?f=1001; I get a 302 redirect to http://xyz.ae/apex/myapp; That's what you are asking

Re: Fwd: tomcat 9.50 - rewrite rule question

On 3/24/22 13:27, Peter Chiu wrote: Application builder->Your application->Shared Components->Application Definition Attributes->Properties->Friendly URLs And that does what, exactly? - To unsubscribe, e-mail:

Re: Fwd: tomcat 9.50 - rewrite rule question

Application builder->Your application->Shared Components->Application Definition Attributes->Properties->Friendly URLs On Thu, Mar 24, 2022 at 3:25 PM rupali singh wrote: > Hi, > > How we can enable friendly url in apex? > > > > On Fri, Mar 25, 2022, 12:48 AM Peter Chiu wrote: > > > Have you

Re: Fwd: tomcat 9.50 - rewrite rule question

Hi, How we can enable friendly url in apex? On Fri, Mar 25, 2022, 12:48 AM Peter Chiu wrote: > Have you consider doing the following > 1. custom URL/domain, and > 2. enable Friendly URLs in APEX > > On Thu, Mar 24, 2022 at 3:09 PM Felix Schumacher < > felix.schumac...@internetallee.de>

Re: Fwd: tomcat 9.50 - rewrite rule question

Have you consider doing the following 1. custom URL/domain, and 2. enable Friendly URLs in APEX On Thu, Mar 24, 2022 at 3:09 PM Felix Schumacher < felix.schumac...@internetallee.de> wrote: > > Am 24.03.22 um 19:23 schrieb rupali singh: > > hi, > > yes context name is apex. > > Good to know. > >

Re: Fwd: tomcat 9.50 - rewrite rule question

Am 24.03.22 um 19:23 schrieb rupali singh: hi, yes context name is apex. Good to know. https://xyz.ae/apex/f?p=1001 to https://xyz.ae/apex/myapp we dont want to change xyz.ae that will name remain as it is , we want to

Re: Fwd: tomcat 9.50 - rewrite rule question

hi, yes context name is apex. https://xyz.ae/apex/f?p=1001 to https://xyz.ae/apex/myapp we dont want to change xyz.ae that will name remain as it is , we want to change f?p=1001 to myapp On Wed,

Re: Fwd: tomcat 9.50 - rewrite rule question

Am 23. März 2022 12:14:25 MEZ schrieb rupali singh : >Hi Chris, > >I already tried with fully qualified name but its not working Can you be more specific, what you tried? Is Chris right and your context name is apex? Felix > >On Tue, Mar 22, 2022, 7:15 PM Christopher Schultz <

Re: Fwd: tomcat 9.50 - rewrite rule question

Hi Chris, I already tried with fully qualified name but its not working On Tue, Mar 22, 2022, 7:15 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > All, > > On 3/21/22 10:19, Felix Schumacher wrote: > > > > Am 21.03.22 um 06:39 schrieb rupali singh: > >> Hi Felix, > >> > >>

Re: Fwd: tomcat 9.50 - rewrite rule question

All, On 3/21/22 10:19, Felix Schumacher wrote: Am 21.03.22 um 06:39 schrieb rupali singh: Hi Felix, location of context.xml file is cat context.xml| grep RewriteValve pwd /opt/tomcat/apache-tomcat-9.0.54/instance/conf That context.xml is thought to be a default template for all

Re: Fwd: tomcat 9.50 - rewrite rule question

ass (just with a little dummy app deployed). Greetings, Thomas -Ursprüngliche Nachricht- Von: rupali singh Gesendet: Sonntag, 20. März 2022 19:23 An: Tomcat Users List Betreff: Re: Fwd: tomcat 9.50 - rewrite rule question Hi, i have referred Around here:https://tomcat.apache.org/tomca

Re: Fwd: tomcat 9.50 - rewrite rule question

> Von: rupali singh > Gesendet: Sonntag, 20. März 2022 19:23 > An: Tomcat Users List > Betreff: Re: Fwd: tomcat 9.50 - rewrite rule question > > Hi, > > i have referred Around > here:https://tomcat.apache.org/tomcat-9.0-doc/rewrite.html#RewriteRule > but still can

Re: Fwd: tomcat 9.50 - rewrite rule question

). Greetings, Thomas -Ursprüngliche Nachricht- Von: rupali singh Gesendet: Sonntag, 20. März 2022 19:23 An: Tomcat Users List Betreff: Re: Fwd: tomcat 9.50 - rewrite rule question Hi, i have referred Around here: https://tomcat.apache.org/tomcat-9.0-doc/rewrite.html#RewriteRule but still

Re: Fwd: tomcat 9.50 - rewrite rule question

be to use the source code of tomcat and set a breakpoint within the filter class (just with a little dummy app deployed). Greetings, Thomas -Ursprüngliche Nachricht- Von: rupali singh Gesendet: Sonntag, 20. März 2022 19:23 An: Tomcat Users List Betreff: Re: Fwd: tomcat 9.50 - rewrite rule

Re: Fwd: tomcat 9.50 - rewrite rule question

Am 19.03.22 um 07:03 schrieb rupali singh: Hi Team, We are using tomcat 9.54 version. Need help in rewriting rule. background : We have an Oracle apex server ( version 21.1) and tomcat is installed on the same server. We have F5 url which redirects to apex installed on tomcat

Re: Fwd: tomcat 9.50 - rewrite rule question

].level = FINE > > Should spit out plenty of information in one of the logfiles. > > > > -Ursprüngliche Nachricht- > > Von: rupali singh > > Gesendet: Sonntag, 20. März 2022 20:17 > > An: Tomcat Users List > > Betreff: Re: Fwd: tomcat 9.50 - rewrite

Re: Fwd: tomcat 9.50 - rewrite rule question

t: Sonntag, 20. März 2022 19:23 > > An: Tomcat Users List > > Betreff: Re: Fwd: tomcat 9.50 - rewrite rule question > > > > Hi, > > > > i have referred Around here: > > https://tomcat.apache.org/tomcat-9.0-doc/rewrite.html#RewriteRule > > but still can'

Re: Fwd: tomcat 9.50 - rewrite rule question

roll down the documentation. > Around here: > https://tomcat.apache.org/tomcat-9.0-doc/rewrite.html#RewriteRule > If something is not clear there, just drop a line > > > > -Ursprüngliche Nachricht- > > Von: rupali singh > > Gesendet: Samstag, 19. März 2022 18:28

Re: Fwd: tomcat 9.50 - rewrite rule question

Hi, Thanks a lot for your quick response.then what options we have in tomcat apache for rewrite rules. Apologies im new to apache tomcat. On Sat, Mar 19, 2022, 9:42 PM Terence M. Bandoian wrote: > On 3/19/2022 1:03 AM, rupali singh wrote: > > Hi Team, > > > > We are using tomcat 9.54

Re: Fwd: tomcat 9.50 - rewrite rule question

On 3/19/2022 1:03 AM, rupali singh wrote: Hi Team, We are using tomcat 9.54 version. Need help in rewriting rule. background : We have an Oracle apex server ( version 21.1) and tomcat is installed on the same server. We have F5 url which redirects to apex installed on tomcat eg

Re: Fwd: [Community] try to add an community growth graph to the website

Hi Mark, Thanks for the guidance! The problem is, I could not get the accurate commit date of each commit in the changelog, especially for those that not bind with bugzilla. If I take it right, the changelog would be the same or a subset of svn log, so I'm not sure if there is anything new I

Re: Fwd: [Community] try to add an community growth graph to the website

On 19/05/2021 22:13, Shuyang Wu wrote: # michaelo, 2018-08-21 04:16:42 -0400 EDT woonsan, 2019-01-08 00:01:45 -0500 EST I'm not familiar with svn at all :( so I'm not sure if I did it correctly. Also, I failed to understand how to search with "provided by ()". I'll appreciate it if you could

Re: Fwd: Jersey libraries 1.18 worked with Tomcat 7 but failing with Tomcat 9 : Root resource classes not getting scanned

Yogish, On 1/29/21 01:24, Yogish Anand wrote: We were using Tomcat 7 and the Jersey libraries 1.18 was able to scan the packages with the below two lines com.sun.jersey.api.core.PackagesResourceConfig.init Scanning for root resource and provider classes in the packages: v1

Re: Fwd: Re: At least one JAR was scanned for TLDs yet contained no TLDs.

Raivo, On 10/8/20 07:22, Raivo Rebane wrote: > Hello > > if I start standalone tomcat program looks like: > > 17868 ?    Sl 0:02 /usr/lib/jvm/default-java/bin/java > -Djava.util.logging.config.file=/opt/tomcat/latest/conf/logging.properties >

Re: Fwd: Re: At least one JAR was scanned for TLDs yet contained no TLDs.

On Thu, Oct 8, 2020 at 3:31 PM Raivo Rebane wrote: > Hello > > if I start standalone tomcat program looks like: > > 17868 ?Sl 0:02 /usr/lib/jvm/default-java/bin/java > -Djava.util.logging.config.file=/opt/tomcat/latest/conf/logging.properties >

Re: Fwd: Re: At least one JAR was scanned for TLDs yet contained no TLDs.

Hello if I start standalone tomcat program looks like: 17868 ?    Sl 0:02 /usr/lib/jvm/default-java/bin/java -Djava.util.logging.config.file=/opt/tomcat/latest/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager

Re: Fwd: Reverse proxy and SSL redirect

On Wed, Jul 1, 2020 at 3:26 AM Mark Thomas wrote: > > On 01/07/2020 00:41, rugman66 . wrote: > > On Wed, Apr 22, 2020 at 9:21 AM Mark Thomas wrote: > >> > >> On 22/04/2020 00:11, rugman66 . wrote: > >> > >> > >> > >>>Tomcat log (I'm trying to get more debug level logging) > >>>

Re: Fwd: Reverse proxy and SSL redirect

On 01/07/2020 00:41, rugman66 . wrote: > On Wed, Apr 22, 2020 at 9:21 AM Mark Thomas wrote: >> >> On 22/04/2020 00:11, rugman66 . wrote: >> >> >> >>>Tomcat log (I'm trying to get more debug level logging) >>> 2020-04-21 13:39:33 INFO app.CompletionRestController >>>

Re: Fwd: Reverse proxy and SSL redirect

On Wed, Apr 22, 2020 at 9:21 AM Mark Thomas wrote: > > On 22/04/2020 00:11, rugman66 . wrote: > > > > >Tomcat log (I'm trying to get more debug level logging) > > 2020-04-21 13:39:33 INFO app.CompletionRestController > > Unsupported Media Type in Header > > > >

Re: Fwd: Reverse proxy and SSL redirect

On 22/04/2020 00:11, rugman66 . wrote: >Tomcat log (I'm trying to get more debug level logging) > 2020-04-21 13:39:33 INFO app.CompletionRestController > Unsupported Media Type in Header > > Postman >415 Unsupported Media Type > > GET URL >

Re: Fwd: Reverse proxy and SSL redirect

On Sat, Apr 18, 2020 at 1:46 AM Mark Thomas wrote: > > On 17/04/2020 18:15, rugman66 . wrote: > > Made correction to ProxyPass and ProxyPassReverse. > > Good. Changing the context path in the reverse proxy opens up the > possibility for all sorts of breakage and is generally best avoided if > at

Re: Fwd: Reverse proxy and SSL redirect

On 17/04/2020 18:15, rugman66 . wrote: > Made correction to ProxyPass and ProxyPassReverse. Good. Changing the context path in the reverse proxy opens up the possibility for all sorts of breakage and is generally best avoided if at all possible. > I have Apache 2.4.6 running as reverse proxy

Re: Fwd: Tomcat 9.0.31 - BUG

On 03/04/2020 19:04, sathis kumar wrote: > *Tomcat Users List >, * > *"Thans for your reply.. When i tried with simple JSP", "worked. Fine.. > When i tried deploying my other application", "ran into that issue :("* That points to an application problem, not a Tomcat problem. You need to remove

Re: Fwd: Tomcat 9.0.31 - BUG

*Tomcat Users List >, * *"Thans for your reply.. When i tried with simple JSP", "worked. Fine.. When i tried deploying my other application", "ran into that issue :("* javax.servlet.ServletException: javax.el.ELException: Unable to find ExpressionFactory of type: # Licensed to the Apache

Re: Fwd: Tomcat 9.0.31 - BUG

On 03/04/2020 16:33, sathis kumar wrote: > Thanks much for your response. I am using the el-api.jar coming along with > Tomcat9.0.31/lib - Still a sample problem.. > JDK version we are using is - > 1.8 Please provide the simplest possible set of steps to recreate this error from a clean Apache

Re: Fwd: Tomcat 9.0.31 - BUG

Thanks much for your response. I am using the el-api.jar coming along with Tomcat9.0.31/lib - Still a sample problem.. JDK version we are using is - > 1.8 On Fri, Apr 3, 2020 at 11:16 AM Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash:

Re: Fwd: Tomcat 9.0.31 - BUG

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Sathis, You have run across this known bug: https://bz.apache.org/bugzilla/show_bug.cgi?id=64097 Please read that bug report for more details, particularly comment #8. Hope that helps, - -chris On 4/3/20 11:05, sathis kumar wrote: > --

Re: Fwd: Advice please for Tomcat 8.5.53-dev with log4j2

On 18/3/20 5:54 pm, Luis Rodríguez Fernández wrote: Grande Brian, congrats! Sorry, I've just read your message, a bit late to the party: time ago I had cooked a tomcat9 container + log4j2 with a sample spring-boot app deployed. You can have a look here [1] Thanks very much, Luis. Although

Re: Fwd: Advice please for Tomcat 8.5.53-dev with log4j2

Grande Brian, congrats! Sorry, I've just read your message, a bit late to the party: time ago I had cooked a tomcat9 container + log4j2 with a sample spring-boot app deployed. You can have a look here [1] Cheers, Luis [1]

Re: Fwd: Advice please for Tomcat 8.5.53-dev with log4j2

On 18/3/20 5:18 pm, Brian Burch wrote: Could resist tinkering a bit more, but I'll be in trouble because I'm late for dinner!! Success! I have just created the catalina.log file formatted according to my own log4j2.xml. Yes, it was my stupid mistake, but I'll write tomorrow about what

Re: Fwd: Advice please for Tomcat 8.5.53-dev with log4j2

On 18/3/20 2:57 pm, Brian Burch wrote: I have done quite a lot of experiments, but I will stick to the case which appears to have produced the most encouraging(!) results. I stumbled across https://logging.apache.org/log4j/2.x/log4j-appserver/index.html. This short page has significant

Re: Fwd: websocket connections consume too much memory

Hello All, Maybe this behavior is caused by the fact defaultMaxSessionIdleTimeout is not set for websockets? Can be updated as follows final WsServerContainer sc = (WsServerContainer)getServletContext().getAttribute(SERVER_CONTAINER_SERVLET_CONTEXT_ATTRIBUTE); if (sc != null) {

Re: Fwd: websocket connections consume too much memory

I retest with *8.5.38* ... org.apache.tomcat.embed tomcat-embed-websocket ${tomcat-embedded.version} org.apache.tomcat.embed tomcat-embed-core ${tomcat-embedded.version} org.apache.tomcat.embed tomcat-embed-el ${tomcat-embedded.version}

Re: Fwd: websocket connections consume too much memory

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Иналь, On 2/19/19 12:12, Иналь Кятов wrote: > I encountered a problem with embedded tomcat 8.5.29 (part of spring > boot 1.5). Can you retest with the current version of 8.5.x? Current version is 8.5.38, released 2019-02-11. - -chris -BEGIN

Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Pawel, On 2/7/19 19:41, Pawel Veselov wrote: > Sorry for a rather rude intrusion. If you think it's rude, why did you do it? > On Thu, Feb 7, 2019 at 4:18 PM Christopher Schultz > wrote: > >> Chunked encoding is like sending a bunch of small

Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request

Sorry for a rather rude intrusion. On Thu, Feb 7, 2019 at 4:18 PM Christopher Schultz wrote: > Chunked encoding is like sending a bunch of small HTTP message-pieces > (I have to be careful about my wording here, since "part" actually > means something in multipart messages May be just

Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request

< chuck.caldar...@unisys.com> wrote: > > From: Bhavesh Mistry [mailto:mistry.p.bhav...@gmail.com] > > Subject: Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length > Corrupting > > Parsing logic for Subsequent Request > > > I am stating following when you h

Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Bhavesh, On 2/7/19 19:11, Christopher Schultz wrote: > The Content-Length of the PUT request says "I'm going to send 128 > bytes". The server is required to accept exactly 128 bytes, no more > no less. There is another option, here, but also

Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Bhavesh, On 2/7/19 18:40, Bhavesh Mistry wrote: > Hi Mark, > > I understand what you are stating the root of issue originated with > the client (wrong client). I am stating following when you have > request/response on the same TCP connection.

RE: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request

> From: Bhavesh Mistry [mailto:mistry.p.bhav...@gmail.com] > Subject: Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting > Parsing logic for Subsequent Request > I am stating following when you have request/response on the same TCP > connection. for

Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request

Hi Mark, I understand what you are stating the root of issue originated with the client (wrong client). I am stating following when you have request/response on the same TCP connection. for example, My understanding (please correct me if my wrong): Client

Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request

On 07/02/2019 20:05, Bhavesh Mistry wrote: > Hi Mark, > > There is no way to validate the END of a request for PUT call and if > Content-Lenght does not match what client had sent payload body then > rejected it and reset position. You can't do that. The only way to determine how much data to

Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request

Hi Mark, There is no way to validate the END of a request for PUT call and if Content-Lenght does not match what client had sent payload body then rejected it and reset position. If content length does match then reject PUT request, and then close the connection for PUT call not for subsequent

Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request

On 07/02/2019 18:48, Bhavesh Mistry wrote: > Hello Tomcat Developers, > > I have a unique situation about HTTP Protocol PAYLOAD parsing and > Content-Length Header. There is nothing unique here. >  When PUT/POST Content-Length is NOT correct > (client send wrong Content-Lenght), the tomcat is

Re: Fwd: Tomcat question

Zahi, On 30.4.2018. 11:09, Zahi Fail wrote: curl -X POST \ http://localhost:8080/userManagement/rest/Traffic/users2 \ -H 'Authorization: Basic dG9tY2F0OnMzY3JldA==' \ -H 'Cache-Control: no-cache' \ -H 'Content-Type: application/json' \ -H 'Postman-Token:

Re: Fwd: Tomcat question

This is the curl message from postman: curl -X POST \ http://localhost:8080/userManagement/rest/Traffic/users2 \ -H 'Authorization: Basic dG9tY2F0OnMzY3JldA==' \ -H 'Cache-Control: no-cache' \ -H 'Content-Type: application/json' \ -H 'Postman-Token: 71819f33-6206-02c5-5cf2-8de6347fc154'

Re: Fwd: Tomcat question

Zahi, On 25.4.2018. 13:19, zahi.f...@gmail.com wrote: I configured in my conf\server.xml file the realm as below: Ok, so the configuration looks fine. You said you are using Postman to send the request. Can you paste the `curl` command that the postman can generate for you just to check if

Re: Fwd: Content-Type is turned to lower when passed through mod_jk - this looks to be a bug.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 10/15/17 6:54 PM, Mark O'Donohue wrote: > Hi > > Just wanted an opinion on this before I logged a bug report against > mod_jk.c > > > Running our proxied request via mod_jk we are seeing the returned > content-type being changing to all

Re: Fwd: [SECURITY] CVE-2017-12615 Apache Tomcat Remote Code Execution via JSP upload

On 22/09/17 10:36, Maarten van Hulsentop wrote: > I have tried to reproduce this issue on a fresh tomcat 7.0.78 installation. > The issue can indeed easily be reproduced on the default servlet by setting > the readonly property to false. After that, it is possible to PUT the jsp > and the GET

Re: Fwd: [SECURITY] CVE-2017-12615 Apache Tomcat Remote Code Execution via JSP upload

Hello, Op wo 20 sep. 2017 om 09:27 schreef Mark Thomas : > On 19/09/17 14:10, Mark Thomas wrote: > > On 19/09/17 14:00, André Warnier (tomcat) wrote: > >> Hello. > >> > >> Did the issue below also affect the DAV application ? > > > > Yes, as the WebDAV servlet also processes

Re: Fwd: [SECURITY] CVE-2017-12615 Apache Tomcat Remote Code Execution via JSP upload

On 19/09/17 14:10, Mark Thomas wrote: > On 19/09/17 14:00, André Warnier (tomcat) wrote: >> Hello. >> >> Did the issue below also affect the DAV application ? > > Yes, as the WebDAV servlet also processes HTTP PUT requests. > > The WebDAV servlet extends the Default servlet so they actually

RE: Fwd: [SECURITY] CVE-2017-12615 Apache Tomcat Remote Code Execution via JSP upload

- From: Mark Thomas [mailto:ma...@apache.org] Sent: 19 September 2017 14:10 To: Tomcat Users List <users@tomcat.apache.org> Subject: Re: Fwd: [SECURITY] CVE-2017-12615 Apache Tomcat Remote Code Execution via JSP upload On 19/09/17 14:00, André Warnier (tomcat) wrote: > Hello. > > Did

Re: Fwd: [SECURITY] CVE-2017-12615 Apache Tomcat Remote Code Execution via JSP upload

On 19/09/17 14:00, André Warnier (tomcat) wrote: > Hello. > > Did the issue below also affect the DAV application ? Yes, as the WebDAV servlet also processes HTTP PUT requests. The WebDAV servlet extends the Default servlet so they actually share the implementation. > And if yes, also only

Re: Fwd: Bug 56684 - java7: java.net.SocketTimeoutException: Accept timed out

On 06/07/17 13:22, Gagandeep Singh wrote: > Hi All, > > This is regarding the tomcat bug mentioned in subject. I have few questions > as below regarding the same. Could anyone please help me understand. > > - Would this issue only occur when the server has not been accessed for 50 > days, as I

Re: Fwd: tomcat automatically binds it to 0.0.0.0 from 127.0.0.1

Yes, It doesnt happens everytime and cannot reproducable Any guess why this is happening ? On Tue, Jun 20, 2017 at 7:01 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Rakesh, > > On 6/19/17 12:43 AM, Rakesh Java wrote: > >

Re: Fwd: tomcat automatically binds it to 0.0.0.0 from 127.0.0.1

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rakesh, On 6/19/17 12:43 AM, Rakesh Java wrote: > Below is my netstat showing port bindings tcp 0 0 0.0.0.0:1234 > 0.0.0.0:* LISTEN That doesn't show the pid or binary bound to port 1234. With this configuration: I get a socket bound to

Re: Fwd: tomcat automatically binds it to 0.0.0.0 from 127.0.0.1

Hi Chris, Below is my netstat showing port bindings tcp 0 0 0.0.0.0:1234 0.0.0.0:* LISTEN On Fri, Jun 16, 2017 at 9:55 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Rakesh, > > On 6/16/17 5:48 AM, Rakesh Java wrote: > > I

Re: Fwd: tomcat automatically binds it to 0.0.0.0 from 127.0.0.1

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rakesh, On 6/16/17 5:48 AM, Rakesh Java wrote: > I have made a port( example 1234) to be bound to the local host > 127.0.0.1 .But when i restart tomcat automatically binds it to > 0.0.0.0 . > > > And my connector in server.xml contains 127.0.0.1

Re: Fwd: Identifying 64k size violation for __jspService methods loaded by Tomcat

On 01/05/17 20:24, Mohammed Manna wrote: > Hi, > > May be i didn't explain the issue clearly. I am using the same compiler as > Tomcat (JDT compiler, not ANT). Ant isn't a complier. It is a build tool. Ant uses javac (i.e. tools.jar) to build with. > When doing a standalone *ant build*, my >

Re: Fwd: Identifying 64k size violation for __jspService methods loaded by Tomcat

Hi, May be i didn't explain the issue clearly. I am using the same compiler as Tomcat (JDT compiler, not ANT). When doing a standalone *ant build*, my pre-compilation doesn't show any 64k size error for __jspService(). But when I launch the application, it *does* throws error on 64k size on

Re: Fwd: Identifying 64k size violation for __jspService methods loaded by Tomcat

On 29/04/17 11:10, Mohammed Manna wrote: > Hello, > > I have retried using the following javac and jasper settings for my project > (using ANT build) - and it still doesn't reveal those 64K errors even when > the compilers are the same. Isn't that good? Doesn't that mean you've found a solution

Re: Fwd: Identifying 64k size violation for __jspService methods loaded by Tomcat

Hello, I have retried using the following javac and jasper settings for my project (using ANT build) - and it still doesn't reveal those 64K errors even when the compilers are the same.

Re: Fwd: Identifying 64k size violation for __jspService methods loaded by Tomcat

On 26/04/17 10:33, Mohammed Manna wrote: > Hello, > > Thanks for suggesting the solutions. This is closer to what I was expecting > in the original message which I sent in the past. Once again, I apologise > if I have made any Negative/Reactive comments about Apache no being > supportive enough.

Re: Fwd: Identifying 64k size violation for __jspService methods loaded by Tomcat

Hello, Thanks for suggesting the solutions. This is closer to what I was expecting in the original message which I sent in the past. Once again, I apologise if I have made any Negative/Reactive comments about Apache no being supportive enough. I have been using various Apache libraries over the

Re: Fwd: Identifying 64k size violation for __jspService methods loaded by Tomcat

On 26/04/17 09:06, Mohammed Manna wrote: > Hello, > > I have emailed and posted a few questions over the web about this, but > haven't received any helpful response. Since the upgrade to 8.0.39, my web > application is failing in various places since the Jasper compiler has now > got more debug

Re: Fwd: Custom JNDIRealm with Configuration

Am 13.04.2017 um 12:58 schrieb Lucas S. Silva: Hi All, I am implementing a custom JNDIRealm and I need to pass some configurations to it. I tried to pass the configuration via Real configuration and in my code I define the setter and getter for *configurationPattern* but when I debug it

Re: Fwd: Failed to stop component [StandardEngine[Catalina].StandardHost[localhost]

On 29 December 2016 09:56:45 GMT+00:00, Fady Haikal wrote: >Dear Mark, >is this bug is fixed in any version? It hasn't been fixed yet but assuming we follow the usual pattern, it will be fixed for the next set of Tomcat releases in early January. Mark >Regards, >Fady >

Re: Fwd: Failed to stop component [StandardEngine[Catalina].StandardHost[localhost]

Dear Mark, is this bug is fixed in any version? Regards, Fady On Thu, Dec 22, 2016 at 10:22 PM, Mark Thomas wrote: > On 22/12/2016 15:46, Fady Haikal wrote: >> We can see the below error on the log file please advise: > > You are using multiple start/start threads and the RMI

Re: Fwd: Failed to stop component [StandardEngine[Catalina].StandardHost[localhost]

On 22/12/2016 15:46, Fady Haikal wrote: > We can see the below error on the log file please advise: You are using multiple start/start threads and the RMI reference cleaning isn't thread safe. Arguably that is a bug in Tomcat but if you fix the RMI memory leaks in your application you won't hit

Re: Fwd: No longer able to use my own org.apache.catalina.authenticator.BasicAuthenticator in Tomcat 8.5.5

On 03/10/2016 14:20, Johannes Michler wrote: > Hi Mark, > > Thanks a lot for pointing out. Indeed I relied to much that I did not get > any faults and didn't check that part. I'll try with the renamed method > tomorrow, but I'm quite sure that will solve the issue. Great. > Regarding returning

Re: Fwd: No longer able to use my own org.apache.catalina.authenticator.BasicAuthenticator in Tomcat 8.5.5

Hi Mark, Thanks a lot for pointing out. Indeed I relied to much that I did not get any faults and didn't check that part. I'll try with the renamed method tomorrow, but I'm quite sure that will solve the issue. Regarding returning http 403 you suggest to do that in our custom basicauthenticator

Re: Fwd: No longer able to use my own org.apache.catalina.authenticator.BasicAuthenticator in Tomcat 8.5.5

On 01/10/2016 18:50, Johannes Michler wrote: > Hi, > > for our own web-application we overwrite the standard way of how Tomcat > BasicAuthenticator is working in order to avoid the popup of a > "Basic-Auth-Dialog" in some situations (where we're calling a service > provided by the tomcat over a

Re: Fwd: Compiling Tomcat Native 1.2.8

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Pierce, On 9/12/16 4:32 PM, Pierce Allen wrote: > I run a collection Tomcat web servers on Redhat 7.2 (up-to-date) > > Normally we like to compile and use the latest stable version of > Tomcat Native we can get our hands on (currently the one that

Re: Fwd: Compiling Tomcat Native 1.2.8

On 12/09/2016 22:32, Pierce Allen wrote: Hello - I run a collection Tomcat web servers on Redhat 7.2 (up-to-date) Normally we like to compile and use the latest stable version of Tomcat Native we can get our hands on (currently the one that ships with Tomcat 8.5.5.0 is labeled tcnative

Re: Fwd: Fwd: EL Stream API differing from the Java one

On 24/08/2016 07:43, Aritz Maeztu wrote: > I've already posted the issue in StackOverflow: > http://stackoverflow.com/questions/39096941/does-tomcats-el-stream-api-make-sense > > Using Tomcat 8.0.30, I've implemented some EL accesses to the stream > API. However, I've found that this expression:

Re: Fwd: tomcat 8.0 session_id resets in AWS

On 29/06/2016 14:05, Gibu George wrote: > Hi All, > > I'm trying to get tomcat to work in a cluster with sessions being persisted > in mysql, in AWS. I have setup two tomcat servers in the clusters using " > org.apache.catalina.tribes.membership.StaticMember". > > The problem that I am facing is

Re: Fwd: webservice deployment on tomcat 1.7 with JAVA 1.8 is giving deployment errors

2016-05-10 17:34 GMT+03:00 Christopher Schultz : > > Looks like the real error is: > >> Caused by: java.util.ServiceConfigurationError: >> javax.xml.validation.SchemaFactory: >> > jar:file:/C:/Program%20Files%20(x86)/Apache%20Software%20Foundation/Tomc >

  1   2   3   4   >