RE: how to prevent user access to JSP pages?

[Mekkelsen Madden, Steve]

If it helps, I also needed to do something very similar where if the user 
connected to the right server running Tomcat and has the right port but wrong 
context or servlet, they would see a default Tomcat page not found revealing 
the application server used (Tomcat) and its version which for us was a 
security concern.  Reading over previous emails here, I used the filter option:

In the conf/context.xml file and now if the user connects to the wrong url, all 
they'll get is:
HTTP Status 404 -- Not Found
With nothing else revealed so this was perfect for us.  There were other 
changes I needed to make in each servlet to also customize the response 
screens, it was only the invalid ones that were more difficult to figure out 
how to do.

Kind Regards,

Steve Mekkelsen Madden 


-Original Message-
From: Terence M. Bandoian  
Sent: Saturday, August 18, 2018 10:39 PM
To: Tomcat Users List 
Subject: Re: how to prevent user access to JSP pages?

On 8/17/2018 8:52 AM, Christopher Schultz wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Mark,
>
> On 8/17/18 3:54 AM, Mark Thomas wrote:
>> On 16/08/18 18:19, Berneburg, Cris J. - US wrote:
>>> Due to security concerns and general fussiness on my part, I'd like 
>>> to prevent users from requesting JSP pages directly, except for the 
>>> login page.  I want all requests to be handled by servlets.  That 
>>> way I can legitimately claim that all requests are being validated, 
>>> input scrubbed, JSP's cannot be taken advantage of w/o their servlet 
>>> chaperones being present, etc.
>> I'm struggling to understand what risks exists with JSPs that don't 
>> with Servlets. After all, a JSP is just an alternative way to write a 
>> Servlet. Tomcat translates the .jsp file to the .java source for a 
>> servlet, compiles it and runs it.
>>
>> Can you elaborate?
> JSP support for input validation, etc. is basically non-existent. I'm 
> sure someone has a crappy library that can do it, and yes, you can 
> implement everything in JSP using miles of tag libraries and stuff 
> like that, but in the application world, that's a serious no-no.
>
> MVC (or some version of it, under various names) is the "proper" way 
> to build software, and JSPs are relegated to the "V" portion of that 
> paradigm.
>
> Once you have decided that JSPs are squarely in the "V" category, it's 
> no longer appropriate for them to be treated as "C" components and 
> therefore they should not be accessed directly. Protecting them from 
> direct-access is a reasonable decision for a number of reasons, 
> including security if you have pages that cough-up sensitive 
> information under the assumption that authentication and authorization 
> requirements have previously been satisfied.
>
> Sure, the container's authentication and authorization should be able 
> to protect those JSPs just fine, but the application may have other 
> controls in place that also need to sanity-check things before the JSP 
> takes over.
>
> So, while there isn't anything particularly "dangerous" about 
> direct-access to JSPs, there are a number of "best practices" that 
> suggest that hiding them is a good idea.
>
> I hope that helps explain Cris's (likely) reasoning a little more.
>
> - -chris


As far as I know, there is no input validation that can be performed in 
servlets that can't also be performed in JSP pages using the same Java code.  
Also, I'm not aware of any functional limitation that prevents JSP pages 
(classes) from being used as controllers.  As I understand them, JSPs can do 
anything that can be done in servlets and offer additional facilities and 
ease-of-use.  They may be thought of as view-generators only but I don't think 
that's a functional limitation.

Could a servlet filter be used to reject external requests for JSP pages?

-Terence Bandoian


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


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

RE: AT WITS END regarding JVM arguments

[Mekkelsen Madden, Steve]

-Original Message-
From: James H. H. Lampert [mailto:jam...@touchtonecorp.com] 
Sent: Tuesday, September 06, 2016 6:59 PM
To: Tomcat Users List 
Subject: Re: AT WITS END regarding JVM arguments

On 9/6/16, 8:05 AM, Christopher Schultz wrote:

> It's worth noting that, when creating the service from the 
> command-line, the service.bat script will use the current environment 
> to configure the service. That means that CATALINA_HOME and 
> CATALINA_BASE are all used to configure the service.
>
> Unfortunately, CATALINA_OPTS is not used. I'll have a look to see how 
> tough it would be to add CATALINA_OPTS-handling to service.bat... it 
> seems like it would be nice to do that, and fairly easy.

I wouldn't sweat that part. I still think that the best way to deal with the 
situation is to put a prominent warning in the preamble comments of the 
relevant configuration files, explaining that the configuration files are 
ignored when Tomcat is run as a Windows Service, including links to relevant 
online documentation for the configuration utility.

I would say that it's valid to assume that somebody *installing* Tomcat on a 
Windows box, to be run as a service, might reasonably be expected to know about 
how it works, and how to configure it, whereas somebody like me, accustomed to 
other platforms, and who has never had a reason to study the Windows service 
part of the Tomcat docs, would have no reason to know about it.

--
JHHL

I do not agree with that statement. It is rarely if ever, safe to assume 
anything.  For years, that IS what I've done to create the Windows Service.  
Why else would you have a service.bat file if it didn't create the service for 
you??  In prior releases (8.0.* and older), I have never had a problem with 
using this to create the Windows Tomcat Service.  JVM Arguments get added, 
memory settings, arguments etc.  Never a problem.  

If it is not working in 8.5 series, I'd say that's a regression issue to be 
fixed.  Adding a preamble doesn't mean someone won't continue to create 
services this way.  If the service.bat won't do it correctly there are two 
choices - fix it so it does create the service properly or remove it from the 
build and make people use the one that does do it correctly.  An ounce of 
prevention saves a lot of headaches down the road for everyone.  Let's go to 
the root of the issue, not apply a band aid to it.

Steve


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


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

RE: Configuring certificate for ssl support on Tomcat 8.5

[Mekkelsen Madden, Steve]

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Wednesday, August 31, 2016 10:52 AM
To: Tomcat Users List 
Subject: Re: Configuring certificate for ssl support on Tomcat 8.5

On 31/08/2016 15:45, Lazar Kirchev wrote:
> Hello,
> 
> According to Tomcat 8.5 documentation [1] when JSSE is used if the key 
> alias is not specified through the attribute certificateKeyAlias of 
> Certificate entry, then "... the first key read from the keystore will 
> be used...".
> However, when the property is not specified Tomcat tries to use a 
> default key alias (which is "tomcat"). At least I got (on Tomcat 
> 8.5.4)
> java.io.IOException: Alias name tomcat does not identify a key entry
> at
> org.apache.tomcat.util.net.jsse.JSSEUtil.getKeyManagers(JSSEUtil.java:213)
> at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(Abstr
> actJsseEndpoint.java:101)
> 
> Is this the intended behavior?

http://svn.us.apache.org/repos/asf/tomcat/tc8.5.x/trunk/webapps/docs/changelog.xml

http://bz.apache.org/bugzilla/show_bug.cgi?id=59867

Mark

--
I got hit by this bug as well when upgrading from 8.0* to 8.5.3.  Adding 
keyAlias="myaliasname" to the connector in server.xml was sufficient to make it 
work.

Steve


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

RE: Tomcat 8.x JvmOptions parameter length restrictions?

[Mekkelsen Madden, Steve]

Yes, thanks folks.  It does appear to be some syntax validation Notepad++ is 
doing with .bat files.  If you create a test.bat and add 1100 characters and 
save it, from the entire line would be selected in blue.  If you put REM in 
front of the characters, then position 1025 and forward are in blue.  Not sure 
the significant of it but that's what my testing turned out.  At least there 
are no hard fast limits restricting jvm options to 1024 characters only, which 
is what I was hoping was the case.

Regards,

Steve Mekkelsen Madden  |  Systems Engineer Fellow / DBA / Certified Scrum 
Master  | GCS | PMF Operations Support  | Pegasystems Inc.
Office: (617) 866.6023 | Mobile: (828) 729.9948 | Email: 
steve.mekkelsen.mad...@pega.com | www.pega.com


-Original Message-
From: Terence M. Bandoian [mailto:tere...@tmbsw.com] 
Sent: Monday, August 29, 2016 10:48 PM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Tomcat 8.x JvmOptions parameter length restrictions?

On 8/29/2016 8:34 AM, Mekkelsen Madden, Steve wrote:
> I've setup Tomcat 8.5.3 as a Windows Service (configured the service.bat 
> file) and everything appears to be working fine.  I'm trying to find out if 
> there are any restrictions to the overall length of the parameters which can 
> be used in the service.bat for --JvmOptions " " ^ line.  This isn't specific 
> to Tomcat 8.5.3 as I saw the same in 8.0.x versions as well.  So it may just 
> be NotePad++ doing something funky.
>
> What I'm seeing when using NotePad++, is at column 1024 the text looks 
> fine.  But for 16 characters after that, the text appears in light 
> blue and the remaining line looks okay.  I can't tell if there is a 
> setting in NotePad++ that is simply identifying the first 1024 
> characters or if the validate for the service.bat file is catching 
> something I should be aware of.  Since this email is text only, it is 
> hard to show it, so I've taken a screen shot and pasted it here: 
> https://postimg.org/image/gv29etcdf/
>
> I don't have any good way to verify if all the parameters did in fact load 
> properly, so reaching out to others to see if they have the same issue and/or 
> know how to resolve it.
>
> Thanks,
> Steve Mekkelsen Madden
>


The Tomcat Service Manager GUI may be used to set Tomcat system properties.  
The Tomcat 32-bit/64-bit Windows Service Installer creates a shortcut to the 
GUI in the Windows start menu named "Configure Tomcat".  The executable for the 
service manager GUI is located in the Tomcat bin directory and named 
Tomcatw.exe.  It is also included in the 32-bit and 64-bit Windows zip 
downloads.

In addition, system properties may be set in catalina.properties which is 
located in the Tomcat conf directory.

Hope that helps.

-Terence Bandoian
  http://www.tmbsw.com/


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

Tomcat 8.x JvmOptions parameter length restrictions?

[Mekkelsen Madden, Steve]

I've setup Tomcat 8.5.3 as a Windows Service (configured the service.bat file) 
and everything appears to be working fine.  I'm trying to find out if there are 
any restrictions to the overall length of the parameters which can be used in 
the service.bat for --JvmOptions " " ^ line.  This isn't specific to Tomcat 
8.5.3 as I saw the same in 8.0.x versions as well.  So it may just be NotePad++ 
doing something funky.

What I'm seeing when using NotePad++, is at column 1024 the text looks fine.  
But for 16 characters after that, the text appears in light blue and the 
remaining line looks okay.  I can't tell if there is a setting in NotePad++ 
that is simply identifying the first 1024 characters or if the validate for the 
service.bat file is catching something I should be aware of.  Since this email 
is text only, it is hard to show it, so I've taken a screen shot and pasted it 
here: https://postimg.org/image/gv29etcdf/

I don't have any good way to verify if all the parameters did in fact load 
properly, so reaching out to others to see if they have the same issue and/or 
know how to resolve it.

Thanks,
Steve Mekkelsen Madden



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

RE: Tomcat starts but home page cannot open with url http://localhost:8080

[Mekkelsen Madden, Steve]

I would suggest speaking to whoever configured the production environment as 
there is something missing or not backed up.  I just installed 7.0.55 without 
making any changes at all, just a clean download, unpack and started tomcat.  I 
was taken directly to the Tomcat manager console even though no app or drivers 
were specified.  The best (in my experience) is to install a clean version of 
Tomcat and port/migrate your production changes to the new instance.  This way 
you can be sure you have everything configured properly and it is a clean 
tomcat environment.  If you have hard coded IP, Server Names, File Paths that 
are specific to Production and not this environment, you'll never get it 
working this way.  I'm sure others in this chain will suggest doing the same 
approach.  Start fresh, start clean, make sure it starts, then make changes.

Good luck!
Steve

From: chandra sekhar [mailto:chandra.c...@gmail.com] 
Sent: Thursday, July 21, 2016 11:29 PM
To: Mekkelsen Madden, Steve <steve.mekkelsenmad...@pega.com>
Cc: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Tomcat starts but home page cannot open with url 
http://localhost:8080

Actually, i didn't configure the Apex ORDS yet with DB.As i told you in 
previous mail chain i just extracted and trying to see the apche tomcat home 
page first before going to configure Apex ORDS.

On Thu, Jul 21, 2016 at 11:26 PM, chandra sekhar <chandra.c...@gmail.com> wrote:
Hi Steve,

Now,Tomcat is up and running.But still i am unable to see the homepage.Please 
advice.

Regards,
chandra

On Thu, Jul 21, 2016 at 11:20 PM, Mekkelsen Madden, Steve 
<steve.mekkelsenmad...@pega.com> wrote:
Hi Chandra,

It does not appear to be an issue with port 8080 or 8005 (the default shutdown 
port), as Tomcat does try to startup, stays up for several minutes and does a 
proper shutdown (assuming you initiated the shutdown as shown in the logs).  
Otherwise, you would see “bind” exceptions in the logs where it is trying to 
access a port that is available and they both look good.

What is showing repeatedly in the log is that the context.xml or data sources 
you use to connect to the database for your application isn’t configured 
properly (Default Database connection not configured properly).  If you have 
specified the database SID/Port/Server details from the tnsnames.ora file, make 
sure you have the correct jdbc driver for the database on the linux server you 
installed Tomcat to and it can connect to the database.  Everything else looks 
good in the logs except for the db connection and deploying your application in 
the webapps/ folder.  If it depends on the DB to load, it would fail and then 
you’d get a http 404 error (page not found) because it never loaded.

-Steve

From: chandra sekhar [mailto:chandra.c...@gmail.com]
Sent: Thursday, July 21, 2016 11:06 PM
To: Mekkelsen Madden, Steve <steve.mekkelsenmad...@pega.com>
Cc: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Tomcat starts but home page cannot open with url 
http://localhost:8080

Hi Steve,

Please find the below details.

1.The port 8080 is available.But,need to check if there is a firewall issue 
like port or IP block.
 netstat -tlnp |grep java
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        0      0 :::127.0.0.1:8005       :::*                        
LISTEN      28914/java
tcp        0      0 :::8080                     :::*                        
LISTEN      28914/java

2.Yes.i took entire directory of apache tomcat.
3.Please find below log info.

Jul 21, 2016 7:38:14 PM org.apache.catalina.core.AprLifecycleListener init
INFO: The APR based Apache Tomcat Native library which allows optimal 
performance in production environments was not found on the java.library.path: 
/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
Jul 21, 2016 7:38:14 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler ["http-bio-8080"]
Jul 21, 2016 7:38:14 PM org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 637 ms
Jul 21, 2016 7:38:14 PM org.apache.catalina.core.StandardService startInternal
INFO: Starting service Catalina
Jul 21, 2016 7:38:14 PM org.apache.catalina.core.StandardEngine startInternal
INFO: Starting Servlet Engine: Apache Tomcat/7.0.55
Jul 21, 2016 7:38:14 PM org.apache.catalina.startup.HostConfig deployWAR
INFO: Deploying web application archive 
/data1/app/apache-tomcat-7.0.55/webapps/apex.war
Jul 21, 2016 7:38:18 PM oracle.dbtools.common.config.file.ConfigurationFolder 
logConfigFolder
INFO: Using configuration folder: 
/data1/app/apache-tomcat-7.0.55/webapps/apex/apex
Default Database connection not configured properly
Jul 21, 2016 7:39:19 PM oracle.dbtools.rt.web.SCListener contextInitialized
INFO: Oracle REST Data Services initialized
Oracle REST Data Services version : 2.0.8.163.10.40
Oracle

RE: Tomcat starts but home page cannot open with url http://localhost:8080

[Mekkelsen Madden, Steve]

Hi Chandra,

It does not appear to be an issue with port 8080 or 8005 (the default shutdown 
port), as Tomcat does try to startup, stays up for several minutes and does a 
proper shutdown (assuming you initiated the shutdown as shown in the logs).  
Otherwise, you would see “bind” exceptions in the logs where it is trying to 
access a port that is available and they both look good.

What is showing repeatedly in the log is that the context.xml or data sources 
you use to connect to the database for your application isn’t configured 
properly (Default Database connection not configured properly).  If you have 
specified the database SID/Port/Server details from the tnsnames.ora file, make 
sure you have the correct jdbc driver for the database on the linux server you 
installed Tomcat to and it can connect to the database.  Everything else looks 
good in the logs except for the db connection and deploying your application in 
the webapps/ folder.  If it depends on the DB to load, it would fail and then 
you’d get a http 404 error (page not found) because it never loaded.

-Steve

From: chandra sekhar [mailto:chandra.c...@gmail.com] 
Sent: Thursday, July 21, 2016 11:06 PM
To: Mekkelsen Madden, Steve <steve.mekkelsenmad...@pega.com>
Cc: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Tomcat starts but home page cannot open with url 
http://localhost:8080

Hi Steve,

Please find the below details.

1.The port 8080 is available.But,need to check if there is a firewall issue 
like port or IP block.
 netstat -tlnp |grep java
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        0      0 :::127.0.0.1:8005       :::*                        
LISTEN      28914/java
tcp        0      0 :::8080                     :::*                        
LISTEN      28914/java

2.Yes.i took entire directory of apache tomcat.
3.Please find below log info.

Jul 21, 2016 7:38:14 PM org.apache.catalina.core.AprLifecycleListener init
INFO: The APR based Apache Tomcat Native library which allows optimal 
performance in production environments was not found on the java.library.path: 
/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
Jul 21, 2016 7:38:14 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler ["http-bio-8080"]
Jul 21, 2016 7:38:14 PM org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 637 ms
Jul 21, 2016 7:38:14 PM org.apache.catalina.core.StandardService startInternal
INFO: Starting service Catalina
Jul 21, 2016 7:38:14 PM org.apache.catalina.core.StandardEngine startInternal
INFO: Starting Servlet Engine: Apache Tomcat/7.0.55
Jul 21, 2016 7:38:14 PM org.apache.catalina.startup.HostConfig deployWAR
INFO: Deploying web application archive 
/data1/app/apache-tomcat-7.0.55/webapps/apex.war
Jul 21, 2016 7:38:18 PM oracle.dbtools.common.config.file.ConfigurationFolder 
logConfigFolder
INFO: Using configuration folder: 
/data1/app/apache-tomcat-7.0.55/webapps/apex/apex
Default Database connection not configured properly
Jul 21, 2016 7:39:19 PM oracle.dbtools.rt.web.SCListener contextInitialized
INFO: Oracle REST Data Services initialized
Oracle REST Data Services version : 2.0.8.163.10.40
Oracle REST Data Services server info: Apache Tomcat/7.0.55

Jul 21, 2016 7:39:27 PM org.apache.catalina.util.SessionIdGenerator 
createSecureRandom
INFO: Creation of SecureRandom instance for session ID generation using 
[SHA1PRNG] took [8,639] milliseconds.
Jul 21, 2016 7:39:27 PM org.apache.catalina.startup.HostConfig deployWAR
INFO: Deployment of web application archive 
/data1/app/apache-tomcat-7.0.55/webapps/apex.war has finished in 72,898 ms
Jul 21, 2016 7:39:27 PM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory 
/data1/app/apache-tomcat-7.0.55/webapps/ROOT
Jul 21, 2016 7:39:27 PM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deployment of web application directory 
/data1/app/apache-tomcat-7.0.55/webapps/ROOT has finished in 36 ms
Jul 21, 2016 7:39:27 PM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory 
/data1/app/apache-tomcat-7.0.55/webapps/apex_bkp
Jul 21, 2016 7:39:29 PM oracle.dbtools.common.config.file.ConfigurationFolder 
logConfigFolder
INFO: Using configuration folder: 
/data1/app/apache-tomcat-7.0.55/webapps/apex/apex_bkp
Jul 21, 2016 7:39:29 PM oracle.dbtools.rt.web.SCListener contextInitialized
INFO: Oracle REST Data Services initialized
Oracle REST Data Services version : 2.0.8.163.10.40
Oracle REST Data Services server info: Apache Tomcat/7.0.55

Jul 21, 2016 7:39:29 PM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deployment of web application directory 
/data1/app/apache-tomcat-7.0.55/webapps/apex_bkp has finished in 2,110 ms
Jul 21, 2016 7:39:29 PM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web

RE: Tomcat starts but home page cannot open with url http://localhost:8080

[Mekkelsen Madden, Steve]

Still not enough detail to help.  Did you look at the log files to see what 
errors are occurring during Tomcat startup?  Assuming no firewall is blocking 
port 8080 on the machine you untarred it too, if you did take a full backup by 
tar'ing the entire folder with the webapps folder too, it should work the same 
as production as long as a) port 8080 is available to use, b) shutdown default 
port 8005 (or whatever is referenced) is available including AJP ports, etc, c) 
you got "ALL" the files including any hard coded external references to 
files/folders, etc and setup the environment the same/similar as production so 
it will work wherever you put it.  Start with the logs, they will provide more 
details than you think.

-Original Message-
From: chandra sekhar [mailto:chandra.c...@gmail.com] 
Sent: Thursday, July 21, 2016 9:30 PM
To: Tomcat Users List 
Subject: Re: Tomcat starts but home page cannot open with url 
http://localhost:8080

Hi,

Please find the below info.

Platform ?   --> Linux x86_64 bit
Where did you get that Tomcat from ? --> just tar backup of Production If 
Windows, the zip version or the installer ?--> Linux x86_64 bit
 apache-tomcat-7.0.55
And how you are trying to "get home page",--> Extracted the tar backup and 
started tomcat.Tomcat running on 8080 port.
And what you get instead of that home page. --> Page cannot be displayed

Regards,
Chandra

On Thu, Jul 21, 2016 at 5:31 PM, André Warnier (tomcat) 
wrote:

> On 21.07.2016 21:51, chandra sekhar wrote:
>
>> Hi All,
>>
>> Can anybody,please help me or give me advice why i am not getting 
>> home page of tomcat after extraction or installation of 
>> apache-tomcat-7.0.55.
>>
>> Appreciated your help.
>>
>> Maybe, if you provide some more information.
> Platform ?
> Where did you get that Tomcat from ?
> If Windows, the zip version or the installer ?
> And how you are trying to "get home page", And what you get instead of 
> that home page.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

RE: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues

[Mekkelsen Madden, Steve]

This was reproduced in dev, staging, testqa on multiple servers.  Yes, the 
response shown is JSON which is puzzling since that only appears when using 
NIO2.  That's why there is so much confusion on this.  At the end of the day, I 
simply deployed Tomcat 8.5.3x64 Windows to each server and migrated all the 
settings from 8.0.32 to 8.5.3 respectively in the context.xml, server.xml, 
tomcat-users.xml and web.xml.  The biggest change in 8.5.3 was the significant 
differences in SSL/TLS configuration required to get Tomcat to even startup 
properly.  I'm referring specifically to the connector arguments that have 
changed.  As an example (noting that this works with NIO, but not as shown with 
NIO2):
***We used to have:***




***Now changed with 8.5.3 settings:***
 
 

 




Am I missing something here?  Has anyone else tried to do the same with NIO2 
protocol and it worked? :-)

Regards,

Steve Mekkelsen Madden  |  Systems Engineer Fellow / DBA / Certified Scrum 
Master  | GCS |  Pegasystems Inc.
Office: (617) 866.6023 | Mobile: (828) 729.9948 | Email: 
steve.mekkelsen.mad...@pega.com | www.pega.com


-Original Message-
From: Felix Schumacher [mailto:felix.schumac...@internetallee.de] 
Sent: Thursday, July 07, 2016 12:53 PM
To: users@tomcat.apache.org
Subject: Re: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues

Am 07.07.2016 um 18:32 schrieb Mekkelsen Madden, Steve:
> Every request, making the environment virtually unstable and unusable since 
> everything we do is using xml.
The second logs showed json :) In any case, can you reproduce the issue in a 
dev environment? It would be superb, if you could make a minimal case, where 
this happens.

Regards,
  Felix
>
> Regards,
>
> Steve Mekkelsen Madden  |  Systems Engineer Fellow / DBA / Certified Scrum 
> Master  | GCS |  Pegasystems Inc.
> Office: (617) 866.6023 | Mobile: (828) 729.9948 | Email: 
> steve.mekkelsen.mad...@pega.com | www.pega.com
>
>
> -Original Message-
> From: Felix Schumacher [mailto:felix.schumac...@internetallee.de]
> Sent: Thursday, July 07, 2016 12:30 PM
> To: users@tomcat.apache.org
> Subject: Re: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding 
> issues
>
> Am 07.07.2016 um 15:04 schrieb Mekkelsen Madden, Steve:
>> Hi, sorry for delay and misinformation of the screenshot.  The 
>> screenshot shows Fiddler seeing the correct xml using both NIO and 
>> NIO2 protocols.  Fiddler does not see anything wrong with the 
>> requests themselves.  However, when we enable more debugging on our 
>> server, the logs are showing this: http://pastebin.com/ShYzr92e
>>
>> Note that, this is the same test case run with NIO (which works fine and no 
>> errors) but fails in NIO2.  Also, that we have been using NIO2 for many 
>> months without any issues under Tomcat 8.0.32.  It wasn't until the upgrade 
>> to 8.5.3 that NIO2 just stopped working.  Hope this helps.
> Can you print out the data on the server side when it fails to parse?
>
> Is this happening on every request or randomly?
>
> Regards,
>Felix
>> Regards,
>>
>> Steve Mekkelsen Madden  |  Systems Engineer Fellow / DBA / Certified Scrum 
>> Master  | GCS |  Pegasystems Inc.
>> Office: (617) 866.6023 | Mobile: (828) 729.9948 | Email: 
>> steve.mekkelsen.mad...@pega.com | www.pega.com
>>
>>
>> -Original Message-
>> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
>> Sent: Wednesday, July 06, 2016 4:45 PM
>> To: Tomcat Users List <users@tomcat.apache.org>
>> Subject: Re: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url 
>> encoding issues
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Steve,
>>
>> On 7/6/16 4:22 PM, Mekkelsen Madden, Steve wrote:
>>> Here is the image I tried attaching.  Sorry about that.
>>> [redacted... my SMTP server really doesn't like that URL]
>> So... what are we looking at, here?
>>
>> I see a POST URL that looks perfectly fine. I also see XML in the POST 
>> request. Is this a shot of Fiddler? Where is the problem?
>>
>> - -chris
>> -BEGIN PGP SIGNATURE-
>> Comment: GPGTools - http://gpgtools.org
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>
>> iQIcBAEBCAAGBQJXfW3LAAoJEBzwKT+lPKRYGsMP/3h+wQNIHoC/95G0VxQY75Kh
>> ClI+ny5Z5NeyVsA8iCrZ1rIr/fBEzE/nnHWlX16yPhkaCBQ8PwJ+i2MV11rYArU9
>> yUIhL2xyAxVAqyBUZGrNidzz6gydvJd2MPNGrtHg6shaIA7XtflX9gMUV16J+3m+
>> 7VC+E+lLBwOEcrYbpxJNni36Cn4QQ6f6sHMgLKsbGZZ6PSl7MGVPts6oz6SUkt6T
>> rwwPF6QLuovnndWlqt9HDaJtTD9/a9emSZgXKPQYACp8poSZ8xM7SxPn9f1XnX6l
>> iyOEc9RYJ3bvKocC8iMKCpS

RE: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues

[Mekkelsen Madden, Steve]

Every request, making the environment virtually unstable and unusable since 
everything we do is using xml.

Regards,

Steve Mekkelsen Madden  |  Systems Engineer Fellow / DBA / Certified Scrum 
Master  | GCS |  Pegasystems Inc.
Office: (617) 866.6023 | Mobile: (828) 729.9948 | Email: 
steve.mekkelsen.mad...@pega.com | www.pega.com


-Original Message-
From: Felix Schumacher [mailto:felix.schumac...@internetallee.de] 
Sent: Thursday, July 07, 2016 12:30 PM
To: users@tomcat.apache.org
Subject: Re: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues

Am 07.07.2016 um 15:04 schrieb Mekkelsen Madden, Steve:
> Hi, sorry for delay and misinformation of the screenshot.  The screenshot 
> shows Fiddler seeing the correct xml using both NIO and NIO2 protocols.  
> Fiddler does not see anything wrong with the requests themselves.  However, 
> when we enable more debugging on our server, the logs are showing this: 
> http://pastebin.com/ShYzr92e
>
> Note that, this is the same test case run with NIO (which works fine and no 
> errors) but fails in NIO2.  Also, that we have been using NIO2 for many 
> months without any issues under Tomcat 8.0.32.  It wasn't until the upgrade 
> to 8.5.3 that NIO2 just stopped working.  Hope this helps.
Can you print out the data on the server side when it fails to parse?

Is this happening on every request or randomly?

Regards,
  Felix
>
> Regards,
>
> Steve Mekkelsen Madden  |  Systems Engineer Fellow / DBA / Certified Scrum 
> Master  | GCS |  Pegasystems Inc.
> Office: (617) 866.6023 | Mobile: (828) 729.9948 | Email: 
> steve.mekkelsen.mad...@pega.com | www.pega.com
>
>
> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Wednesday, July 06, 2016 4:45 PM
> To: Tomcat Users List <users@tomcat.apache.org>
> Subject: Re: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Steve,
>
> On 7/6/16 4:22 PM, Mekkelsen Madden, Steve wrote:
>> Here is the image I tried attaching.  Sorry about that.
>> [redacted... my SMTP server really doesn't like that URL]
> So... what are we looking at, here?
>
> I see a POST URL that looks perfectly fine. I also see XML in the POST 
> request. Is this a shot of Fiddler? Where is the problem?
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJXfW3LAAoJEBzwKT+lPKRYGsMP/3h+wQNIHoC/95G0VxQY75Kh
> ClI+ny5Z5NeyVsA8iCrZ1rIr/fBEzE/nnHWlX16yPhkaCBQ8PwJ+i2MV11rYArU9
> yUIhL2xyAxVAqyBUZGrNidzz6gydvJd2MPNGrtHg6shaIA7XtflX9gMUV16J+3m+
> 7VC+E+lLBwOEcrYbpxJNni36Cn4QQ6f6sHMgLKsbGZZ6PSl7MGVPts6oz6SUkt6T
> rwwPF6QLuovnndWlqt9HDaJtTD9/a9emSZgXKPQYACp8poSZ8xM7SxPn9f1XnX6l
> iyOEc9RYJ3bvKocC8iMKCpSn41/XAGpiS3dwpYbNrN15sd2emRze2seDfJVI4Xtm
> 1d7GRqXUadjCjq/PzDSihrFjHBU+6+7BKd/hdqn6raci6HbtQPizkUTkPDWPXUTg
> T9Y7TOvi9zZNro9jLxErluN/A/niY8so53DFqT2kxV9wr2COf3dRu8UTyFM/4Mul
> 6bcGpno5CjvpfwVltlB8BTwRUctGEWe3kYcUfUBOTMNFFAMUYq+/4saL/gOATD8P
> LMcNXqbkex5fPrARU+vGgQvanFGeZMR7w9UXJbd9ACEWJUgRAnr18/5RtbVzWVjO
> gd4uPaLFgyFV573Hpe4Luzg7OngDu7BXZqThKXXaiG4cZSKmdjyjJVb4709GMOWc
> ARZb7MipIot/KGBBJhNd
> =bPg7
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>


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

RE: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues

[Mekkelsen Madden, Steve]

Hi, sorry for delay and misinformation of the screenshot.  The screenshot shows 
Fiddler seeing the correct xml using both NIO and NIO2 protocols.  Fiddler does 
not see anything wrong with the requests themselves.  However, when we enable 
more debugging on our server, the logs are showing this: 
http://pastebin.com/ShYzr92e

Note that, this is the same test case run with NIO (which works fine and no 
errors) but fails in NIO2.  Also, that we have been using NIO2 for many months 
without any issues under Tomcat 8.0.32.  It wasn't until the upgrade to 8.5.3 
that NIO2 just stopped working.  Hope this helps.

Regards,

Steve Mekkelsen Madden  |  Systems Engineer Fellow / DBA / Certified Scrum 
Master  | GCS |  Pegasystems Inc.
Office: (617) 866.6023 | Mobile: (828) 729.9948 | Email: 
steve.mekkelsen.mad...@pega.com | www.pega.com


-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Wednesday, July 06, 2016 4:45 PM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Steve,

On 7/6/16 4:22 PM, Mekkelsen Madden, Steve wrote:
> Here is the image I tried attaching.  Sorry about that. 
> [redacted... my SMTP server really doesn't like that URL]

So... what are we looking at, here?

I see a POST URL that looks perfectly fine. I also see XML in the POST request. 
Is this a shot of Fiddler? Where is the problem?

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJXfW3LAAoJEBzwKT+lPKRYGsMP/3h+wQNIHoC/95G0VxQY75Kh
ClI+ny5Z5NeyVsA8iCrZ1rIr/fBEzE/nnHWlX16yPhkaCBQ8PwJ+i2MV11rYArU9
yUIhL2xyAxVAqyBUZGrNidzz6gydvJd2MPNGrtHg6shaIA7XtflX9gMUV16J+3m+
7VC+E+lLBwOEcrYbpxJNni36Cn4QQ6f6sHMgLKsbGZZ6PSl7MGVPts6oz6SUkt6T
rwwPF6QLuovnndWlqt9HDaJtTD9/a9emSZgXKPQYACp8poSZ8xM7SxPn9f1XnX6l
iyOEc9RYJ3bvKocC8iMKCpSn41/XAGpiS3dwpYbNrN15sd2emRze2seDfJVI4Xtm
1d7GRqXUadjCjq/PzDSihrFjHBU+6+7BKd/hdqn6raci6HbtQPizkUTkPDWPXUTg
T9Y7TOvi9zZNro9jLxErluN/A/niY8so53DFqT2kxV9wr2COf3dRu8UTyFM/4Mul
6bcGpno5CjvpfwVltlB8BTwRUctGEWe3kYcUfUBOTMNFFAMUYq+/4saL/gOATD8P
LMcNXqbkex5fPrARU+vGgQvanFGeZMR7w9UXJbd9ACEWJUgRAnr18/5RtbVzWVjO
gd4uPaLFgyFV573Hpe4Luzg7OngDu7BXZqThKXXaiG4cZSKmdjyjJVb4709GMOWc
ARZb7MipIot/KGBBJhNd
=bPg7
-END PGP SIGNATURE-

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


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

RE: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues

[Mekkelsen Madden, Steve]

Here is the image I tried attaching.  Sorry about that.  
https://ibin.co/2n9zIx3n9qUH.jpg


Regards,

Steve Mekkelsen Madden  |  Systems Engineer Fellow / DBA / Certified Scrum 
Master  | GCS |  Pegasystems Inc.
Office: (617) 866.6023 | Mobile: (828) 729.9948 | Email: 
steve.mekkelsen.mad...@pega.com | www.pega.com


-Original Message-
From: Mekkelsen Madden, Steve 
Sent: Wednesday, July 06, 2016 3:44 PM
To: users@tomcat.apache.org
Subject: RE: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues

Thanks Felix. See below


-Original Message-
From: Felix Schumacher [mailto:felix.schumac...@internetallee.de]
Sent: Wednesday, July 06, 2016 3:29 PM
To: users@tomcat.apache.org
Subject: Re: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues

Am 06.07.2016 um 19:14 schrieb Mekkelsen Madden, Steve:
> This particular issue has raised a lot of issues in-house and we would 
> greatly appreciate a response from someone having more details on why NIO2 no 
> longer works.
>
> Thanks!
>
>
> -Original Message-
> From: Mekkelsen Madden, Steve
> Sent: Friday, July 01, 2016 12:56 PM
> To: Tomcat Users List <users@tomcat.apache.org>
> Subject: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding 
> issues
>
> Hi all,
>
> Is anyone aware of why after upgrading from Tomcat 8.0.32x64 (Windows) to 
> 8.5.3x64 using the connector protocol of: 
> protocol="org.apache.coyote.http11.Http11Nio2Protocol"  fails with url 
> encoding errors?  Once it was changed back to 
> protocol="org.apache.coyote.http11.Http11NioProtocol" all the errors stopped. 
>  This completely broke the application and made it unusable as the xml being 
> returned was not decoded and resulted in sax parse exceptions with our AJAX 
> connections.   I haven't found anything related to the protocol changing, 
> only the parameters for the SSL/TLS attributes which are in place and work.  
> It's almost like it's blocking the requests when it should be unblocking the 
> requests?  Thanks!!
Have you tried to compare the responses, that you get through the two 
connectors? Especially the characters before the xml prolog would be 
interesting.
Do you get the same errors, when you are requesting the url without tls?

Regards,
  Felix

Steve: We did not try turning off TLS in this case since this is what was 
already enabled in Production and required due to servers being accessible 
outside the network.  What the engineer found is that Fiddler showed all XML 
content (all the strings) that is being sent to and from the server were being 
encoded.  However, the XML content in fiddler does not have the encoded 
content.  I've attached a screenshot showing the request if that helps.

>
> Database Type: Oracle 12c Linux x64
> Driver used: ojdbc7.jar
> Connector attribute:  
>protocol="org.apache.coyote.http11.Http11NioProtocol"
>   maxThreads="150" disableUploadTimeout="true"
>   SSLEnabled="true"
>   sslDefaultHost="vgcspsteste1.rpega.com">
>
>certificateKeystoreFile="D:\certificates\ourcert.keystore" 
> certificateKeystorePassword="***" certificateKeyAlias="ourAlias" 
> type="RSA"/>
>
>   
> An example of the error looks like the below:
> 23 Jun 2016 01:28:39,731 [sl-nio2-8443-exec-11] 
> (ngineinterface.service.HttpAPI) ERROR: Error adopting XML from post data 
> com.pega.pegarules.pub.clipboard.InvalidStreamError: InvalidStream  
> com.pega.pegarules.data.internal.clipboard.XMLStream.newStream(String, 
> StorageStream)   sax parse error: Content is not allowed in prolog.
> From: (H64E3757ED751A9AEE78817056219F4F9:10.224.243.66)
>   at 
> com.pega.pegarules.data.internal.clipboard.XMLStream.newStream(XMLStream.java:477)
>   at 
> com.pega.pegarules.data.internal.clipboard.XMLStream.newStream(XMLStream.java:432)
>   at 
> com.pega.pegarules.data.internal.clipboard.ClipboardPageImpl.adoptXMLForm(ClipboardPageImpl.java:818)
>   at 
> com.pega.pegarules.session.internal.engineinterface.service.HttpAPI.mapInputData(HttpAPI.java:2481)
>   at 
> com.pega.pegarules.session.external.engineinterface.service.EngineAPI.activityExecutionProlog(EngineAPI.java:554)
>   at 
> com.pega.pegarules.session.external.engineinterface.service.EngineAPI.processRequestInner(EngineAPI.java:388)
>   at sun.reflect.GeneratedMethodAccessor90.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> com.pega.pegarules.session.internal.PRSessionProvi

RE: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues

[Mekkelsen Madden, Steve]

Thanks Felix. See below


-Original Message-
From: Felix Schumacher [mailto:felix.schumac...@internetallee.de] 
Sent: Wednesday, July 06, 2016 3:29 PM
To: users@tomcat.apache.org
Subject: Re: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues

Am 06.07.2016 um 19:14 schrieb Mekkelsen Madden, Steve:
> This particular issue has raised a lot of issues in-house and we would 
> greatly appreciate a response from someone having more details on why NIO2 no 
> longer works.
>
> Thanks!
>
>
> -Original Message-
> From: Mekkelsen Madden, Steve
> Sent: Friday, July 01, 2016 12:56 PM
> To: Tomcat Users List <users@tomcat.apache.org>
> Subject: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding 
> issues
>
> Hi all,
>
> Is anyone aware of why after upgrading from Tomcat 8.0.32x64 (Windows) to 
> 8.5.3x64 using the connector protocol of: 
> protocol="org.apache.coyote.http11.Http11Nio2Protocol"  fails with url 
> encoding errors?  Once it was changed back to 
> protocol="org.apache.coyote.http11.Http11NioProtocol" all the errors stopped. 
>  This completely broke the application and made it unusable as the xml being 
> returned was not decoded and resulted in sax parse exceptions with our AJAX 
> connections.   I haven't found anything related to the protocol changing, 
> only the parameters for the SSL/TLS attributes which are in place and work.  
> It's almost like it's blocking the requests when it should be unblocking the 
> requests?  Thanks!!
Have you tried to compare the responses, that you get through the two 
connectors? Especially the characters before the xml prolog would be 
interesting.
Do you get the same errors, when you are requesting the url without tls?

Regards,
  Felix

Steve: We did not try turning off TLS in this case since this is what was 
already enabled in Production and required due to servers being accessible 
outside the network.  What the engineer found is that Fiddler showed all XML 
content (all the strings) that is being sent to and from the server were being 
encoded.  However, the XML content in fiddler does not have the encoded 
content.  I've attached a screenshot showing the request if that helps.

>
> Database Type: Oracle 12c Linux x64
> Driver used: ojdbc7.jar
> Connector attribute:  
>protocol="org.apache.coyote.http11.Http11NioProtocol"
>   maxThreads="150" disableUploadTimeout="true"
>   SSLEnabled="true"
>   sslDefaultHost="vgcspsteste1.rpega.com">
>
>certificateKeystoreFile="D:\certificates\ourcert.keystore" 
> certificateKeystorePassword="***" certificateKeyAlias="ourAlias" 
> type="RSA"/>
>
>   
> An example of the error looks like the below:
> 23 Jun 2016 01:28:39,731 [sl-nio2-8443-exec-11] 
> (ngineinterface.service.HttpAPI) ERROR: Error adopting XML from post data 
> com.pega.pegarules.pub.clipboard.InvalidStreamError: InvalidStream  
> com.pega.pegarules.data.internal.clipboard.XMLStream.newStream(String, 
> StorageStream)   sax parse error: Content is not allowed in prolog.
> From: (H64E3757ED751A9AEE78817056219F4F9:10.224.243.66)
>   at 
> com.pega.pegarules.data.internal.clipboard.XMLStream.newStream(XMLStream.java:477)
>   at 
> com.pega.pegarules.data.internal.clipboard.XMLStream.newStream(XMLStream.java:432)
>   at 
> com.pega.pegarules.data.internal.clipboard.ClipboardPageImpl.adoptXMLForm(ClipboardPageImpl.java:818)
>   at 
> com.pega.pegarules.session.internal.engineinterface.service.HttpAPI.mapInputData(HttpAPI.java:2481)
>   at 
> com.pega.pegarules.session.external.engineinterface.service.EngineAPI.activityExecutionProlog(EngineAPI.java:554)
>   at 
> com.pega.pegarules.session.external.engineinterface.service.EngineAPI.processRequestInner(EngineAPI.java:388)
>   at sun.reflect.GeneratedMethodAccessor90.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> com.pega.pegarules.session.internal.PRSessionProviderImpl.performTargetActionWithLock(PRSessionProviderImpl.java:1277)
>   at 
> com.pega.pegarules.session.internal.PRSessionProviderImpl.doWithRequestorLocked(PRSessionProviderImpl.java:1015)
>   at 
> com.pega.pegarules.session.internal.PRSessionProviderImpl.doWithRequestorLocked(PRSessionProviderImpl.java:848)
>   at 
> com.pega.pegarules.session.external.engineinterface.service.EngineAPI.processRequest(EngineAPI.java:331)
>   at 
> com.pega.pegarules.session.internal.engineinterface.service.HttpAPI.invoke(HttpAPI.java:817)
> 

RE: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues

[Mekkelsen Madden, Steve]

This particular issue has raised a lot of issues in-house and we would greatly 
appreciate a response from someone having more details on why NIO2 no longer 
works.

Thanks!


-Original Message-
From: Mekkelsen Madden, Steve 
Sent: Friday, July 01, 2016 12:56 PM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues

Hi all,

Is anyone aware of why after upgrading from Tomcat 8.0.32x64 (Windows) to 
8.5.3x64 using the connector protocol of: 
protocol="org.apache.coyote.http11.Http11Nio2Protocol"  fails with url encoding 
errors?  Once it was changed back to 
protocol="org.apache.coyote.http11.Http11NioProtocol" all the errors stopped.  
This completely broke the application and made it unusable as the xml being 
returned was not decoded and resulted in sax parse exceptions with our AJAX 
connections.   I haven't found anything related to the protocol changing, only 
the parameters for the SSL/TLS attributes which are in place and work.  It's 
almost like it's blocking the requests when it should be unblocking the 
requests?  Thanks!!

Database Type: Oracle 12c Linux x64
Driver used: ojdbc7.jar
Connector attribute: 

 

 

An example of the error looks like the below:
23 Jun 2016 01:28:39,731 [sl-nio2-8443-exec-11] 
(ngineinterface.service.HttpAPI) ERROR: Error adopting XML from post data 
com.pega.pegarules.pub.clipboard.InvalidStreamError: InvalidStream
com.pega.pegarules.data.internal.clipboard.XMLStream.newStream(String, 
StorageStream)   sax parse error: Content is not allowed in prolog.
From: (H64E3757ED751A9AEE78817056219F4F9:10.224.243.66) 
at 
com.pega.pegarules.data.internal.clipboard.XMLStream.newStream(XMLStream.java:477)
at 
com.pega.pegarules.data.internal.clipboard.XMLStream.newStream(XMLStream.java:432)
at 
com.pega.pegarules.data.internal.clipboard.ClipboardPageImpl.adoptXMLForm(ClipboardPageImpl.java:818)
at 
com.pega.pegarules.session.internal.engineinterface.service.HttpAPI.mapInputData(HttpAPI.java:2481)
at 
com.pega.pegarules.session.external.engineinterface.service.EngineAPI.activityExecutionProlog(EngineAPI.java:554)
at 
com.pega.pegarules.session.external.engineinterface.service.EngineAPI.processRequestInner(EngineAPI.java:388)
at sun.reflect.GeneratedMethodAccessor90.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.pega.pegarules.session.internal.PRSessionProviderImpl.performTargetActionWithLock(PRSessionProviderImpl.java:1277)
at 
com.pega.pegarules.session.internal.PRSessionProviderImpl.doWithRequestorLocked(PRSessionProviderImpl.java:1015)
at 
com.pega.pegarules.session.internal.PRSessionProviderImpl.doWithRequestorLocked(PRSessionProviderImpl.java:848)
at 
com.pega.pegarules.session.external.engineinterface.service.EngineAPI.processRequest(EngineAPI.java:331)
at 
com.pega.pegarules.session.internal.engineinterface.service.HttpAPI.invoke(HttpAPI.java:817)
at 
com.pega.pegarules.session.internal.engineinterface.etier.impl.EngineImpl._invokeEngine_privact(EngineImpl.java:327)
at 
com.pega.pegarules.session.internal.engineinterface.etier.impl.EngineImpl.invokeEngine(EngineImpl.java:270)
at 
com.pega.pegarules.session.internal.engineinterface.etier.impl.EngineImpl.invokeEngine(EngineImpl.java:247)
at 
com.pega.pegarules.priv.context.JNDIEnvironment.invokeEngineInner(JNDIEnvironment.java:278)
at 
com.pega.pegarules.priv.context.JNDIEnvironment.invokeEngine(JNDIEnvironment.java:223)
at 
com.pega.pegarules.web.impl.WebStandardImpl.makeEtierRequest(WebStandardImpl.java:574)
at 
com.pega.pegarules.web.impl.WebStandardImpl.doPost(WebStandardImpl.java:374)
at sun.reflect.GeneratedMethodAccessor89.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.pega.pegarules.internal.bootstrap.PRBootstrap.invokeMethod(PRBootstrap.java:338)
at 
com.pega.pegarules.internal.bootstrap.PRBootstrap.invokeMethodPropagatingThrowable(PRBootstrap.java:379)
at 
com.pega.pegarules.boot.internal.extbridge.AppServerBridgeToPega.invokeMethodPropagatingThrowable(AppServerBridgeToPega.java:216)
at 
com.pega.pegarules.boot.internal.extbridge.AppServerBridgeToPega.invokeMethod(AppServerBridgeToPega.java:265)
at 
com.pega.pegarules.internal.web.servlet.WebStandardBoot.doPost(WebStandardBoot.java:118)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:648)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
at 
org.apache.catalina.core.ApplicationFi

SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues

[Mekkelsen Madden, Steve]

Hi all,

Is anyone aware of why after upgrading from Tomcat 8.0.32x64 (Windows) to 
8.5.3x64 using the connector protocol of: 
protocol="org.apache.coyote.http11.Http11Nio2Protocol"  fails with url encoding 
errors?  Once it was changed back to 
protocol="org.apache.coyote.http11.Http11NioProtocol" all the errors stopped.  
This completely broke the application and made it unusable as the xml being 
returned was not decoded and resulted in sax parse exceptions with our AJAX 
connections.   I haven't found anything related to the protocol changing, only 
the parameters for the SSL/TLS attributes which are in place and work.  It's 
almost like it's blocking the requests when it should be unblocking the 
requests?  Thanks!!

Database Type: Oracle 12c Linux x64
Driver used: ojdbc7.jar
Connector attribute: 

 

 

An example of the error looks like the below:
23 Jun 2016 01:28:39,731 [sl-nio2-8443-exec-11] 
(ngineinterface.service.HttpAPI) ERROR: Error adopting XML from post data 
com.pega.pegarules.pub.clipboard.InvalidStreamError: InvalidStream
com.pega.pegarules.data.internal.clipboard.XMLStream.newStream(String, 
StorageStream)   sax parse error: Content is not allowed in prolog.
From: (H64E3757ED751A9AEE78817056219F4F9:10.224.243.66) 
at 
com.pega.pegarules.data.internal.clipboard.XMLStream.newStream(XMLStream.java:477)
at 
com.pega.pegarules.data.internal.clipboard.XMLStream.newStream(XMLStream.java:432)
at 
com.pega.pegarules.data.internal.clipboard.ClipboardPageImpl.adoptXMLForm(ClipboardPageImpl.java:818)
at 
com.pega.pegarules.session.internal.engineinterface.service.HttpAPI.mapInputData(HttpAPI.java:2481)
at 
com.pega.pegarules.session.external.engineinterface.service.EngineAPI.activityExecutionProlog(EngineAPI.java:554)
at 
com.pega.pegarules.session.external.engineinterface.service.EngineAPI.processRequestInner(EngineAPI.java:388)
at sun.reflect.GeneratedMethodAccessor90.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.pega.pegarules.session.internal.PRSessionProviderImpl.performTargetActionWithLock(PRSessionProviderImpl.java:1277)
at 
com.pega.pegarules.session.internal.PRSessionProviderImpl.doWithRequestorLocked(PRSessionProviderImpl.java:1015)
at 
com.pega.pegarules.session.internal.PRSessionProviderImpl.doWithRequestorLocked(PRSessionProviderImpl.java:848)
at 
com.pega.pegarules.session.external.engineinterface.service.EngineAPI.processRequest(EngineAPI.java:331)
at 
com.pega.pegarules.session.internal.engineinterface.service.HttpAPI.invoke(HttpAPI.java:817)
at 
com.pega.pegarules.session.internal.engineinterface.etier.impl.EngineImpl._invokeEngine_privact(EngineImpl.java:327)
at 
com.pega.pegarules.session.internal.engineinterface.etier.impl.EngineImpl.invokeEngine(EngineImpl.java:270)
at 
com.pega.pegarules.session.internal.engineinterface.etier.impl.EngineImpl.invokeEngine(EngineImpl.java:247)
at 
com.pega.pegarules.priv.context.JNDIEnvironment.invokeEngineInner(JNDIEnvironment.java:278)
at 
com.pega.pegarules.priv.context.JNDIEnvironment.invokeEngine(JNDIEnvironment.java:223)
at 
com.pega.pegarules.web.impl.WebStandardImpl.makeEtierRequest(WebStandardImpl.java:574)
at 
com.pega.pegarules.web.impl.WebStandardImpl.doPost(WebStandardImpl.java:374)
at sun.reflect.GeneratedMethodAccessor89.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.pega.pegarules.internal.bootstrap.PRBootstrap.invokeMethod(PRBootstrap.java:338)
at 
com.pega.pegarules.internal.bootstrap.PRBootstrap.invokeMethodPropagatingThrowable(PRBootstrap.java:379)
at 
com.pega.pegarules.boot.internal.extbridge.AppServerBridgeToPega.invokeMethodPropagatingThrowable(AppServerBridgeToPega.java:216)
at 
com.pega.pegarules.boot.internal.extbridge.AppServerBridgeToPega.invokeMethod(AppServerBridgeToPega.java:265)
at 
com.pega.pegarules.internal.web.servlet.WebStandardBoot.doPost(WebStandardBoot.java:118)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:648)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
at 
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
at 

RE: Need help with URL redirecting

[Mekkelsen Madden, Steve]

One thing you could do is have an entry in your webapps\ROOT folder called 
like: MyAppRedirect.html  (name can be anything)
Inside the file you need something like:


In your conf\web.xml at the bottom of it, you'll see 3 lines shown below:

index.html
index.htm
index.jsp


Change this to point to your MyAppRedirect.html page.

MyAppRedirect.html


That's a simple way to redirect your application.  Your DNS / reverse proxy 
could take care of the port # and users only need to call your application by 
name (https://callMyApplication.domain.com) when the DNS/reverse proxy 
redirects it to the server's port say 8088, the html file appends the remaining 
portion of the url to what the users typed.


-Original Message-
From: Sean Son [mailto:linuxmailinglistsem...@gmail.com] 
Sent: Monday, June 20, 2016 12:42 PM
To: Tomcat Users List ; a...@ice-sa.com
Subject: Re: Need help with URL redirecting

On Fri, Jun 17, 2016 at 3:39 PM, André Warnier (tomcat) 
wrote:

> Hi.
> Another tip : on his list,mit is preferred if you respond in or below 
> the previous text.
> That's why I moved your previous answer.
> It makes it easier to follow the conversation without having to scroll 
> back and forth all the time.
>
> >
>
>>
>> On Fri, Jun 17, 2016 at 12:03 PM, André Warnier (tomcat) 
>> 
>> wrote:
>>
>> On 17.06.2016 17:03, Sean Son wrote:
>>>
>>> Hello all

 I am new to the list. This is what i am trying to do but need help on:


 I have a webapp running on tomcat 8:
 https://myapp.example.com:8443/myapp

 I am going to set up a DNS record myapp.example.com which will 
 point to the IP address of the tomcat server that hosts the 
 webapp.. I want this new DNS record myapp.example.com to redirect 
 to https://myapp.example.com:8443/myapp.
 In other words, I want the URL to redirect port 80 to the URL for 
 the webapp automatically so the users will not have to enter in the 
 port number whenever they want to browse to the webapp. I tried 
 doing research on google and I was not able to find a straight 
 forward way of doing this.
 Any
 help is greatly appreciated!



 The first thing you would have to check, is whether port 80 is 
 still
>>> free
>>> on that server, or if there is already another webserver (e.g. 
>>> Apache
>>> httpd) using it.
>>>
>>> The second thing to clarify is whether, apart from "myapp", there 
>>> are other web applications (not called "myapp") which you are 
>>> running or would want to run under Tomcat on that server.
>>> If not, then you might want to run your application as the *default* 
>>> application, so that users would get to it with the URL "
>>> https://myapp.example.com:8443/;, instead of "
>>> https://myapp.example.com:8443/myapp;.
>>> To do this first, have a look at :
>>>   http://wiki.apache.org/tomcat/HowTo
>>> and look at #17 : How do I make my web application be the tomcat 
>>> default application
>>>
>>> It will just be easier if you clear up the above points first, 
>>> because there are multiple possibilities, and it narrows down the 
>>> scope of the tips we can provide.
>>>
>>>
> On 17.06.2016 18:43, Sean Son wrote:
>
>> Hello Andre
>>
>> thank you for your response.
>>
>> There are no other webservers running on this machine. There are 
>> other web apps as well, but the only way to access them is through 
>> myapp. So should I deploy myapp as the default app ?
>>
>>
> Yes, I think that it will make the rest easier.
> So do that, as per the instructions above, and then we will continue.
>
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Thank you for the tidbit about how to reply :) So I used number 17 from the 
website and i deployed the war file as the ROOT.war file.  What should the next 
steps be?


I thank you again for all of your help!