Re: SEVERE: A child container failed during start

[Karen Goh]

Sent from Yahoo Mail for iPhone


On Saturday, November 30, 2019, 6:18 AM, Mark Thomas  wrote:

On 29/11/2019 21:28, Karen Goh wrote:
> I have done so but it is no use. I have deleted the Tomcat and add an new 
> instance before run the server again.
> caused by java.lang.IllegalArgumentException : Filter mapping specifies an 
> unknown filter name[SessionValidator]
> Sorry I am having problem with writing here using Yahoo mail n I have to type 
> things out in iPhone so I can’t copy n paste the entire error message. Should 
> you need more info in order to help me I hope I can just write above the 
> reply message.

You seem to be missing the point. The problematic filter is named:

httpHeaderSecurity

You need to find where that is referenced in your code and/or configuration.
I can’t find this filter at all, even though I am playing with something along 
the line of httpHeaderSecurity (JWT/JSSE etc to be precise) but my project is 
done intermittently cos most of the time I am meshing up the code from various 
sources and use it...
What do I do in this case?  Re-start a fresh project?

Mark


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

Re: SEVERE: A child container failed during start

[Mark Thomas]

On 29/11/2019 21:28, Karen Goh wrote:
> I have done so but it is no use. I have deleted the Tomcat and add an new 
> instance before run the server again.
> caused by java.lang.IllegalArgumentException : Filter mapping specifies an 
> unknown filter name[SessionValidator]
> Sorry I am having problem with writing here using Yahoo mail n I have to type 
> things out in iPhone so I can’t copy n paste the entire error message. Should 
> you need more info in order to help me I hope I can just write above the 
> reply message.

You seem to be missing the point. The problematic filter is named:

httpHeaderSecurity

You need to find where that is referenced in your code and/or configuration.

Mark


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

Re: SEVERE: A child container failed during start

[Karen Goh]

Sent from Yahoo Mail for iPhone


On Saturday, November 30, 2019, 5:14 AM, M. Manna  wrote:

Karen,

On Fri, 29 Nov 2019 at 20:51, Karen Goh 
wrote:

>
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Friday, November 29, 2019, 8:39 PM, Karen Goh
>  wrote:
>
>
>
>
>
>
> On Friday, November 29, 2019, 6:59:38 PM GMT+8, Mark Thomas <
> ma...@apache.org> wrote:
>
>
> On 29/11/2019 10:44, Karen Goh wrote:
> > Hi experts,
> >
> >
> > Basically, I have now upgraded my dynamic MVC web app to use openJDK 13
> and running it with Tomcat 9.0.27. Windows OS. Eclipse 2019-09.
> >
> > Have been trying to tackling the problem with no avail.
> >
> > Would appreciate some tips on how to make these error go away.
>
> 
>
> > Caused by: java.lang.IllegalArgumentException: Filter mapping specifies
> an unknown filter name [httpHeaderSecurity]
>
> 
> I am not sure why the error persists even if I change the filter mapping
> to :
>
> SessionValidator/login.jsp
> And here is snippet my Filter :
> @WebFilter(“/SessionValidator”)public class SessionValidator implements
> Filter
> public void doFilter(ServletRequest request, ServletResponse response,
> FilterChain chain) throws IOException, ServletException{
> ..HttpSession session = httpRequest.getSession();If(session.isNew())
> {httpResponse.sendRedirect(httpResponse.encodedRedirectURL(httpRequest.getContextPath()
> + “/login.jsp”return;}And then redirect the user to error.html if log in
> user is null.
> Please let me know what’s wrong.
> Thanks
> Where and how is this filter specified as being required?
> Where and how is this filter defined?
>
> Please see below
>
> 
> http://www.w3.org/2001/XMLSchema-instance"; xmlns="
> http://xmlns.jcp.org/xml/ns/javaee"; xsi:schemaLocation="
> http://xmlns.jcp.org/xml/ns/javaee
> http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd"; version="4.0">
>  Archetype Created Web Application
>  
>  
>  Restricted Area
>  /search.jsp
>  
>  
>  
>  SessionValidator
>  Controller.SessionValidator
>  
>  
>  404
>  /error.html
>  
>  
>  403
>  /error.html
>  
>  
>  500
>  /error.html
>  
>  
>  java.lang.Exception
>  /error.html
>  
> 
>
>
> Mark
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
>
>
>
 I would advise that you remove @WebFilter and try again. Seems like it's
conflicted with processing annotation based and web.xml supplied filter
definitions.
Once you remove the annotation, give it a try and let us know.
I have done so but it is no use. I have deleted the Tomcat and add an new 
instance before run the server again.
caused by java.lang.IllegalArgumentException : Filter mapping specifies an 
unknown filter name[SessionValidator]
Sorry I am having problem with writing here using Yahoo mail n I have to type 
things out in iPhone so I can’t copy n paste the entire error message. Should 
you need more info in order to help me I hope I can just write above the reply 
message. Tks
Please advise.
Thanks.





Thanks,

Re: SEVERE: A child container failed during start

[M. Manna]

Karen,

On Fri, 29 Nov 2019 at 20:51, Karen Goh 
wrote:

>
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Friday, November 29, 2019, 8:39 PM, Karen Goh
>  wrote:
>
>
>
>
>
>
> On Friday, November 29, 2019, 6:59:38 PM GMT+8, Mark Thomas <
> ma...@apache.org> wrote:
>
>
> On 29/11/2019 10:44, Karen Goh wrote:
> > Hi experts,
> >
> >
> > Basically, I have now upgraded my dynamic MVC web app to use openJDK 13
> and running it with Tomcat 9.0.27. Windows OS. Eclipse 2019-09.
> >
> > Have been trying to tackling the problem with no avail.
> >
> > Would appreciate some tips on how to make these error go away.
>
> 
>
> > Caused by: java.lang.IllegalArgumentException: Filter mapping specifies
> an unknown filter name [httpHeaderSecurity]
>
> 
> I am not sure why the error persists even if I change the filter mapping
> to :
>
> SessionValidator/login.jsp
> And here is snippet my Filter :
> @WebFilter(“/SessionValidator”)public class SessionValidator implements
> Filter
> public void doFilter(ServletRequest request, ServletResponse response,
> FilterChain chain) throws IOException, ServletException{
> ..HttpSession session = httpRequest.getSession();If(session.isNew())
> {httpResponse.sendRedirect(httpResponse.encodedRedirectURL(httpRequest.getContextPath()
> + “/login.jsp”return;}And then redirect the user to error.html if log in
> user is null.
> Please let me know what’s wrong.
> Thanks
> Where and how is this filter specified as being required?
> Where and how is this filter defined?
>
> Please see below
>
> 
> http://www.w3.org/2001/XMLSchema-instance"; xmlns="
> http://xmlns.jcp.org/xml/ns/javaee"; xsi:schemaLocation="
> http://xmlns.jcp.org/xml/ns/javaee
> http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd"; version="4.0">
>  Archetype Created Web Application
>  
>  
>  Restricted Area
>  /search.jsp
>  
>  
>  
>  SessionValidator
>  Controller.SessionValidator
>  
>  
>  404
>  /error.html
>  
>  
>  403
>  /error.html
>  
>  
>  500
>  /error.html
>  
>  
>  java.lang.Exception
>  /error.html
>  
> 
>
>
> Mark
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
>
>
>
 I would advise that you remove @WebFilter and try again. Seems like it's
conflicted with processing annotation based and web.xml supplied filter
definitions.
Once you remove the annotation, give it a try and let us know.

Thanks,

Re: SEVERE: A child container failed during start

[Karen Goh]

Sent from Yahoo Mail for iPhone


On Friday, November 29, 2019, 8:39 PM, Karen Goh  
wrote:






On Friday, November 29, 2019, 6:59:38 PM GMT+8, Mark Thomas  
wrote:


On 29/11/2019 10:44, Karen Goh wrote:
> Hi experts,
>
>
> Basically, I have now upgraded my dynamic MVC web app to use openJDK 13 and 
> running it with Tomcat 9.0.27. Windows OS. Eclipse 2019-09.
>
> Have been trying to tackling the problem with no avail.
>
> Would appreciate some tips on how to make these error go away.



> Caused by: java.lang.IllegalArgumentException: Filter mapping specifies an 
> unknown filter name [httpHeaderSecurity]


I am not sure why the error persists even if I change the filter mapping to :
SessionValidator/login.jsp
And here is snippet my Filter :
@WebFilter(“/SessionValidator”)public class SessionValidator implements 
Filter
public void doFilter(ServletRequest request, ServletResponse response, 
FilterChain chain) throws IOException, ServletException{
..HttpSession session = httpRequest.getSession();If(session.isNew()) 
{httpResponse.sendRedirect(httpResponse.encodedRedirectURL(httpRequest.getContextPath()
 + “/login.jsp”return;}And then redirect the user to error.html if log in user 
is null.
Please let me know what’s wrong.
Thanks
Where and how is this filter specified as being required?
Where and how is this filter defined?

Please see below


http://www.w3.org/2001/XMLSchema-instance"; 
xmlns="http://xmlns.jcp.org/xml/ns/javaee"; 
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee 
http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd"; version="4.0">
 Archetype Created Web Application
 
 
 Restricted Area
 /search.jsp
  
 
 
 SessionValidator
 Controller.SessionValidator
 
 
 404
 /error.html
 
 
 403
 /error.html
 
 
 500
 /error.html
 
 
 java.lang.Exception
 /error.html
 



Mark


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

  

Re: Tomcat 9 relaxedQueryChars format

[Robert Hicks]

Yeah, I read that and I will talk to my co-admin about it.

Thanks!

On Fri, Nov 29, 2019 at 10:43 AM M. Manna  wrote:

> To clarify (along with my last reply) - what you are trying to do is not
> correct. The tomcat documentation confirms that only the following are
> allowed
>
> The HTTP/1.1 specification 
> requires
> > that certain characters are %nn encoded when used in URI query strings.
> > Unfortunately, many user agents including all the major browsers are not
> > compliant with this specification and use these characters in unencoded
> > form. To prevent Tomcat rejecting such requests, this attribute may be
> used
> > to specify the additional characters to allow. If not specified, no
> > additional characters will be allowed. The value may be any combination
> of
> > the following characters: " < > [ \ ] ^ ` { | } . Any other characters
> > present in the value will be ignored.
>
>
> On Fri, 29 Nov 2019 at 15:39, M. Manna  wrote:
>
> > Robert,
> >
> > On Fri, 29 Nov 2019 at 15:28, Robert Hicks 
> wrote:
> >
> >> What is the correct format?
> >>
> >> I see the following used when I do a search:
> >>
> >> relaxedQueryChars="[,],{,}.|"
> >>
> >> relaxedQueryChars="[ ] { } |"
> >>
> >> relaxedQueryChars="[]|{}^\`"<>"
> >>
> >> We use that last one. I am running down this error:
> >>
> >> java.lang.IllegalArgumentException: Invalid character found in the
> >> request target. The valid characters are defined in RFC 7230 and RFC
> >> 3986
> >>
> >> Thanks!
> >>
> >> --
> >>
> >>
> > This is a working version in Http11AprProtocol
> >
> > relaxedQueryChars="{[,:]|}"
> >
> >
> >
> >
> >> Bob
> >>
> >
>

Re: Tomcat 9 relaxedQueryChars format

[M. Manna]

To clarify (along with my last reply) - what you are trying to do is not
correct. The tomcat documentation confirms that only the following are
allowed

The HTTP/1.1 specification  requires
> that certain characters are %nn encoded when used in URI query strings.
> Unfortunately, many user agents including all the major browsers are not
> compliant with this specification and use these characters in unencoded
> form. To prevent Tomcat rejecting such requests, this attribute may be used
> to specify the additional characters to allow. If not specified, no
> additional characters will be allowed. The value may be any combination of
> the following characters: " < > [ \ ] ^ ` { | } . Any other characters
> present in the value will be ignored.


On Fri, 29 Nov 2019 at 15:39, M. Manna  wrote:

> Robert,
>
> On Fri, 29 Nov 2019 at 15:28, Robert Hicks  wrote:
>
>> What is the correct format?
>>
>> I see the following used when I do a search:
>>
>> relaxedQueryChars="[,],{,}.|"
>>
>> relaxedQueryChars="[ ] { } |"
>>
>> relaxedQueryChars="[]|{}^\`"<>"
>>
>> We use that last one. I am running down this error:
>>
>> java.lang.IllegalArgumentException: Invalid character found in the
>> request target. The valid characters are defined in RFC 7230 and RFC
>> 3986
>>
>> Thanks!
>>
>> --
>>
>>
> This is a working version in Http11AprProtocol
>
> relaxedQueryChars="{[,:]|}"
>
>
>
>
>> Bob
>>
>

Re: Tomcat 9 relaxedQueryChars format

[M. Manna]

Robert,

On Fri, 29 Nov 2019 at 15:28, Robert Hicks  wrote:

> What is the correct format?
>
> I see the following used when I do a search:
>
> relaxedQueryChars="[,],{,}.|"
>
> relaxedQueryChars="[ ] { } |"
>
> relaxedQueryChars="[]|{}^\`"<>"
>
> We use that last one. I am running down this error:
>
> java.lang.IllegalArgumentException: Invalid character found in the
> request target. The valid characters are defined in RFC 7230 and RFC
> 3986
>
> Thanks!
>
> --
>
>
This is a working version in Http11AprProtocol

relaxedQueryChars="{[,:]|}"




> Bob
>

Tomcat 9 relaxedQueryChars format

[Robert Hicks]

What is the correct format?

I see the following used when I do a search:

relaxedQueryChars="[,],{,}.|"

relaxedQueryChars="[ ] { } |"

relaxedQueryChars="[]|{}^\`"<>"

We use that last one. I am running down this error:

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

Thanks!

-- 

Bob

Re: Double Slash Support in Tomcat 9.0.27

[M. Manna]

Kushagra,

On Fri, 29 Nov 2019 at 12:29, Kushagra Bindal 
wrote:

> Hi Mark,
>
> This astrik is because I highlighted it as BOLD. But I guess at your end it
> is being received as plain text. Resending the content in context.xml
>
> 
>
> 
> 
> WEB-INF/web.xml
> WEB-INF/tomcat-web.xml
> ${catalina.base}/conf/web.xml
>
>  type="javax.sql.DataSource"/>
>
>  className="org.apache.tomcat.util.http.LegacyCookieProcessor" />
>
> 
> 
>
> 
> 
> 
>
>
>
> On Fri, Nov 29, 2019 at 5:52 PM M. Manna  wrote:
>
> > Hi
> >
> > On Fri, 29 Nov 2019 at 11:43, Kushagra Bindal  >
> > wrote:
> >
> > > Hi Mark,
> > >
> > > We tried to put the changes as suggested by you. Below are the changes
> > that
> > > we have made in context.xml file.
> > >
> > > 
> >
> >
> > Why this asterisk? *
> >
> > >
> > >
> > > 
> > > 
> > > WEB-INF/web.xml
> > > WEB-INF/tomcat-web.xml
> > > ${catalina.base}/conf/web.xml
> > >
> > >  > > type="javax.sql.DataSource"/>
> > >
> > >  > > className="org.apache.tomcat.util.http.LegacyCookieProcessor" />
> > >
> > > 
> > > 
> > >
> > > 
> > > 
> > > 
> > >
> > > But after restart still I am getting below errors in tomcat's
> > > *localhost_access_log.2019-11-29.txt* file.
> > >
> > > 172.18.0.3 - - [29/Nov/2019:11:27:45 +] "GET
> > > /sdm/restcall/v1/platform//healthCheck HTTP/1.0" 404 -
> > > 172.18.0.3 - - [29/Nov/2019:11:27:45 +] "GET
> > > /sdm/restcall/v1/platform//healthCheck HTTP/1.0" 404 -
> > > 172.18.0.3 - - [29/Nov/2019:11:27:46 +] "GET
> > > /sdm/restcall/v1/platform//healthCheck HTTP/1.0" 404 -
> > >
> > > Please help me in correcting the syntax.
> > >
> > > Regards
> > > Kushagra
> > >
> > > On Fri, Nov 29, 2019 at 4:02 PM Kushagra Bindal <
> > bindal.kusha...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Hi Mark,
> > > >
> > > > Thanks for providing the response.
> > > >
> > > > Yes, you are right that we should design our application to remove //
> > > from
> > > > being used.
> > > >
> > > > I will plan it accordingly, for the provided solution in below. Let
> me
> > > try
> > > > the same and I will revert back to you in case of any further queries
> > and
> > > > concerns.
> > > >
> > > > On Fri, Nov 29, 2019 at 2:56 PM M. Manna  wrote:
> > > >
> > > >> HI,
> > > >>
> > > >>
> > > >> On Fri, 29 Nov 2019 at 09:00, Kushagra Bindal <
> > > bindal.kusha...@gmail.com>
> > > >> wrote:
> > > >>
> > > >> > Hi,
> > > >> >
> > > >> > We are working on upgrading our enterprise application from 8.5.24
> > to
> > > >> > 9.0.27 version.
> > > >> >
> > > >> > What we have observed that in earlier version i.e. 8.5.24 we were
> > able
> > > >> to
> > > >> > process process a REST URI have  double slash ("//") in it.
> > > >> >
> > > >> > But when we are upgrading it to 9.0.27 we found that now the same
> > url
> > > >> which
> > > >> > was working earlier it is now throwing 404 status code.
> > > >> >
> > > >> > Now, the problem is that we can not remove these double slash (//)
> > > >> manually
> > > >> > as it is used widely.
> > > >> >
> > > >> > So, can someone please provide a possible solution of this issue?
> > > >> >
> > > >>
> > > >>  Tomcat processes HTTP query and URL using RFC 7230 standards. But
> > > >> multiple
> > > >> leading forward slash support was disabled by default for good
> > reasons.
> > > >> This was done in 8.5.31 due to issues with Http Redirects involving
> > > >> Servlets.
> > > >>
> > > >> If you must use this, you have to modify your application context to
> > add
> > > >> the override as true - the attribute is called
> > > >> "allowMultipleLeadingForwardSlashInPath".
> > > >>
> > > >> https://tomcat.apache.org/tomcat-8.5-doc/config/context.html
> > > >>
> > > >> But I would sincerely recommend that you work on such designs and
> > > correct
> > > >> them in your application. There is always a "way". This is one of
> the
> > > >> reasons web applications become obsolete requires huge maintenance.
> > > >>
> > > >> Thanks,
> > > >>
> > > >> >
> > > >> > --
> > > >> > Regards,
> > > >> > Kushagra Bindal
> > > >> > +91-9013792807
> > > >> >
> > > >>
> > > >
> > > >
> > > > --
> > > > Regards,
> > > > Kushagra Bindal
> > > > +91-9013792807
> > > >
> > >
> > >
> > > --
> > > Regards,
> > > Kushagra Bindal
> > > +91-9013792807
> > >
> >
>
>
I have just started a tomcat with


in the context.xml file. works just fine. I am not Mark, but he did suggest
that your issue is probably handled better in filtering at Servlet request
level.

If you also provide the below (as Mark suggested earlier in his reply),
that will be great:


>
>
>
> *Can you provide more details such as:- an example request URI- the
>  for the servlet you expect it to match toThanks,Mark  *


Thanks,



> --
> Regards,
> Kushagra Bindal
> +91-9013792807
>

Re: SEVERE: A child container failed during start

[Karen Goh]

 




On Friday, November 29, 2019, 6:59:38 PM GMT+8, Mark Thomas  
wrote:


On 29/11/2019 10:44, Karen Goh wrote:
> Hi experts,
>
>
> Basically, I have now upgraded my dynamic MVC web app to use openJDK 13 and 
> running it with Tomcat 9.0.27. Windows OS. Eclipse 2019-09.
>
> Have been trying to tackling the problem with no avail.
>
> Would appreciate some tips on how to make these error go away.



> Caused by: java.lang.IllegalArgumentException: Filter mapping specifies an 
> unknown filter name [httpHeaderSecurity]



Where and how is this filter specified as being required?
Where and how is this filter defined?

Please see below


http://www.w3.org/2001/XMLSchema-instance"; 
xmlns="http://xmlns.jcp.org/xml/ns/javaee"; 
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee 
http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd"; version="4.0">
 Archetype Created Web Application
 
 
 Restricted Area
 /search.jsp
  
 
 
 SessionValidator
 Controller.SessionValidator
 
 
 404
 /error.html
 
 
 403
 /error.html
 
 
 500
 /error.html
 
 
 java.lang.Exception
 /error.html
 



Mark


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

  

Re: Double Slash Support in Tomcat 9.0.27

[Kushagra Bindal]

Hi Mark,

This astrik is because I highlighted it as BOLD. But I guess at your end it
is being received as plain text. Resending the content in context.xml





WEB-INF/web.xml
WEB-INF/tomcat-web.xml
${catalina.base}/conf/web.xml














On Fri, Nov 29, 2019 at 5:52 PM M. Manna  wrote:

> Hi
>
> On Fri, 29 Nov 2019 at 11:43, Kushagra Bindal 
> wrote:
>
> > Hi Mark,
> >
> > We tried to put the changes as suggested by you. Below are the changes
> that
> > we have made in context.xml file.
> >
> > 
>
>
> Why this asterisk? *
>
> >
> >
> > 
> > 
> > WEB-INF/web.xml
> > WEB-INF/tomcat-web.xml
> > ${catalina.base}/conf/web.xml
> >
> >  > type="javax.sql.DataSource"/>
> >
> >  > className="org.apache.tomcat.util.http.LegacyCookieProcessor" />
> >
> > 
> > 
> >
> > 
> > 
> > 
> >
> > But after restart still I am getting below errors in tomcat's
> > *localhost_access_log.2019-11-29.txt* file.
> >
> > 172.18.0.3 - - [29/Nov/2019:11:27:45 +] "GET
> > /sdm/restcall/v1/platform//healthCheck HTTP/1.0" 404 -
> > 172.18.0.3 - - [29/Nov/2019:11:27:45 +] "GET
> > /sdm/restcall/v1/platform//healthCheck HTTP/1.0" 404 -
> > 172.18.0.3 - - [29/Nov/2019:11:27:46 +] "GET
> > /sdm/restcall/v1/platform//healthCheck HTTP/1.0" 404 -
> >
> > Please help me in correcting the syntax.
> >
> > Regards
> > Kushagra
> >
> > On Fri, Nov 29, 2019 at 4:02 PM Kushagra Bindal <
> bindal.kusha...@gmail.com
> > >
> > wrote:
> >
> > > Hi Mark,
> > >
> > > Thanks for providing the response.
> > >
> > > Yes, you are right that we should design our application to remove //
> > from
> > > being used.
> > >
> > > I will plan it accordingly, for the provided solution in below. Let me
> > try
> > > the same and I will revert back to you in case of any further queries
> and
> > > concerns.
> > >
> > > On Fri, Nov 29, 2019 at 2:56 PM M. Manna  wrote:
> > >
> > >> HI,
> > >>
> > >>
> > >> On Fri, 29 Nov 2019 at 09:00, Kushagra Bindal <
> > bindal.kusha...@gmail.com>
> > >> wrote:
> > >>
> > >> > Hi,
> > >> >
> > >> > We are working on upgrading our enterprise application from 8.5.24
> to
> > >> > 9.0.27 version.
> > >> >
> > >> > What we have observed that in earlier version i.e. 8.5.24 we were
> able
> > >> to
> > >> > process process a REST URI have  double slash ("//") in it.
> > >> >
> > >> > But when we are upgrading it to 9.0.27 we found that now the same
> url
> > >> which
> > >> > was working earlier it is now throwing 404 status code.
> > >> >
> > >> > Now, the problem is that we can not remove these double slash (//)
> > >> manually
> > >> > as it is used widely.
> > >> >
> > >> > So, can someone please provide a possible solution of this issue?
> > >> >
> > >>
> > >>  Tomcat processes HTTP query and URL using RFC 7230 standards. But
> > >> multiple
> > >> leading forward slash support was disabled by default for good
> reasons.
> > >> This was done in 8.5.31 due to issues with Http Redirects involving
> > >> Servlets.
> > >>
> > >> If you must use this, you have to modify your application context to
> add
> > >> the override as true - the attribute is called
> > >> "allowMultipleLeadingForwardSlashInPath".
> > >>
> > >> https://tomcat.apache.org/tomcat-8.5-doc/config/context.html
> > >>
> > >> But I would sincerely recommend that you work on such designs and
> > correct
> > >> them in your application. There is always a "way". This is one of the
> > >> reasons web applications become obsolete requires huge maintenance.
> > >>
> > >> Thanks,
> > >>
> > >> >
> > >> > --
> > >> > Regards,
> > >> > Kushagra Bindal
> > >> > +91-9013792807
> > >> >
> > >>
> > >
> > >
> > > --
> > > Regards,
> > > Kushagra Bindal
> > > +91-9013792807
> > >
> >
> >
> > --
> > Regards,
> > Kushagra Bindal
> > +91-9013792807
> >
>


-- 
Regards,
Kushagra Bindal
+91-9013792807

Re: Double Slash Support in Tomcat 9.0.27

[M. Manna]

Hi

On Fri, 29 Nov 2019 at 11:43, Kushagra Bindal 
wrote:

> Hi Mark,
>
> We tried to put the changes as suggested by you. Below are the changes that
> we have made in context.xml file.
>
> 


Why this asterisk? *

>
>
> 
> 
> WEB-INF/web.xml
> WEB-INF/tomcat-web.xml
> ${catalina.base}/conf/web.xml
>
>  type="javax.sql.DataSource"/>
>
>  className="org.apache.tomcat.util.http.LegacyCookieProcessor" />
>
> 
> 
>
> 
> 
> 
>
> But after restart still I am getting below errors in tomcat's
> *localhost_access_log.2019-11-29.txt* file.
>
> 172.18.0.3 - - [29/Nov/2019:11:27:45 +] "GET
> /sdm/restcall/v1/platform//healthCheck HTTP/1.0" 404 -
> 172.18.0.3 - - [29/Nov/2019:11:27:45 +] "GET
> /sdm/restcall/v1/platform//healthCheck HTTP/1.0" 404 -
> 172.18.0.3 - - [29/Nov/2019:11:27:46 +] "GET
> /sdm/restcall/v1/platform//healthCheck HTTP/1.0" 404 -
>
> Please help me in correcting the syntax.
>
> Regards
> Kushagra
>
> On Fri, Nov 29, 2019 at 4:02 PM Kushagra Bindal  >
> wrote:
>
> > Hi Mark,
> >
> > Thanks for providing the response.
> >
> > Yes, you are right that we should design our application to remove //
> from
> > being used.
> >
> > I will plan it accordingly, for the provided solution in below. Let me
> try
> > the same and I will revert back to you in case of any further queries and
> > concerns.
> >
> > On Fri, Nov 29, 2019 at 2:56 PM M. Manna  wrote:
> >
> >> HI,
> >>
> >>
> >> On Fri, 29 Nov 2019 at 09:00, Kushagra Bindal <
> bindal.kusha...@gmail.com>
> >> wrote:
> >>
> >> > Hi,
> >> >
> >> > We are working on upgrading our enterprise application from 8.5.24 to
> >> > 9.0.27 version.
> >> >
> >> > What we have observed that in earlier version i.e. 8.5.24 we were able
> >> to
> >> > process process a REST URI have  double slash ("//") in it.
> >> >
> >> > But when we are upgrading it to 9.0.27 we found that now the same url
> >> which
> >> > was working earlier it is now throwing 404 status code.
> >> >
> >> > Now, the problem is that we can not remove these double slash (//)
> >> manually
> >> > as it is used widely.
> >> >
> >> > So, can someone please provide a possible solution of this issue?
> >> >
> >>
> >>  Tomcat processes HTTP query and URL using RFC 7230 standards. But
> >> multiple
> >> leading forward slash support was disabled by default for good reasons.
> >> This was done in 8.5.31 due to issues with Http Redirects involving
> >> Servlets.
> >>
> >> If you must use this, you have to modify your application context to add
> >> the override as true - the attribute is called
> >> "allowMultipleLeadingForwardSlashInPath".
> >>
> >> https://tomcat.apache.org/tomcat-8.5-doc/config/context.html
> >>
> >> But I would sincerely recommend that you work on such designs and
> correct
> >> them in your application. There is always a "way". This is one of the
> >> reasons web applications become obsolete requires huge maintenance.
> >>
> >> Thanks,
> >>
> >> >
> >> > --
> >> > Regards,
> >> > Kushagra Bindal
> >> > +91-9013792807
> >> >
> >>
> >
> >
> > --
> > Regards,
> > Kushagra Bindal
> > +91-9013792807
> >
>
>
> --
> Regards,
> Kushagra Bindal
> +91-9013792807
>

Re: Tomcat 7.x.x, 8.x.x, 8.5.x and 9.x.x: Session serialization w/o authentication related information

[Klein, Carsten]

On 28/11/2019 10:20, Mark Thomas wrote:

On 28/11/2019 08:03, Klein, Carsten wrote:

Hi there,


Thanks for answering my questions. See my remarks inline:

in all recent Tomcat versions the standard session implementation
declares authentication related fields as 'transient', so both the
session's authType as well as it's authenticated Principal is not saved
and restored across restarts.


It isn't just recent versions. It has been that way for 2 decades. All
the way back to Tomcat 4.0.x



I guessed as much.


On those fields there is a comment that clearly describes that:

/**
   * The authenticated Principal associated with this session, if any.
   * IMPLEMENTATION NOTE:  This object is not saved and
   * restored across session serializations!
   */
protected transient Principal principal = null;

However, the comment does not say WHY that information is omitted from
serialization.

It's fine to have session data persisted across restarts, however,
currently, a session is no longer authenticated after a restart (at
least with form login, with which credentials are not sent with every
request).

Actually, at least for my mind, that draws session persistence quite
useless, because, after a restart, the client must re-login prior to use
any resources having a security constraint.


Useless seems a bit strong. The session data is still there. Nothing is
lost. But the user does have to re-enter their credentials to continue
(if the authentication mechanism doesn't do it automatically).

If re-entering the credentials is an issue, have you considered using an
alternative authentication mechanism?



Yes, useless may be too strong. However, we are developing Ajax-driven 
B2B client applications, which terminate / end the session when they 
detect loss of authentication. Technically, these apps periodically send 
keep-alive messages to the server (in order to keep the session alive, 
since with Ajax the server is only queried when data must be loaded or 
updated). When such a keep-alive fails with a 401 code, the session has 
gone and the application terminates (so, the Admin is able to 
'disconnect' clients by invalidating their session). Currently, this 
happens for all active clients after reloading the context or restarting 
Tomcat :-(



That may be a security thing, but if, for example, passwords stored in
the GenericPrincipal instance are not serialized, I don't see a security
problem with persisting the session's principal.


User names and passwords are generally viewed as more sensitive that the
Principal object which is generally viewed as more sensitive than the
session ID.

Where users draw the line between what is acceptable and unacceptable is
going to vary.


I'm with you. And likely our setup is special in a way. However, I've 
rarely seen that you have to re-enter credentials in a professional web 
application like Google or Facebook, for example.


In some of our projects we use self-written replacements for Tomcat's 
GenericPrincipal (ours is serializable, I know yours in version 8 or 8.5 
is too, but on Ubuntu 14.04 we're still on Tomcat 7), StandardSession 
and StandardManager. However, it's some work to keep these classes up to 
date for new versions of Tomcat. So my basic question was, couldn't 
Tomcat do that for us?


I understand that different users have different requirements and for 
some, persisting a Principal (likely including a password) on disk for 
some seconds during a reload is really not acceptable. BTW, why ever do 
you save passwords??


So, the best solution to that would be to make this a configurable 
option of the Manager, named 'persistPrincipal', for example. Maybe I 
could even help developing that (if I had some time).





Do you have any ideas on that or do you know how to work around this?
Tomcat restarts are required from time to time. But it's really a bad
idea to kick out all currently logged-in users just because Tomcat needs
to be reconfigured, for example.


Re-entering credentials seems to be a major issue in this instance. Are
you able to share what is driving that (with more information we might
be able to identify a other solutions).

There are various 3rd-party session managers available for Tomcat. One
of those may well retain the Principal across restarts.


Yes, that may be true. And most if not all those frameworks are rather 
complex, feature-overloaded and can do everything for you (if you know how).


Actually, for our client applications, we use Tomcat only as a simple 
web server as well as for authentication and sessions. (Tomcat is also 
the container for GeoServer, which is part of most of our setups). So, a 
pure Tomcat solution would be my first choice.


Carsten

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

Re: Double Slash Support in Tomcat 9.0.27

[Kushagra Bindal]

Hi Mark,

We tried to put the changes as suggested by you. Below are the changes that
we have made in context.xml file.





WEB-INF/web.xml
WEB-INF/tomcat-web.xml
${catalina.base}/conf/web.xml












But after restart still I am getting below errors in tomcat's
*localhost_access_log.2019-11-29.txt* file.

172.18.0.3 - - [29/Nov/2019:11:27:45 +] "GET
/sdm/restcall/v1/platform//healthCheck HTTP/1.0" 404 -
172.18.0.3 - - [29/Nov/2019:11:27:45 +] "GET
/sdm/restcall/v1/platform//healthCheck HTTP/1.0" 404 -
172.18.0.3 - - [29/Nov/2019:11:27:46 +] "GET
/sdm/restcall/v1/platform//healthCheck HTTP/1.0" 404 -

Please help me in correcting the syntax.

Regards
Kushagra

On Fri, Nov 29, 2019 at 4:02 PM Kushagra Bindal 
wrote:

> Hi Mark,
>
> Thanks for providing the response.
>
> Yes, you are right that we should design our application to remove // from
> being used.
>
> I will plan it accordingly, for the provided solution in below. Let me try
> the same and I will revert back to you in case of any further queries and
> concerns.
>
> On Fri, Nov 29, 2019 at 2:56 PM M. Manna  wrote:
>
>> HI,
>>
>>
>> On Fri, 29 Nov 2019 at 09:00, Kushagra Bindal 
>> wrote:
>>
>> > Hi,
>> >
>> > We are working on upgrading our enterprise application from 8.5.24 to
>> > 9.0.27 version.
>> >
>> > What we have observed that in earlier version i.e. 8.5.24 we were able
>> to
>> > process process a REST URI have  double slash ("//") in it.
>> >
>> > But when we are upgrading it to 9.0.27 we found that now the same url
>> which
>> > was working earlier it is now throwing 404 status code.
>> >
>> > Now, the problem is that we can not remove these double slash (//)
>> manually
>> > as it is used widely.
>> >
>> > So, can someone please provide a possible solution of this issue?
>> >
>>
>>  Tomcat processes HTTP query and URL using RFC 7230 standards. But
>> multiple
>> leading forward slash support was disabled by default for good reasons.
>> This was done in 8.5.31 due to issues with Http Redirects involving
>> Servlets.
>>
>> If you must use this, you have to modify your application context to add
>> the override as true - the attribute is called
>> "allowMultipleLeadingForwardSlashInPath".
>>
>> https://tomcat.apache.org/tomcat-8.5-doc/config/context.html
>>
>> But I would sincerely recommend that you work on such designs and correct
>> them in your application. There is always a "way". This is one of the
>> reasons web applications become obsolete requires huge maintenance.
>>
>> Thanks,
>>
>> >
>> > --
>> > Regards,
>> > Kushagra Bindal
>> > +91-9013792807
>> >
>>
>
>
> --
> Regards,
> Kushagra Bindal
> +91-9013792807
>


-- 
Regards,
Kushagra Bindal
+91-9013792807

Re: SEVERE: A child container failed during start

[M. Manna]

Hi,

On Fri, 29 Nov 2019 at 10:45, Karen Goh 
wrote:

> Hi experts,
>
>
> Basically, I have now upgraded my dynamic MVC web app to use openJDK 13
> and running it with Tomcat 9.0.27.  Windows OS. Eclipse 2019-09.
>
> Have been trying to tackling the problem with no avail.
>
> Would appreciate some tips on how to make these error go away.
>
> Here's the error :
>
> Nov 29, 2019 6:25:18 PM org.apache.catalina.core.ContainerBase
> startInternal
> SEVERE: A child container failed during start
> java.util.concurrent.ExecutionException:
> org.apache.catalina.LifecycleException: Failed to start component
> [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/webApp-hi5]]
> at
> java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at
> java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
> at
> org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:916)
> at
> org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:841)
> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> at
> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1384)
> at
> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1374)
> at
> java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
> at
> java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:140)
> at
> org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:909)
> at
> org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:262)
> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> at
> org.apache.catalina.core.StandardService.startInternal(StandardService.java:421)
> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> at
> org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:930)
> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> at org.apache.catalina.startup.Catalina.start(Catalina.java:633)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:567)
> at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:344)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:475)
> Caused by: org.apache.catalina.LifecycleException: Failed to start
> component
> [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/webApp-hi5]]
> at
> org.apache.catalina.util.LifecycleBase.handleSubClassException(LifecycleBase.java:440)
> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:198)
> at
> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1384)
> at
> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1374)
> at
> java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
> at
> java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:140)
> at
> org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:909)
> ... 21 more
> Caused by: java.lang.IllegalArgumentException: Filter mapping specifies an
> unknown filter name [httpHeaderSecurity]
> at
> org.apache.catalina.core.StandardContext.validateFilterMap(StandardContext.java:3009)
> at
> org.apache.catalina.core.StandardContext.addFilterMap(StandardContext.java:2971)
> at
> org.apache.catalina.startup.ContextConfig.configureContext(ContextConfig.java:1288)
> at
> org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1168)
> at
> org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:774)
> at
> org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:301)
> at
> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123)
> at
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5051)
> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> ... 27 more
>
> Nov 29, 2019 6:25:18 PM org.apache.catalina.core.ContainerBase
> startInternal
> SEVERE: A child container failed during start
> java.util.concurrent.ExecutionException:
> org.

Re: SEVERE: A child container failed during start

[Mark Thomas]

On 29/11/2019 10:44, Karen Goh wrote:
> Hi experts,
> 
> 
> Basically, I have now upgraded my dynamic MVC web app to use openJDK 13 and 
> running it with Tomcat 9.0.27.  Windows OS. Eclipse 2019-09.
> 
> Have been trying to tackling the problem with no avail.
> 
> Would appreciate some tips on how to make these error go away.



> Caused by: java.lang.IllegalArgumentException: Filter mapping specifies an 
> unknown filter name [httpHeaderSecurity]



Where and how is this filter specified as being required?
Where and how is this filter defined?

Mark

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

SEVERE: A child container failed during start

[Karen Goh]

Hi experts,


Basically, I have now upgraded my dynamic MVC web app to use openJDK 13 and 
running it with Tomcat 9.0.27.  Windows OS. Eclipse 2019-09.

Have been trying to tackling the problem with no avail.

Would appreciate some tips on how to make these error go away.

Here's the error :

Nov 29, 2019 6:25:18 PM org.apache.catalina.core.ContainerBase startInternal
SEVERE: A child container failed during start
java.util.concurrent.ExecutionException: 
org.apache.catalina.LifecycleException: Failed to start component 
[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/webApp-hi5]]
at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
at 
org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:916)
at 
org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:841)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at 
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1384)
at 
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1374)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at 
org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
at 
java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:140)
at 
org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:909)
at 
org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:262)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at 
org.apache.catalina.core.StandardService.startInternal(StandardService.java:421)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at 
org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:930)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at org.apache.catalina.startup.Catalina.start(Catalina.java:633)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:344)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:475)
Caused by: org.apache.catalina.LifecycleException: Failed to start component 
[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/webApp-hi5]]
at 
org.apache.catalina.util.LifecycleBase.handleSubClassException(LifecycleBase.java:440)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:198)
at 
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1384)
at 
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1374)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at 
org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
at 
java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:140)
at 
org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:909)
... 21 more
Caused by: java.lang.IllegalArgumentException: Filter mapping specifies an 
unknown filter name [httpHeaderSecurity]
at 
org.apache.catalina.core.StandardContext.validateFilterMap(StandardContext.java:3009)
at 
org.apache.catalina.core.StandardContext.addFilterMap(StandardContext.java:2971)
at 
org.apache.catalina.startup.ContextConfig.configureContext(ContextConfig.java:1288)
at 
org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1168)
at 
org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:774)
at 
org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:301)
at 
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123)
at 
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5051)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
... 27 more

Nov 29, 2019 6:25:18 PM org.apache.catalina.core.ContainerBase startInternal
SEVERE: A child container failed during start
java.util.concurrent.ExecutionException: 
org.apache.catalina.LifecycleException: A child container failed during start
at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
 

Re: Double Slash Support in Tomcat 9.0.27

[Kushagra Bindal]

Hi Mark,

Thanks for providing the response.

Yes, you are right that we should design our application to remove // from
being used.

I will plan it accordingly, for the provided solution in below. Let me try
the same and I will revert back to you in case of any further queries and
concerns.

On Fri, Nov 29, 2019 at 2:56 PM M. Manna  wrote:

> HI,
>
>
> On Fri, 29 Nov 2019 at 09:00, Kushagra Bindal 
> wrote:
>
> > Hi,
> >
> > We are working on upgrading our enterprise application from 8.5.24 to
> > 9.0.27 version.
> >
> > What we have observed that in earlier version i.e. 8.5.24 we were able to
> > process process a REST URI have  double slash ("//") in it.
> >
> > But when we are upgrading it to 9.0.27 we found that now the same url
> which
> > was working earlier it is now throwing 404 status code.
> >
> > Now, the problem is that we can not remove these double slash (//)
> manually
> > as it is used widely.
> >
> > So, can someone please provide a possible solution of this issue?
> >
>
>  Tomcat processes HTTP query and URL using RFC 7230 standards. But multiple
> leading forward slash support was disabled by default for good reasons.
> This was done in 8.5.31 due to issues with Http Redirects involving
> Servlets.
>
> If you must use this, you have to modify your application context to add
> the override as true - the attribute is called
> "allowMultipleLeadingForwardSlashInPath".
>
> https://tomcat.apache.org/tomcat-8.5-doc/config/context.html
>
> But I would sincerely recommend that you work on such designs and correct
> them in your application. There is always a "way". This is one of the
> reasons web applications become obsolete requires huge maintenance.
>
> Thanks,
>
> >
> > --
> > Regards,
> > Kushagra Bindal
> > +91-9013792807
> >
>


-- 
Regards,
Kushagra Bindal
+91-9013792807

Re: Double Slash Support in Tomcat 9.0.27

[Mark Thomas]

On 29/11/2019 09:00, Kushagra Bindal wrote:
> Hi,
> 
> We are working on upgrading our enterprise application from 8.5.24 to
> 9.0.27 version.
> 
> What we have observed that in earlier version i.e. 8.5.24 we were able to
> process process a REST URI have  double slash ("//") in it.
> 
> But when we are upgrading it to 9.0.27 we found that now the same url which
> was working earlier it is now throwing 404 status code.
> 
> Now, the problem is that we can not remove these double slash (//) manually
> as it is used widely.
> 
> So, can someone please provide a possible solution of this issue?

Can you provide more details such as:
- an example request URI
- the  for the servlet you expect it to match to

Thanks,

Mark

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

Re: Double Slash Support in Tomcat 9.0.27

[M. Manna]

HI,


On Fri, 29 Nov 2019 at 09:00, Kushagra Bindal 
wrote:

> Hi,
>
> We are working on upgrading our enterprise application from 8.5.24 to
> 9.0.27 version.
>
> What we have observed that in earlier version i.e. 8.5.24 we were able to
> process process a REST URI have  double slash ("//") in it.
>
> But when we are upgrading it to 9.0.27 we found that now the same url which
> was working earlier it is now throwing 404 status code.
>
> Now, the problem is that we can not remove these double slash (//) manually
> as it is used widely.
>
> So, can someone please provide a possible solution of this issue?
>

 Tomcat processes HTTP query and URL using RFC 7230 standards. But multiple
leading forward slash support was disabled by default for good reasons.
This was done in 8.5.31 due to issues with Http Redirects involving
Servlets.

If you must use this, you have to modify your application context to add
the override as true - the attribute is called
"allowMultipleLeadingForwardSlashInPath".

https://tomcat.apache.org/tomcat-8.5-doc/config/context.html

But I would sincerely recommend that you work on such designs and correct
them in your application. There is always a "way". This is one of the
reasons web applications become obsolete requires huge maintenance.

Thanks,

>
> --
> Regards,
> Kushagra Bindal
> +91-9013792807
>

Double Slash Support in Tomcat 9.0.27

[Kushagra Bindal]

Hi,

We are working on upgrading our enterprise application from 8.5.24 to
9.0.27 version.

What we have observed that in earlier version i.e. 8.5.24 we were able to
process process a REST URI have  double slash ("//") in it.

But when we are upgrading it to 9.0.27 we found that now the same url which
was working earlier it is now throwing 404 status code.

Now, the problem is that we can not remove these double slash (//) manually
as it is used widely.

So, can someone please provide a possible solution of this issue?

-- 
Regards,
Kushagra Bindal
+91-9013792807

RE: FW: tomcat creating new ssl session id for same session

[Rekha.MS]

Hi Chris,

Some more details added below. Please let me know id any more details needed.

Thanks,
Rekha MS

-Original Message-
From: Christopher Schultz 
Sent: Thursday, November 28, 2019 7:19 PM
To: users@tomcat.apache.org
Subject: Re: FW: tomcat creating new ssl session id for same session

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rekha,

On 11/28/19 01:33, rekha...@dell.com wrote:
> Thanks for your prompt reply. Please find my response inline.

It seems you forgot to include any useful responses.

> -Original Message- From: Christopher Schultz 
>  Sent: Wednesday, November 27, 2019
> 11:15 PM To: users@tomcat.apache.org Subject: Re: FW: tomcat creating 
> new ssl session id for same session
> 
> Rekha,
> 
> On 11/27/19 05:15, rekha...@dell.com wrote:
>> I am using javax.servlet.request.ssl_session_id for session 
>> validation. But tomcat creating new ssl session id and user session 
>> validation is failing.
> 
> How are you performing the validation?
> 
> Rekha MS: Ssl_session_id is used for validation.

Yes... HOW, exactly?
Rekha MS: ssl_session_id is validated with the previous ssl_sesion_id stored. 
For the same user session ,assumption is ssl_session_id is same for all 
requests.
But now I am seeing ssl_session_id is changing for the same user session.

> What is the order-of-events that you are observing?
> 
> Rekha MS : Ssl_session_id is same for some requests and then it 
> changes after some time.

That was clear from your original post. I'm asking for SPECIFICS. For example, 
the TLS handshake establishes an ssl_session_id and the the next request seems 
to change the session id. Or maybe the session id changes every 30 minutes? OR 
after you suspend the OS on the client and come out of sleep?
Rekha MS: TLS handshake establishes an ssl_session_id and the next request in 
the same user session seems to change the session id

Please give some details or nobody will be able to help you.

> What version of Tomcat, and what kind of  are you using?
> 
> Rekha MS: Tomcat 8.5.15 , Nio connector(Http11NioProtocol to be
> specific)

That is a quite old version of Tomcat. Is there a reason you are 2.5-year-old 
version of Tomcat with published vulnerabilities and many many bug fixes?
Rekha MS:  I have upgraded to 9.0.21 version.

Have you read the changelog? Perhaps there are interesting things in there 
related to your issue.

Are you using OpenSSL or the pure-Java cryptographic provider?
Rekha MS :Java cryptographic provider.

>> Please let me know when tomcat creates new ssl session id and how by 
>> mandate it to use same ssl session id for same user session
> 
> TLS session ids must change periodically when certain renegotiations 
> occur. This is actually a security feature. I'm not sure it is 
> possible to disable it entirely> Rekha MS: what triggers these 
> renegotiations?

If anything about the connection must change -- such as the server requesting a 
client certificate -- a renegotiation occurs. The session id is not required to 
change, but it may change.

The client or the server may request renegotiation at any time for any reason. 
AFAIK, Tomcat does not request renegotiation unless a client certificate is 
requested/required for authentication and the client didn't volunteer one 
during the handshake.
Rekha MS: We do not have client certificate, does this cause renegotiations to 
happen. This was not happening before. From which release is such request 
renegotiation enforced.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3f0GEACgkQHPApP6U8
pFgz0Q/+Ltbz35ZyHwGU1eupyP7K921l3FNVssH/PAbuX82aZhAZFVM19vaRXTDX
vQJrAV4OBF8CSXZ45McjPVaBjensuK2cGbPc46LCXNtGEkB8hjoMH1EayCDc8K8k
PaXgQKWczsitcd7dchjQOV6inK3CTwjD9yK93eUrAlJDbzjUbTOoMVf4Z1XmrOJw
/k2Y1Om8140br9EkEgIELTQr72OcbGPsQTEl780Gq2kFv1PC8mxgbpNZbqCsvmPa
YDMQLEstlmmaF+yztL46EGRVbVopxcJLT4kpkr4/Qk5Al6weVRlvZInaDyXJn9IJ
t3k5cDHhAUG4Tv477zHche+aexDimmlsMA8FKclp30iV4h8383TCURXEQkGEmnm9
Y+Kx9lneWuwCIuNJvdInl7seao9iCaWuuYbekVhpBkk9sLLO++HzFe0+w4kSqZ8y
qPV+ttmXt7kwkFbzXvlyrbs8GAEIX+H1m/vVa+OQghF27Qg8hnG2NiV6VsfU8/2i
DCfUp9+EjD6w5V+mEuNjZTo9+Miz5Cxl42G2QmbcojE0HiPDZ073gRwT60qJJvxp
APCmjIi5XT/yGjw/RUUR9Lxh4wNzdZF7uEduRyYJtkkc2pvVtiGW8ZWoW0UL3M/T
nznBlddv7I0SqtvHGpnye+lMZXwhNEAm6sat0/UzxVfGeaLjlgY=
=D24+
-END PGP SIGNATURE-

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

RE: FW: tomcat creating new ssl session id for same session

[Rekha.MS]

Thanks for your prompt reply. Please find my response inline.


-Original Message-
From: Christopher Schultz 
Sent: Wednesday, November 27, 2019 11:15 PM
To: users@tomcat.apache.org
Subject: Re: FW: tomcat creating new ssl session id for same session

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rekha,

On 11/27/19 05:15, rekha...@dell.com wrote:
> I am using javax.servlet.request.ssl_session_id for session 
> validation. But tomcat creating new ssl session id and user session 
> validation is failing.

How are you performing the validation?
Rekha MS: Ssl_session_id is used for validation.

What is the order-of-events that you are observing?
Rekha MS : Ssl_session_id is same for some requests and then it changes after 
some time.

What version of Tomcat, and what kind of  are you using?
Rekha MS: Tomcat 8.5.15 , Nio connector(Http11NioProtocol to be specific)

> Please let me know when tomcat creates new ssl session id and how by 
> mandate it to use same ssl session id for same user session

TLS session ids must change periodically when certain renegotiations occur. 
This is actually a security feature. I'm not sure it is possible to disable it 
entirely Rekha MS: what triggers these renegotiations?

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3etiEACgkQHPApP6U8
pFiKsg/+MSt/JOsbkOtL/x9z9RDV85HQtj3oQK6GQY5bp66ZTsZZugkwEbUdg8wb
3IDrw4qYuuyGs+PXqqjKwd76Td9EVWYBUEbtw3HPmOx2g0g3XsfTEgKetMRSyJrh
Xh6vTFb9PPwlR1Lozv+OAkQXIradAZUXxHxWY6lcR1ox1X8A8VlnzTKA1oPBL+qk
1q6coOcNuhSJ2DjFFCmaBBp75qBQMFRvcIQacChQEfT1oFdFWkt22L8tmwLF3bKZ
gb8Tc4ohDkwWZUeSeiq6p6dIN8LhK7q40rJH3akEwQJGrD3dPoSojwGiLKXvOMkj
2czFC4SdJ6MJnjxh57LvKlcxwIP+heEIpF1lscGjfZn+sSzzVDRLZkgkV0hXF4aG
uDIKLvETzW88mE4ddfxHICf6IAsLcz6aSR2TaGlJdNgNnsbOooLJc6+cyoA3M1oc
1FpvyzSZsckKpA6KRKqOtNlvveDSgtrTr7EmgK0a2pjAiaq69zxttGfyyOwcKIQw
aozuJBRH4mtP1HAT+4EKeUAUHtuPUXeGMJwoFa4MDMu2+HT9krIFB9kcixDuPy5k
6CFfPkXcVCN+XcChWYrI9HJ0vKRh0DzVVEB14RG/8V+oSXUM0+imJdC2I4QFBI0r
y1ssOJkam+ZzP+fc5Mz1v/hbbLmX2Y1pe4d/FLNF91l+IXRsKOY=
=J9i5
-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

[OT] Re: FW: tomcat creating new ssl session id for same session

[tomcat/perl]

On 29.11.2019 06:59, rekha...@dell.com wrote:

Highly Restricted - Confidential

...

Then maybe a public list, which is also archived for years in various places, is not the 
best communication channel ?



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