Reminder: Community Over Code Asia 2024 CFP closes on Apr 22nd

2024-04-18 Thread Huxing Zhang 
Hi All,

The CFP for Community Over Code Asia, including the Web server and
Tomcat track, is closing very soon -  at 4:00 PM on 22 Apr 2024
Beijing time.

Details: https://sessionize.com/communityovercode-asia-2024

Please do not wait until the last minute. We hope to see you in Hangzhou!

-- 
Best Regards！
Huxing

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

Re: Tomcat closes connections on unexpected status codes

2024-04-18 Thread Pawel Veselov 
On Thu, Apr 18, 2024 at 9:40 AM Adwait Kumar Singh  wrote:
> >  I'm not (yet) convinced distinguishing between those scenarios is always
> > going to be possible.
> I have a Tomcat patch which we use at work to do this, i.e always close the
> connection if HTTP parsing fails but not if it's a user set status. I can
> create a PR for feedback.

It can't be that straightforward though. The HTTP parsing can very well fail
well past the point the application was invoked, and returned a status, during
chunked request parsing. The server can't respond with another error though,
as the headers are/can be committed, it has no recourse but to try to send them
if possible, and then shutdown the connection.

And handling incomplete body reads from the application is also going
to be a nuisance
that has to be dealt with. Tomcat will have to consume the remainder of the body
without application doing so, which may not be desirable in all cases, and
will require either an API change to be supported as being signalled by the
application (here is my status, but PLEASE don't break the HTTP connection),
or requiring the application to diligently consume the body till the end before
returning service back to Tomcat, or having that as a configuration parameter.

I actually don't know how Tomcat deals with bodies that aren't fully read by
the app right now. I would very much like to know for sure.

>
> On Thu, Apr 18, 2024 at 8:42 AM Mark Thomas  wrote:
>
> > On 18/04/2024 15:18, Stefan Ansing wrote:
> > > Hi Rémy, Mark,
> > >
> > >
> > >
> > > I just want to make sure that we’re understanding each other. I can see
> > > that the connection needs to be closed in certain conditions to prevent
> > > request smuggling attacks. I certainly don’t want to change that
> > behaviour.
> > >
> > > However, I’m facing a scenario where an application is responding to a
> > > valid request (from HTTP perspective), with a valid response using these
> > > status codes (more specifically status codes 400 and 500).
> >
> > If the request is a valid HTTP request then a 400 status doesn't seem
> > appropriate to me.
> >
> > If the server is correctly handling that request to generate the
> > response, a 500 status doesn't seem right either.
> >
> > >
> > > I don’t think that in this scenario a request smuggling attack could be
> > > executed, or am I missing something?
> >
> > The main issue is if the original request is invalid HTTP there is no
> > way to determine where the next HTTP request starts.
> >
> > If there is a proxy in the mix then the risks of something going wrong
> > tend to go up.
> >
> > Mark

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

Re: Tomcat closes connections on unexpected status codes

2024-04-18 Thread Pawel Veselov 
> On 18/04/2024 15:18, Stefan Ansing wrote:
> > Hi Rémy, Mark,
> > I just want to make sure that we’re understanding each other. I can see
> > that the connection needs to be closed in certain conditions to prevent
> > request smuggling attacks. I certainly don’t want to change that behaviour.
> > However, I’m facing a scenario where an application is responding to a
> > valid request (from HTTP perspective), with a valid response using these
> > status codes (more specifically status codes 400 and 500).
> If the request is a valid HTTP request then a 400 status doesn't seem
> appropriate to me.

It's by now, however, a de-facto standard. Every time I try to determine
"which HTTP response should I send back in case of issues with the data",
I find myself scrolling through the list of defined codes and not
finding anything
that would otherwise fit. The HTTP spec states what should the server
do in case of HTTP protocol errors (respond with an appropriate 4xx), but
that's all that the spec covers for the protocol, and it doesn't prohibit use
of 400 for application-level errors. Out of the entire 4xx codes, 400
is (maybe also
414?) the only one that is used for protocol problems, others are for
application
level errors, but they are very specific and limiting (IMHO).

Then, how do I return error paths, when implementing things like a web service?
Either returning it with 200 and custom headers that indicate it's an
error response,
or a 400 with the same. In which case, the difference on the client side is -
does it have to logically differentiate valid response from an error based just
on these custom headers/mime type, or differentiate protocol-related 400 from
application-related 400, and can always treat 200 as proper.

Then I look at "what do others do", and I see AWS that uses 400 for all client
errors, and the way a client knows it's an application error is because there is
content that wouldn't be typically returned if there is a protocol problem.
So I follow suit.

> If the server is correctly handling that request to generate the
> response, a 500 status doesn't seem right either.

Right. 5xx - my fault, 4xx - your fault.

> > I don’t think that in this scenario a request smuggling attack could be
> > executed, or am I missing something?
> The main issue is if the original request is invalid HTTP there is no
> way to determine where the next HTTP request starts.

I'd imagine it reasonable that as long as Tomcat doesn't find any issues
with the HTTP protocol itself - closing connections wouldn't serve any
helpful purpose in that case, except for not having to read the remainder
of the message. I'd like to know how the connection can be mucked up
otherwise, whether a proxy is involved or not.

>
> If there is a proxy in the mix then the risks of something going wrong
> tend to go up.
>
> Mark

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

Re: Tomcat closes connections on unexpected status codes

2024-04-18 Thread Adwait Kumar Singh 
>
>  I'm not (yet) convinced distinguishing between those scenarios is always
> going to be possible.


I have a Tomcat patch which we use at work to do this, i.e always close the
connection if HTTP parsing fails but not if it's a user set status. I can
create a PR for feedback.

On Thu, Apr 18, 2024 at 8:42 AM Mark Thomas  wrote:

> On 18/04/2024 15:18, Stefan Ansing wrote:
> > Hi Rémy, Mark,
> >
> >
> >
> > I just want to make sure that we’re understanding each other. I can see
> > that the connection needs to be closed in certain conditions to prevent
> > request smuggling attacks. I certainly don’t want to change that
> behaviour.
> >
> > However, I’m facing a scenario where an application is responding to a
> > valid request (from HTTP perspective), with a valid response using these
> > status codes (more specifically status codes 400 and 500).
>
> If the request is a valid HTTP request then a 400 status doesn't seem
> appropriate to me.
>
> If the server is correctly handling that request to generate the
> response, a 500 status doesn't seem right either.
>
> >
> > I don’t think that in this scenario a request smuggling attack could be
> > executed, or am I missing something?
>
> The main issue is if the original request is invalid HTTP there is no
> way to determine where the next HTTP request starts.
>
> If there is a proxy in the mix then the risks of something going wrong
> tend to go up.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Tomcat closes connections on unexpected status codes

2024-04-18 Thread Mark Thomas 

On 18/04/2024 15:18, Stefan Ansing wrote:

Hi Rémy, Mark,



I just want to make sure that we’re understanding each other. I can see
that the connection needs to be closed in certain conditions to prevent
request smuggling attacks. I certainly don’t want to change that behaviour.

However, I’m facing a scenario where an application is responding to a
valid request (from HTTP perspective), with a valid response using these
status codes (more specifically status codes 400 and 500).


If the request is a valid HTTP request then a 400 status doesn't seem 
appropriate to me.


If the server is correctly handling that request to generate the 
response, a 500 status doesn't seem right either.




I don’t think that in this scenario a request smuggling attack could be
executed, or am I missing something?


The main issue is if the original request is invalid HTTP there is no 
way to determine where the next HTTP request starts.


If there is a proxy in the mix then the risks of something going wrong 
tend to go up.


Mark

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

Re: Tomcat closes connections on unexpected status codes

2024-04-18 Thread Mark Thomas 

On 18/04/2024 15:16, Adwait Kumar Singh wrote:

I think we should *always* close connections in cases where it can lead to
request smuggling vulnerabilities like when there is an error during header
or request line parsing, but allowing the user to control connection close
when the status is being set by the user, should be safe?


I'm not (yet) convinced distinguishing between those scenarios is always 
going to be possible.



It allows users to send back responses like InvalidInputException with a
400 status without being forced to close the connection.


I appreciate why a 400 is used here but 400 has always struck me as more 
for protocol level issues rather than application level issues.


That is the fundamental problem here. The status codes are being used 
for two completely different purposes.


Mark





On Thu, Apr 18, 2024 at 6:41 AM Rémy Maucherat  wrote:


On Thu, Apr 18, 2024 at 1:17 PM Mark Thomas  wrote:


On 18/04/2024 09:07, Stefan Ansing wrote:

Hi,

We've observed some unexpected behaviour in Apache Tomcat (version

10.1.19)

where we see that HTTP/1.1 connections are closed whenever a servlet
application returns the following status codes: 400, 408, 411, 414,

500,

503, 501. This causes client applications to rapidly reconnect and

induce

high server-side CPU load due to doing TLS handshakes.

The 400 and 500 status codes are commonly used in RESTful

microservices to

communicate errors. Reviewing RFC 9112 I couldn't find any requirement

for

closing connections on these status codes.

After testing with Undertow (version 2.3.12), where we didn't see the

same

behaviour, we believe that these status codes do not necessitate a new
connection.


The Tomcat developers disagree. Connections are closed after these
status codes to avoid various forms of request smuggling attacks.


Checking the Tomcat sources makes me believe that the behaviour is
hard-coded[1]. I'm reaching out here to re-evaluate the list of status
codes and to discuss the possibilities of making the behaviour

configurable.


Making this list of status codes configurable seems reasonable. The
default can stay as current and if users want to change it then they
have to accept the associated security risks.


If it's insecure, then it would still be a valid CVE even if the
configuration is optional. We don't have an "allowSmuggling" attribute
on the connector to relax header or status line parsing, even though
many would have wanted it in the past ...

Rémy


Mark




A colleague of mine reported a bug for this issue:
https://bz.apache.org/bugzilla/show_bug.cgi?id=68901

Kind regards,
Stefan Ansing

[1]:


https://github.com/apache/tomcat/blame/bc900e0100de9879604b93af4722c272ab3d1a24/java/org/apache/coyote/http11/Http11Processor.java#L604-L617




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



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






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

Re: Tomcat closes connections on unexpected status codes

2024-04-18 Thread Mark Thomas 

On 18/04/2024 14:41, Rémy Maucherat wrote:

On Thu, Apr 18, 2024 at 1:17 PM Mark Thomas  wrote:


On 18/04/2024 09:07, Stefan Ansing wrote:

Hi,

We've observed some unexpected behaviour in Apache Tomcat (version 10.1.19)
where we see that HTTP/1.1 connections are closed whenever a servlet
application returns the following status codes: 400, 408, 411, 414, 500,
503, 501. This causes client applications to rapidly reconnect and induce
high server-side CPU load due to doing TLS handshakes.

The 400 and 500 status codes are commonly used in RESTful microservices to
communicate errors. Reviewing RFC 9112 I couldn't find any requirement for
closing connections on these status codes.

After testing with Undertow (version 2.3.12), where we didn't see the same
behaviour, we believe that these status codes do not necessitate a new
connection.


The Tomcat developers disagree. Connections are closed after these
status codes to avoid various forms of request smuggling attacks.


Checking the Tomcat sources makes me believe that the behaviour is
hard-coded[1]. I'm reaching out here to re-evaluate the list of status
codes and to discuss the possibilities of making the behaviour configurable.


Making this list of status codes configurable seems reasonable. The
default can stay as current and if users want to change it then they
have to accept the associated security risks.


If it's insecure, then it would still be a valid CVE even if the
configuration is optional. We don't have an "allowSmuggling" attribute
on the connector to relax header or status line parsing, even though
many would have wanted it in the past ...


I don't think it is quite that black and white.

If the client connects directly to the server (no proxy) then there 
request smuggling is a lot less likely and arguably impossible (assuming 
no Tomcat bugs).


If there is a proxy that is when there is a risk of request smuggling.

Given that there are circumstances where the risk of request smuggling 
is low (possibly none) it seems reasonable to allow users to configure 
the status codes that trigger connection close.


Mark

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

Re: Tomcat closes connections on unexpected status codes

2024-04-18 Thread Stefan Ansing 
Op do 18 apr 2024 om 15:41 schreef Rémy Maucherat :

> On Thu, Apr 18, 2024 at 1:17 PM Mark Thomas  wrote:
> >
> > On 18/04/2024 09:07, Stefan Ansing wrote:
> > > Hi,
> > >
> > > We've observed some unexpected behaviour in Apache Tomcat (version
> 10.1.19)
> > > where we see that HTTP/1.1 connections are closed whenever a servlet
> > > application returns the following status codes: 400, 408, 411, 414,
> 500,
> > > 503, 501. This causes client applications to rapidly reconnect and
> induce
> > > high server-side CPU load due to doing TLS handshakes.
> > >
> > > The 400 and 500 status codes are commonly used in RESTful
> microservices to
> > > communicate errors. Reviewing RFC 9112 I couldn't find any requirement
> for
> > > closing connections on these status codes.
> > >
> > > After testing with Undertow (version 2.3.12), where we didn't see the
> same
> > > behaviour, we believe that these status codes do not necessitate a new
> > > connection.
> >
> > The Tomcat developers disagree. Connections are closed after these
> > status codes to avoid various forms of request smuggling attacks.
> >
> > > Checking the Tomcat sources makes me believe that the behaviour is
> > > hard-coded[1]. I'm reaching out here to re-evaluate the list of status
> > > codes and to discuss the possibilities of making the behaviour
> configurable.
> >
> > Making this list of status codes configurable seems reasonable. The
> > default can stay as current and if users want to change it then they
> > have to accept the associated security risks.
>
> If it's insecure, then it would still be a valid CVE even if the
> configuration is optional. We don't have an "allowSmuggling" attribute
> on the connector to relax header or status line parsing, even though
> many would have wanted it in the past ...
>
> Rémy
>
> > Mark
> >
> >
> > >
> > > A colleague of mine reported a bug for this issue:
> > > https://bz.apache.org/bugzilla/show_bug.cgi?id=68901
> > >
> > > Kind regards,
> > > Stefan Ansing
> > >
> > > [1]:
> > >
> https://github.com/apache/tomcat/blame/bc900e0100de9879604b93af4722c272ab3d1a24/java/org/apache/coyote/http11/Http11Processor.java#L604-L617
> > >
> >
> > -
> > 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
>
>
Hi Rémy, Mark,



I just want to make sure that we’re understanding each other. I can see
that the connection needs to be closed in certain conditions to prevent
request smuggling attacks. I certainly don’t want to change that behaviour.

However, I’m facing a scenario where an application is responding to a
valid request (from HTTP perspective), with a valid response using these
status codes (more specifically status codes 400 and 500).

I don’t think that in this scenario a request smuggling attack could be
executed, or am I missing something?



Stefan

Re: Tomcat closes connections on unexpected status codes

2024-04-18 Thread Adwait Kumar Singh 
I think we should *always* close connections in cases where it can lead to
request smuggling vulnerabilities like when there is an error during header
or request line parsing, but allowing the user to control connection close
when the status is being set by the user, should be safe?

It allows users to send back responses like InvalidInputException with a
400 status without being forced to close the connection.

On Thu, Apr 18, 2024 at 6:41 AM Rémy Maucherat  wrote:

> On Thu, Apr 18, 2024 at 1:17 PM Mark Thomas  wrote:
> >
> > On 18/04/2024 09:07, Stefan Ansing wrote:
> > > Hi,
> > >
> > > We've observed some unexpected behaviour in Apache Tomcat (version
> 10.1.19)
> > > where we see that HTTP/1.1 connections are closed whenever a servlet
> > > application returns the following status codes: 400, 408, 411, 414,
> 500,
> > > 503, 501. This causes client applications to rapidly reconnect and
> induce
> > > high server-side CPU load due to doing TLS handshakes.
> > >
> > > The 400 and 500 status codes are commonly used in RESTful
> microservices to
> > > communicate errors. Reviewing RFC 9112 I couldn't find any requirement
> for
> > > closing connections on these status codes.
> > >
> > > After testing with Undertow (version 2.3.12), where we didn't see the
> same
> > > behaviour, we believe that these status codes do not necessitate a new
> > > connection.
> >
> > The Tomcat developers disagree. Connections are closed after these
> > status codes to avoid various forms of request smuggling attacks.
> >
> > > Checking the Tomcat sources makes me believe that the behaviour is
> > > hard-coded[1]. I'm reaching out here to re-evaluate the list of status
> > > codes and to discuss the possibilities of making the behaviour
> configurable.
> >
> > Making this list of status codes configurable seems reasonable. The
> > default can stay as current and if users want to change it then they
> > have to accept the associated security risks.
>
> If it's insecure, then it would still be a valid CVE even if the
> configuration is optional. We don't have an "allowSmuggling" attribute
> on the connector to relax header or status line parsing, even though
> many would have wanted it in the past ...
>
> Rémy
>
> > Mark
> >
> >
> > >
> > > A colleague of mine reported a bug for this issue:
> > > https://bz.apache.org/bugzilla/show_bug.cgi?id=68901
> > >
> > > Kind regards,
> > > Stefan Ansing
> > >
> > > [1]:
> > >
> https://github.com/apache/tomcat/blame/bc900e0100de9879604b93af4722c272ab3d1a24/java/org/apache/coyote/http11/Http11Processor.java#L604-L617
> > >
> >
> > -
> > 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
>
>

clustering logging erors Tomcat10 with Java 17

2024-04-18 Thread Rick Noel 
Hello,

Can someone try to explain what this Catalina.log snippet is saying in regards 
to clustering status?

It looks like to me, this machine successfully sent a session data state msg to 
the other machine in the cluster, but 60 sec later the other machine did not 
respond with with its session data state

*


INFO: Starting clustering manager at [##0001]
Apr 18, 2024 9:42:21 AM org.apache.catalina.ha.session.DeltaManager 
getAllClusterSessions
INFO: Manager [##0001], requesting session state from 
[org.apache.catalina.tribes.membership.MemberImpl[tcp://{127, 0, 0, 
1}:4001,{127, 0, 0, 1},4001, alive=2087779, securePort=-1, UDP Port=-1, id={-96 
81 2 46 1 32 64 76 -97 -53 -48 3 -22 122 -8 28 }, payload={}, command={}, 
domain={}]]. This operation will timeout if no session state has been received 
within [60] seconds.
18-Apr-2024 09:42:21.062 INFO 
[MessageDispatchInterceptor.MessageDispatchThread[station-Channel]1] 
org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor.report 
ThroughputInterceptor Report[
   Tx Msg:1 messages
   Sent:0.00 MiB (total)
   Sent:0.00 MiB (application)
   Time:0.00 seconds
   Tx Speed:0.15 MiB/s (total)
   Tx Speed:0.15 MiB/s (application)
   Error Msg:0
   Rx Msg:3 messages
   Rx Speed:0.00 MiB/s (since 1st msg)
   Received:0.00 MiB]
Apr 18, 2024 9:43:21 AM org.apache.catalina.ha.session.DeltaManager 
waitForSendAllSessions
SEVERE: Manager [##0001]: No session state sent at [4/18/24, 9:42 AM] received, 
timing out after [60,076] ms.
Apr 18, 2024 9:43:21 AM org.apache.catalina.ha.session.DeltaManager 
getAllClusterSessions
WARNING: Manager [##0001]: Drop message [SESSION-GET-ALL] inside 
GET_ALL_SESSIONS sync phase start date [4/18/24, 9:42 AM] message date 
[4/18/24, 9:42 AM]


*
Any ideas why clustering is not working?

Here is how I have clustering defined in server.xml




 


 

   

   


   

 

   

   

   

   

 


 



 






Rick Noel
Systems Programmer | Westwood One
rn...@westwoodone.com

Re: Tomcat closes connections on unexpected status codes

2024-04-18 Thread Rémy Maucherat 
On Thu, Apr 18, 2024 at 1:17 PM Mark Thomas  wrote:
>
> On 18/04/2024 09:07, Stefan Ansing wrote:
> > Hi,
> >
> > We've observed some unexpected behaviour in Apache Tomcat (version 10.1.19)
> > where we see that HTTP/1.1 connections are closed whenever a servlet
> > application returns the following status codes: 400, 408, 411, 414, 500,
> > 503, 501. This causes client applications to rapidly reconnect and induce
> > high server-side CPU load due to doing TLS handshakes.
> >
> > The 400 and 500 status codes are commonly used in RESTful microservices to
> > communicate errors. Reviewing RFC 9112 I couldn't find any requirement for
> > closing connections on these status codes.
> >
> > After testing with Undertow (version 2.3.12), where we didn't see the same
> > behaviour, we believe that these status codes do not necessitate a new
> > connection.
>
> The Tomcat developers disagree. Connections are closed after these
> status codes to avoid various forms of request smuggling attacks.
>
> > Checking the Tomcat sources makes me believe that the behaviour is
> > hard-coded[1]. I'm reaching out here to re-evaluate the list of status
> > codes and to discuss the possibilities of making the behaviour configurable.
>
> Making this list of status codes configurable seems reasonable. The
> default can stay as current and if users want to change it then they
> have to accept the associated security risks.

If it's insecure, then it would still be a valid CVE even if the
configuration is optional. We don't have an "allowSmuggling" attribute
on the connector to relax header or status line parsing, even though
many would have wanted it in the past ...

Rémy

> Mark
>
>
> >
> > A colleague of mine reported a bug for this issue:
> > https://bz.apache.org/bugzilla/show_bug.cgi?id=68901
> >
> > Kind regards,
> > Stefan Ansing
> >
> > [1]:
> > https://github.com/apache/tomcat/blame/bc900e0100de9879604b93af4722c272ab3d1a24/java/org/apache/coyote/http11/Http11Processor.java#L604-L617
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

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

Re: Regarding Tomcat url redirection

2024-04-18 Thread lavanya tech 
Hi Chris,

Thanks for message,

I am attaching server.xml and context.xml and rewrite.config files.
The paths are

/git/app/apache-tomcat-10.1.11/webapps/towl/context.xml





/git/app/apache-tomcat-10.1.11/webapps/towl/WEB-INF/rewrite.config

https://www.example.com:/example [R=301,L]

server.xml






  
  
  
  
  
  
  
  

  
  


  

  
  



























  
  

  
  


  

  
  
  example.com
  
  







  

  


Thanks
Ammu

On Thu, Apr 18, 2024 at 2:17 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Ammu,
>
> On 4/18/24 07:45, lavanya tech wrote:
> > I added classname rewrite valeus in contex.xml file .
> >
> >  
> >   />
> >  
> >
> > created rewrite.config so both of them is located under  conf under
> > apache-tomcat.
> >
> >
> >   >   > https://www.example.com:/example [R=301,L]
> >
> > So according to the documentaion they say context.xml should be placed
> > under webapps and rewrite.config file should be put in WEB-INF folder of
> > apache-tomcat . I placed and restarted tomcat webserver but still it
> > doesnot redirect.
>
> Can you give full paths to both server.xml and rewrite.config, re-post
> your current server.xml  element, and the complete contents of
> rewrite.config?
>
> Have you looked at the log files after start?
>
> -chris
>
> > On Thu, Apr 18, 2024 at 1:36 PM lavanya tech 
> > wrote:
> >
> >> Hi Thomas,
> >>
> >> Thanks for the fast response.
> >>
> >> I added classname rewrite valeus in contex.xml file .
> >>
> >>  
> >>   />
> >>  
> >>
> >> created rewrite.config so both of them is located under  conf under
> >> apache-tomcat.
> >>
> >> So according to the documentaion they say context.xml should be placed
> >> under webapps and rewrite.config file should be put in WEB-INF folder of
> >> apache-tomcat
> >>
> >> Thnks,
> >> Ammu
> >>
> >>
> >>
> >> On Thu, Apr 18, 2024 at 1:22 PM Mark Thomas  wrote:
> >>
> >>> On 18/04/2024 12:05, lavanya tech wrote:
>  Hi Team,
> 
>  I am using "Tomcat 10.1" in our environment and I wanted to redirect
> url
>  from https://example.com to https://www.servercom: and for this i
>  modified the server.xml as below in tomcat config, and the below
>  configuration doesnot seems to work. Does anyone has ideas. Please
> >>> suggest.
>  The url alone https://www.servercom:/ already works. But just
>  redirection from the old to one doesnot.
> 
>   >>> autoDeploy="true">
>    
>    example.com
>    
> >>> className="org.apache.catalina.valves.rewrite.RewriteValve"/>
>    
>  autoDeploy="true">
>    
>    example.com
> >>> className="org.apache.catalina.valves.rewrite.RewriteValve"/>
>    
>  unpackWARs="true" autoDeploy="true">
>    
>    example.com
>    
>  https://www.servercom:/example/$1 [R=301,L]
> >>>
> >>> 1. That isn't valid XML.
> >>>
> >>> 2. Where in the Tomcat docs does it say you can nest re-write rules in
> a
> >>> Host element (or any other element)?
> >>>
>    
>    
>    
>    
>  
> >>>
> >>> You need to configure the RewriteValve.
> >>> https://tomcat.apache.org/tomcat-10.1-doc/rewrite.html
> >>>
> >>> Mark
> >>>
> >>> -
> >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >>> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>>
> >>>
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Regarding Tomcat url redirection

2024-04-18 Thread Christopher Schultz 

Ammu,

On 4/18/24 07:45, lavanya tech wrote:

I added classname rewrite valeus in contex.xml file .

 
 
 

created rewrite.config so both of them is located under  conf under
apache-tomcat.


 https://www.example.com:/example [R=301,L]

So according to the documentaion they say context.xml should be placed
under webapps and rewrite.config file should be put in WEB-INF folder of
apache-tomcat . I placed and restarted tomcat webserver but still it
doesnot redirect.


Can you give full paths to both server.xml and rewrite.config, re-post 
your current server.xml  element, and the complete contents of 
rewrite.config?


Have you looked at the log files after start?

-chris


On Thu, Apr 18, 2024 at 1:36 PM lavanya tech 
wrote:


Hi Thomas,

Thanks for the fast response.

I added classname rewrite valeus in contex.xml file .

 
 
 

created rewrite.config so both of them is located under  conf under
apache-tomcat.

So according to the documentaion they say context.xml should be placed
under webapps and rewrite.config file should be put in WEB-INF folder of
apache-tomcat

Thnks,
Ammu



On Thu, Apr 18, 2024 at 1:22 PM Mark Thomas  wrote:


On 18/04/2024 12:05, lavanya tech wrote:

Hi Team,

I am using "Tomcat 10.1" in our environment and I wanted to redirect url
from https://example.com to https://www.servercom: and for this i
modified the server.xml as below in tomcat config, and the below
configuration doesnot seems to work. Does anyone has ideas. Please

suggest.

The url alone https://www.servercom:/ already works. But just
redirection from the old to one doesnot.


autoDeploy="true">

  
  example.com
  
  
className="org.apache.catalina.valves.rewrite.RewriteValve"/>

  
  
  
  example.com
  
className="org.apache.catalina.valves.rewrite.RewriteValve"/>

  
  
  
  example.com
  
  https://www.servercom:/example/$1 [R=301,L]


1. That isn't valid XML.

2. Where in the Tomcat docs does it say you can nest re-write rules in a
Host element (or any other element)?


  
  
  
  



You need to configure the RewriteValve.
https://tomcat.apache.org/tomcat-10.1-doc/rewrite.html

Mark

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






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

Re: Question on the ErrorReportValve

2024-04-18 Thread Christopher Schultz 

Jon,

On 4/17/24 13:26, Mcalexander, Jon J. wrote:

Thank you. The documentation makes it somewhat confusing because it
starts out that a Valve can exist in Engine, Host, and Context
Containers, and then in the subsequent valve list is the
ErrorReportValve, but it doesn’t make it clear as to where it can go.
If we put one in the Engine container, does it then also cover the
Host containers since If you are willing to write-up a documentation patch, we can commit it 
for you.


-chris


From: Konstantin Kolinko 
Sent: Wednesday, April 17, 2024 10:44 AM
To: Tomcat Users List 
Subject: Re: Question on the ErrorReportValve

пн, 15 апр. 2024 г. в 19: 37, Mcalexander, Jon J. : > > Hi all! > Quick question on the ErrorReportValve and location within 
the server. xml file. I know that typically this would be inside


пн, 15 апр. 2024 г. в 19:37, Mcalexander, Jon J.

mailto:jonmcalexan...@wellsfargo.com.invalid>>:






Hi all!



Quick question on the ErrorReportValve and location within the server.xml file. I know that 
typically this would be inside the  element, but if you have Multiple 
 elements, do you add the valve to each Host section, or can it be placed at the 
Engine or even Server level?




Unlikely.



A Valve is expected to be in a certain place on the request processing pipeline.



Note that a Host has an attribute named errorReportValveClass. If you

do not specify a Valve explicitly, a default one will be created.



Best regards,

Konstantin Kolinko



-

To unsubscribe, e-mail: 
users-unsubscr...@tomcat.apache.org

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





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

Re: Regarding Tomcat url redirection

2024-04-18 Thread lavanya tech 
Hi Thomas,

Thanks for the fast response.

I added classname rewrite valeus in contex.xml file .





created rewrite.config so both of them is located under  conf under
apache-tomcat.


https://www.example.com:/example [R=301,L]

So according to the documentaion they say context.xml should be placed
under webapps and rewrite.config file should be put in WEB-INF folder of
apache-tomcat . I placed and restarted tomcat webserver but still it
doesnot redirect.


Thnks,
Ammu

On Thu, Apr 18, 2024 at 1:36 PM lavanya tech 
wrote:

> Hi Thomas,
>
> Thanks for the fast response.
>
> I added classname rewrite valeus in contex.xml file .
>
> 
> 
> 
>
> created rewrite.config so both of them is located under  conf under
> apache-tomcat.
>
> So according to the documentaion they say context.xml should be placed
> under webapps and rewrite.config file should be put in WEB-INF folder of
> apache-tomcat
>
> Thnks,
> Ammu
>
>
>
> On Thu, Apr 18, 2024 at 1:22 PM Mark Thomas  wrote:
>
>> On 18/04/2024 12:05, lavanya tech wrote:
>> > Hi Team,
>> >
>> > I am using "Tomcat 10.1" in our environment and I wanted to redirect url
>> > from https://example.com to https://www.servercom: and for this i
>> > modified the server.xml as below in tomcat config, and the below
>> > configuration doesnot seems to work. Does anyone has ideas. Please
>> suggest.
>> > The url alone https://www.servercom:/ already works. But just
>> > redirection from the old to one doesnot.
>> >
>> > > autoDeploy="true">
>> >  
>> >  example.com
>> >  
>> >  > className="org.apache.catalina.valves.rewrite.RewriteValve"/>
>> >  
>> >  > > autoDeploy="true">
>> >  
>> >  example.com
>> >  > className="org.apache.catalina.valves.rewrite.RewriteValve"/>
>> >  
>> >  > > unpackWARs="true" autoDeploy="true">
>> >  
>> >  example.com
>> >  
>> >  > >  > > https://www.servercom:/example/$1 [R=301,L]
>>
>> 1. That isn't valid XML.
>>
>> 2. Where in the Tomcat docs does it say you can nest re-write rules in a
>> Host element (or any other element)?
>>
>> >  
>> >  
>> >  
>> >  
>> > 
>>
>> You need to configure the RewriteValve.
>> https://tomcat.apache.org/tomcat-10.1-doc/rewrite.html
>>
>> Mark
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>

Re: Regarding Tomcat url redirection

2024-04-18 Thread lavanya tech 
Hi Thomas,

Thanks for the fast response.

I added classname rewrite valeus in contex.xml file .





created rewrite.config so both of them is located under  conf under
apache-tomcat.

So according to the documentaion they say context.xml should be placed
under webapps and rewrite.config file should be put in WEB-INF folder of
apache-tomcat

Thnks,
Ammu



On Thu, Apr 18, 2024 at 1:22 PM Mark Thomas  wrote:

> On 18/04/2024 12:05, lavanya tech wrote:
> > Hi Team,
> >
> > I am using "Tomcat 10.1" in our environment and I wanted to redirect url
> > from https://example.com to https://www.servercom: and for this i
> > modified the server.xml as below in tomcat config, and the below
> > configuration doesnot seems to work. Does anyone has ideas. Please
> suggest.
> > The url alone https://www.servercom:/ already works. But just
> > redirection from the old to one doesnot.
> >
> >  autoDeploy="true">
> >  
> >  example.com
> >  
> >  
> >  
> >   > autoDeploy="true">
> >  
> >  example.com
> >   className="org.apache.catalina.valves.rewrite.RewriteValve"/>
> >  
> >   > unpackWARs="true" autoDeploy="true">
> >  
> >  example.com
> >  
> >   >   > https://www.servercom:/example/$1 [R=301,L]
>
> 1. That isn't valid XML.
>
> 2. Where in the Tomcat docs does it say you can nest re-write rules in a
> Host element (or any other element)?
>
> >  
> >  
> >  
> >  
> > 
>
> You need to configure the RewriteValve.
> https://tomcat.apache.org/tomcat-10.1-doc/rewrite.html
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Regarding Tomcat url redirection

2024-04-18 Thread Mark Thomas 

On 18/04/2024 12:05, lavanya tech wrote:

Hi Team,

I am using "Tomcat 10.1" in our environment and I wanted to redirect url
from https://example.com to https://www.servercom: and for this i
modified the server.xml as below in tomcat config, and the below
configuration doesnot seems to work. Does anyone has ideas. Please suggest.
The url alone https://www.servercom:/ already works. But just
redirection from the old to one doesnot.


 
 example.com
 
 
 
 
 
 example.com
 
 
 
 
 example.com
 
 https://www.servercom:/example/$1 [R=301,L]


1. That isn't valid XML.

2. Where in the Tomcat docs does it say you can nest re-write rules in a 
Host element (or any other element)?



 
 
 
 



You need to configure the RewriteValve.
https://tomcat.apache.org/tomcat-10.1-doc/rewrite.html

Mark

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

Re: Tomcat closes connections on unexpected status codes

2024-04-18 Thread Mark Thomas 

On 18/04/2024 09:07, Stefan Ansing wrote:

Hi,

We've observed some unexpected behaviour in Apache Tomcat (version 10.1.19)
where we see that HTTP/1.1 connections are closed whenever a servlet
application returns the following status codes: 400, 408, 411, 414, 500,
503, 501. This causes client applications to rapidly reconnect and induce
high server-side CPU load due to doing TLS handshakes.

The 400 and 500 status codes are commonly used in RESTful microservices to
communicate errors. Reviewing RFC 9112 I couldn't find any requirement for
closing connections on these status codes.

After testing with Undertow (version 2.3.12), where we didn't see the same
behaviour, we believe that these status codes do not necessitate a new
connection.


The Tomcat developers disagree. Connections are closed after these 
status codes to avoid various forms of request smuggling attacks.



Checking the Tomcat sources makes me believe that the behaviour is
hard-coded[1]. I'm reaching out here to re-evaluate the list of status
codes and to discuss the possibilities of making the behaviour configurable.


Making this list of status codes configurable seems reasonable. The 
default can stay as current and if users want to change it then they 
have to accept the associated security risks.


Mark




A colleague of mine reported a bug for this issue:
https://bz.apache.org/bugzilla/show_bug.cgi?id=68901

Kind regards,
Stefan Ansing

[1]:
https://github.com/apache/tomcat/blame/bc900e0100de9879604b93af4722c272ab3d1a24/java/org/apache/coyote/http11/Http11Processor.java#L604-L617



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

Re: Regarding Tomcat url redirection

2024-04-18 Thread lavanya tech 
Hi Team,

I am using "Tomcat 10.1" in our environment and I wanted to redirect url
from https://example.com to https://www.servercom: and for this i
modified the server.xml as below in tomcat config, and the below
configuration doesnot seems to work. Does anyone has ideas. Please suggest.
The url alone https://www.servercom:/ already works. But just
redirection from the old to one doesnot.



example.com





example.com




example.com

https://www.servercom:/example/$1 [R=301,L]








Thanks,
Ammu

Tomcat closes connections on unexpected status codes

2024-04-18 Thread Stefan Ansing 
Hi,

We've observed some unexpected behaviour in Apache Tomcat (version 10.1.19)
where we see that HTTP/1.1 connections are closed whenever a servlet
application returns the following status codes: 400, 408, 411, 414, 500,
503, 501. This causes client applications to rapidly reconnect and induce
high server-side CPU load due to doing TLS handshakes.

The 400 and 500 status codes are commonly used in RESTful microservices to
communicate errors. Reviewing RFC 9112 I couldn't find any requirement for
closing connections on these status codes.

After testing with Undertow (version 2.3.12), where we didn't see the same
behaviour, we believe that these status codes do not necessitate a new
connection.

Checking the Tomcat sources makes me believe that the behaviour is
hard-coded[1]. I'm reaching out here to re-evaluate the list of status
codes and to discuss the possibilities of making the behaviour configurable.

A colleague of mine reported a bug for this issue:
https://bz.apache.org/bugzilla/show_bug.cgi?id=68901

Kind regards,
Stefan Ansing

[1]:
https://github.com/apache/tomcat/blame/bc900e0100de9879604b93af4722c272ab3d1a24/java/org/apache/coyote/http11/Http11Processor.java#L604-L617