Re: Potentially useful filter for debugging, etc.
devOn 02/06/2023 18:55, Christopher Schultz wrote: Mark, On 6/2/23 11:00, Mark Thomas wrote: On 02/06/2023 15:35, Christopher Schultz wrote: All, I've built a Filter for use with a client who has many environments, many reverse proxies, and many application servers and were getting confused about what was what. Basically, it just adds a "Via" header as appropriate and has some configurability to choose the header name, override the protocol and server-name if requested, and to limit the number of IP-segments reported in the value. Would this be something useful to add to Tomcat? That implies that Tomcat is acting as a reverse proxy. Given that functionality isn't built into Tomcat, I'd expect whatever component is providing the reverse proxy functionality to provide the Via header and any other appropriate debug tools. It seems a little odd to provide a debug tool with Tomcat for a feature that Tomcat doesn't implement. I was thinking that Tomcat here was an origin server and reporting its own identity, etc. to the reverse-proxy, which would then add its own "Via" header. I'm a little confused about how this all works. Shouldn't the reverse proxy add the Via header before forwarding the request? Is the Filter adding a Via header? I read the original post as it was. But Via headers are for proxy's not origin servers. Maybe an example would help. Or a link to the Filter's source. I am generally in favour of adding Filters that are generally useful but wary of things that appear to behave in unexpected ways. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat-native] branch main updated: native: Fix the build with rlibtool
On 05/06/2023 21:20, Rainer Jung wrote: Something is wrong with our regeneration of configure in the release process, at least for the 2.x branch (main). The configure script contains "LT_INIT" verbatim instead of LT_INIT being replaced by its script implementation. I can't actually say what is wrong :( If I run "autoreconf --force --install" on my system LT_INIT gets resolved but configure also get much bigger (more than double the size). Let me know if you have no good idea and I should investigate deeper. Sorry, no idea here. I tested the PR to the extent I check I could still build with the PR applied but went no deeper. Linux build systems are mostly a mystery to me. Mark Thanks and regards, Rainer Am 31.10.22 um 21:02 schrieb ma...@apache.org: This is an automated email from the ASF dual-hosted git repository. markt pushed a commit to branch main in repository https://gitbox.apache.org/repos/asf/tomcat-native.git The following commit(s) were added to refs/heads/main by this push: new 54dccd3a4 native: Fix the build with rlibtool new 4f7fb7f44 Merge pull request #14 from orbea/slibtool 54dccd3a4 is described below commit 54dccd3a4dc01801d9311b3160808305ec9fc2cf Author: orbea AuthorDate: Thu Jul 21 17:59:14 2022 -0700 native: Fix the build with rlibtool When building tomcat-native with slibtool using the rlibtool symlink the build will fail. This is because rlibtool requires the generated libtool script to determine if the build is shared, static or both. Gentoo bug: https://bugs.gentoo.org/778914 --- native/configure.in | 3 +++ 1 file changed, 3 insertions(+) diff --git a/native/configure.in b/native/configure.in index 567894b10..e082ae6d2 100644 --- a/native/configure.in +++ b/native/configure.in @@ -50,6 +50,9 @@ AC_SUBST(TCN_CONFIG_LOCATION) AC_CANONICAL_TARGET AC_PROG_INSTALL +dnl Generate the libtool script which is needed for rlibtool +LT_INIT + dnl dnl compute the top directory of the build dnl note: this is needed for LIBTOOL and exporting the bundled Expat - 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 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Potentially useful filter for debugging, etc.
вт, 6 июн. 2023 г. в 13:43, Mark Thomas : > > devOn 02/06/2023 18:55, Christopher Schultz wrote: > > Mark, > > > > On 6/2/23 11:00, Mark Thomas wrote: > >> On 02/06/2023 15:35, Christopher Schultz wrote: > >>> All, > >>> > >>> I've built a Filter for use with a client who has many environments, > >>> many reverse proxies, and many application servers and were getting > >>> confused about what was what. > >>> I think that Chris wants to be able to trace origins of responses. >From what servers they originated (and maybe what proxies it came through). "Adding a header" generally can be done by the well-known "urlrewrite" filter. Or by mod_header at Apache HTTPD. Is there any interest in implementing just "adding a header"? Is it the logic of managing the "Via" header that makes it interesting? BTW, specification of the Via header: https://www.rfc-editor.org/rfc/rfc9110.html#name-via Generally, there will be other proxies in front of Tomcat. Woldn't it be better to have the logic on those servers? It is rare to use Tomcat itself as a proxy. As a preceding example I am thinking about "Ray IDs" as used by Cloudflare: https://developers.cloudflare.com/fundamentals/get-started/reference/cloudflare-ray-id/ Those are hashed. It also looks like those IDs are assigned per-request. Essentially, unique IDs for requests. The general usage seems to be that the IDs are logged, and are analyzed afterwards. BTW, as an alternative, there exists the "Server" header, For an HTTP connector it can be configured with "server" and "serverRemoveAppProvidedValues" attributes on a Connector. It seems that there is no configuration for an AJP Connector. https://tomcat.apache.org/tomcat-10.1-doc/config/http.html#Standard_Implementation Specification: https://www.rfc-editor.org/rfc/rfc9110.html#name-server Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Potentially useful filter for debugging, etc.
Mark,
On 6/6/23 06:42, Mark Thomas wrote:
devOn 02/06/2023 18:55, Christopher Schultz wrote:
Mark,
On 6/2/23 11:00, Mark Thomas wrote:
On 02/06/2023 15:35, Christopher Schultz wrote:
All,
I've built a Filter for use with a client who has many environments,
many reverse proxies, and many application servers and were getting
confused about what was what.
Basically, it just adds a "Via" header as appropriate and has some
configurability to choose the header name, override the protocol and
server-name if requested, and to limit the number of IP-segments
reported in the value.
Would this be something useful to add to Tomcat?
That implies that Tomcat is acting as a reverse proxy. Given that
functionality isn't built into Tomcat, I'd expect whatever component
is providing the reverse proxy functionality to provide the Via
header and any other appropriate debug tools. It seems a little odd
to provide a debug tool with Tomcat for a feature that Tomcat doesn't
implement.
I was thinking that Tomcat here was an origin server and reporting its
own identity, etc. to the reverse-proxy, which would then add its own
"Via" header.
I'm a little confused about how this all works.
Sorry, I think I didn't give enough explanation.
Shouldn't the reverse proxy add the Via header before forwarding the
request?
Is the Filter adding a Via header? I read the original post as it was.
But Via headers are for proxy's not origin servers.
Maybe an example would help. Or a link to the Filter's source.
It's possible that I may be abusing the HTTP Via header, but I don't
think so.
The idea was to provide information to the *client* about which servers
are handling the request. The HTTP Via header seems to fit the billing,
as a response-header and not a request-header. I'm not worried about
request-headers at all, here.
My Filter basically says 'add "Via: protocol/version myself" header to
the response' and that's it. The reverse-proxy can augment the Via
response header with its own. So for a simple setup where we have two
web servers and two Tomcat servers cross-linked, the client might see a
response header looking like this:
Via: HTTP/1.1 web1, HTTP/1.1 tomcat2
I am generally in favour of adding Filters that are generally useful but
wary of things that appear to behave in unexpected ways.
As you should be.
I created this Filter to be used in a situation with multiple
environments and where there are multiple reverse proxies between the
client and the Tomcat server. We were tracking-down what we believed was
a misconfiguration of one or more of the reverse-proxies that
cross-linked environments and we needed to figure out which pair of
reverse-proxy servers were being used in a simple way e.g. using curl.
(Automation wasn't going to solve this one, unfortunately, given the way
things had been deployed).
So we configured the Tomcat servers to announce themselves and the httpd
servers to do the same, using the Via header in this way.
I suppose the httpd instance could set the header to include BOTH
servers, since it really ought to know its own identity as well as the
identity of the origin server it's connecting to, but ... I chose this
way instead since upstream could be more complicated than httpd knows.
Here is the code of the doFilter function without the source of the
supporting functions:
StringBuilder serverIdentifier = new StringBuilder(64); // 64
characters ought to be enough for anybody
String protocol = getProtocol();
if(null == protocol) {
protocol = httpRequest.getProtocol();
if(null != protocol) {
if(!getIncludeProtocolName()) {
int pos = protocol.indexOf('/');
if(0 <= pos) {
protocol = protocol.substring(pos + 1);
}
}
serverIdentifier.append(protocol);
}
} else {
serverIdentifier.append(protocol);
}
String serverName = getServerName();
if(null == serverName) {
serverName = getTrimmedIPAddress(httpRequest.getLocalAddr());
}
serverIdentifier.append(' ').append(serverName);
if(getIncludePort()) {
serverIdentifier.append(':').append(httpRequest.getLocalPort());
}
httpResponse.addHeader(getHeaderName(),
serverIdentifier.toString());
Most of the stuff has reasonable defaults. If you installed this on
localhost IPv4 and didn't override anything, you'd get "Via: HTTP/1.1 1"
i the response header because the IP address 127.0.0.1 would have all
but the last octet of the address removed, leaving just the "1". This is
pretty useless for localhost, but in a subnet with multiple backends,
you'd get e.g. "Via: HTTP/1.1 42" and "Via HTTP/1.1 43" for servers on
x.x.x.42 and x.x.x.43 respectively.
You can override everything, including which header to use, the "na
[ANN] Community Over Code Conference NA 2023 in Halifax, Canada, 7-10 Oct 2023, CFP is OPEN!
All, [Cross-posting to dev@, please reply to users@] The Community Over Code Conference (formerly ApacheCon) North America 2023 is in-person in Halifax, Nova Scotia, Canada. It will be held 7 - 10 October 2023 at a location to-be-announced. The call-for-presentations (CFP) is currently open and Tomcat is a part of the "web servers" track this year. https://communityovercode.org/ The link for the CFP is at the top of the page, where you can submit a proposal. Note that you don't have to have the presentation ready to go today in order to make a proposal. It's just gotta be ready around 30 seconds before you start to present it ;) (There is a tradition at these conferences of editing ones slides during the previous presentation. I don't recommend it, but anyone who is intimidated by the process can rest assured that even repeat-presenters are putting things together at the last moment.) Anyone who has never attended an ASF conference should consider making this year their first: it's great fun, and you get to meet a lof of folks from all over the ASF, not just the Tomcat or httpd people, but folks working on projects you've never even heard of. If you aren't sure if you are interested in presenting, or aren't sure if you have the experience, knowledge, etc. to warrant a position as a speaker, please consider the following: 1. This is a welcoming community 2. This community exists to serve YOU 3. You are a part of this community 4. Helping others within the community encourages others to do the same 5. Topics can be very wide-ranging. Here are some examples of presentations from previous ASF events: [From Committers / directly about Tomcat] - Running Apache Tomcat on GraalVM - Tomcat in clusters and clouds - Using Let's Encrypt with Tomcat - Securing Tomcat - Reverse-proxying Tomcat - Load balancing with Tomcat - Clustering with Tomcat [From Non-Committers or not directly about Tomcat] - Packaging Tomcat for Linux Distributions - I Love Lucee -- a Java implementation of Cold Fusion - Routing CDN traffic at scale using Tomcat - Secure Web Applications using Apache Fortress - Monitoring Tomcat; various tools - Building Reactive Applications on Tomcat - Troubleshooting performance using thread dumps - High Throughput Production Systems on Tomcat - Why I Love Open Source - Introduction to Spring Boot - Tomcat, TomEE, and Meecrowave - Apache Tomcat: Enabling Scripting Languages in JSPs If you are using Tomcat at $work and doing something interesting, we'd love to hear about it. 6. You don't need to be the foremost expert in $feature to talk about it 7. We are actively looking for speakers to talk about these and other topics: - Deploying Tomcat in an auto-scaling environment (e.g. AWS EBS) - Tomcat should really have [Feature X] - Whatever you think might be interesting! Please consider speaking ESPECIALLY if you haven't done so before. If you are worried about whether your idea is good enough: don't. Just submit your idea to the CFP -- you don't have to write-up the presentation in order to submit an idea, just write a paragraph or two about what you want to do -- and the track chairpersons (chairpeople?[1]) will decide whether or not to include your presentation in the event. (And chances are good that if you submit an idea it will be accepted.) Please reply to the users list with any questions you may have about ApacheCon, the Tomcat track, or submitting a talk proposal. Thanks, -chris On behalf of all Community over Code NA 2023 web-server/Tomcat Track chairpersons. [1] https://vignette.wikia.nocookie.net/rickandmorty/images/c/cd/Furniture.png/revision/latest/scale-to-width-down/1000?cb=20160910223642 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 9.0.76
On Mon, Jun 5, 2023 at 3:49 AM Rémy Maucherat wrote: > The proposed Apache Tomcat 9.0.76 release is now available for voting. > > The notable changes compared to 9.0.75 are: > > - Add support for virtual threads. (Java 21+ only) > > - Update HTTP/2 to use the RFC-9218 prioritization scheme. > > - Deprecate the xssProtectionEnabled from HttpHeaderSecurityFilter >and set the default value to false. > > - Update Tomcat Native to 2.0.4 which includes binaries for Windows >built with OpenSSL 3.0.9. > > Along with lots of other bug fixes and improvements. > > For full details, see the changelog: > https://nightlies.apache.org/tomcat/tomcat-9.0.x/docs/changelog.html > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.76/ > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1440 > The tag is: > https://github.com/apache/tomcat/tree/9.0.76 > ff0629ca2bd82d6bff5245c02b42d932149df34d > b6eac326b5 > > The proposed 9.0.76 release is: > [ ] -1, Broken - do not release > [x] +1, Stable - go ahead and release as 9.0.76 > Test pass on Fedora 36. > Rémy > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: [VOTE] Release Apache Tomcat 8.5.90
On Fri, Jun 2, 2023 at 8:08 PM Christopher Schultz wrote: > > The proposed Apache Tomcat 8.5.90 release is now available for voting. > > The notable changes compared to 8.5.89 are: > > - Add support for virtual threads. (Java 21+ only) > > - Update HTTP/2 to use the RFC-9218 prioritization scheme. > > - Deprecate the xssProtectionEnabled from HttpHeaderSecurityFilter >and set the default value to false. > > - Update Tomcat Native to 1.2.37 which includes binaries for Windows >built with OpenSSL 1.1.1u. > > Along with lots of other bug fixes and improvements. > > For full details, see the changelog: > https://nightlies.apache.org/tomcat/tomcat-8.5.x/docs/changelog.html > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.90/ > > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1438 > > The tag is: > https://github.com/apache/tomcat/tree/8.5.90/ > 136713c528bfcd31563c1e7b7685d4983bb3559c > > The proposed 8.5.90 release is: > [ ] Broken - do not release > [X] Stable - go ahead and release as 8.5.90 (stable) Rémy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66627] New: Regression due to MessageBytes refactoring
https://bz.apache.org/bugzilla/show_bug.cgi?id=66627
Bug ID: 66627
Summary: Regression due to MessageBytes refactoring
Product: Tomcat 9
Version: 9.0.71
Hardware: All
OS: All
Status: NEW
Severity: regression
Priority: P2
Component: Util
Assignee: dev@tomcat.apache.org
Reporter: bill-apa...@carpenter.org
Target Milestone: -
This commit,
https://github.com/apache/tomcat/commit/10a1a6d46d952bab4dfde44c3c0de12b0330da79,
that appeared in 9.0.71 made changes to MessageBytes.toString() that cause a
serious regression under some circumstances. This is preventing us from
upgrading to later Tomcat releases to pick up security fixes.
If the MessageByte object is of type T_BYTES or T_CHARS, it gets converted to
type T_STR. Although there is nothing in the general contract of toString()
that prohibits modifying the object, it's an unexpected side-effect. The
JavaDoc for MessageBytes.getType() explicitly says it returns "the type of the
original content", so the change breaks that contract.
But it's more serious than a mere disagreement with documentation. Some
colleagues of mine were a few days ahead of me in investigating this problem
(they were working with tomcat-embed-core and I was working woth Tomcat
standalone). Most of this explanation is due to their research.
If something calls MessageBytes.toString(), fragile assumptions elsewhere can
fall apart. For example, if you use a Java agent like OpenTelemetry, it
intercepts every request in order to obtain the URL path for logging.
CoyoteAdapter.postParseRequest() then makes a mistake because the MessageBytes
object changed from type T_BYTES to type T_STR, and this assumption is no
longer true:
/*
* The URI is chars or String, and has been sent using an in-memory protocol
handler. The following
* assumptions are made: - req.requestURI() has been set to the 'original'
non-decoded, non-normalized
* URI - req.decodedURI() has been set to the decoded, normalized form of
req.requestURI()
*/
The downstream result of that is a 404 response for every URL path.
Experimentally, I found that simply removing the type reassignment, as seen
here, was enough to resolve the immediate issue. State tracking in the
MessageBytes class is a bit complicated, and I have not looked carefully to see
if this proposed fix has any undesired consequences.
/**
* Compute the string value.
* @return the string
*/
@Override
public String toString() {
switch (type) {
case T_NULL:
case T_STR:
// No conversion required
break;
case T_BYTES:
//type = T_STR;
strValue = byteC.toString();
break;
case T_CHARS:
//type = T_STR;
strValue = charC.toString();
break;
}
return strValue;
}
--
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: [VOTE] Release Apache Tomcat 10.1.10
On Fri, Jun 2, 2023 at 11:43 AM Christopher Schultz < ch...@christopherschultz.net> wrote: > The proposed Apache Tomcat 10.1.10 release is now available for > voting. > > The notable changes compared to 10.1.9 are: > > - Add support for virtual threads. (Java 21+ only) > > - Update HTTP/2 to use the RFC-9218 prioritization scheme. > > - Deprecate the xssProtectionEnabled from HttpHeaderSecurityFilter >and set the default value to false. > > - Update Tomcat Native to 2.0.4 which includes binaries for Windows >built with OpenSSL 3.0.9. > > For full details, see the change log: > https://nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html > > Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 > without changes. Java EE applications designed for Tomcat 9 and earlier > may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat > will automatically convert them to Jakarta EE and copy them to the > webapps directory. > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.10/ > > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1439 > > The tag is: > https://github.com/apache/tomcat/tree/10.1.10 > 744f57269b2dda2dfcd252fff7f04744a7fcd5b8 > > The proposed 10.1.10 release is: > [ ] Broken - do not release > [X] Stable - go ahead and release as 10.1.10 > +1 Igal > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: [VOTE] Release Apache Tomcat 9.0.76
On Mon, Jun 5, 2023 at 12:49 AM Rémy Maucherat wrote: > The proposed Apache Tomcat 9.0.76 release is now available for voting. > > The notable changes compared to 9.0.75 are: > > - Add support for virtual threads. (Java 21+ only) > > - Update HTTP/2 to use the RFC-9218 prioritization scheme. > > - Deprecate the xssProtectionEnabled from HttpHeaderSecurityFilter >and set the default value to false. > > - Update Tomcat Native to 2.0.4 which includes binaries for Windows >built with OpenSSL 3.0.9. > > Along with lots of other bug fixes and improvements. > > For full details, see the changelog: > https://nightlies.apache.org/tomcat/tomcat-9.0.x/docs/changelog.html > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.76/ > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1440 > The tag is: > https://github.com/apache/tomcat/tree/9.0.76 > ff0629ca2bd82d6bff5245c02b42d932149df34d > b6eac326b5 > > The proposed 9.0.76 release is: > [ ] -1, Broken - do not release > [X] +1, Stable - go ahead and release as 9.0.76 > +1 Igal > > Rémy > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
