RE: [External] Re: Security Headers Implementation in Tomcat 6.x version

[Shaik, Mohammad N.]

Hi Chris,

What should be name of the new JAR file that I would create for the Filter 
classes?

There are multiple JAR files in lib folder. Does the name of these JAR files 
have any significance?

My understanding is that as long as you have your code (.class files) is 
present in any of the JAR files under "lib" folder, system would get it. You 
don’t need to have a specific-named JAR files having specific-named .class 
files. The .class files from all the jar files under lib folder is considered 
as one big collection, and based on the invoked classname its corresponding 
.class file gets executed from that big code. Multiple JAR files with different 
names is setup just for logical classification of classes. Please correct me if 
this is not right.

- Mohammad

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: 31 May 2017 23:52
To: users@tomcat.apache.org
Subject: [External] Re: Security Headers Implementation in Tomcat 6.x version

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mohammad,

On 5/31/17 6:37 AM, Shaik, Mohammad N. wrote:
> Can I simply use the JAR files from Tomcat 7 that contains executable
> code of filter classes (security headers), and put them into
> corresponding location in Tomcat 6?

Definitely don't do that. But you could probably grab the compiled .class files 
from Tomcat 7's binary distribution... just make sure you have all of them.

So, basically, create a new JAR file that contains only those Filter classes 
(don't forget any inner classes that might be found in separate .class files).

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

iQIcBAEBCAAGBQJZLwnHAAoJEBzwKT+lPKRYVZ4P/1XAtHfld2JwqfQLLUTaiZ7C
jlJoUOjImnwTI4JAKOnlaSIQ0c0IhboBlPxcuBOaAbn5zbKOQZslqbWhidnHuKp5
T5C8eChRR8OuP6cJAi2zCx0m7NgxInaYRIMdbxBGIwnAOZkaq0UgKY2JYo9OUfeJ
S5VRuZIKdH8nE3dlriC72uZkn2ZXPoHMe3KyfsNZzR8UNqyZmQwUsb8645Xiw0up
Sik6onVBiqSubnLCYslhizMiK7r7hU55whMbsS3tDXnfck8ZwE6nRldxRw630vet
D9b00aUw5Em9SW9ZaeIG/n6x/L7hTFzJJFhKMuhEQHndo610xDiI+d2fADEfvx/i
L5BKGzVwoUtq0MpUxKpwMeoKagA9NYpbSDyLpeJViqv/m77KOA4O2hGwmcq/UOml
XFQ//5yaHvGL+W8ICNZCzgdTX5OgOwx0Nbu9ii7//FOcI5O2uT+0EN+LoagGpDNy
OJmQm5PsXJDvScoyNRK+z6mgPpe+3YPR7tKfx9Aw6TlPecB8VaXY2zLMf7g0wck3
AMtGfaqKw1kSjLEmLrSb7rUCDxEROXh4zgpZS1Xv0/0tPfmoFPWxx7msw6bVd9CB
aKKw7NbMkUehs4lBixzPGHqBQfpMyvJByUQyY4ThUCrJM/DU/9y2rwdwJGYFR+lv
mD63/FtqNHglnYULpUTS
=jN8f
-END PGP SIGNATURE-

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




This message is for the designated recipient only and may contain privileged, 
proprietary, or otherwise confidential information. If you have received it in 
error, please notify the sender immediately and delete the original. Any other 
use of the e-mail by you is prohibited. Where allowed by local law, electronic 
communications with Accenture and its affiliates, including e-mail and instant 
messaging (including content), may be scanned by our systems for the purposes 
of information security and assessment of internal compliance with Accenture 
policy.
__

www.accenture.com

tomcat 7, null tag attributes

[Chris Cheshire]

I am using tomcat 7 on CentOS 7 and I need to pass a null value to tag
attributes of type Long/Integer/Float, however it is *always* coerced to
zero.

<%@attribute name="parentId" required="true" rtexprvalue="true"
type="java.lang.Long" %>

Changing required to false does nothing. I tried setting the system
property org.apache.el.parser.COERCE_TO_ZERO to false in tomcat.conf
(-Dorg.apache.el.parser.COERCE_TO_ZERO=false with my other JAVA_OPTS) but
this does nothing. The value before it hits the tag is null and inside the
tag is 0. If I query the System properties it shows it as set to false, but
Tomcat is not honoring it and is still coercing nulls to zero. I understand
the spec says to do this etc but that defeats the purpose of using an
object vs atomic type in the first place and is horribly shortsighted.

Upgrading to Tomcat 8 is not a solution unfortunately as there is no RPM
for it.

How do I pass a null Long/Float/Integer as a tag attribute and have it kept
as null and not turned into an incorrect value?

Chris

Re: Possible bug between Apache 2.4 and Tomcat 7 via AJP when POSTing

[Mark Eggers]

Nic,

On 5/31/2017 5:42 AM, Nicholas Cottrell wrote:
> Hi All!
> 
> I'm having a problem setting up an existing webapp from Apache
> 2.2/Tomcat6 on a new server running Centos 7, and the following
> packages:
> 
> httpd 2.4.6-45.el7.centos.4 tomcat.noarch
> 7.0.69-11.el7_3 @updates tomcat-native.x86_64
> 1.1.34-1.el7@epel
> 
> For debugging I have enabled AJP/1.3 and 8009 and HTTP on 8080, then
> use Apache to ProxyPass.
> 
> With my initial configuration, data from a form POST is not available
> via request.getParameter:
> 
> ProxyPass / ajp://localhost:8009/  retry=1
> acquire=3000 timeout=600 Keepalive=On ProxyPassReverse /
> ajp://localhost:8009/ 
> 
> But changing it to this fixes everything:
> 
> ProxyPass / http://localhost:8080/  retry=1
> acquire=3000 timeout=600 Keepalive=On ProxyPassReverse /
> http://localhost:8080/ 
> 
> In the broken instance, request.getParameter("x") returned null, but
> request.getReader() returned bytes with "x=123" so seems that Apache
> is sending the POST body but Tomcat is not processing it correctly,
> yes?
> 
> Please also see
> https://stackoverflow.com/questions/44167876/problems-with-post-parameters-with-tomcat-ajp-on-apache-2-4-but-not-2-2
> 
> for my steps so far.
> 
> I would prefer to switch back to AJP for the proxy, since I
> understand it is more performant, right? Should I try forcing a
> Tomcat 8 install to see if the problem persists there too?
> 
> Best, Nic.
> 

I wasn't aware that mod_proxy_ajp was available on a stock CentOS 7 even
with epel enabled.

If you're using the ajp protocol (it's not HTTP), then you'll need to
get mod_jk (from tomcat.apache.org) and build it yourself. It's not
difficult.

However, the configuration is quite a bit different. Fortunately, there
is an excellent set of example configuration files in the source (see
the conf subdirectory).

mod_proxy_ajp.so was shipped with CentOS 6, but does not appear to be
available with CentOS 7.

Either that - or go with mod_proxy_http and proxy to the HTTP connector
(default in server.xml is port 8080).

. . . just my two cents
/mde/




signature.asc
Description: OpenPGP digital signature

Re: Custom Webapp loading..

[Hassan Khan]

So the precise exception is Only a type can be imported. ABC resolves to a
package..

Stacktrace is :
at
org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:102)
at
org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:212)
at
org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:457)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:377)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:349)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:333)
at
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:600)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:368)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:385)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:329)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:728)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590)
at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:524)
at
org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:895)
at
org.apache.jsp.iNexx.common._005fshinglesTop_jsp._jspService(_005fshinglesTop_jsp.java:385)
==> JSP page called from the main webapp referencing the modular apps



On Wed, May 31, 2017 at 5:05 PM, Hassan Khan 
wrote:

> Hi,
>
> We have a main webapp (Tomcat\Webapp) that has many modular webapps (
> (Tomcat\Webapp\app\) under it that can be removed and added by the user.
> The main webapp has the service and connectors , but the modular webapps
> do not need it.
>
> The problem is currently when the main webapp tries to access a jar in the
> modular webapps lib dir... we have a class not found exception.. that is
> why we need to load the jars from the modular webapps Web-INF\lib directory.
>
> Thanks
>
>
>
> On Wed, May 31, 2017 at 5:00 PM, Aurélien Terrestris <
> aterrest...@gmail.com> wrote:
>
>> hi
>>
>> what are you trying to do exactly ?
>>
>> If you just need to start one webapp after another one in a precise order,
>> you need as many Services (+Connector on a different port, + Host) as
>> webapps.
>>
>> A.T.
>>
>>
>>
>>
>>
>> 2017-05-31 22:48 GMT+02:00 Hassan Khan :
>>
>> > Hi,
>> >
>> > We have the following structure for webapps in tomcat 6.
>> >
>> > Tomcat > Webapp > Application 1 >WEB-INF >lib
>> > Tomcat > Webapp > Application 1 > Application >WEB-INF> lib
>> >
>> >
>> > The  Tomcat > Webapp > Application 1 >WEB-INF >lib gets loaded with
>> > addwebapp() function..
>> > but for Tomcat > Webapp > Application 1 > Application >WEB-INF> lib ,
>> we
>> > wrote a custom webapploader that extended WebappLoader.
>> >
>> > Now we are upgrading to tomcat 8.5
>> >
>> > Wanted to know if any other way to accomplish the same task.
>> >
>> > Was working on using the same extended loader .. but the start()
>> function
>> > has changed to InternalStart() and getting a exception as below:
>> > Caused by: org.apache.catalina.LifecycleException: An invalid Lifecycle
>> > transition was attempted ([after_start]) for component
>> > [WebappLoader[/SandBox/Primar]] in state [STARTING_PREP]
>> >
>> >  Any pointer are appreciated.. not that familiar with extending apache
>> > classes.
>> >
>> > Thanks
>> > Hassan
>> >
>> >
>> >
>> >
>> > On Wed, May 31, 2017 at 4:42 PM, Hassan Khan 
>> > wrote:
>> >
>> > > Hi,
>> > >
>> > > We have the following structure for webapp in tomcat 6.
>> > >
>> > > Tomcat > Webapp > Application 1 > Application >WEB-INF> lib
>> > >
>> > > T
>> > > he Alpp
>> > >
>> > > --
>> > > Hassan Khan
>> > >
>> >
>> >
>> >
>> > --
>> > Hassan Khan
>> >
>>
>
>
>
> --
> Hassan Khan
>



-- 
Hassan Khan

Re: Custom Webapp loading..

[Hassan Khan]

Hi,

We have a main webapp (Tomcat\Webapp) that has many modular webapps (
(Tomcat\Webapp\app\) under it that can be removed and added by the user.
The main webapp has the service and connectors , but the modular webapps do
not need it.

The problem is currently when the main webapp tries to access a jar in the
modular webapps lib dir... we have a class not found exception.. that is
why we need to load the jars from the modular webapps Web-INF\lib directory.

Thanks



On Wed, May 31, 2017 at 5:00 PM, Aurélien Terrestris 
wrote:

> hi
>
> what are you trying to do exactly ?
>
> If you just need to start one webapp after another one in a precise order,
> you need as many Services (+Connector on a different port, + Host) as
> webapps.
>
> A.T.
>
>
>
>
>
> 2017-05-31 22:48 GMT+02:00 Hassan Khan :
>
> > Hi,
> >
> > We have the following structure for webapps in tomcat 6.
> >
> > Tomcat > Webapp > Application 1 >WEB-INF >lib
> > Tomcat > Webapp > Application 1 > Application >WEB-INF> lib
> >
> >
> > The  Tomcat > Webapp > Application 1 >WEB-INF >lib gets loaded with
> > addwebapp() function..
> > but for Tomcat > Webapp > Application 1 > Application >WEB-INF> lib ,  we
> > wrote a custom webapploader that extended WebappLoader.
> >
> > Now we are upgrading to tomcat 8.5
> >
> > Wanted to know if any other way to accomplish the same task.
> >
> > Was working on using the same extended loader .. but the start() function
> > has changed to InternalStart() and getting a exception as below:
> > Caused by: org.apache.catalina.LifecycleException: An invalid Lifecycle
> > transition was attempted ([after_start]) for component
> > [WebappLoader[/SandBox/Primar]] in state [STARTING_PREP]
> >
> >  Any pointer are appreciated.. not that familiar with extending apache
> > classes.
> >
> > Thanks
> > Hassan
> >
> >
> >
> >
> > On Wed, May 31, 2017 at 4:42 PM, Hassan Khan 
> > wrote:
> >
> > > Hi,
> > >
> > > We have the following structure for webapp in tomcat 6.
> > >
> > > Tomcat > Webapp > Application 1 > Application >WEB-INF> lib
> > >
> > > T
> > > he Alpp
> > >
> > > --
> > > Hassan Khan
> > >
> >
> >
> >
> > --
> > Hassan Khan
> >
>



-- 
Hassan Khan

Re: Custom Webapp loading..

[Aurélien Terrestris]

hi

what are you trying to do exactly ?

If you just need to start one webapp after another one in a precise order,
you need as many Services (+Connector on a different port, + Host) as
webapps.

A.T.





2017-05-31 22:48 GMT+02:00 Hassan Khan :

> Hi,
>
> We have the following structure for webapps in tomcat 6.
>
> Tomcat > Webapp > Application 1 >WEB-INF >lib
> Tomcat > Webapp > Application 1 > Application >WEB-INF> lib
>
>
> The  Tomcat > Webapp > Application 1 >WEB-INF >lib gets loaded with
> addwebapp() function..
> but for Tomcat > Webapp > Application 1 > Application >WEB-INF> lib ,  we
> wrote a custom webapploader that extended WebappLoader.
>
> Now we are upgrading to tomcat 8.5
>
> Wanted to know if any other way to accomplish the same task.
>
> Was working on using the same extended loader .. but the start() function
> has changed to InternalStart() and getting a exception as below:
> Caused by: org.apache.catalina.LifecycleException: An invalid Lifecycle
> transition was attempted ([after_start]) for component
> [WebappLoader[/SandBox/Primar]] in state [STARTING_PREP]
>
>  Any pointer are appreciated.. not that familiar with extending apache
> classes.
>
> Thanks
> Hassan
>
>
>
>
> On Wed, May 31, 2017 at 4:42 PM, Hassan Khan 
> wrote:
>
> > Hi,
> >
> > We have the following structure for webapp in tomcat 6.
> >
> > Tomcat > Webapp > Application 1 > Application >WEB-INF> lib
> >
> > T
> > he Alpp
> >
> > --
> > Hassan Khan
> >
>
>
>
> --
> Hassan Khan
>

Re: Custom Webapp loading..

[Hassan Khan]

Hi,

We have the following structure for webapps in tomcat 6.

Tomcat > Webapp > Application 1 >WEB-INF >lib
Tomcat > Webapp > Application 1 > Application >WEB-INF> lib


The  Tomcat > Webapp > Application 1 >WEB-INF >lib gets loaded with
addwebapp() function..
but for Tomcat > Webapp > Application 1 > Application >WEB-INF> lib ,  we
wrote a custom webapploader that extended WebappLoader.

Now we are upgrading to tomcat 8.5

Wanted to know if any other way to accomplish the same task.

Was working on using the same extended loader .. but the start() function
has changed to InternalStart() and getting a exception as below:
Caused by: org.apache.catalina.LifecycleException: An invalid Lifecycle
transition was attempted ([after_start]) for component
[WebappLoader[/SandBox/Primar]] in state [STARTING_PREP]

 Any pointer are appreciated.. not that familiar with extending apache
classes.

Thanks
Hassan




On Wed, May 31, 2017 at 4:42 PM, Hassan Khan 
wrote:

> Hi,
>
> We have the following structure for webapp in tomcat 6.
>
> Tomcat > Webapp > Application 1 > Application >WEB-INF> lib
>
> T
> he Alpp
>
> --
> Hassan Khan
>



-- 
Hassan Khan

Re: Possible bug between Apache 2.4 and Tomcat 7 via AJP when POSTing

[tomcat]

On 31.05.2017 21:52, Nicholas Cottrell wrote:

On 5/31/17 8:42 AM, Nicholas Cottrell wrote:

Hi All!

I'm having a problem setting up an existing webapp from Apache
2.2/Tomcat6 on a new server running Centos 7, and the following
packages:

httpd   2.4.6-45.el7.centos.4 tomcat.noarch
7.0.69-11.el7_3 @updates tomcat-native.x86_64
1.1.34-1.el7@epel

For debugging I have enabled AJP/1.3 and 8009 and HTTP on 8080,
then use Apache to ProxyPass.

With my initial configuration, data from a form POST is not
available via request.getParameter:

ProxyPass / ajp://localhost:8009/  > retry=1
acquire=3000 timeout=600 Keepalive=On ProxyPassReverse /
ajp://localhost:8009/  >

But changing it to this fixes everything:

ProxyPass / http://localhost:8080/  > retry=1
acquire=3000 timeout=600 Keepalive=On ProxyPassReverse /
http://localhost:8080/  >

In the broken instance, request.getParameter("x") returned null,
but request.getReader() returned bytes with "x=123" so seems that
Apache is sending the POST body but Tomcat is not processing it
correctly, yes?

Please also see
https://stackoverflow.com/questions/44167876/problems-with-post-parame 


ters-with-tomcat-ajp-on-apache-2-4-but-not-2-2



eters-with-tomcat-ajp-on-apache-2-4-but-not-2-2>

for my steps so far.

I would prefer to switch back to AJP for the proxy, since I
understand it is more performant, right? Should I try forcing a
Tomcat 8 install to see if the problem persists there too?


If you call request.getReader/getInputStream before any of the
request.getParameter family of methods, then all request.getParameter*
methods will return null. That's because Tomcat must consume the
request body in order to parse POST parameters. If you call
request.getReader/getInputStream, then Tomcat assumes that you will be
handling the request body (and any associated parameters therein).

Is it possible that you are "damaging" the request by inspecting the
request body?


I've been thinking about that but I don't call getReader/getInputStream 
anywhere myself.
Also, the fact that accessing the same page via 8080 directly to Tomcat works, 
but via Apache/AJP through Tomcat's port 8009 works fine, and setting the proxy 
to use the 8080 also works.



There must be a typo in the phrase above, or else what are you complaining 
about ?




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

Custom Webapp loading..

[Hassan Khan]

Hi,

We have the following structure for webapp in tomcat 6.

Tomcat > Webapp > Application 1 > Application >WEB-INF> lib

T
he Alpp

-- 
Hassan Khan

Re: Possible bug between Apache 2.4 and Tomcat 7 via AJP when POSTing

[Nicholas Cottrell]

> On 5/31/17 8:42 AM, Nicholas Cottrell wrote:
>> Hi All!
>> 
>> I'm having a problem setting up an existing webapp from Apache
>> 2.2/Tomcat6 on a new server running Centos 7, and the following
>> packages:
>> 
>> httpd2.4.6-45.el7.centos.4 tomcat.noarch
>> 7.0.69-11.el7_3 @updates tomcat-native.x86_64
>> 1.1.34-1.el7@epel
>> 
>> For debugging I have enabled AJP/1.3 and 8009 and HTTP on 8080,
>> then use Apache to ProxyPass.
>> 
>> With my initial configuration, data from a form POST is not
>> available via request.getParameter:
>> 
>> ProxyPass / ajp://localhost:8009/  
>> > retry=1
>> acquire=3000 timeout=600 Keepalive=On ProxyPassReverse /
>> ajp://localhost:8009/  > >
>> 
>> But changing it to this fixes everything:
>> 
>> ProxyPass / http://localhost:8080/  
>> > retry=1
>> acquire=3000 timeout=600 Keepalive=On ProxyPassReverse /
>> http://localhost:8080/  > >
>> 
>> In the broken instance, request.getParameter("x") returned null,
>> but request.getReader() returned bytes with "x=123" so seems that
>> Apache is sending the POST body but Tomcat is not processing it
>> correctly, yes?
>> 
>> Please also see
>> https://stackoverflow.com/questions/44167876/problems-with-post-parame 
>> 
> ters-with-tomcat-ajp-on-apache-2-4-but-not-2-2
>> > 
> eters-with-tomcat-ajp-on-apache-2-4-but-not-2-2>
>> for my steps so far.
>> 
>> I would prefer to switch back to AJP for the proxy, since I
>> understand it is more performant, right? Should I try forcing a
>> Tomcat 8 install to see if the problem persists there too?
> 
> If you call request.getReader/getInputStream before any of the
> request.getParameter family of methods, then all request.getParameter*
> methods will return null. That's because Tomcat must consume the
> request body in order to parse POST parameters. If you call
> request.getReader/getInputStream, then Tomcat assumes that you will be
> handling the request body (and any associated parameters therein).
> 
> Is it possible that you are "damaging" the request by inspecting the
> request body?

I've been thinking about that but I don't call getReader/getInputStream 
anywhere myself. 
Also, the fact that accessing the same page via 8080 directly to Tomcat works, 
but via Apache/AJP through Tomcat's port 8009 works fine, and setting the proxy 
to use the 8080 also works.

Re: Possible bug between Apache 2.4 and Tomcat 7 via AJP when POSTing

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Nic,

On 5/31/17 8:42 AM, Nicholas Cottrell wrote:
> Hi All!
> 
> I'm having a problem setting up an existing webapp from Apache
> 2.2/Tomcat6 on a new server running Centos 7, and the following
> packages:
> 
> httpd 2.4.6-45.el7.centos.4 tomcat.noarch
> 7.0.69-11.el7_3 @updates tomcat-native.x86_64
> 1.1.34-1.el7@epel
> 
> For debugging I have enabled AJP/1.3 and 8009 and HTTP on 8080,
> then use Apache to ProxyPass.
> 
> With my initial configuration, data from a form POST is not
> available via request.getParameter:
> 
> ProxyPass / ajp://localhost:8009/  retry=1
> acquire=3000 timeout=600 Keepalive=On ProxyPassReverse /
> ajp://localhost:8009/ 
> 
> But changing it to this fixes everything:
> 
> ProxyPass / http://localhost:8080/  retry=1
> acquire=3000 timeout=600 Keepalive=On ProxyPassReverse /
> http://localhost:8080/ 
> 
> In the broken instance, request.getParameter("x") returned null,
> but request.getReader() returned bytes with "x=123" so seems that
> Apache is sending the POST body but Tomcat is not processing it
> correctly, yes?
> 
> Please also see
> https://stackoverflow.com/questions/44167876/problems-with-post-parame
ters-with-tomcat-ajp-on-apache-2-4-but-not-2-2
> 
> for my steps so far.
> 
> I would prefer to switch back to AJP for the proxy, since I
> understand it is more performant, right? Should I try forcing a
> Tomcat 8 install to see if the problem persists there too?

If you call request.getReader/getInputStream before any of the
request.getParameter family of methods, then all request.getParameter*
methods will return null. That's because Tomcat must consume the
request body in order to parse POST parameters. If you call
request.getReader/getInputStream, then Tomcat assumes that you will be
handling the request body (and any associated parameters therein).

Is it possible that you are "damaging" the request by inspecting the
request body?

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

iQIcBAEBCAAGBQJZLwp0AAoJEBzwKT+lPKRY+GkP/RRGHM9JZmBneogWEN1WEjJK
LhBlXJE1aQvKaP7Mpsj5q8VG+/pjWVfBSz8yBcLQPK4ty27LjPQF9fa1kTQZikrc
xpe5pJDo/Tp/xeztPLWf3l4fvBaH8/fjbb+U9XrA1+00rev1FmcI/E5Qz6qMpj70
P2g/eCWYVUaNGNjrSR4YGGFzjq3/e7uD+a1V/gdQ5XtQQZBwT8tY4BdWBqbXmKoS
MCvDzORr5QpD7Oy2OA9SCQ9/oMNe8ygmfKNlX+zMaasUhFfcXNP20iVor8YQLuLL
jHmABh0VyRwKwodOcpiXg28+7sdGaD5HQvqG1flTS9xK2OdzYNLVXuek2smq3KU4
1qXiUp8dz6V7H/CYjG8hWXgQnZnfdgHSyi/S0NiZucQ35v4IbhRjQzKaLGHduqyV
5GP5eToQ2OrSwdFYVoa73E8eQgiBmDrodDzc9Ocew/fOTVQ1rP8nsNYU77mjwr3k
Zh1m9RtG0Yi7RvBE9ifIm1p2woQQkD7ctIeaQvpUjJFfmexC3UFTFzwj9WLg0l46
rREx7BPkua9rxr+ttlSN/Dij26CPTVoy/RbM0naIBZYHBRNd4KFy85INdxYC79ug
ZZZrlQEozSEqtA7ooT5+fw25B9cudH+Dy5mfjqxtF2m8Ll0p3m+o1f53T0sEHV7m
hZTfhw0inWvHyEiece/v
=NL2s
-END PGP SIGNATURE-

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

Re: Apache Tomcat 7 (7.0.78) - Introduction

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

付传淮,

On 5/31/17 3:31 AM, 付传淮 wrote:
> I am learning tomcat,I found such a title on the following page. 
> http://tomcat.apache.org/tomcat-7.0-doc/introduction.html at all
> Introduction of the tomcat document,you can see:
> 
> Context - In a nutshell, a Context is a web application.
> 
> Term2 - This is it.
> 
> Term3 - This is it!
> 
> I do not understand what the Term 2 and 3 are doing, is this the
> key just like the key character reserved in Java?

I think those are terms that nobody ever defined. It looks like a
copy/paste mistake.

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

iQIcBAEBCAAGBQJZLwneAAoJEBzwKT+lPKRYGeQP/iOeURUDXN9TAYou7L7f2eaS
l2FhBisfvu8LBJH00kzdrsggoBkCwIpun8QULLDLwkz/FdwQtLigqZ+PR7VhFXOr
FaHk8q1GQ72K3Wsaxn7OR5Or7k/ZCO8TKqzFlxhXbASNT8fuM150IIs1J16aLhfX
muHFDHTAe5USW4lWxcJAu0US0NArtwsLBKTpkDziiVnyOpmz0i/cCuhMkScGFEOr
5jwJ0rOlGan5PA+KhP0JxfSotLXGod8AWj1c1vTceCtXWISoTdRzcNBn8K09WKnH
k5bFoOZrRZei6NU/iBi8kYoMGjtVyGFT57Xs4e4a7hCqJbqW6/jYhfuYTcyDdTjr
l/ri94uKySLGGigf54sTA0hNKjeZzCgCSjCiHd97ISYrE6kpJXznNyTvxyMeEzCr
he3BuCzqJhcIVMGBx+nctKRZW2mghDgaB0xjYXybmyykkPIJlOoUl1pxx5oe64U9
hm/5oQan/J5gCDkaqTUCmSoLofixZTcuuJwHs+7pxxVa7SgvcJ2Ot/SdSEFZEDNy
wtZ5nAgIwqui/9pw/CPlWi5Btp3zt3VlZPd286b0yyybpEl/qbqwsG3xpfMWvjLN
Dd1jO+IfHxB9SBT7Wg+sPPoETdJdh2NwHx15/M2Ak9uhGx61ptLMYcRymNOpfqpK
eGFQjj0zjDoDlJvFz1az
=zC3Y
-END PGP SIGNATURE-

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

Re: Security Headers Implementation in Tomcat 6.x version

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mohammad,

On 5/31/17 6:37 AM, Shaik, Mohammad N. wrote:
> Can I simply use the JAR files from Tomcat 7 that contains 
> executable code of filter classes (security headers), and put them 
> into corresponding location in Tomcat 6?

Definitely don't do that. But you could probably grab the compiled
.class files from Tomcat 7's binary distribution... just make sure you
have all of them.

So, basically, create a new JAR file that contains only those Filter
classes (don't forget any inner classes that might be found in
separate .class files).

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

iQIcBAEBCAAGBQJZLwnHAAoJEBzwKT+lPKRYVZ4P/1XAtHfld2JwqfQLLUTaiZ7C
jlJoUOjImnwTI4JAKOnlaSIQ0c0IhboBlPxcuBOaAbn5zbKOQZslqbWhidnHuKp5
T5C8eChRR8OuP6cJAi2zCx0m7NgxInaYRIMdbxBGIwnAOZkaq0UgKY2JYo9OUfeJ
S5VRuZIKdH8nE3dlriC72uZkn2ZXPoHMe3KyfsNZzR8UNqyZmQwUsb8645Xiw0up
Sik6onVBiqSubnLCYslhizMiK7r7hU55whMbsS3tDXnfck8ZwE6nRldxRw630vet
D9b00aUw5Em9SW9ZaeIG/n6x/L7hTFzJJFhKMuhEQHndo610xDiI+d2fADEfvx/i
L5BKGzVwoUtq0MpUxKpwMeoKagA9NYpbSDyLpeJViqv/m77KOA4O2hGwmcq/UOml
XFQ//5yaHvGL+W8ICNZCzgdTX5OgOwx0Nbu9ii7//FOcI5O2uT+0EN+LoagGpDNy
OJmQm5PsXJDvScoyNRK+z6mgPpe+3YPR7tKfx9Aw6TlPecB8VaXY2zLMf7g0wck3
AMtGfaqKw1kSjLEmLrSb7rUCDxEROXh4zgpZS1Xv0/0tPfmoFPWxx7msw6bVd9CB
aKKw7NbMkUehs4lBixzPGHqBQfpMyvJByUQyY4ThUCrJM/DU/9y2rwdwJGYFR+lv
mD63/FtqNHglnYULpUTS
=jN8f
-END PGP SIGNATURE-

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

Re: Considering @serverEndPoint url for routing the request , if the request is of ws:// type

[Bhuvan Gupta]

Martin,
>
> according to the author of Guice 4.0 there are 2 COMPLETELY DIFFERENT
> CONFIGURATIONS for WebServlet and WebSocket configurations


WebServlet is used for configuring the routes/ scope from guice module.

Where as extending ServerEndpointConfig.Configurator is not something Guice
provided it is provided by
JSR(356).
I can explain over call as well.
Skype:bhuvangupta89



On Wed, May 31, 2017 at 5:39 PM, Martin Gainty  wrote:

> according to the author of Guice 4.0 there are 2 COMPLETELY DIFFERENT
> CONFIGURATIONS for WebServlet and
>
> WebSocket configurations
>
>
> Custom Guice servlet context listener:
>
> public class CustomServletContextListener extends GuiceServletContextListener 
> {
> public static Injector injector;
>
> @Override
> protected Injector getInjector() {
> injector = Guice.createInjector(...);
> return injector;
> }}
>
> Websockets custom configurator:
>
> public class CustomConfigurator extends Configurator {
>   @Override
>   public  T getEndpointInstance(Class clazz)
> throws InstantiationException {
> return CustomServletContextListener.injector.getInstance(clazz);
>   }}
>
> And then in the Websocket endpoint:
>
> @ServerEndpoint(value = "/ws/sample_endpoint", configurator = 
> CustomConfigurator.class)public class SampleEndpoint {
>   private final SomeService service;
>
>   @Inject
>   public SampleEndpoint(SomeService service) {
> this.service = service;
>   }
>   ...}
>
> in ServerEndpoint you need to change your configurator to WebSocket
> Configurator class that extends ServerEndpointConfig.Configurator
>
>
> https://stackoverflow.com/questions/27499800/tomcat8-
> websockets-jsr-356-with-guice-3-0
>
> 
> Tomcat8 WebSockets (JSR-356) with Guice 3.0
> 
> stackoverflow.com
> I am trying to @Inject a Guice service into a @ServerEndpoint. I am using
> Tomcat 8.0.15 as the JSR-356 implementation. However, the dependency
> injection isn't working. Is there any additional
>
>
>
> BTW: if your claim that Guice is NOT JSR-356 conformant is valid you need
> to take this up with Guice Authors
>
> i use Guice occasionally opting instead to use Spring Framework 4.x for
> the majority of my work
>
>
> Good Luck!
> Martin
> __
>
>
> --
> *From:* Bhuvan Gupta 
> *Sent:* Tuesday, May 30, 2017 11:33 PM
> *To:* Martin Gainty; Tomcat Users List
> *Subject:* Re: Considering @serverEndPoint url for routing the request ,
> if the request is of ws:// type
>
> >>>at what point does your websocket class extend org.apache.tomcat.webso
> cket.server.WsFilter
>
> I am not extending the o.a.t.w.s.WsFilter at any point , i am using the
> JSR(356) where i only need to define the @ServerEndPoint.
>
> If you look at the 6th observation in https://stackoverflow.com/
> questions/44216801/tomcat-using-servlet-and-websocket-
> jsr356-in-same-web-app
>
> 
> Tomcat: using servlet and websocket (jsr356) in same web app
> 
> stackoverflow.com
> I create a sample webapp using Guice-servlets and websocket in tomcat, now
> once guice filter is used websocket stop working Basic information: In my
> web.xml, i initialized the Guiceservlet using
>
>
>
>
>
> On Wed, May 31, 2017 at 12:00 AM, Martin Gainty 
> wrote:
>
>> possibly mixing up asking guice to inject HttpServlets with asking
>> guice injecting webSocket classes
>>
>>
>> at what point does your websocket class extend org.apache.tomcat.webso
>> cket.server.WsFilter
>>
>>
>> ?
>> M
>> __
>>
>>
>>
>>
>> --
>> *From:* Bhuvan Gupta 
>> *Sent:* Tuesday, May 30, 2017 11:12 AM
>> *To:* Tomcat Users List
>> *Subject:* Re: Considering @serverEndPoint url for routing the request ,
>> if the request is of ws:// type
>>
>> I have added some observation for the issue and observation 5 is
>> interesting
>> Basically it shows that web.xml filter are registered before WsFilter can
>> register, which creates a problem
>>
>> Please clarify:
>>
>> https://stackoverflow.com/questions/44216801/tomcat-using-
>> servlet-and-websocket-jsr356-in-same-web-app
>>
>> 
>> Tomcat: using servlet and websocket (jsr356) in same web app
>> 
>> stackoverflow.com
>> I create a sample webapp using Guice-servlets and websocket in tomcat,
>> 

Possible bug between Apache 2.4 and Tomcat 7 via AJP when POSTing

[Nicholas Cottrell]

Hi All!

I'm having a problem setting up an existing webapp from Apache 2.2/Tomcat6 on a 
new server running Centos 7, and the following packages:

httpd   2.4.6-45.el7.centos.4
tomcat.noarch7.0.69-11.el7_3 @updates   
tomcat-native.x86_64 1.1.34-1.el7@epel  

For debugging I have enabled AJP/1.3 and 8009 and HTTP on 8080, then use Apache 
to ProxyPass.

With my initial configuration, data from a form POST is not available via 
request.getParameter:

  ProxyPass / ajp://localhost:8009/  retry=1 
acquire=3000 timeout=600 Keepalive=On
  ProxyPassReverse / ajp://localhost:8009/ 

But changing it to this fixes everything:

  ProxyPass / http://localhost:8080/  retry=1 
acquire=3000 timeout=600 Keepalive=On
  ProxyPassReverse / http://localhost:8080/ 

In the broken instance, request.getParameter("x") returned null, but 
request.getReader() returned bytes with "x=123" so seems that Apache is sending 
the POST body but Tomcat is not processing it correctly, yes?

Please also see 
https://stackoverflow.com/questions/44167876/problems-with-post-parameters-with-tomcat-ajp-on-apache-2-4-but-not-2-2
 

 for my steps so far.

I would prefer to switch back to AJP for the proxy, since I understand it is 
more performant, right? Should I try forcing a Tomcat 8 install to see if the 
problem persists there too?

Best,
Nic.

Re: Security Headers Implementation in Tomcat 6.x version

[Olaf Kock]

Am 29.05.2017 um 13:34 schrieb Shaik, Mohammad N.:
> Hello Olaf,
>
> Thanks for your response!
>
> Based on your inputs, we are thinking to put Apache httpd in front of Tomcat 
> 6 server, since our header configuration is going to be static.
>
> Can you please help us in identifying which version of Apache HTTP Server we 
> can use for Tomcat 6 version? Also, it will be great if you can share some 
> guidelines on how to implement Apache in front of Tomcat.

For completeness sake I'd like to answer a few of these questions,
rather briefly. It seems that you're deep into implementing
Christopher's solution of compiling the newer filters for Tomcat 6.

Every current Apache httpd is fine, no version restriction. Especially:
Choose one that will get updates for quite a while, not like the
outdated Tomcat version you're running. Read on mod_proxy,
mod_proxy_ajp, mod_jk and mod_proxy_http, which are all keywords on the
connection between Apache and tomcat. Once you've set this up, setting
the headers is a matter of adding the "Header" directive to httpd's
configuration. I understand though, that setting up the connection can
be some task if you've never done that. Especially if you're using
https, and also refer to it in your webapp's code (e.g. to validate
client certs) - but as you give no clue you're doing that, I'm assuming
you don't and the setup would be easy.

Anyway, feel free to utilize the newer code - I just wanted this
information to be in this thread as well. However, once you're done with
it: Utilize even more newer code and prepare to migrate away from your
discontinued tomcat version.

Olaf



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

Re: Security Headers Implementation in Tomcat 6.x version

[Violeta Georgieva]

Hi,

2017-05-31 13:37 GMT+03:00 Shaik, Mohammad N. <
mohammad.n.sh...@accenture.com>:
>
> Hi Chris,
>
> Can I simply use the JAR files from Tomcat 7 that contains executable
code of filter classes (security headers), and put them into corresponding
location in Tomcat 6?

I would not recommend that. You might easily hit variety of class loading
problems.
Just grab the java files and compile them against Tomcat/lib.

Regards,
Violeta

>
> Regards,
> Mohammad
>
> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: 30 May 2017 21:06
> To: users@tomcat.apache.org
> Subject: Re: Security Headers Implementation in Tomcat 6.x version
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Mohammad,
>
> On 5/30/17 2:13 AM, Shaik, Mohammad N. wrote:
> > Thanks for the valuable input, that helps!! We shall go with getting
> > the source package of Tomcat 7, put them in Tomcat 6 and use the
> > filters of Tomcat 7 in Tomcat 6.
> >
> > Can you please let me know from where I can get/download the source
> > package of Tomcat 7? Also can you please share the location of the
> > source package in Tomcat 6 so that we can replace it with the one from
> > Tomcat 7?
>
> The source download for Tomcat 7 is in the same place all the other
downloads are.
>
> You will not need the source for Tomcat 6, nor will you need to build the
complete source-to-binary for Tomcat 7. Just grab the source, take the
classes you need, and compile them against the servlet JAR you already have
for Tomcat 6. Feel free to re-name the packages if they are awkward for you
to compile/install and then just reference the new class names in your
application/server.
>
> Remember to watch for patches to those source files in Tomcat 7 in case
they include e.g. security updates -- you'll want to apply those same
updates to the code you have taken from Tomcat 7.
>
> A longer-term goal should be to upgrade to Tomcat 8 or 8.5. Tomcat is
backward-compatible with all spec-compliant applications, though it does
behave differently sometimes as the Servlet Experts Group has clarified
certain questions or added new capabilities (like annotation-processing). I
recommend a long period of testing with a new version of Tomcat, but I also
recommend that you begin that testing as soon as possible. Tomcat 6 will
probably receive *no further updates, security or otherwise*, even if a
vulnerability is foun d.
>
> - -chris
>
> > -Original Message- From: Christopher Schultz
> > [mailto:ch...@christopherschultz.net] Sent: 29 May 2017 20:57 To:
> > users@tomcat.apache.org Subject: Re: Security Headers Implementation
> > in Tomcat 6.x version
> >
> > Mohammad,
> >
> > On 5/29/17 7:34 AM, Shaik, Mohammad N. wrote:
> >> Based on your inputs, we are thinking to put Apache httpd in front of
> >> Tomcat 6 server, since our header configuration is going to be
> >> static.
> >
> > This might not be a bad idea for a number of reasons, but it is by no
> > means required.
> >
> > You can download the Tomcat 7 source package and use the security
> > filters from Tomcat 7[1] in Tomcat 6: there is nothing in there that
> > actually requires Tomcat 7 to run.
> >
> >> Can you please help us in identifying which version of Apache HTTP
> >> Server we can use for Tomcat 6 version? Also, it will be great if you
> >> can share some guidelines on how to implement Apache in front of
> >> Tomcat.
> > All supported versions of Apache web server work with app supported
> > versions of Tomcat (as well as Tomcat 6). You have several choices for
> > how to connect them together, but the most straightforward is to use
> > mod_proxy_http from httpd to Tomcat.
> > Tomcat behaves exactly as it did before and requires no additional
> > configuration unless you are moving TLS termination from Tomcat to
> > httpd. If that's the case, there are many guides on the web as well as
> > on Tomcat's Presentations Page[2] that document how to do that.
> >
> > Hope that helps, -chris
> >
> > [1] http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html [2]
> > http://tomcat.apache.org/presentations.html
> >
> > -
> >
> >
> >
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >
> > 
> >
> > This message is for the designated recipient only and may contain
> > privileged, proprietary, or otherwise confidential information. If you
> > have received it in error, please notify the sender immediately and
> > delete the original. Any other use of the e-mail by you is prohibited.
> > Where allowed by local law, electronic communications with Accenture
> > and its affiliates, including e-mail and instant messaging (including
> > content), may be scanned by our systems for the purposes of
> > information security and assessment of internal compliance with
> > Accenture policy.
> > 

Re: Security Headers Implementation in Tomcat 6.x version

[Violeta Georgieva]

Hi,

2017-05-31 13:34 GMT+03:00 Shaik, Mohammad N. <
mohammad.n.sh...@accenture.com>:
>
> Hi Chris,
>
> I got the source files (.java) of the filter classes that I was looking
for.
>
> Should we compile the source file against the servlet jar file(s) present
in "[Tomcat]\lib\"

Yes.
Compile them against the jar files located in Tomcat/lib.
The servlet API classes will be loaded from Tomcat/lib a.k.a. common
loader. More you can find here:

http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html#Class_Loader_Definitions
- Common — This class loader contains additional classes that are made
visible to both Tomcat internal classes and to all web applications.
- WebappX — A class loader is created for each web application that is
deployed in a single Tomcat instance.


> or "[Tomcat]\webapps\ApplicationName\WEB-INF\lib"? I see there are
multiple JAR files in both these locations. How to locate the exact JAR
file which should be used to compile source files?
>
> My understanding is that as long as you have your code (.class files) in
any of the JAR files under "lib" folder, system would get it. You don’t
need to have specific code in specific JAR file. Code from all the jar
files under lib folder is considered as one big code, and based on the
class invoked its corresponding code gets executed from that one big code.
Please correct me if this is not right.
>
> Also, should we include the filters in web.xml file under
"[Tomcat]\conf\" folder or under "WEB-INF" folder of my application?

The web.xml located in Tomcat/conf is the "global" one. The configurations
there will be applied to every web application deployed on the Tomcat
instance. So if you need to apply this filter to all web apps then place
the definition and configurations there. Otherwise you can provide the
filter definition and configurations in the WEB-INF/web.xml for a
particular web app.

Regards,
Violeta

>
>
> Regards,
> Mohammad
>
> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: 30 May 2017 21:06
> To: users@tomcat.apache.org
> Subject: Re: Security Headers Implementation in Tomcat 6.x version
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Mohammad,
>
> On 5/30/17 2:13 AM, Shaik, Mohammad N. wrote:
> > Thanks for the valuable input, that helps!! We shall go with getting
> > the source package of Tomcat 7, put them in Tomcat 6 and use the
> > filters of Tomcat 7 in Tomcat 6.
> >
> > Can you please let me know from where I can get/download the source
> > package of Tomcat 7? Also can you please share the location of the
> > source package in Tomcat 6 so that we can replace it with the one from
> > Tomcat 7?
>
> The source download for Tomcat 7 is in the same place all the other
downloads are.
>
> You will not need the source for Tomcat 6, nor will you need to build the
complete source-to-binary for Tomcat 7. Just grab the source, take the
classes you need, and compile them against the servlet JAR you already have
for Tomcat 6. Feel free to re-name the packages if they are awkward for you
to compile/install and then just reference the new class names in your
application/server.
>
> Remember to watch for patches to those source files in Tomcat 7 in case
they include e.g. security updates -- you'll want to apply those same
updates to the code you have taken from Tomcat 7.
>
> A longer-term goal should be to upgrade to Tomcat 8 or 8.5. Tomcat is
backward-compatible with all spec-compliant applications, though it does
behave differently sometimes as the Servlet Experts Group has clarified
certain questions or added new capabilities (like annotation-processing). I
recommend a long period of testing with a new version of Tomcat, but I also
recommend that you begin that testing as soon as possible. Tomcat 6 will
probably receive *no further updates, security or otherwise*, even if a
vulnerability is foun d.
>
> - -chris
>
> > -Original Message- From: Christopher Schultz
> > [mailto:ch...@christopherschultz.net] Sent: 29 May 2017 20:57 To:
> > users@tomcat.apache.org Subject: Re: Security Headers Implementation
> > in Tomcat 6.x version
> >
> > Mohammad,
> >
> > On 5/29/17 7:34 AM, Shaik, Mohammad N. wrote:
> >> Based on your inputs, we are thinking to put Apache httpd in front of
> >> Tomcat 6 server, since our header configuration is going to be
> >> static.
> >
> > This might not be a bad idea for a number of reasons, but it is by no
> > means required.
> >
> > You can download the Tomcat 7 source package and use the security
> > filters from Tomcat 7[1] in Tomcat 6: there is nothing in there that
> > actually requires Tomcat 7 to run.
> >
> >> Can you please help us in identifying which version of Apache HTTP
> >> Server we can use for Tomcat 6 version? Also, it will be great if you
> >> can share some guidelines on how to implement Apache in front of
> >> Tomcat.
> > All supported versions of Apache web server work with app supported
> > versions of Tomcat (as well as 

RE: Security Headers Implementation in Tomcat 6.x version

[Shaik, Mohammad N.]

Hi Chris,

Can I simply use the JAR files from Tomcat 7 that contains executable code of 
filter classes (security headers), and put them into corresponding location in 
Tomcat 6?

Regards,
Mohammad

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: 30 May 2017 21:06
To: users@tomcat.apache.org
Subject: Re: Security Headers Implementation in Tomcat 6.x version

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mohammad,

On 5/30/17 2:13 AM, Shaik, Mohammad N. wrote:
> Thanks for the valuable input, that helps!! We shall go with getting
> the source package of Tomcat 7, put them in Tomcat 6 and use the
> filters of Tomcat 7 in Tomcat 6.
>
> Can you please let me know from where I can get/download the source
> package of Tomcat 7? Also can you please share the location of the
> source package in Tomcat 6 so that we can replace it with the one from
> Tomcat 7?

The source download for Tomcat 7 is in the same place all the other downloads 
are.

You will not need the source for Tomcat 6, nor will you need to build the 
complete source-to-binary for Tomcat 7. Just grab the source, take the classes 
you need, and compile them against the servlet JAR you already have for Tomcat 
6. Feel free to re-name the packages if they are awkward for you to 
compile/install and then just reference the new class names in your 
application/server.

Remember to watch for patches to those source files in Tomcat 7 in case they 
include e.g. security updates -- you'll want to apply those same updates to the 
code you have taken from Tomcat 7.

A longer-term goal should be to upgrade to Tomcat 8 or 8.5. Tomcat is 
backward-compatible with all spec-compliant applications, though it does behave 
differently sometimes as the Servlet Experts Group has clarified certain 
questions or added new capabilities (like annotation-processing). I recommend a 
long period of testing with a new version of Tomcat, but I also recommend that 
you begin that testing as soon as possible. Tomcat 6 will probably receive *no 
further updates, security or otherwise*, even if a vulnerability is foun d.

- -chris

> -Original Message- From: Christopher Schultz
> [mailto:ch...@christopherschultz.net] Sent: 29 May 2017 20:57 To:
> users@tomcat.apache.org Subject: Re: Security Headers Implementation
> in Tomcat 6.x version
>
> Mohammad,
>
> On 5/29/17 7:34 AM, Shaik, Mohammad N. wrote:
>> Based on your inputs, we are thinking to put Apache httpd in front of
>> Tomcat 6 server, since our header configuration is going to be
>> static.
>
> This might not be a bad idea for a number of reasons, but it is by no
> means required.
>
> You can download the Tomcat 7 source package and use the security
> filters from Tomcat 7[1] in Tomcat 6: there is nothing in there that
> actually requires Tomcat 7 to run.
>
>> Can you please help us in identifying which version of Apache HTTP
>> Server we can use for Tomcat 6 version? Also, it will be great if you
>> can share some guidelines on how to implement Apache in front of
>> Tomcat.
> All supported versions of Apache web server work with app supported
> versions of Tomcat (as well as Tomcat 6). You have several choices for
> how to connect them together, but the most straightforward is to use
> mod_proxy_http from httpd to Tomcat.
> Tomcat behaves exactly as it did before and requires no additional
> configuration unless you are moving TLS termination from Tomcat to
> httpd. If that's the case, there are many guides on the web as well as
> on Tomcat's Presentations Page[2] that document how to do that.
>
> Hope that helps, -chris
>
> [1] http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html [2]
> http://tomcat.apache.org/presentations.html
>
> -
>
>
>
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
> 
>
> This message is for the designated recipient only and may contain
> privileged, proprietary, or otherwise confidential information. If you
> have received it in error, please notify the sender immediately and
> delete the original. Any other use of the e-mail by you is prohibited.
> Where allowed by local law, electronic communications with Accenture
> and its affiliates, including e-mail and instant messaging (including
> content), may be scanned by our systems for the purposes of
> information security and assessment of internal compliance with
> Accenture policy.
> __

>
>
>
www.accenture.com
>
> -
>
>
>
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - 

RE: Security Headers Implementation in Tomcat 6.x version

[Shaik, Mohammad N.]

Hi Chris,

I got the source files (.java) of the filter classes that I was looking for.

Should we compile the source file against the servlet jar file(s) present in 
"[Tomcat]\lib\" or "[Tomcat]\webapps\ApplicationName\WEB-INF\lib"? I see there 
are multiple JAR files in both these locations. How to locate the exact JAR 
file which should be used to compile source files?

My understanding is that as long as you have your code (.class files) in any of 
the JAR files under "lib" folder, system would get it. You don’t need to have 
specific code in specific JAR file. Code from all the jar files under lib 
folder is considered as one big code, and based on the class invoked its 
corresponding code gets executed from that one big code. Please correct me if 
this is not right.

Also, should we include the filters in web.xml file under "[Tomcat]\conf\" 
folder or under "WEB-INF" folder of my application?


Regards,
Mohammad

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: 30 May 2017 21:06
To: users@tomcat.apache.org
Subject: Re: Security Headers Implementation in Tomcat 6.x version

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mohammad,

On 5/30/17 2:13 AM, Shaik, Mohammad N. wrote:
> Thanks for the valuable input, that helps!! We shall go with getting
> the source package of Tomcat 7, put them in Tomcat 6 and use the
> filters of Tomcat 7 in Tomcat 6.
>
> Can you please let me know from where I can get/download the source
> package of Tomcat 7? Also can you please share the location of the
> source package in Tomcat 6 so that we can replace it with the one from
> Tomcat 7?

The source download for Tomcat 7 is in the same place all the other downloads 
are.

You will not need the source for Tomcat 6, nor will you need to build the 
complete source-to-binary for Tomcat 7. Just grab the source, take the classes 
you need, and compile them against the servlet JAR you already have for Tomcat 
6. Feel free to re-name the packages if they are awkward for you to 
compile/install and then just reference the new class names in your 
application/server.

Remember to watch for patches to those source files in Tomcat 7 in case they 
include e.g. security updates -- you'll want to apply those same updates to the 
code you have taken from Tomcat 7.

A longer-term goal should be to upgrade to Tomcat 8 or 8.5. Tomcat is 
backward-compatible with all spec-compliant applications, though it does behave 
differently sometimes as the Servlet Experts Group has clarified certain 
questions or added new capabilities (like annotation-processing). I recommend a 
long period of testing with a new version of Tomcat, but I also recommend that 
you begin that testing as soon as possible. Tomcat 6 will probably receive *no 
further updates, security or otherwise*, even if a vulnerability is foun d.

- -chris

> -Original Message- From: Christopher Schultz
> [mailto:ch...@christopherschultz.net] Sent: 29 May 2017 20:57 To:
> users@tomcat.apache.org Subject: Re: Security Headers Implementation
> in Tomcat 6.x version
>
> Mohammad,
>
> On 5/29/17 7:34 AM, Shaik, Mohammad N. wrote:
>> Based on your inputs, we are thinking to put Apache httpd in front of
>> Tomcat 6 server, since our header configuration is going to be
>> static.
>
> This might not be a bad idea for a number of reasons, but it is by no
> means required.
>
> You can download the Tomcat 7 source package and use the security
> filters from Tomcat 7[1] in Tomcat 6: there is nothing in there that
> actually requires Tomcat 7 to run.
>
>> Can you please help us in identifying which version of Apache HTTP
>> Server we can use for Tomcat 6 version? Also, it will be great if you
>> can share some guidelines on how to implement Apache in front of
>> Tomcat.
> All supported versions of Apache web server work with app supported
> versions of Tomcat (as well as Tomcat 6). You have several choices for
> how to connect them together, but the most straightforward is to use
> mod_proxy_http from httpd to Tomcat.
> Tomcat behaves exactly as it did before and requires no additional
> configuration unless you are moving TLS termination from Tomcat to
> httpd. If that's the case, there are many guides on the web as well as
> on Tomcat's Presentations Page[2] that document how to do that.
>
> Hope that helps, -chris
>
> [1] http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html [2]
> http://tomcat.apache.org/presentations.html
>
> -
>
>
>
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
> 
>
> This message is for the designated recipient only and may contain
> privileged, proprietary, or otherwise confidential information. If you
> have received it in error, please notify the sender immediately and
> delete the original. Any other use of the e-mail by you is 

Re: parallel deployment and websockets

[Johan Compagner]

On 31 May 2017 at 10:11, Mark Thomas  wrote:

>
> >>
> >>
> > would a feature request be accepted for this that there can be a cookie
> set
> > where that "load balancer" would also look at?
> > and that  cookie always make sure that it goes to the context it started
> > from as long as that context is there?
>
> Maybe.
>
> What is the use case? Why can't a new WebSocket connection be created to
> the new version of the web application?
>

because it looses then state.
Like i said below, our application is a statefull application but we use
websocket what was previously ajax request to push back and forward changes
to server and client
(so a data change on the server is pushed right away to the client)

We have our own session tracking over the websocket url:

wss://domain/websocketendpoint/sessionuuidparam

the first time that sessionuuidparam is null but then we push that value to
the client and store it in the session storage (so that tab in the browser)
and if we do a refresh or a reconnect then we send that session uuid to the
server and the server will connect that new websocket endpoint to our
"session" object

So a new context would not find that session object because i guess that is
a fully new classloader/application deploy...
so we lost the session.
In the ajax version this would not happen because that is all pure async
http request to the server with a http session object..



>
> > Because it is quite annoying that it is tied to a jsessionid of a
> > HttpSession that should then be created and kept alive for the whole
> > websocket session..
> >
> > i can do something like this:
> >
> > https://stackoverflow.com/questions/17936440/accessing-httpsession-from-
> httpservletrequest-in-a-web-socket-serverendpoint
> >
> > but isn't that kind of doing something that shouldn't be done? Like
> keeping
> > a reference to a http session?
> >
> > Even if i do the above then still i need to "touch" the session on every
> > websocket request to keep it alive
> > Or set the max idle time out to -1 so it never by itself invalidates()
> > And then when i know the websocket session is really gone i will call
> > invalidate() on it myself..
>
> If you are invalidating the HTTP session once the WebSocket connection
> closes, why keep the session alive in the first place?
>


No we wouldn't close it on the websocket connection close, but on the
timeout of the Session object that is behind that connection
And if before the time out happens a new websocket connection is coming in
(with the above url) then we quickly re attach the session object to that
new endpoint and it will go on

only after a while if there is no new websocket being setup, we invalidate
the session object (and then we could also invalidate the http session that
we stored)


So in the end this is just kind of the same as http sessions in tomcat...
but then real session support over multiply request for websockets
And we don't use a cookie but purely have the id always in the url because
this way multiply tabs in the browser are always independent of each other.

So it would be nice if tomcat would have versioning support for websockets
under the hood...
Like a setting that we could turn on and then when an upgrade happens
tomcat auto sends a cookie which it reuses to connect to the right context
version

johan

Re: parallel deployment and websockets

[Mark Thomas]

On 31/05/17 08:38, Johan Compagner wrote:
>>
>>
>> It depends. If the URL in the HTTP UPGRADE request includes the session
>> ID, and that session ID is still valid in ##1, then the WebSocket
>> request will be handled by ##1.
>>
>> Mark
>>
>>
> would a feature request be accepted for this that there can be a cookie set
> where that "load balancer" would also look at?
> and that  cookie always make sure that it goes to the context it started
> from as long as that context is there?

Maybe.

What is the use case? Why can't a new WebSocket connection be created to
the new version of the web application?

> Because it is quite annoying that it is tied to a jsessionid of a
> HttpSession that should then be created and kept alive for the whole
> websocket session..
> 
> i can do something like this:
> 
> https://stackoverflow.com/questions/17936440/accessing-httpsession-from-httpservletrequest-in-a-web-socket-serverendpoint
> 
> but isn't that kind of doing something that shouldn't be done? Like keeping
> a reference to a http session?
> 
> Even if i do the above then still i need to "touch" the session on every
> websocket request to keep it alive
> Or set the max idle time out to -1 so it never by itself invalidates()
> And then when i know the websocket session is really gone i will call
> invalidate() on it myself..

If you are invalidating the HTTP session once the WebSocket connection
closes, why keep the session alive in the first place?

Mark


> 
> But this is all quite cumbersome
> 
> We just have state there is no way around it, but the communication between
> server and client is after the first startup completely over websocket
> (just like ajax before)>
> For example it would be nice if tomcat did this just under the hood. if
> tomcat upgrades a http request to a websocket then it will also just push a
> small cookie on it to know which context version it was on...
> 
> johan
> 


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

Re: Apache Tomcat 7 (7.0.78) - Introduction

[Addy D]

On Wed, May 31, 2017 at 1:01 PM, 付传淮 <337435...@qq.com> wrote:

> I am learning tomcat,I found such a title on the following page.
> http://tomcat.apache.org/tomcat-7.0-doc/introduction.html
> at all Introduction of the tomcat document,you can see:
>
> Context - In a nutshell, a Context is a web application.
>
> Term2 - This is it.
>
> Term3 - This is it!
>
> I do not understand what the Term 2 and 3 are doing, is this the key just
> like the key character reserved in Java?


I think they are just trying to explain the terminology used in their
document and Term1 and Term2 are example for it. So if I have understood it
correctly it is like *context *- In a nutshell, a Context is a web
application. explains the meaning of context. And context it self is a term
and hence it is in bold.

Re: parallel deployment and websockets

[Johan Compagner]

>
>
> It depends. If the URL in the HTTP UPGRADE request includes the session
> ID, and that session ID is still valid in ##1, then the WebSocket
> request will be handled by ##1.
>
> Mark
>
>
would a feature request be accepted for this that there can be a cookie set
where that "load balancer" would also look at?
and that  cookie always make sure that it goes to the context it started
from as long as that context is there?

Because it is quite annoying that it is tied to a jsessionid of a
HttpSession that should then be created and kept alive for the whole
websocket session..

i can do something like this:

https://stackoverflow.com/questions/17936440/accessing-httpsession-from-httpservletrequest-in-a-web-socket-serverendpoint

but isn't that kind of doing something that shouldn't be done? Like keeping
a reference to a http session?

Even if i do the above then still i need to "touch" the session on every
websocket request to keep it alive
Or set the max idle time out to -1 so it never by itself invalidates()
And then when i know the websocket session is really gone i will call
invalidate() on it myself..

But this is all quite cumbersome

We just have state there is no way around it, but the communication between
server and client is after the first startup completely over websocket
(just like ajax before)

For example it would be nice if tomcat did this just under the hood. if
tomcat upgrades a http request to a websocket then it will also just push a
small cookie on it to know which context version it was on...

johan

Apache Tomcat 7 (7.0.78) - Introduction

[??????]

I am learning tomcat,I found such a title on the following page.
http://tomcat.apache.org/tomcat-7.0-doc/introduction.html
at all Introduction of the tomcat document,you can see:

Context - In a nutshell, a Context is a web application.

Term2 - This is it.

Term3 - This is it!

I do not understand what the Term 2 and 3 are doing, is this the key just like 
the key character reserved in Java?