Chris,
On Fri, Apr 19, 2024 at 4:40 AM Christopher Schultz
wrote:
>
> Pawel,
>
> On 4/18/24 20:21, Pawel Veselov 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
> Assuming it's easy for Tomcat to differentiate between errors generated
My PR was based on the assumption that it is easy, since Tomcat always
invokes this method[1] if it's a badRequest.
[1]
Stefan,
On 4/24/24 13:58, Stefan Ansing wrote:
Op do 18 apr 2024 om 17:42 schreef 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
Op do 18 apr 2024 om 17:42 schreef 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
es. 404 means "this
>> resource does not exist" and 204 means "this resource DOES EXIST but it
>> doesn't contain anything". Your application may not differentiate
>> between those two cases, but as a client I would be confused if "Not
>> Found&qu
04 No Content is normally used with PUT and DELETE requests.
>
> Yes, you can use those. 200 would also make sense and, of course 201 for
> new resources.
>
> -chris
>
> > -Original Message-
> > From: Christopher Schultz
> > Sent: perjantai 19. huhtikuuta 202
hultz
Sent: perjantai 19. huhtikuuta 2024 14.27
To: users@tomcat.apache.org
Subject: Re: Tomcat closes connections on unexpected status codes
Mark,
On 4/18/24 11:38, Mark Thomas wrote:
On 18/04/2024 15:16, Adwait Kumar Singh wrote:
I think we should *always* close connections in cases where it can
lead
rri
-Original Message-
From: Christopher Schultz
Sent: perjantai 19. huhtikuuta 2024 14.27
To: users@tomcat.apache.org
Subject: Re: Tomcat closes connections on unexpected status codes
Mark,
On 4/18/24 11:38, Mark Thomas wrote:
> On 18/04/2024 15:16, Adwait Kumar Singh wrote:
>> I thi
Pawel,
On 4/18/24 20:21, Pawel Veselov 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
Pawel,
On 4/18/24 20:32, Pawel Veselov wrote:
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
Mark,
On 4/18/24 11:38, Mark Thomas wrote:
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
All,
On 4/18/24 10: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
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
> 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.
> >
>
> 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,
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
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
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
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
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
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
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
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
23 matches
Mail list logo
