Re: [PROPOSAL] Deprecate JAAS Realm in 10.0.x and remove in 10.1.x

[Romain Manni-Bucau]

Thinking out loud: can't it become a jaspic jaas impl delivered on central
(this point is crucial), can be tomcat-jaas or so but not bundled by
default in the distribution?
Jaspic enables to do from the app so it becomes an option it seems which
enables the use case so limit a lot the required "glue" to compensate a
drop or is it still "too much" to maintain in your opinion?

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



Le lun. 26 avr. 2021 à 21:46, Jean-Louis MONTEIRO  a
écrit :

> Le lun. 26 avr. 2021 à 20:48, Mark Thomas  a écrit :
>
> > On 26/04/2021 18:49, Jean-Louis MONTEIRO wrote:
> > > JAAS, JASPIC and Jakarta Security are all different.
> >
> > My mistake. I knew JASPIC had a slightly bigger rename than most specs
> > and incorrectly thought it became Jakarta Security. It actually became
> > Jakarta Authentication. All previous references from me in this thread
> > to "Jakarta Security" should be read as "Jakarta Authentication".
> >
>
> No problem.
>
>
> >
> > > Tomcat does not implement Jakarta Security so removing JAAS creates a
> gap
> > > in my opinion.
> > >
> > > I'd second Romain, JASPIC requires a SAM to be implemented by the
> > > application.
> > >
> > > Long story short, I'd probably deprecate for 10.x and target a removal
> > for
> > > 11.x
> >
> > In the normal course of things 10.1 would have been 11.0 but we are
> > taking the opportunity align Jakarta EE major version and Tomcat major
> > version as well as have a (much) shorter support lifespan for 10.0
> > (Jakarta EE 9) as that is seen as a transitional release.
> >
> > Tomcat 10.1 will implement the usual subset of specs from Jakarta EE 10.
> >
>
> Sorry I missed that information.
> So it appeared to be a bit too aggressive to deprecate and remove.
>
>
> >
> > Mark
> >
> >
> > > Le lun. 26 avr. 2021 à 18:17, Mark Thomas  a écrit :
> > >
> > >> In reviewing references to Java EE (and J2EE) remaining in the Tomcat
> 10
> > >> repo I found the following:
> > >>
> > >> 
> > >> JAASRealm is prototype for Tomcat of the JAAS-based J2EE
> authentication
> > >> framework for J2EE v1.4, based on the  > >> href="https://www.jcp.org/en/jsr/detail?id=196";>JCP Specification
> > >> Request 196 to enhance container-managed security and promote
> > >> 'pluggable' authentication mechanisms whose implementations would be
> > >> container-independent.
> > >> 
> > >>
> > >> JSR became JASPIC (now Jakarta Security) and Tomcat has an
> > implementation.
> > >>
> > >> Searching through the mailing lists I found the following references
> to
> > >> usage of the JAASRealm (going back ~5 years).
> > >>
> > >> [1] Tomcat 7 user using JAAS based auth to an LDAP server
> > >> [2] Tomcat 9 user using SPNEGO with the JAAS realm
> > >> [3] Tomcat 8.5 user using SPNEGO with the JAAS realm
> > >> [4] Tomcat 7 users with custom CLIENT-CERT auth based on JAAS realm
> > >> [5] User wanting access to HttpServletRequest during auth
> > >>
> > >> Most, if not all, of those have better solutions available than the
> JAAS
> > >> Realm. And those wanting some form of custom auth do have the "proper"
> > >> Jakarta Security API to work with.
> > >>
> > >> Therefore, I'm not currently seeing a good reason to keep the
> JAASRealm.
> > >> Any objections to immediate deprecation with removal planned for
> 10.1.x?
> > >>
> > >> Mark
> > >>
> > >>
> > >> [1] http://markmail.org/message/ndvr5ilxovoo4ins
> > >> [2] http://markmail.org/message/5ocdnmqvvlvjsxas
> > >> [3] http://markmail.org/message/wki275i5yhlg3yyo
> > >> [4] http://markmail.org/message/av2sv6g4kgm6ouu4
> > >> [5] http://markmail.org/message/fm4ggo3ge4r47gar
> > >>
> > >> -
> > >> 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
> >
> >
>
> --
> Jean-Louis
>

[Bug 58464] servletRequest.getHeaderNames() returns all header names in lower case

[bugzilla]

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

Gonzalo  changed:

   What|Removed |Added

 Resolution|WONTFIX |---
 Status|RESOLVED|REOPENED

--- Comment #5 from Gonzalo  ---
Hello, 

Marks said:
"Unless there is something in one of the specifications that Tomcat implements
that mandates header case is preserved (unlikely given that the HTTP spec
states header names are case insensitive) this is going to get resolved as
WONTFIX."

This issue must be reopened because the HTTP protocol is not be respected by
Tomcat. Duplicated headers are not a problem as well, but that behavior is
breaking the protocol when header Transfer-Encoding is duplicated with the
value "chunked". Topic related at
https://tools.ietf.org/html/rfc7230#section-3.3.1

The important:
   A recipient MUST be able to parse the chunked transfer coding
   (Section 4.1) because it plays a crucial role in framing messages
   when the payload body size is not known in advance.  A sender MUST
   NOT apply chunked more than once to a message body (i.e., chunking an
   already chunked message is not allowed).  If any transfer coding
   other than chunked is applied to a request payload body, the sender
   MUST apply chunked as the final transfer coding to ensure that the
   message is properly framed.  If any transfer coding other than
   chunked is applied to a response payload body, the sender MUST either
   apply chunked as the final transfer coding or terminate the message
   by closing the connection.

That is a big problem when you are at Cloud environments using Envoy proxy with
Istio, more info about it here:
https://discuss.istio.io/t/unsupported-transfer-encoding-error-in-istio-proxy/6021/8
 

I think this must be fixed, at my case my team will change all Tomcat servers
to Undertow just to workaround this issue (more than 1500 Tomcat servers)

-- 
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

[Bug 65267] New: Implement mod_hedaers like filter

[bugzilla]

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

Bug ID: 65267
   Summary: Implement mod_hedaers like filter
   Product: Tomcat 10
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Catalina
  Assignee: dev@tomcat.apache.org
  Reporter: ma...@apache.org
  Target Milestone: --

We are seeing an increasing number of issues caused by poorly written
applications writing invalid and/or inappropriate HTTP headers. A common
example is a simple HTTP proxy that blindly copies all the HTTP response
headers it receives. When this includes per-hop headers such as
Transfer-Encoding breakage often follows.

The most recent discussion on this topic was on the dev list:
http://markmail.org/thread/3ajgz6yjgski5svz

This discussion concluded a mod_headers like filter would address this issue
and be a useful addition to Tomcat. This enhancement request is to implement
such a Filter.

The expectation is that it would be back-ported to 9.0.x and 8.5.x.

-- 
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

[Bug 58464] servletRequest.getHeaderNames() returns all header names in lower case

[bugzilla]

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

Mark Thomas  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|REOPENED|RESOLVED

--- Comment #6 from Mark Thomas  ---
Returning this issue to the original WONTFIX status as the issue described in
comment #5 is unrelated to this issue.

The issue described in comment #5 is an application issue (poorly implemented
proxy). This has been discussed previously at:
https://tomcat.markmail.org/thread/zf3a3t75crxn76nb 

Further comments related to this problem described in comment #5 should be
added to that thread or the associated enhancement request in bug 65267

-- 
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

[Bug 65267] Implement mod_headers like filter

[bugzilla]

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

Mark Thomas  changed:

   What|Removed |Added

Summary|Implement mod_hedaers like  |Implement mod_headers like
   |filter  |filter

-- 
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: [PROPOSAL] Deprecate JAAS Realm in 10.0.x and remove in 10.1.x

[Christopher Schultz]

Mark,

On 4/26/21 12:17, Mark Thomas wrote:
In reviewing references to Java EE (and J2EE) remaining in the Tomcat 10 
repo I found the following:



JAASRealm is prototype for Tomcat of the JAAS-based J2EE authentication
framework for J2EE v1.4, based on the href="https://www.jcp.org/en/jsr/detail?id=196";>JCP Specification 
Request 196 to enhance container-managed security and promote 
'pluggable' authentication mechanisms whose implementations would be

container-independent.


JSR became JASPIC (now Jakarta Security) and Tomcat has an implementation.

Searching through the mailing lists I found the following references to 
usage of the JAASRealm (going back ~5 years).


[1] Tomcat 7 user using JAAS based auth to an LDAP server
[2] Tomcat 9 user using SPNEGO with the JAAS realm
[3] Tomcat 8.5 user using SPNEGO with the JAAS realm
[4] Tomcat 7 users with custom CLIENT-CERT auth based on JAAS realm
[5] User wanting access to HttpServletRequest during auth

Most, if not all, of those have better solutions available than the JAAS 
Realm. And those wanting some form of custom auth do have the "proper" 
Jakarta Security API to work with.


Therefore, I'm not currently seeing a good reason to keep the JAASRealm. 
Any objections to immediate deprecation with removal planned for 10.1.x?


Only if someone gives a presentation at this year's ApacheCon @Home 
about JASPIC and its use by mere mortals. I'd love to see "how to use 
JASPIC to authenticate against my JDBC credential store" (aka 
"re-creating DataSourceRealm using JASPIC").


-chris

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

svn commit: r1889238 - in /tomcat/site/trunk: ./ docs/ xdocs/

[violetagg]

Author: violetagg
Date: Tue Apr 27 16:16:14 2021
New Revision: 1889238

URL: http://svn.apache.org/viewvc?rev=1889238&view=rev
Log:
Updates (excluding docs) for 7.0.109 release

Modified:
tomcat/site/trunk/build.properties.default
tomcat/site/trunk/docs/doap_Tomcat.rdf
tomcat/site/trunk/docs/download-70.html
tomcat/site/trunk/docs/index.html
tomcat/site/trunk/docs/migration-7.html
tomcat/site/trunk/docs/oldnews.html
tomcat/site/trunk/docs/whichversion.html
tomcat/site/trunk/xdocs/doap_Tomcat.rdf
tomcat/site/trunk/xdocs/download-70.xml
tomcat/site/trunk/xdocs/index.xml
tomcat/site/trunk/xdocs/migration-7.xml
tomcat/site/trunk/xdocs/oldnews.xml
tomcat/site/trunk/xdocs/whichversion.xml

Modified: tomcat/site/trunk/build.properties.default
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/build.properties.default?rev=1889238&r1=1889237&r2=1889238&view=diff
==
--- tomcat/site/trunk/build.properties.default (original)
+++ tomcat/site/trunk/build.properties.default Tue Apr 27 16:16:14 2021
@@ -36,7 +36,7 @@ tomcat.loc=https://downloads.apache.org/
 
 
 # - Tomcat versions -
-tomcat70=7.0.108
+tomcat70=7.0.109
 tomcat85=8.5.65
 tomcat90=9.0.45
 tomcat100=10.0.5

Modified: tomcat/site/trunk/docs/doap_Tomcat.rdf
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/docs/doap_Tomcat.rdf?rev=1889238&r1=1889237&r2=1889238&view=diff
==
--- tomcat/site/trunk/docs/doap_Tomcat.rdf (original)
+++ tomcat/site/trunk/docs/doap_Tomcat.rdf Tue Apr 27 16:16:14 2021
@@ -81,8 +81,8 @@
 
   
 Latest Stable 7.0.x Release
-2021-02-05
-7.0.108
+2021-04-26
+7.0.109
   
 
 

Modified: tomcat/site/trunk/docs/download-70.html
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/docs/download-70.html?rev=1889238&r1=1889237&r2=1889238&view=diff
==
--- tomcat/site/trunk/docs/download-70.html (original)
+++ tomcat/site/trunk/docs/download-70.html Tue Apr 27 16:16:14 2021
@@ -12,7 +12,7 @@
 
   Quick Navigation
 
-[define v]7.0.108[end]
+[define v]7.0.109[end]
 https://downloads.apache.org/tomcat/tomcat-7/KEYS";>KEYS |
 [v] |
 Browse |

Modified: tomcat/site/trunk/docs/index.html
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/docs/index.html?rev=1889238&r1=1889237&r2=1889238&view=diff
==
--- tomcat/site/trunk/docs/index.html (original)
+++ tomcat/site/trunk/docs/index.html Tue Apr 27 16:16:14 2021
@@ -36,6 +36,25 @@ wiki page.
 Apache Tomcat, Tomcat, Apache, the Apache feather, and the Apache Tomcat
 project logo are trademarks of the Apache Software Foundation.
 
+2021-04-26 Tomcat 7.0.109 Released
+
+The Apache Tomcat Project is proud to announce the release of version 7.0.109 
of
+Apache Tomcat. This release implements specifications that are part of the Java
+EE 6 platform. This release contains a number of bug fixes and improvements
+compared to version 7.0.108.
+
+
+Full details of these changes, and all the other changes, are available in the
+Tomcat 7 
changelog.
+
+
+Note: Apache Tomcat 7.0.x has reached end of life.
+Read more...
+
+
+
+https://tomcat.apache.org/download-70.cgi";>Download
+
 2021-04-06 Tomcat 10.0.5 Released
 
 The Apache Tomcat Project is proud to announce the release of version 10.0.5
@@ -148,28 +167,6 @@ Full details of these changes, and all t
 
 https://tomcat.apache.org/download-migration.cgi";>Download
 
-2021-02-05 Tomcat 7.0.108 Released
-
-The Apache Tomcat Project is proud to announce the release of version 7.0.108 
of
-Apache Tomcat. This release implements specifications that are part of the Java
-EE 6 platform. This release contains a number of bug fixes and improvements
-compared to version 7.0.107.
-
-Fix a potential file descriptor leak when WebSocket connections are
-attempted and fail. Patch provided by Maurizio Adami.
-
-
-Full details of these changes, and all the other changes, are available in the
-Tomcat 7 
changelog.
-
-
-Note: End of life date for Apache Tomcat 7.0.x is 
announced.
-Read more...
-
-
-
-https://tomcat.apache.org/download-70.cgi";>Download
-
 2020-03-06 Tomcat Connectors 1.2.48 Released
 
 The Apache Tomcat Project is proud to announce the release of version 1.2.48 of

Modified: tomcat/site/trunk/docs/migration-7.html
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/docs/migration-7.html?rev=1889238&r1=1889237&r2=1889238&view=diff
==
--- tomcat/site/trunk/docs/migration-7.html (original)
+++ tomcat/site/trunk/docs/migration-7.html Tue Apr 27 16:16:14 2021
@@ -615,8 +615,9 @@ of Apache Tomcat.
 7.0.104
 7.0.105
 7.0.106
-7.0.107

svn commit: r1889240 - in /tomcat/site/trunk/docs/tomcat-7.0-doc: ./ annotationapi/ annotationapi/javax/annotation/ annotationapi/javax/annotation/security/ annotationapi/javax/annotation/sql/ api/ ap

[violetagg]

Author: violetagg
Date: Tue Apr 27 16:26:31 2021
New Revision: 1889240

URL: http://svn.apache.org/viewvc?rev=1889240&view=rev
Log:
Update docs for Apache Tomcat 7.0.109 release.


[This commit notification would consist of 65 parts, 
which exceeds the limit of 50 ones, so it was shortened to the summary.]

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

svn commit: r47448 - /release/tomcat/tomcat-7/v7.0.108/

[violetagg]

Author: violetagg
Date: Tue Apr 27 16:33:56 2021
New Revision: 47448

Log:
Remove 7.0.108

Removed:
release/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

[ANN] Apache Tomcat 7.0.109 released

[Violeta Georgieva]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 7.0.109.

Apache Tomcat is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Expression Language and Java
WebSocket technologies.

This release contains a number of bug fixes and improvements compared to
version 7.0.108.


*** IMPORTANT ***

Tomcat 7.0.x has reached the end of life. It is extremely unlikely that
there
will be any further releases of the 7.0.x series.

All users of Tomcat 7.0.x should upgrade to a supported version.

 *** IMPORTANT ***


Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-7.0-doc/changelog.html

Apache Tomcat website:
http://tomcat.apache.org

Downloads:
http://tomcat.apache.org/download-70.cgi

Migration guides from Apache Tomcat 5.5.x and 6.0.x:
http://tomcat.apache.org/migration.html

Enjoy

The Apache Tomcat team

mod_headers as a Filter

[Mark Thomas]

Hi all,

I've started to  look at this and I am struggling to see a way to 
implement something that looks like mod_headers as a Filter.


Request headers are fairly simple. The process looks something like:
a) take a copy of all the headers received
b) apply all the rules for request headers
c) wrap the request, overriding the various getHeader... methods and
   return values appropriate for the modified set of headers

Response headers are where I am currently stuck.
A similar model to request headers might look like:
a) wrap the response
b) intercept all the headers set by the application
c) apply all the rules for response headers
d) call the appropriate setHeader... methods on the wrapped response
   for the modified set of headers

The problem is that d) (and hence c) needs to be done immediately before 
the response is committed and - short of buffering the entire response 
body - there is no way to know when that is going to happen.


Is the answer we need to buffer the entire response body?

Any cunning ideas on how to detect (in a Filter or wrapped response) 
that the response is about to be committed?


I guess we could try and track bytes (about to be) written and compare 
that to the known buffer size. That seems a little fragile on first 
impression.


Another option is to abandon the mod_headers clone aim and do something 
simpler along the lines of blocking applications from setting specific 
headers and/or header/value combinations.


Thoughts?

Mark

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

[Bug 65262] Enable websocket endpoints to be IoC friendly (javaee integration at least)

[bugzilla]

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

--- Comment #1 from Mark Thomas  ---
WebSocket endpoints already use the InstanceManager.

https://github.com/apache/tomcat/blob/master/java/org/apache/tomcat/websocket/WsSession.java#L180

https://github.com/apache/tomcat/blob/master/java/org/apache/tomcat/websocket/WsSession.java#L548

Is the request to have the InstanceManager create the endpoint instances from
the class name rather than use InstanceManager.newInstance(Object) ?


Using the InstanceManager for Encoders and Decoders looks to be rather more
complex. I looked at the spec but I didn't see a requirement for this 7.1.1
only discusses WebSocket endpoint classes.

-- 
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: ApacheCon @Home 2021 Call for Presentations is closing soon (2021-05-03)

[Christopher Schultz]

All,

This is a reminder to please submit your presentations for ApacheCon 
@Home for review before the deadline at 08:00 UTC on 2021-05-03.


There have been just 5 presentations submitted to far for the Tomcat 
track, and only 2 that look look like they were "from the community" (as 
opposed to recurring presentations from committers).


We'd love to have more presentations from USERS of Tomcat and not just 
the committers. I would love to see some presentations like "this is how 
we use Apache Tomcat to power our product/service/team/sump pump" 
because those are the most interesting to me, personally.


Thanks,
-chris

On 4/1/21 15:13, Christopher Schultz wrote:

All,

ApacheCon @Home is coming to your city/town/village/hamlet/countryside 
this September 21 - 23.


Like last year's event, this one will be virtual, so there is no need to 
book travel/accommodations or potentially arrange for time-off from 
work. You don't even need to wear pants if you don't want to.


The Call for Presentations is open NOW. Please submit your Tomcat (or 
other!) related presentation on this site:


https://acah2021.jamhosted.net/

Feel free to browse the Presentations Page[1] on the Tomcat web site for 
some idea of what presentations have been given in the past. Anything 
related to Tomcat, servlet (etc.) specs, Java web application 
development, etc. would be considered in-scope for the Tomcat track. 
There are many other tracks planned as well.


Yous presentation does /not need to be completed/ when you submit your 
idea. So if you have an idea, go ahead and submit it. You will have a 
few months to build your idea into a presentation.


If you have any questions, please send a message to the users@ list with 
"ApacheCon" in the subject. Please don't email me individually unless 
you have a question that cannot be answered by anyone but me. My reply 
would go to the users@ list anyway, so you may as well post the question 
to the list in the first place :)


Thanks,
-chris

[1] https://tomcat.apache.org/presentations.html


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

Re: mod_headers as a Filter

[Raymond Augé]

Couldn't you add a callback/hook to commit() impl and trigger the rules
during that callback/hook?

But with that the filter is merely a shell for pushing rules into that
callback/hook registry.

- Ray

On Tue, Apr 27, 2021 at 1:04 PM Mark Thomas  wrote:

> Hi all,
>
> I've started to  look at this and I am struggling to see a way to
> implement something that looks like mod_headers as a Filter.
>
> Request headers are fairly simple. The process looks something like:
> a) take a copy of all the headers received
> b) apply all the rules for request headers
> c) wrap the request, overriding the various getHeader... methods and
> return values appropriate for the modified set of headers
>
> Response headers are where I am currently stuck.
> A similar model to request headers might look like:
> a) wrap the response
> b) intercept all the headers set by the application
> c) apply all the rules for response headers
> d) call the appropriate setHeader... methods on the wrapped response
> for the modified set of headers
>
> The problem is that d) (and hence c) needs to be done immediately before
> the response is committed and - short of buffering the entire response
> body - there is no way to know when that is going to happen.
>
> Is the answer we need to buffer the entire response body?
>
> Any cunning ideas on how to detect (in a Filter or wrapped response)
> that the response is about to be committed?
>
> I guess we could try and track bytes (about to be) written and compare
> that to the known buffer size. That seems a little fragile on first
> impression.
>
> Another option is to abandon the mod_headers clone aim and do something
> simpler along the lines of blocking applications from setting specific
> headers and/or header/value combinations.
>
> Thoughts?
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

-- 
*Raymond Augé* (@rotty3000)
Senior Software Architect *Liferay, Inc.* (@Liferay)
OSGi Fellow

Re: mod_headers as a Filter

[Romain Manni-Bucau]

Isnt the response buffer size giving a sufficient hint or callback like
(dont rewrite before it is reached or body starts to be read)? Guess filter
must force some size if not set but sounds like something to check, no?

Le mar. 27 avr. 2021 à 21:32, Raymond Augé 
a écrit :

> Couldn't you add a callback/hook to commit() impl and trigger the rules
> during that callback/hook?
>
> But with that the filter is merely a shell for pushing rules into that
> callback/hook registry.
>
> - Ray
>
> On Tue, Apr 27, 2021 at 1:04 PM Mark Thomas  wrote:
>
> > Hi all,
> >
> > I've started to  look at this and I am struggling to see a way to
> > implement something that looks like mod_headers as a Filter.
> >
> > Request headers are fairly simple. The process looks something like:
> > a) take a copy of all the headers received
> > b) apply all the rules for request headers
> > c) wrap the request, overriding the various getHeader... methods and
> > return values appropriate for the modified set of headers
> >
> > Response headers are where I am currently stuck.
> > A similar model to request headers might look like:
> > a) wrap the response
> > b) intercept all the headers set by the application
> > c) apply all the rules for response headers
> > d) call the appropriate setHeader... methods on the wrapped response
> > for the modified set of headers
> >
> > The problem is that d) (and hence c) needs to be done immediately before
> > the response is committed and - short of buffering the entire response
> > body - there is no way to know when that is going to happen.
> >
> > Is the answer we need to buffer the entire response body?
> >
> > Any cunning ideas on how to detect (in a Filter or wrapped response)
> > that the response is about to be committed?
> >
> > I guess we could try and track bytes (about to be) written and compare
> > that to the known buffer size. That seems a little fragile on first
> > impression.
> >
> > Another option is to abandon the mod_headers clone aim and do something
> > simpler along the lines of blocking applications from setting specific
> > headers and/or header/value combinations.
> >
> > Thoughts?
> >
> > Mark
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> >
> >
>
> --
> *Raymond Augé* (@rotty3000)
> Senior Software Architect *Liferay, Inc.* (@Liferay)
> OSGi Fellow
>

[Bug 65262] Enable websocket endpoints to be IoC friendly (javaee integration at least)

[bugzilla]

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

--- Comment #2 from romain.manni-bucau  ---
Hmm, endpoint api starts from a class on server side so should use the related
instance manager instantiator and not only the injection "newInstance"
probably. For an annotated endpoint you likely inject PojoEndpoint since the
bean is not an endpoint which is not that useful.

I'd also like encoders/decoders to comply to the IoC/instance manager otherwise
no way to get a bound resource like a mapper.

-- 
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: mod_headers as a Filter

[Rémy Maucherat]

On Tue, Apr 27, 2021 at 7:05 PM Mark Thomas  wrote:

> Hi all,
>
> I've started to  look at this and I am struggling to see a way to
> implement something that looks like mod_headers as a Filter.
>
> Request headers are fairly simple. The process looks something like:
> a) take a copy of all the headers received
> b) apply all the rules for request headers
> c) wrap the request, overriding the various getHeader... methods and
> return values appropriate for the modified set of headers
>
> Response headers are where I am currently stuck.
> A similar model to request headers might look like:
> a) wrap the response
> b) intercept all the headers set by the application
> c) apply all the rules for response headers
> d) call the appropriate setHeader... methods on the wrapped response
> for the modified set of headers
>
> The problem is that d) (and hence c) needs to be done immediately before
> the response is committed and - short of buffering the entire response
> body - there is no way to know when that is going to happen.
>
> Is the answer we need to buffer the entire response body?
>
> Any cunning ideas on how to detect (in a Filter or wrapped response)
> that the response is about to be committed?
>
> I guess we could try and track bytes (about to be) written and compare
> that to the known buffer size. That seems a little fragile on first
> impression.
>
> Another option is to abandon the mod_headers clone aim and do something
> simpler along the lines of blocking applications from setting specific
> headers and/or header/value combinations.
>
> Thoughts?
>

I remember after doing the rewrite valve I got asked a bit about
mod_headers because "why not". However, now I recall I found out it would
be far less practical. So I very quickly moved on since it was also less
useful than rewrite. I would still probably not do it.

Rémy


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