[PR] removed null eval statement code if os400 [tomcat]
CloudWise-Lukemiao opened a new pull request, #701: URL: https://github.com/apache/tomcat/pull/701 Code optimization removed the null eval statement code if os400 is true in the script -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PR] Avoid performance issues that may arise when the array is large. [tomcat]
rmaucher commented on PR #702: URL: https://github.com/apache/tomcat/pull/702#issuecomment-1968755182 I think FilterDef getAsyncSupported can be optimized. But I'm not super convinced by the rest. Where is the inflection point ? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PR] Attempt to protect against asynchronous thread safety violations [tomcat]
markt-asf closed pull request #700: Attempt to protect against asynchronous thread safety violations URL: https://github.com/apache/tomcat/pull/700 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PR] Attempt to protect against asynchronous thread safety violations [tomcat]
markt-asf commented on PR #700: URL: https://github.com/apache/tomcat/pull/700#issuecomment-1969192558 I'm closing this as I have come up with a better plan that makes slightly better uses of the existing facades to trigger some NPEs when this happens. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
(tomcat) branch main updated: Performance tweaks for filter chain
This is an automated email from the ASF dual-hosted git repository.
remm pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/main by this push:
new 835e1be32a Performance tweaks for filter chain
835e1be32a is described below
commit 835e1be32a936fe5b40b340e9b83a3036cd28bbf
Author: remm
AuthorDate: Wed Feb 28 16:11:17 2024 +0100
Performance tweaks for filter chain
Actually, the check to see if the filter is present was quite
inefficient due to the increment size and the lack of loop exit.
Investigating using a LinkedHashMap is a possibility.
---
java/org/apache/catalina/core/ApplicationFilterChain.java | 13 ++---
java/org/apache/tomcat/util/descriptor/web/FilterDef.java | 6 ++
webapps/docs/changelog.xml| 8
3 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/java/org/apache/catalina/core/ApplicationFilterChain.java
b/java/org/apache/catalina/core/ApplicationFilterChain.java
index de4144ad68..fd7a892d1a 100644
--- a/java/org/apache/catalina/core/ApplicationFilterChain.java
+++ b/java/org/apache/catalina/core/ApplicationFilterChain.java
@@ -17,6 +17,7 @@
package org.apache.catalina.core;
import java.io.IOException;
+import java.util.Arrays;
import java.util.Set;
import jakarta.servlet.Filter;
@@ -113,7 +114,7 @@ public final class ApplicationFilterChain implements
FilterChain {
Filter filter = filterConfig.getFilter();
if (request.isAsyncSupported() &&
-
"false".equalsIgnoreCase(filterConfig.getFilterDef().getAsyncSupported())) {
+
!(filterConfig.getFilterDef().getAsyncSupportedBoolean())) {
request.setAttribute(Globals.ASYNC_SUPPORTED_ATTR,
Boolean.FALSE);
}
filter.doFilter(request, response, this);
@@ -182,16 +183,14 @@ public final class ApplicationFilterChain implements
FilterChain {
void addFilter(ApplicationFilterConfig filterConfig) {
// Prevent the same filter being added multiple times
-for (ApplicationFilterConfig filter : filters) {
-if (filter == filterConfig) {
+for (int i = 0; i < n; i++) {
+if (filters[i] == filterConfig) {
return;
}
}
if (n == filters.length) {
-ApplicationFilterConfig[] newFilters = new
ApplicationFilterConfig[n + INCREMENT];
-System.arraycopy(filters, 0, newFilters, 0, n);
-filters = newFilters;
+filters = Arrays.copyOf(filters, n + INCREMENT);
}
filters[n++] = filterConfig;
@@ -250,7 +249,7 @@ public final class ApplicationFilterChain implements
FilterChain {
public void findNonAsyncFilters(Set result) {
for (int i = 0; i < n; i++) {
ApplicationFilterConfig filter = filters[i];
-if
("false".equalsIgnoreCase(filter.getFilterDef().getAsyncSupported())) {
+if (!(filter.getFilterDef().getAsyncSupportedBoolean())) {
result.add(filter.getFilterClass());
}
}
diff --git a/java/org/apache/tomcat/util/descriptor/web/FilterDef.java
b/java/org/apache/tomcat/util/descriptor/web/FilterDef.java
index 3a208964e0..b742d5c19c 100644
--- a/java/org/apache/tomcat/util/descriptor/web/FilterDef.java
+++ b/java/org/apache/tomcat/util/descriptor/web/FilterDef.java
@@ -162,8 +162,14 @@ public class FilterDef implements Serializable {
public void setAsyncSupported(String asyncSupported) {
this.asyncSupported = asyncSupported;
+asyncSupportedBoolean = !("false".equalsIgnoreCase(asyncSupported));
}
+private boolean asyncSupportedBoolean = true;
+
+public boolean getAsyncSupportedBoolean() {
+return asyncSupportedBoolean;
+}
// - Public Methods
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 89e5be6a97..c7fcb3e46d 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -112,6 +112,14 @@
+
+
+
+Minor performance improvement for building filter chains. Based on
+ideas from 702 by Luke Miao. (remm)
+
+
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
(tomcat) branch 10.1.x updated: Performance tweaks for filter chain
This is an automated email from the ASF dual-hosted git repository.
remm pushed a commit to branch 10.1.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/10.1.x by this push:
new 55ff302cfb Performance tweaks for filter chain
55ff302cfb is described below
commit 55ff302cfb6e9b2694ebcdbd554fdf60d180dc51
Author: remm
AuthorDate: Wed Feb 28 16:11:17 2024 +0100
Performance tweaks for filter chain
Actually, the check to see if the filter is present was quite
inefficient due to the increment size and the lack of loop exit.
Investigating using a LinkedHashMap is a possibility.
---
java/org/apache/catalina/core/ApplicationFilterChain.java | 13 ++---
java/org/apache/tomcat/util/descriptor/web/FilterDef.java | 6 ++
webapps/docs/changelog.xml| 8
3 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/java/org/apache/catalina/core/ApplicationFilterChain.java
b/java/org/apache/catalina/core/ApplicationFilterChain.java
index 998799f4ab..321be19258 100644
--- a/java/org/apache/catalina/core/ApplicationFilterChain.java
+++ b/java/org/apache/catalina/core/ApplicationFilterChain.java
@@ -19,6 +19,7 @@ package org.apache.catalina.core;
import java.io.IOException;
import java.security.Principal;
import java.security.PrivilegedActionException;
+import java.util.Arrays;
import java.util.Set;
import jakarta.servlet.Filter;
@@ -160,7 +161,7 @@ public final class ApplicationFilterChain implements
FilterChain {
Filter filter = filterConfig.getFilter();
if (request.isAsyncSupported() &&
-
"false".equalsIgnoreCase(filterConfig.getFilterDef().getAsyncSupported())) {
+
!(filterConfig.getFilterDef().getAsyncSupportedBoolean())) {
request.setAttribute(Globals.ASYNC_SUPPORTED_ATTR,
Boolean.FALSE);
}
if (Globals.IS_SECURITY_ENABLED) {
@@ -249,16 +250,14 @@ public final class ApplicationFilterChain implements
FilterChain {
void addFilter(ApplicationFilterConfig filterConfig) {
// Prevent the same filter being added multiple times
-for (ApplicationFilterConfig filter : filters) {
-if (filter == filterConfig) {
+for (int i = 0; i < n; i++) {
+if (filters[i] == filterConfig) {
return;
}
}
if (n == filters.length) {
-ApplicationFilterConfig[] newFilters = new
ApplicationFilterConfig[n + INCREMENT];
-System.arraycopy(filters, 0, newFilters, 0, n);
-filters = newFilters;
+filters = Arrays.copyOf(filters, n + INCREMENT);
}
filters[n++] = filterConfig;
@@ -317,7 +316,7 @@ public final class ApplicationFilterChain implements
FilterChain {
public void findNonAsyncFilters(Set result) {
for (int i = 0; i < n; i++) {
ApplicationFilterConfig filter = filters[i];
-if
("false".equalsIgnoreCase(filter.getFilterDef().getAsyncSupported())) {
+if (!(filter.getFilterDef().getAsyncSupportedBoolean())) {
result.add(filter.getFilterClass());
}
}
diff --git a/java/org/apache/tomcat/util/descriptor/web/FilterDef.java
b/java/org/apache/tomcat/util/descriptor/web/FilterDef.java
index 3a208964e0..b742d5c19c 100644
--- a/java/org/apache/tomcat/util/descriptor/web/FilterDef.java
+++ b/java/org/apache/tomcat/util/descriptor/web/FilterDef.java
@@ -162,8 +162,14 @@ public class FilterDef implements Serializable {
public void setAsyncSupported(String asyncSupported) {
this.asyncSupported = asyncSupported;
+asyncSupportedBoolean = !("false".equalsIgnoreCase(asyncSupported));
}
+private boolean asyncSupportedBoolean = true;
+
+public boolean getAsyncSupportedBoolean() {
+return asyncSupportedBoolean;
+}
// - Public Methods
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 0d11f722ed..42637e78b7 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -105,6 +105,14 @@
issues do not "pop up" wrt. others).
-->
+
+
+
+Minor performance improvement for building filter chains. Based on
+ideas from 702 by Luke Miao. (remm)
+
+
+
-
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: Performance tweaks for filter chain
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 6c55aab511 Performance tweaks for filter chain
6c55aab511 is described below
commit 6c55aab51121280a66866e387ddfbd46ee0e42e0
Author: remm
AuthorDate: Wed Feb 28 16:11:17 2024 +0100
Performance tweaks for filter chain
Actually, the check to see if the filter is present was quite
inefficient due to the increment size and the lack of loop exit.
Investigating using a LinkedHashMap is a possibility.
---
java/org/apache/catalina/core/ApplicationFilterChain.java | 13 ++---
java/org/apache/tomcat/util/descriptor/web/FilterDef.java | 6 ++
webapps/docs/changelog.xml| 8
3 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/java/org/apache/catalina/core/ApplicationFilterChain.java
b/java/org/apache/catalina/core/ApplicationFilterChain.java
index c038a36709..e6a45a05dc 100644
--- a/java/org/apache/catalina/core/ApplicationFilterChain.java
+++ b/java/org/apache/catalina/core/ApplicationFilterChain.java
@@ -19,6 +19,7 @@ package org.apache.catalina.core;
import java.io.IOException;
import java.security.Principal;
import java.security.PrivilegedActionException;
+import java.util.Arrays;
import java.util.Set;
import javax.servlet.Filter;
@@ -164,7 +165,7 @@ public final class ApplicationFilterChain implements
FilterChain {
Filter filter = filterConfig.getFilter();
if (request.isAsyncSupported() &&
-
"false".equalsIgnoreCase(filterConfig.getFilterDef().getAsyncSupported())) {
+
!(filterConfig.getFilterDef().getAsyncSupportedBoolean())) {
request.setAttribute(Globals.ASYNC_SUPPORTED_ATTR,
Boolean.FALSE);
}
if (Globals.IS_SECURITY_ENABLED) {
@@ -253,16 +254,14 @@ public final class ApplicationFilterChain implements
FilterChain {
void addFilter(ApplicationFilterConfig filterConfig) {
// Prevent the same filter being added multiple times
-for (ApplicationFilterConfig filter : filters) {
-if (filter == filterConfig) {
+for (int i = 0; i < n; i++) {
+if (filters[i] == filterConfig) {
return;
}
}
if (n == filters.length) {
-ApplicationFilterConfig[] newFilters = new
ApplicationFilterConfig[n + INCREMENT];
-System.arraycopy(filters, 0, newFilters, 0, n);
-filters = newFilters;
+filters = Arrays.copyOf(filters, n + INCREMENT);
}
filters[n++] = filterConfig;
@@ -315,7 +314,7 @@ public final class ApplicationFilterChain implements
FilterChain {
public void findNonAsyncFilters(Set result) {
for (int i = 0; i < n; i++) {
ApplicationFilterConfig filter = filters[i];
-if
("false".equalsIgnoreCase(filter.getFilterDef().getAsyncSupported())) {
+if (!(filter.getFilterDef().getAsyncSupportedBoolean())) {
result.add(filter.getFilterClass());
}
}
diff --git a/java/org/apache/tomcat/util/descriptor/web/FilterDef.java
b/java/org/apache/tomcat/util/descriptor/web/FilterDef.java
index dcee3005a0..83b03e2730 100644
--- a/java/org/apache/tomcat/util/descriptor/web/FilterDef.java
+++ b/java/org/apache/tomcat/util/descriptor/web/FilterDef.java
@@ -162,8 +162,14 @@ public class FilterDef implements Serializable {
public void setAsyncSupported(String asyncSupported) {
this.asyncSupported = asyncSupported;
+asyncSupportedBoolean = !("false".equalsIgnoreCase(asyncSupported));
}
+private boolean asyncSupportedBoolean = true;
+
+public boolean getAsyncSupportedBoolean() {
+return asyncSupportedBoolean;
+}
// - Public Methods
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 83799fc7a3..83db5b068a 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -105,6 +105,14 @@
issues do not "pop up" wrt. others).
-->
+
+
+
+Minor performance improvement for building filter chains. Based on
+ideas from 702 by Luke Miao. (remm)
+
+
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PR] Avoid performance issues that may arise when the array is large. [tomcat]
rmaucher commented on PR #702: URL: https://github.com/apache/tomcat/pull/702#issuecomment-1969224578 I added some optimizations, still based on the array. If you investigate something, then fully using a LinkedHashSet would likely be better than HashSet + array. Please provide actual micro benchmarks to determine when/if it becomes better than the current code. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PR] Avoid performance issues that may arise when the array is large. [tomcat]
rmaucher closed pull request #702: Avoid performance issues that may arise when the array is large. URL: https://github.com/apache/tomcat/pull/702 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: (tomcat) branch main updated: Performance tweaks for filter chain
> diff --git a/java/org/apache/tomcat/util/descriptor/web/FilterDef.java
> b/java/org/apache/tomcat/util/descriptor/web/FilterDef.java
> index 3a208964e0..b742d5c19c 100644
> --- a/java/org/apache/tomcat/util/descriptor/web/FilterDef.java
> +++ b/java/org/apache/tomcat/util/descriptor/web/FilterDef.java
> @@ -162,8 +162,14 @@ public class FilterDef implements Serializable {
>
> public void setAsyncSupported(String asyncSupported) {
> this.asyncSupported = asyncSupported;
> +asyncSupportedBoolean = !("false".equalsIgnoreCase(asyncSupported));
> }
>
> +private boolean asyncSupportedBoolean = true;
Why "true" by default?
Looking into Java Servlet 4.0 specification,
---
servlet-4_0_FINAL.pdf
2.3.3.3 Asynchronous processing says:
"The @WebServlet and @WebFilter annotations described in Chapter 8 have an
attribute - asyncSupported that is a boolean with a default value of false."
"14.3 Deployment Descriptor" says:
7. filter Element
...
The optional async-supported element, when specified, indicates
that the filter supports asynchronous request processing.
10. servlet Element
...
The optional async-
supported element, when specified, indicates that the Servlet can support
asynchronous request processing.
---
I read it so that an omission means "false".
I see that the old code uses "false".equalsIgnoreCase(), but I wonder why.
Also I wonder whether FilterDef and ServletDef classes handling of
asyncSupported could be aligned.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: (tomcat) branch main updated: Performance tweaks for filter chain
On Wed, Feb 28, 2024 at 5:10 PM Konstantin Kolinko
wrote:
>
> > diff --git a/java/org/apache/tomcat/util/descriptor/web/FilterDef.java
> > b/java/org/apache/tomcat/util/descriptor/web/FilterDef.java
> > index 3a208964e0..b742d5c19c 100644
> > --- a/java/org/apache/tomcat/util/descriptor/web/FilterDef.java
> > +++ b/java/org/apache/tomcat/util/descriptor/web/FilterDef.java
> > @@ -162,8 +162,14 @@ public class FilterDef implements Serializable {
> >
> > public void setAsyncSupported(String asyncSupported) {
> > this.asyncSupported = asyncSupported;
> > +asyncSupportedBoolean =
> > !("false".equalsIgnoreCase(asyncSupported));
> > }
> >
> > +private boolean asyncSupportedBoolean = true;
>
> Why "true" by default?
>
> Looking into Java Servlet 4.0 specification,
> ---
> servlet-4_0_FINAL.pdf
> 2.3.3.3 Asynchronous processing says:
> "The @WebServlet and @WebFilter annotations described in Chapter 8 have an
> attribute - asyncSupported that is a boolean with a default value of false."
>
> "14.3 Deployment Descriptor" says:
> 7. filter Element
> ...
> The optional async-supported element, when specified, indicates
> that the filter supports asynchronous request processing.
>
> 10. servlet Element
> ...
> The optional async-
> supported element, when specified, indicates that the Servlet can support
> asynchronous request processing.
> ---
>
> I read it so that an omission means "false".
> I see that the old code uses "false".equalsIgnoreCase(), but I wonder why.
I coded it like this because of that, so it is equivalent.
And it then works because of:
https://github.com/apache/tomcat/blob/main/java/org/apache/catalina/startup/ContextConfig.java#L1398
> Also I wonder whether FilterDef and ServletDef classes handling of
> asyncSupported could be aligned.
I didn't want to change the API [ok only in 11].
Rémy
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Buildbot failure in on tomcat-9.0.x
Build status: BUILD FAILED: Snapshot deployed to ASF Maven snapshot repository (failure) Worker used: bb_worker2_ubuntu URL: https://ci2.apache.org/#builders/37/builds/875 Blamelist: remm Build Text: Snapshot deployed to ASF Maven snapshot repository (failure) Status Detected: new failure Build Source Stamp: [branch 9.0.x] 6c55aab51121280a66866e387ddfbd46ee0e42e0 Steps: worker_preparation: 0 git: 0 shell: 0 shell_1: 0 shell_2: 0 shell_3: 0 shell_4: 0 shell_5: 0 compile: 1 shell_6: 0 shell_7: 0 shell_8: 2 -- ASF Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 68677] no support for enviroment variables/request attributes
https://bz.apache.org/bugzilla/show_bug.cgi?id=68677 --- Comment #4 from Christopher Schultz --- The typical way to do this is: 1. Remove all inbound HTTP headers you want to set at the proxy 2. Set your specific HTTP headers at the proxy 3. Read your now-trusted HTTP headers from the request in Tomcat Can I direct you to https://tomcat.apache.org/presentations.html#latest-migrate-ajp-http for the "Migrating AJP -> HTTP" presentation? -- 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 68677] no support for enviroment variables/request attributes
https://bz.apache.org/bugzilla/show_bug.cgi?id=68677 --- Comment #5 from dub...@gmail.com --- Again - I need something integrated w/ Tomcat and a true reverse proxy over HTTP will never be that. How would things like REMOTE_USER or the client certificate get propagated to Tomcat? This is something your presentation fails to discuss and is arguably the biggest advantage of AJP over other protocols. -- 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 68677] no support for enviroment variables/request attributes
https://bz.apache.org/bugzilla/show_bug.cgi?id=68677 --- Comment #6 from Christopher Schultz --- (In reply to dub357 from comment #5) > How would things like REMOTE_USER or the client > certificate get propagated to Tomcat? This is something your presentation > fails to discuss and is arguably the biggest advantage of AJP over other > protocols. Slide 30 recommends using SSLValve specifically to handle client certificates. I think REMOTE_USER is not handled by any component other than the AJP connector at this point. There is certainly room for improvement, there. -- 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 68677] no support for enviroment variables/request attributes
https://bz.apache.org/bugzilla/show_bug.cgi?id=68677 --- Comment #7 from dub...@gmail.com --- Im stuck with IIS, hence the request for a mod to the isapi filter connector. If I could use Apache, I would be able to use the JkEnvVar directive. -- 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 68677] no support for enviroment variables/request attributes
https://bz.apache.org/bugzilla/show_bug.cgi?id=68677 dub...@gmail.com changed: What|Removed |Added Severity|normal |enhancement -- 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
Add support for HTTP connectors to accept REMOTE_USER information from a proxy?
All, When using AJP, setting tomcatAuthentication="false" allows mod_jk or mod_proxy_ajp to transmit authenticated user information across the connection to Tomcat so that request.getRemoteUser() will return whatever httpd has for REMOTE_USER. The same is not true for the HTTP connectors. RemoteIPValve takes care of X-Forwarded-* headers SSLValve takes care of SSL_* variables for cipher, client cert, etc. This appears to be one of the only commonly-used pieces of information that is difficult to transmit across HTTP while it's easy with AJP. https://lists.apache.org/thread/bmps52nv8h63mkfqhzmh7p5bhhglgbpl As a part of my crusade to get people to move from AJP to HTTP, I'd like to propose that we make arrangements for this information to be transmitted in some reasonable way. One way to do it would be to add something to RemoteIPValve that would be willing to accept e.g. X-Remote-User header and assign that to the request. (This would be disabled by default!) Straightforward, relatively easy to understand and configure, and uses existing components. But perhaps X-Remote-User is "out of scope" for RemoteIPValve? Another way would be to add tomcatAuthentication="false" as an option for the HTTP connector. It would behave like its AJP twin, except it would look in HTTP headers for ... X-Remote-User? REMOTE_USER? Somethign user-configurable? While this option mirrors the way it's done for AJP, I don't like it as much as using RemoteIPValve, if for no other reason than it has nothing to do with the connector itself and the RemoteIPValve already has similar configuration options for setting the names of special HTTP headers. We could introduce a new Valve that just does this, and maybe adds other things later that we find are also missing. This introduces a completely new component, makes the valve chain even longer, etc. and so I still favor adding this to RemoteIPValve. Thoughts? Thanks, -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 68677] no support for enviroment variables/request attributes
https://bz.apache.org/bugzilla/show_bug.cgi?id=68677 --- Comment #8 from Christopher Schultz --- I've proposed making arrangements for REMOTE_USER on the dev list. I realize that's not quite what you are asking for, here, but I thought I'd mention it since I really do think we as a community should move away from AJP. -- 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 68677] no support for enviroment variables/request attributes
https://bz.apache.org/bugzilla/show_bug.cgi?id=68677
--- Comment #9 from Christopher Schultz ---
Back to your original request...
Could you set HTTP headers (to proxy either using AJP or HTTP) and then have
your application pick those up using a Filter? Something like:
Client -- HTTP --> IIS
IIS adds header Request-Attribute-Foo
IIS adds header Request-Attribute-Bar
IIS -- AJP or HTTP --> Tomcat
RequestAttributeFilter grabs all Request-Attribute-* headers
- request.setAttribute("Foo", request.getHeader("Request-Attribute-Foo"))
- request.setAttribute("Bar", request.getHeader("Request-Attribute-Bar"))
I guess what I'm really asking is "do you need this to be implemented in mod_jk
or can you do it another way?"
The reason REMOTE_USER, etc. really need to be done differently is because you
really want the REMOTE_USER and friends to be available as early as possible in
the request-processing pipeline. That's why you would usually use a Valve for
these kinds of things, including before any Authenticator valve runs.
If your application just needs some request attributes, can you grab them this
way? Or, maybe even get them directly from the request headers instead of
attributes?
--
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 68677] no support for enviroment variables/request attributes
https://bz.apache.org/bugzilla/show_bug.cgi?id=68677
--- Comment #10 from dub...@gmail.com ---
First off, what I'm asking for already exists in mod_jk via the JkEnvVar
directive. I just want the same thing for jk_isapi_plugin (the IIS equivalent
of mod_jk).
This request stemmed from a deep dive into an issue I've been researching
related to IIS and Adobe ColdFusion. ColdFusion installs the Tomcat connector
for the server that its set up to run within. I think you run it by itself
(basically running Tomcat by itself) but its recommended to run within a web
server for additional security (lord knows its a target vector) and ease of
setup. For my organization, that server is IIS so it installs the IIS
connector (isapi_redirect.dll) and requests get sent through IIS to
ColdFusion/Tomcat via AJP. This is an out-of-the-box install.
Now - we have another module/filter installed in IIS which handles SAML
authentication called Shibboleth Service Provider. By default, the Shibboleth
SP software manipulates the request and after its performed authentication of
the user, it stores REMOTE_USER and information about how they authenticated in
request attributes/variables. Those attributes are made available to
applications as part of the environment. For things like PHP, you can access
them via $_SERVER["some_var"]. For ASP, its
request.ServerVariables("some_var") for Java/JSP its
httpServletRequest.getAttribute("some_var").
Because the IIS connector doesn't pass any of this information on to Tomcat, I
cannot access it within my ColdFusion code. Luckily the Shibboleth SP software
has an option to store the information in request headers, but it strongly
recommended to not do this because those can be spoofed by the client.
So long story short, I absolutely need REMOTE_USER from IIS so I need AJP. The
jk_isapi_plugin provides this (yay). However I cannot access the request
variables that other modules/filters may set in IIS. For Shibboleth SP, I'm
forced to tell it to store the information in headers - a security risk
arguably more severe than using AJP.
--
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
[PR] Remove duplicate if statements from the OutputBuffer.close() method [tomcat]
RealTake opened a new pull request, #703: URL: https://github.com/apache/tomcat/pull/703 Hello I was checking the code regarding the "Content-length" of the response and found it. In my opinion, it is because I decided that it is unnecessary to double check !coyoteResponse.isCommitted() inside the if statement. So I made the code concise and clear by eliminating unnecessary duplicates. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
