[tomcat] branch 7.0.x updated: Add release date for 7.0.108

[violetagg]

This is an automated email from the ASF dual-hosted git repository.

violetagg pushed a commit to branch 7.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/7.0.x by this push:
 new 46b3699  Add release date for 7.0.108
46b3699 is described below

commit 46b3699cca1250e1d87db7e76c0d73abef0851a1
Author: Violeta Georgieva [VMware] 
AuthorDate: Fri Feb 5 09:04:31 2021 +0200

Add release date for 7.0.108
---
 webapps/docs/changelog.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 6c87635..6b52b35 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -120,7 +120,7 @@
 -->
 
 
-
+
   
 
   


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

svn commit: r45840 - /dev/tomcat/tomcat-7/v7.0.108/ /release/tomcat/tomcat-7/v7.0.108/

[violetagg]

Author: violetagg
Date: Fri Feb  5 06:50:43 2021
New Revision: 45840

Log:
Release Tomcat 7.0.108

Added:
release/tomcat/tomcat-7/v7.0.108/
  - copied from r45839, dev/tomcat/tomcat-7/v7.0.108/
Removed:
dev/tomcat/tomcat-7/v7.0.108/


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

Re: [RESULT][VOTE] Release Apache Tomcat 7.0.108

[Violeta Georgieva]

Hi,

На чт, 28.01.2021 г. в 11:48 ч. Violeta Georgieva 
написа:
>
> The proposed Apache Tomcat 7.0.108 release is now available for voting.
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.108/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1295/
> The git tag is:
> https://github.com/apache/tomcat/tree/7.0.108
> b57a2ea4466a2d4ea03a0f90e3f0d6c485b3cfea
>
> The proposed 7.0.108 release is:
> [ ] Broken - do not release
> [ ] Stable - go ahead and release as 7.0.108 Stable


+1 (binding):   mgrigorov, violetagg, remm, kkolinko, fschumacher

No other voters were cast.

The vote has passed.

I'll do the release shortly and announce it once the mirrors catch up.

Regards,
Violeta

Re: [VOTE] Release Apache Tomcat 7.0.108

[Felix Schumacher]

Am 28.01.21 um 10:48 schrieb Violeta Georgieva:
> The proposed Apache Tomcat 7.0.108 release is now available for voting.
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.108/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1295/
> The git tag is:
> https://github.com/apache/tomcat/tree/7.0.108
> b57a2ea4466a2d4ea03a0f90e3f0d6c485b3cfea
>
> The proposed 7.0.108 release is:
> [ ] Broken - do not release
> [x] Stable - go ahead and release as 7.0.108 Stable

Regards

 Felix

>
> Regards,
> Violeta
>

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

Re: Applications setting connection specific HTTP headers

[Romain Manni-Bucau]

+1, out of curiosity, cant rewrite valve help somehow?

Le jeu. 4 févr. 2021 à 19:11, Mark Thomas  a écrit :

> On 04/02/2021 17:56, Romain Manni-Bucau wrote:
> > I always fixed it by a filter until now.
> > What about adding a filter in tomcat and if users complain move to
> another
> > solution? Can even be marked @Alpha for a few I guess.
>
> We have been talking about a ModHeadersFilter for quite some time.
>
> This might be the time to implement it.
>
> Mark
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: Applications setting connection specific HTTP headers

[Mark Thomas]

On 04/02/2021 17:56, Romain Manni-Bucau wrote:
> I always fixed it by a filter until now.
> What about adding a filter in tomcat and if users complain move to another
> solution? Can even be marked @Alpha for a few I guess.

We have been talking about a ModHeadersFilter for quite some time.

This might be the time to implement it.

Mark


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

Re: Applications setting connection specific HTTP headers

[Romain Manni-Bucau]

I always fixed it by a filter until now.
What about adding a filter in tomcat and if users complain move to another
solution? Can even be marked @Alpha for a few I guess.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le jeu. 4 févr. 2021 à 17:55, Mark Thomas  a écrit :

> On 04/02/2021 16:37, Romain Manni-Bucau wrote:
> > (if it helps) From what I saw which was close to that it was due to the
> > current microservice erea where it is very common to have poor man
> proxies
> > coded in java/tomcat and forwarding all headers of a HTTP request, this
> is
> > not uncommon and will even work on some containers (and always in bad
> tests
> > ;)) but nothing a filter can't fix trivially.
>
> That is the scenario I am looking at. If your experience is that a
> filter is (nearly) always safe in those scenarios then that is the way
> to go.
>
> Thanks,
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: Applications setting connection specific HTTP headers

[Mark Thomas]

On 04/02/2021 16:37, Romain Manni-Bucau wrote:
> (if it helps) From what I saw which was close to that it was due to the
> current microservice erea where it is very common to have poor man proxies
> coded in java/tomcat and forwarding all headers of a HTTP request, this is
> not uncommon and will even work on some containers (and always in bad tests
> ;)) but nothing a filter can't fix trivially.

That is the scenario I am looking at. If your experience is that a
filter is (nearly) always safe in those scenarios then that is the way
to go.

Thanks,

Mark

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

Re: Applications setting connection specific HTTP headers

[Michael Osipov]

Am 2021-02-04 um 17:36 schrieb Rémy Maucherat:

On Thu, Feb 4, 2021 at 5:31 PM Michael Osipov  wrote:


Am 2021-02-03 um 13:03 schrieb Mark Thomas:

Hi all,

We have an open PR related to this for HTTP/2 (#277) and I am seeing
related issues at $work with HTTP.

In short, applications are doing things like:

response.setHeader("Transfer-Encoding", "chunked");

which, as you'd expect is causing problems if:
- Tomcat doesn't chunk the response
- Tomcat does chunk the response, adds its own "chunked" value and the
user agent rightly objects to "chunked" appearing twice

And so on.

I'd like to put something into Tomcat to address this.

I think it should be disabled by default so correctly written
applications pay a very small penalty. Along the lines of

if (someSetting != null) {
  // Do header checks
}

In terms of options I think we need:
- something representing the current, allow anything, behaviour
- an option to log (with a stack trace so the offending code can be
identified) attempts to set such headers
- an option to ignore attempts to set such headers

Do we need an option that throws an exception if there is an attempt to
set such headers?

Do we need an option to control which headers and which values will
trigger this behaviour? This would make the configuration rather more
complex. You'd need to be able to set multiple combinations of header,
value and action.

Is adding debug (no stacktrace) and trace (with stacktrace) logging to
addHeader() sufficient? For identifying faulty code this helps but it
doesn't provide a way to work-around the problem. For that you need
something that blocks the adding of the header.

I'm still considering what might be the best way to fix this. Hence the
brain dump above. Thoughts?


Re-reading the PR and your description, I do not really understand why
the container should handle and automagically fix bad application code?
Doing non-sense in appication code shall lead to undefined behavior.
Autofixing means that devs will never fix the real cause and Tomcat will
handle the symptom.

Can you explain why the problems at work cannot be fixed in the webapp
itself?



Probably it's: Customer X using library Y, says there's no possible way he
could ever update library Y with a fixed version. Thankfully, getting
Tomcat devs to work around the library issue instead is easy to do.
Solution !


This doesn't count because with the same counter-argument we have 
rejected to reintroduce reason phrases in 9/10. Explanation: fix the 
client, not us.



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

Re: Applications setting connection specific HTTP headers

[Romain Manni-Bucau]

(if it helps) From what I saw which was close to that it was due to the
current microservice erea where it is very common to have poor man proxies
coded in java/tomcat and forwarding all headers of a HTTP request, this is
not uncommon and will even work on some containers (and always in bad tests
;)) but nothing a filter can't fix trivially.
So helping is clearly interesting, I'm not 100% sure it belongs to tomcat
but a configurable filter wouldnt hurt or impact other users while not
active by default I think and it will help for these cases.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le jeu. 4 févr. 2021 à 17:31, Michael Osipov  a écrit :

> Am 2021-02-03 um 13:03 schrieb Mark Thomas:
> > Hi all,
> >
> > We have an open PR related to this for HTTP/2 (#277) and I am seeing
> > related issues at $work with HTTP.
> >
> > In short, applications are doing things like:
> >
> > response.setHeader("Transfer-Encoding", "chunked");
> >
> > which, as you'd expect is causing problems if:
> > - Tomcat doesn't chunk the response
> > - Tomcat does chunk the response, adds its own "chunked" value and the
> >user agent rightly objects to "chunked" appearing twice
> >
> > And so on.
> >
> > I'd like to put something into Tomcat to address this.
> >
> > I think it should be disabled by default so correctly written
> > applications pay a very small penalty. Along the lines of
> >
> > if (someSetting != null) {
> >  // Do header checks
> > }
> >
> > In terms of options I think we need:
> > - something representing the current, allow anything, behaviour
> > - an option to log (with a stack trace so the offending code can be
> >identified) attempts to set such headers
> > - an option to ignore attempts to set such headers
> >
> > Do we need an option that throws an exception if there is an attempt to
> > set such headers?
> >
> > Do we need an option to control which headers and which values will
> > trigger this behaviour? This would make the configuration rather more
> > complex. You'd need to be able to set multiple combinations of header,
> > value and action.
> >
> > Is adding debug (no stacktrace) and trace (with stacktrace) logging to
> > addHeader() sufficient? For identifying faulty code this helps but it
> > doesn't provide a way to work-around the problem. For that you need
> > something that blocks the adding of the header.
> >
> > I'm still considering what might be the best way to fix this. Hence the
> > brain dump above. Thoughts?
>
> Re-reading the PR and your description, I do not really understand why
> the container should handle and automagically fix bad application code?
> Doing non-sense in appication code shall lead to undefined behavior.
> Autofixing means that devs will never fix the real cause and Tomcat will
> handle the symptom.
>
> Can you explain why the problems at work cannot be fixed in the webapp
> itself?
>
> M
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: Applications setting connection specific HTTP headers

[Rémy Maucherat]

On Thu, Feb 4, 2021 at 5:31 PM Michael Osipov  wrote:

> Am 2021-02-03 um 13:03 schrieb Mark Thomas:
> > Hi all,
> >
> > We have an open PR related to this for HTTP/2 (#277) and I am seeing
> > related issues at $work with HTTP.
> >
> > In short, applications are doing things like:
> >
> > response.setHeader("Transfer-Encoding", "chunked");
> >
> > which, as you'd expect is causing problems if:
> > - Tomcat doesn't chunk the response
> > - Tomcat does chunk the response, adds its own "chunked" value and the
> >user agent rightly objects to "chunked" appearing twice
> >
> > And so on.
> >
> > I'd like to put something into Tomcat to address this.
> >
> > I think it should be disabled by default so correctly written
> > applications pay a very small penalty. Along the lines of
> >
> > if (someSetting != null) {
> >  // Do header checks
> > }
> >
> > In terms of options I think we need:
> > - something representing the current, allow anything, behaviour
> > - an option to log (with a stack trace so the offending code can be
> >identified) attempts to set such headers
> > - an option to ignore attempts to set such headers
> >
> > Do we need an option that throws an exception if there is an attempt to
> > set such headers?
> >
> > Do we need an option to control which headers and which values will
> > trigger this behaviour? This would make the configuration rather more
> > complex. You'd need to be able to set multiple combinations of header,
> > value and action.
> >
> > Is adding debug (no stacktrace) and trace (with stacktrace) logging to
> > addHeader() sufficient? For identifying faulty code this helps but it
> > doesn't provide a way to work-around the problem. For that you need
> > something that blocks the adding of the header.
> >
> > I'm still considering what might be the best way to fix this. Hence the
> > brain dump above. Thoughts?
>
> Re-reading the PR and your description, I do not really understand why
> the container should handle and automagically fix bad application code?
> Doing non-sense in appication code shall lead to undefined behavior.
> Autofixing means that devs will never fix the real cause and Tomcat will
> handle the symptom.
>
> Can you explain why the problems at work cannot be fixed in the webapp
> itself?
>

Probably it's: Customer X using library Y, says there's no possible way he
could ever update library Y with a fixed version. Thankfully, getting
Tomcat devs to work around the library issue instead is easy to do.
Solution !

Rémy


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

Re: Applications setting connection specific HTTP headers

[Michael Osipov]

Am 2021-02-03 um 13:03 schrieb Mark Thomas:

Hi all,

We have an open PR related to this for HTTP/2 (#277) and I am seeing
related issues at $work with HTTP.

In short, applications are doing things like:

response.setHeader("Transfer-Encoding", "chunked");

which, as you'd expect is causing problems if:
- Tomcat doesn't chunk the response
- Tomcat does chunk the response, adds its own "chunked" value and the
   user agent rightly objects to "chunked" appearing twice

And so on.

I'd like to put something into Tomcat to address this.

I think it should be disabled by default so correctly written
applications pay a very small penalty. Along the lines of

if (someSetting != null) {
 // Do header checks
}

In terms of options I think we need:
- something representing the current, allow anything, behaviour
- an option to log (with a stack trace so the offending code can be
   identified) attempts to set such headers
- an option to ignore attempts to set such headers

Do we need an option that throws an exception if there is an attempt to
set such headers?

Do we need an option to control which headers and which values will
trigger this behaviour? This would make the configuration rather more
complex. You'd need to be able to set multiple combinations of header,
value and action.

Is adding debug (no stacktrace) and trace (with stacktrace) logging to
addHeader() sufficient? For identifying faulty code this helps but it
doesn't provide a way to work-around the problem. For that you need
something that blocks the adding of the header.

I'm still considering what might be the best way to fix this. Hence the
brain dump above. Thoughts?


Re-reading the PR and your description, I do not really understand why 
the container should handle and automagically fix bad application code? 
Doing non-sense in appication code shall lead to undefined behavior. 
Autofixing means that devs will never fix the real cause and Tomcat will 
handle the symptom.


Can you explain why the problems at work cannot be fixed in the webapp 
itself?


M

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

RE: Question

[jonmcalexander]

Thank you so much Mark!!! Yesterday was a PEBKAC day.


Sent with BlackBerry Work (www.blackberry.com)

From: Mark Thomas 
Sent: Feb 4, 2021 1:57 AM
To: dev@tomcat.apache.org
Subject: Re: Question

On 04/02/2021 05:04, jonmcalexan...@wellsfargo.com.INVALID wrote:
> Hi Folks! Another wild and crazy question.
>
> So, Tomcat 10.0.2. I see that it uses Jakarta EE 9, and the README states it 
> requires at least Java 8. So, will it run just fine on Java 1.8x or does the 
> Jakarta EE 1.9 have to be installed?

You only need Java 8.

There is no such thing as Jakarta EE 1.9.

Jakarta EE 9 is a collection of APIs and specifications for how those
APIs are expected to behave. Tomcat implements a subset of those
specifications and APIs (Servlet, WebSocket, EL, Server Pages,
Authentication and Annotations).

Note that you cannot take an application that works on Tomcat 9 and use
it unchanged on Tomcat 10 because in the move from Java EE 8 (Tomcat 9)
to Jakarta EE 9 (Tomcat 10) the java package name used by all the APIs
changed from javax... to jakarta...

The Tomcat community has provided a migration tool that converts
applications from Java EE 8 to Jakarta EE 9:
https://github.com/apache/tomcat-jakartaee-migration

HTH,

Mark


>
> Thanks,
>
> Dream * Excel * Explore * Inspire
> Jon McAlexander
> Infrastructure Engineer
> Asst Vice President
>
> Middleware Product Engineering
> Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions
>
> 8080 Cobblestone Rd | Urbandale, IA 50322
> MAC: F4469-010
> Tel 515-988-2508 | Cell 515-988-2508
>
> jonmcalexan...@wellsfargo.com
>
> Upcoming PTO: 10/30/2020, 11/6/2020, 11/13/2020, 11/20/2020, 11/27/2020, 
> 12/2/2020, 12/4/2020, 12/11/2020, 12/18/2020, 12/28/2020, 12/29/2020, 
> 12/30/2020, 12/31/2020
> This message may contain confidential and/or privileged information. If you 
> are not the addressee or authorized to receive this for the addressee, you 
> must not use, copy, disclose, or take any action based on this message or any 
> information herein. If you have received this message in error, please advise 
> the sender immediately by reply e-mail and delete this message. Thank you for 
> your cooperation.
>
>


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


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

Re: Applications setting connection specific HTTP headers

[Mark Thomas]

On 04/02/2021 15:33, Christopher Schultz wrote:
> Mark,
> 
> On 2/4/21 8:52 AM, Mark Thomas wrote:
>> On 04/02/2021 13:28, Christopher Schultz wrote:
>>> I think this should be done in a Valve that is enabled by default, but
>>> can be disabled, rendering zero penalty for "well-behaved" applications.
>>> The Valve can simply wrap the response with a wrapper that either prints
>>> an error to the log (maybe first migration path, enabled now) or throws
>>> an exception (second migration path, in the future).
>>
>> Valves can't wrap requests or responses. It would require some major
>> refactoring to make that possible.
> 
> Well, you *can* wrap them. Maybe it's not a good idea[1], but its
> certainly possible.

That is a lot simpler than I recall.

> [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=45014
> 
> I still don't understand why wrapping the request is such a risky thing.
> Only in Tomcat code, suddenly OOP decoration pattern doesn't apply?

My concern is if an application is doing things like
addHeader("Transfer-Encoding","chunked") it is messing around at a
fairly low level and I would not be surprised to see the same
application trying to cast HttpServletResponse to ResponseFacade and
assuming it is not wrapped.

For a spec compliant app, I agree a Filter is the obvious choice.

Maybe I am over estimating the risk of apps making inappropriate casts
and/or assumptions of no wrapping. For the specific cases I have in mind
I don't have hard information so I am leaning towards assuming the worst.

Mark

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

Re: Applications setting connection specific HTTP headers

[Christopher Schultz]

Mark,

On 2/4/21 8:52 AM, Mark Thomas wrote:
> On 04/02/2021 13:28, Christopher Schultz wrote:
>> I think this should be done in a Valve that is enabled by default, but
>> can be disabled, rendering zero penalty for "well-behaved" applications.
>> The Valve can simply wrap the response with a wrapper that either prints
>> an error to the log (maybe first migration path, enabled now) or throws
>> an exception (second migration path, in the future).
> 
> Valves can't wrap requests or responses. It would require some major
> refactoring to make that possible.

Well, you *can* wrap them. Maybe it's not a good idea[1], but its
certainly possible.

-chris

[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=45014

I still don't understand why wrapping the request is such a risky thing.
Only in Tomcat code, suddenly OOP decoration pattern doesn't apply?

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

Re: [VOTE] Release Apache Tomcat 7.0.108

[Konstantin Kolinko]

чт, 28 янв. 2021 г. в 12:49, Violeta Georgieva :
>
> The proposed Apache Tomcat 7.0.108 release is now available for voting.
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.108/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1295/
> The git tag is:
> https://github.com/apache/tomcat/tree/7.0.108
> b57a2ea4466a2d4ea03a0f90e3f0d6c485b3cfea
>
> The proposed 7.0.108 release is:
> [ ] Broken - do not release
> [x] Stable - go ahead and release as 7.0.108 Stable

Unit tests are OK with Java 6u45 (with known expected failures), 7u80,
8u282, 11u10 on Windows 10.

Best regards,
Konstantin Kolinko

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

Re: Applications setting connection specific HTTP headers

[Mark Thomas]

On 04/02/2021 13:28, Christopher Schultz wrote:
> I think this should be done in a Valve that is enabled by default, but
> can be disabled, rendering zero penalty for "well-behaved" applications.
> The Valve can simply wrap the response with a wrapper that either prints
> an error to the log (maybe first migration path, enabled now) or throws
> an exception (second migration path, in the future).

Valves can't wrap requests or responses. It would require some major
refactoring to make that possible.

Mark

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

Re: Applications setting connection specific HTTP headers

[Christopher Schultz]

Mark,

On 2/3/21 07:03, Mark Thomas wrote:

Hi all,

We have an open PR related to this for HTTP/2 (#277) and I am seeing
related issues at $work with HTTP.

In short, applications are doing things like:

response.setHeader("Transfer-Encoding", "chunked");

which, as you'd expect is causing problems if:
- Tomcat doesn't chunk the response
- Tomcat does chunk the response, adds its own "chunked" value and the
   user agent rightly objects to "chunked" appearing twice

And so on.

I'd like to put something into Tomcat to address this.

I think it should be disabled by default so correctly written
applications pay a very small penalty. Along the lines of

if (someSetting != null) {
 // Do header checks
}

In terms of options I think we need:
- something representing the current, allow anything, behaviour
- an option to log (with a stack trace so the offending code can be
   identified) attempts to set such headers
- an option to ignore attempts to set such headers

Do we need an option that throws an exception if there is an attempt to
set such headers?

Do we need an option to control which headers and which values will
trigger this behaviour? This would make the configuration rather more
complex. You'd need to be able to set multiple combinations of header,
value and action.

Is adding debug (no stacktrace) and trace (with stacktrace) logging to
addHeader() sufficient? For identifying faulty code this helps but it
doesn't provide a way to work-around the problem. For that you need
something that blocks the adding of the header.

I'm still considering what might be the best way to fix this. Hence the
brain dump above. Thoughts?


Hmm. How hard would it be to allow the application to '/instruct/ Tomcat 
to chunk the response by setting this header?


On second thought, there is a better way to do that: flush the output 
stream explicitly, right?


I think this should be done in a Valve that is enabled by default, but 
can be disabled, rendering zero penalty for "well-behaved" applications. 
The Valve can simply wrap the response with a wrapper that either prints 
an error to the log (maybe first migration path, enabled now) or throws 
an exception (second migration path, in the future).


Making it possible to check for various combinations of header names and 
values doesn't seem worth the effort at the moment, but perhaps naming 
the valve something generic so it could be expanded in the future would 
be a good idea.


-chris

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

Re: Applications setting connection specific HTTP headers

[Romain Manni-Bucau]

Le jeu. 4 févr. 2021 à 11:09, Mark Thomas  a écrit :

> Responses in line:
>
> On 03/02/2021 19:55, Raymond Auge wrote:
> > What about an integration point that acts as a passthrough to such
> changes
> > that let you "monitor" and/or "defend" against these operations (using
> > whatever policy you wish).
> > The default would be no-op.
>
> That certainly provides most flexibility and could easily be implemented
> in a way that avoids the issues with the Filter approach.
>
> I suspect a lot of users that want/need the sort of functionality we are
> discussing here won't want to / be able to deploy custom code and would
> prefer a configuration only solution. We could address that by providing
> some custom implementations.
>
> > On Wed, Feb 3, 2021 at 11:15 AM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
>
> 
>
> >> So you mean the application uses tomcat internals (like casting the
> >> Response/Request) but does not work on Tomcat? :s
>
> Yes, casting is what concerns me. And making assumptions about whether
> the response is wrapped and with what concrete classes in what order.
> Adding another wrapper might break things.
>

Not if we enforce it to be first which is only configuration as of today
and what you are looking for, no?
If not I'm not sure how the hypothesis that the app is broken on tomcat can
be (if the app uses tomcat internals it works on tomcat or needs fixes
tomcat does not need to do for the app IMHO).
Concretely, I only see this feature as a portability helper (from another
container/env), in other cases (ie the app was developped for tomcat but
does not work on tomcat) I'm not sure tomcat should help.
When I do "1+2" and expect 2 the language/compiler/other never help for
good reasons.

What I like with the filter option is that the user will understand what
tomcat does even not aware of tomcat internals.
If we add a HttpOutputBuffer wrapper which handles header keys/values and
an error is logged/thrown from there I think it will be way less clear for
most people even if it is very close.
Overall a new Header dedicate spi seems overkill since we have already
multiple extension point to control headers, no?



>
> 
>
> I spent a little time this morning looking through the Tomcat code base
> for calls that manipulated the response headers to see what might be
> problematic.
>
> If we look at which headers and/or values are known to cause problems or
> might cause problems the list is a lot shorter than I expected.
>
> Tomcat already silently prevents an application from setting multiple
> content-length (and content-type) headers.
>
> As far as I can tell we'd need at least the following additional checks:
>
> - Any app set vary header needs to by syntactically correct (Tomcat
>   depends on this if Tomcat needs to manipulate the header).
>
> - The app must not set "Transfer-Encoding: chunked" as Tomcat always
>   adds this if required and multiple values are known to be rejected by
>   some reverse proxies.
>
> - The app must not set "Connection: keep-alive" if
>   useKeepAliveResponseHeader="true" is set on the Connector.
>
> - It is debatable whether or not we allow users to set
>   "Connection: close". Given there may still be valid use cases for this
>I think we should allow it.
>
> I don't think we need to restrict Connection any further. We need to
> allow "Connection: upgrade" so we can't block it completely.
>
> I am currently wondering whether a simple solution that blocks known bad
> header/value combinations and logs what has been blocked is sufficient
> or whether we need / should go down the integration point approach and
> introduce "HeaderValidator" or similar.
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

[Bug 64938] response.setCharacterEncoding(null) should clear previous charset

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=64938

Mark Thomas  changed:

   What|Removed |Added

 Status|NEEDINFO|NEW

--- Comment #5 from Mark Thomas  ---
The spec project has provided clarification via updated Javadoc. Strictly that
only applies to the next iteration of the Servlet spec but do I intend to look
at applying this to current Tomcat versions.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Applications setting connection specific HTTP headers

[Mark Thomas]

Responses in line:

On 03/02/2021 19:55, Raymond Auge wrote:
> What about an integration point that acts as a passthrough to such changes
> that let you "monitor" and/or "defend" against these operations (using
> whatever policy you wish).
> The default would be no-op.

That certainly provides most flexibility and could easily be implemented
in a way that avoids the issues with the Filter approach.

I suspect a lot of users that want/need the sort of functionality we are
discussing here won't want to / be able to deploy custom code and would
prefer a configuration only solution. We could address that by providing
some custom implementations.

> On Wed, Feb 3, 2021 at 11:15 AM Romain Manni-Bucau 
> wrote:



>> So you mean the application uses tomcat internals (like casting the
>> Response/Request) but does not work on Tomcat? :s

Yes, casting is what concerns me. And making assumptions about whether
the response is wrapped and with what concrete classes in what order.
Adding another wrapper might break things.



I spent a little time this morning looking through the Tomcat code base
for calls that manipulated the response headers to see what might be
problematic.

If we look at which headers and/or values are known to cause problems or
might cause problems the list is a lot shorter than I expected.

Tomcat already silently prevents an application from setting multiple
content-length (and content-type) headers.

As far as I can tell we'd need at least the following additional checks:

- Any app set vary header needs to by syntactically correct (Tomcat
  depends on this if Tomcat needs to manipulate the header).

- The app must not set "Transfer-Encoding: chunked" as Tomcat always
  adds this if required and multiple values are known to be rejected by
  some reverse proxies.

- The app must not set "Connection: keep-alive" if
  useKeepAliveResponseHeader="true" is set on the Connector.

- It is debatable whether or not we allow users to set
  "Connection: close". Given there may still be valid use cases for this
   I think we should allow it.

I don't think we need to restrict Connection any further. We need to
allow "Connection: upgrade" so we can't block it completely.

I am currently wondering whether a simple solution that blocks known bad
header/value combinations and logs what has been blocked is sufficient
or whether we need / should go down the integration point approach and
introduce "HeaderValidator" or similar.

Mark

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

[tomcat] branch 9.0.x updated: Cleanups

[remm]

This is an automated email from the ASF dual-hosted git repository.

remm pushed a commit to branch 9.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/9.0.x by this push:
 new 04f3694  Cleanups
04f3694 is described below

commit 04f3694ef13a36830e160c426f46880663475f46
Author: remm 
AuthorDate: Thu Feb 4 10:49:42 2021 +0100

Cleanups
---
 java/org/apache/tomcat/util/net/NioEndpoint.java | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/java/org/apache/tomcat/util/net/NioEndpoint.java 
b/java/org/apache/tomcat/util/net/NioEndpoint.java
index bc552f4..55d7d9e 100644
--- a/java/org/apache/tomcat/util/net/NioEndpoint.java
+++ b/java/org/apache/tomcat/util/net/NioEndpoint.java
@@ -284,12 +284,12 @@ public class NioEndpoint extends 
AbstractJsseEndpoint
 FileAttribute> attrs = 
PosixFilePermissions.asFileAttribute(permissions);
 Files.setAttribute(path, attrs.name(), attrs.value());
 } else {
-java.io.File file = 
Paths.get(getUnixDomainSocketPath()).toFile();
+java.io.File file = path.toFile();
 if (permissions.contains(PosixFilePermission.OTHERS_READ) 
&& !file.setReadable(true, false)) {
-log.warn(sm.getString("endpoint.nio.perms.readFail", 
path));
+log.warn(sm.getString("endpoint.nio.perms.readFail", 
file.getPath()));
 }
 if (permissions.contains(PosixFilePermission.OTHERS_WRITE) 
&& !file.setWritable(true, false)) {
-log.warn(sm.getString("endpoint.nio.perms.writeFail", 
path));
+log.warn(sm.getString("endpoint.nio.perms.writeFail", 
file.getPath()));
 }
 }
 }


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

[tomcat] branch master updated: Cleanups

[remm]

This is an automated email from the ASF dual-hosted git repository.

remm pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/master by this push:
 new fb63c2c  Cleanups
fb63c2c is described below

commit fb63c2c50e104c6aba3a5481f1fd7fc555df761d
Author: remm 
AuthorDate: Thu Feb 4 10:49:42 2021 +0100

Cleanups
---
 java/org/apache/tomcat/util/net/NioEndpoint.java | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/java/org/apache/tomcat/util/net/NioEndpoint.java 
b/java/org/apache/tomcat/util/net/NioEndpoint.java
index bc3f2ad..9cbf422 100644
--- a/java/org/apache/tomcat/util/net/NioEndpoint.java
+++ b/java/org/apache/tomcat/util/net/NioEndpoint.java
@@ -227,12 +227,12 @@ public class NioEndpoint extends 
AbstractJsseEndpoint
 FileAttribute> attrs = 
PosixFilePermissions.asFileAttribute(permissions);
 Files.setAttribute(path, attrs.name(), attrs.value());
 } else {
-java.io.File file = 
Paths.get(getUnixDomainSocketPath()).toFile();
+java.io.File file = path.toFile();
 if (permissions.contains(PosixFilePermission.OTHERS_READ) 
&& !file.setReadable(true, false)) {
-log.warn(sm.getString("endpoint.nio.perms.readFail", 
path));
+log.warn(sm.getString("endpoint.nio.perms.readFail", 
file.getPath()));
 }
 if (permissions.contains(PosixFilePermission.OTHERS_WRITE) 
&& !file.setWritable(true, false)) {
-log.warn(sm.getString("endpoint.nio.perms.writeFail", 
path));
+log.warn(sm.getString("endpoint.nio.perms.writeFail", 
file.getPath()));
 }
 }
 }


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

Re: [VOTE] Release Apache Tomcat 7.0.108

[Rémy Maucherat]

On Thu, Jan 28, 2021 at 10:49 AM Violeta Georgieva 
wrote:

> The proposed Apache Tomcat 7.0.108 release is now available for voting.
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.108/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1295/
> The git tag is:
> https://github.com/apache/tomcat/tree/7.0.108
> b57a2ea4466a2d4ea03a0f90e3f0d6c485b3cfea
>
> The proposed 7.0.108 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 7.0.108 Stable
>
> Regards,
> Violeta
>

So at most one more release to go and 7 is done.

Rémy

[Bug 62224] SafeForkJoinWorkerThreadFactory breaks class loading on org.apache.naming.java.javaURLContextFactory

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=62224

Mark Thomas  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #7 from Mark Thomas  ---
This issue is fixed.

As per comment #4:

Note that with the memory leak protection in place or when running on Java 9
onwards, the TCCL will have to be set on a ForkJoin thread.

Please follow up on the users mailing list and include the simplest possible
test case that demonstrates the problem you are seeing. If that discussion
determines that you have found a bug then this issue can be re-opened or a new
issue created as appropriate.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org