[Bug 64153] ServerContainer is not available in ServletContext
https://bz.apache.org/bugzilla/show_bug.cgi?id=64153 Mark Thomas changed: What|Removed |Added Status|NEEDINFO|NEW --- Comment #5 from Mark Thomas --- It is the change for bug 64021. It is caused by a difference between context.getParentClassLoader() and context.getLoader().getClassLoader().getParent(). I haven't got a fix yet but it should be fairly simple, -- 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: Enabling http to https redirects for tomcat.apache.org
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 2/25/20 17:29, Mark Thomas wrote: > On 25/02/2020 20:45, Christopher Schultz wrote: >> Mark, >> >> On 2/25/20 14:34, Mark Thomas wrote: >>> On 25/02/2020 15:53, Felix Schumacher wrote: Hi all, as more and more browsers are marking http as unsecure, we should redirect all http requests to tomcat.apache.org to https. >> >>> I really don't like this. >> >>> I'm happy to support https for those people that want to use it >>> but I see no need to require https for everybody for >>> tomcat.apache.org. >> >>> We should not be dictating to our users what security / privacy >>> / caching / performance / etc. trade-offs are appropriate for >>> them. We should support as many options as possible and let our >>> users decided. >> >>> I'm not quite -1 on this but I am close. >> >> https://www.troyhunt.com/heres-why-your-static-website-needs-https/ > >> > Sorry, not convinced. We need to let users make this choice. > > The numbers are significant. > > tomcat.apache.org from China can be significantly slower over > https compared to http. Typically 2 to 3 times slower in my testing > with > > https://www.websitepulse.com/tools/china-firewall-test# > > 3.5s to 8s to load the index page over https compared to ~1.5s > over http. That said, I didn't repeat the test enough for those > results to be considered statistically reliable. Plus, the Great Firewall is already a giant MiTM, so forcing HTTPS doesn't really prevent them from performing whatever content filtering/tampering they want, anyway. > Not everyone has a low latency, high bandwidth connection to the > internet. We need to let the users decide if they want to pay the > performance penalty for the benefits of https or not. We should not > be assuming we know best for everyone. What's a few three-legged handshakes between friends? Hopefully TLSv1.3 will improve things for everyone. Well, unless they are deployed in AWS (*ducks*). - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5VpQIACgkQHPApP6U8 pFjIKxAAuJkW5JCWyPc7cKvumAEO1bEws9LvngupUxPevsEnkG2smw2sGo46N8cj YSWBTo+XJawKQGyPt9C9QEXgw7c2L0YYK6yrMfEz+pEErZwXB1hpREn8PaBzlvgC fHJoj1BakHbWyS8lGRP7ninkpUWav1ZLOOVZnPJTMIG/wQqSM29TcO6wDPWTVVOD SJzA7adP4XZAQMGq0hiNphZzqWOdLweF2pScb0avB6Pzin0AzJdCoItCCC+PiLY1 iOJ7gv6WPYrvrqjQGXxbwZH8cjg/nQbTlf1QOBAoCP+/MNIECT4vsmJcBuWa07e8 4cpS/4b1RqGCL8m68Emmv1uhrqR5oShIJ4bVUprK4c4xLhtCGrRBRv9bgdyKjVq6 gzDMl+qju46RniLMNJ9AzbMByfGTbf97tbjJjP9Hhnn3fuaG/2yOnotL+32eNdGU SmprXNb3l9vbnfyqsDLP2Nn82btHE7FsmsCeA7AvccMSF7lB8iq7MSub4m6TuVsG Jwtgnz8WnuajNh5SAfA+xDhvMd2KMOGg1f/vPLXr4vEOT3t2bWZxgVUN4DM3+FTF 0UNl4DDYijQ6SdejAkS4XhSBqPUpyA8txE56uNkhS51qrDxA9VDbjoQzQ2hYieUg RBW2JSeMqxF2qOwLbo3hmJTnYlEJnWhaMWuG2+az7mPlnrY4xU4= =AapR -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Enabling http to https redirects for tomcat.apache.org
On 25/02/2020 20:45, Christopher Schultz wrote:
> Mark,
>
> On 2/25/20 14:34, Mark Thomas wrote:
>> On 25/02/2020 15:53, Felix Schumacher wrote:
>>> Hi all,
>>>
>>> as more and more browsers are marking http as unsecure, we
>>> should redirect all http requests to tomcat.apache.org to https.
>
>> I really don't like this.
>
>> I'm happy to support https for those people that want to use it but
>> I see no need to require https for everybody for
>> tomcat.apache.org.
>
>> We should not be dictating to our users what security / privacy /
>> caching / performance / etc. trade-offs are appropriate for them.
>> We should support as many options as possible and let our users
>> decided.
>
>> I'm not quite -1 on this but I am close.
>
> https://www.troyhunt.com/heres-why-your-static-website-needs-https/
Sorry, not convinced. We need to let users make this choice.
The numbers are significant.
tomcat.apache.org from China can be significantly slower over https
compared to http. Typically 2 to 3 times slower in my testing with
https://www.websitepulse.com/tools/china-firewall-test#
3.5s to 8s to load the index page over https compared to ~1.5s over
http. That said, I didn't repeat the test enough for those results to be
considered statistically reliable.
Not everyone has a low latency, high bandwidth connection to the
internet. We need to let the users decide if they want to pay the
performance penalty for the benefits of https or not. We should not be
assuming we know best for everyone.
Mark
>
> -chris
>
>>> We can enable that by adding a rewrite rule to the .htaccess file
>>> in the xdocs folder of our site repo.
>>>
>>> For JMeter we used the following fragment:
>>>
>>> RewriteEngine On
>>>
>>> # Redirect http to https # From Cordova PMC Member raphinesse #
>>> https://s.apache.org/An8s
>>>
>>> # If we receive a forwarded http request from a proxy...
>>> RewriteCond %{HTTP:X-Forwarded-Proto} =http [OR]
>>>
>>> # ...or just a plain old http request directly from the client
>>> RewriteCond %{HTTP:X-Forwarded-Proto} ="" RewriteCond %{HTTPS}
>>> !=on
>>>
>>> # Redirect to https version RewriteRule ^
>>> https://%{HTTP_HOST}%{REQUEST_URI} [L]
>>>
>>> Anything against adding this to our .htaccess file?
>
>
>>>
>>> Felix
>>>
>>>
>>> -
>>>
>>>
> 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
>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch master updated: BZ 64166. HttpServletResponse.getHeaderNames() now returns unique names
On 25/02/2020 20:47, Christopher Schultz wrote:
> Mark,
>
> On 2/25/20 14:38, ma...@apache.org wrote:
>> This is an automated email from the ASF dual-hosted git
>> repository.
>
>> markt 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 e9ee933 BZ 64166. HttpServletResponse.getHeaderNames()
>> now returns unique names e9ee933 is described below
>
>> commit e9ee9338f3b4c694b7fd90b69ed468dbdeff5a76 Author: Mark Thomas
>> AuthorDate: Tue Feb 25 14:16:44 2020 +
>
>> BZ 64166. HttpServletResponse.getHeaderNames() now returns unique
>> names
>
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=64166 ---
>> java/org/apache/catalina/connector/Response.java | 7 ---
>> webapps/docs/changelog.xml | 4 2 files
>> changed, 8 insertions(+), 3 deletions(-)
>
>> diff --git a/java/org/apache/catalina/connector/Response.java
>> b/java/org/apache/catalina/connector/Response.java index
>> fce5570..9ec0b5d 100644 ---
>> a/java/org/apache/catalina/connector/Response.java +++
>> b/java/org/apache/catalina/connector/Response.java @@ -30,9 +30,11
>> @@ import java.util.ArrayList; import java.util.Arrays; import
>> java.util.Collection; import java.util.Enumeration; +import
>> java.util.LinkedHashSet;
>
> Is header order actually important?
Probably not but it might be for custom headers. I didn't want to change
the order to be on the safe side.
Mark
> AFAICT, the only time order matters is when header[0] is used for
> "status code" which is not uncommon, but weird.
>
>> import java.util.List; import java.util.Locale; import
>> java.util.Map; +import java.util.Set; import
>> java.util.function.Supplier;
>
>> import jakarta.servlet.ServletOutputStream; @@ -868,9 +870,8 @@
>> public class Response implements HttpServletResponse {
>
>> @Override public Collection getHeaders(String name) { -
>> Enumeration enumeration = -
>> getCoyoteResponse().getMimeHeaders().values(name); -
>> List result = new ArrayList<>(); +
>> Enumeration enumeration =
>> getCoyoteResponse().getMimeHeaders().values(name); +
>> Set result = new LinkedHashSet<>(); while
>> (enumeration.hasMoreElements()) {
>> result.add(enumeration.nextElement()); } diff --git
>> a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml index
>> 5632768..dd93f38 100644 --- a/webapps/docs/changelog.xml +++
>> b/webapps/docs/changelog.xml @@ -59,6 +59,10 @@ Add extension point
>> to DeltaSession to improve subclassing. Patch provided by ThStock.
>> (schultz) + +64166: Ensure
>> that the names returned by +
>> HttpServletResponse.getHeaderNames() are unique.
>> (markt) + > name="Coyote">
>
> -chris
>
> -
> 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
[Bug 64153] ServerContainer is not available in ServletContext
https://bz.apache.org/bugzilla/show_bug.cgi?id=64153 --- Comment #4 from Boris Petrov --- Yes, I'm sorry the reproduction project is far from the best possible but it was easiest for me. You're more familiar with Tomcat itself and I believe that the important code is in `server_runner.rb` so if you could just use that as a blueprint to create a new project that reproduces the issue...? I guess the problem is somewhere in "org.apache.tomcat.embed:tomcat-embed-websocket" because that's what's missing when using a production/standalone Tomcat where the problem doesn't appear. As for the missing JAR - as I said, that's not relevant here. In our own project we don't get that error. I'm not sure why it's here but it doesn't matter anyway - the "real" issue is visible even with it. -- 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: Enabling http to https redirects for tomcat.apache.org
+1 with some light (1 month?) notice time in case anyone uses http directly
intentionally, will avoid some security breaches http can get, in
particular on subdomains.
Le mar. 25 févr. 2020 à 21:45, Christopher Schultz <
ch...@christopherschultz.net> a écrit :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Mark,
>
> On 2/25/20 14:34, Mark Thomas wrote:
> > On 25/02/2020 15:53, Felix Schumacher wrote:
> >> Hi all,
> >>
> >> as more and more browsers are marking http as unsecure, we
> >> should redirect all http requests to tomcat.apache.org to https.
> >
> > I really don't like this.
> >
> > I'm happy to support https for those people that want to use it but
> > I see no need to require https for everybody for
> > tomcat.apache.org.
> >
> > We should not be dictating to our users what security / privacy /
> > caching / performance / etc. trade-offs are appropriate for them.
> > We should support as many options as possible and let our users
> > decided.
> >
> > I'm not quite -1 on this but I am close.
>
> https://www.troyhunt.com/heres-why-your-static-website-needs-https/
>
> - -chris
>
> >> We can enable that by adding a rewrite rule to the .htaccess file
> >> in the xdocs folder of our site repo.
> >>
> >> For JMeter we used the following fragment:
> >>
> >> RewriteEngine On
> >>
> >> # Redirect http to https # From Cordova PMC Member raphinesse #
> >> https://s.apache.org/An8s
> >>
> >> # If we receive a forwarded http request from a proxy...
> >> RewriteCond %{HTTP:X-Forwarded-Proto} =http [OR]
> >>
> >> # ...or just a plain old http request directly from the client
> >> RewriteCond %{HTTP:X-Forwarded-Proto} ="" RewriteCond %{HTTPS}
> >> !=on
> >>
> >> # Redirect to https version RewriteRule ^
> >> https://%{HTTP_HOST}%{REQUEST_URI} [L]
> >>
> >> Anything against adding this to our .htaccess file?
> >
> >
> >>
> >> Felix
> >>
> >>
> >> -
> >>
> >>
> 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
> >
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5Vh3kACgkQHPApP6U8
> pFgktRAAh34aN6pyZaMz2n/Bha81mbNjglrMcxkrEswqMCJM0/8Wbw8hgB+3JArQ
> dfIYipA2KTtjEzRgGU74qGcvDnEpTcoWi+csvmU7nwExt2RClmMF/5KqvYi67QZZ
> l0klgHATRjNPrPOkvZy8Op0fFS6/bnXzvESS/lusz6aLrqiXRxqDVyDgCiBxzrXr
> m2VLdE/re1CyFzcNcNmHUAUNs37/0E2WB1d11OvblE3I9eRb1Vk+FHtsfkDmNEoX
> 0RE7sQlr12ElMQ3OYOHsErxrxgTD2J/+CXqbMra8sWQ4pgEZPMX/7k5bGyr3IpTh
> sOiSR9KNShfJtjKXp2ngJJKbEgDpr4SOYAh5FwGyUKmxflw+nqbc/Zd5bA6H4GNH
> 27p0Ec2ArCSDM4vlIeYbtBo8xqAuq2ArVywyUVrWog4mk0Hita2OHnp6Y8CFcZwR
> hVv2fuFzd9/zueHG1TvLpB86Mr40MS8j2OelAACixECkV8CAo+64hXLLELgl5XXd
> wu6J60tKXXgTlcQcoa0h9nm27D3YKLBUnH6CuOxjUGxVHwH6Bmc2OdR5l+FRNHkl
> 35MEkqCXThXc62/G/sBW4/Kd7bF/A0wYXT8dKYb6p/s4GXZ9yM3sgjQr9N/b0sP0
> RukK+6i6vgtsY7xf8eSVtUAgYNyV4ndxpQyYBiyRHVh06nfGgHQ=
> =qS1l
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
[Bug 64153] ServerContainer is not available in ServletContext
https://bz.apache.org/bugzilla/show_bug.cgi?id=64153 --- Comment #3 from Mark Thomas --- nokogiri 1.10.8 is broken. It includes jing.jar in the lib directory that in turn has a reference to saxon.jar in its classpath. That JAR is missing. I wondered if that failure was causing the WebSocket container failure but that does not seem to be the case. Still investigating. This would be a lot easier with a WAR that I could deploy to my own Tomcat instance rather than trying to figure out how to get better logging and/or debugging working with a bunch of technologies I am unfamiliar with. -- 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: [tomcat] branch master updated: BZ 64166. HttpServletResponse.getHeaderNames() now returns unique names
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Mark,
On 2/25/20 14:38, ma...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git
> repository.
>
> markt 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 e9ee933 BZ 64166. HttpServletResponse.getHeaderNames()
> now returns unique names e9ee933 is described below
>
> commit e9ee9338f3b4c694b7fd90b69ed468dbdeff5a76 Author: Mark Thomas
> AuthorDate: Tue Feb 25 14:16:44 2020 +
>
> BZ 64166. HttpServletResponse.getHeaderNames() now returns unique
> names
>
> https://bz.apache.org/bugzilla/show_bug.cgi?id=64166 ---
> java/org/apache/catalina/connector/Response.java | 7 ---
> webapps/docs/changelog.xml | 4 2 files
> changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/java/org/apache/catalina/connector/Response.java
> b/java/org/apache/catalina/connector/Response.java index
> fce5570..9ec0b5d 100644 ---
> a/java/org/apache/catalina/connector/Response.java +++
> b/java/org/apache/catalina/connector/Response.java @@ -30,9 +30,11
> @@ import java.util.ArrayList; import java.util.Arrays; import
> java.util.Collection; import java.util.Enumeration; +import
> java.util.LinkedHashSet;
Is header order actually important?
AFAICT, the only time order matters is when header[0] is used for
"status code" which is not uncommon, but weird.
> import java.util.List; import java.util.Locale; import
> java.util.Map; +import java.util.Set; import
> java.util.function.Supplier;
>
> import jakarta.servlet.ServletOutputStream; @@ -868,9 +870,8 @@
> public class Response implements HttpServletResponse {
>
> @Override public Collection getHeaders(String name) { -
> Enumeration enumeration = -
> getCoyoteResponse().getMimeHeaders().values(name); -
> List result = new ArrayList<>(); +
> Enumeration enumeration =
> getCoyoteResponse().getMimeHeaders().values(name); +
> Set result = new LinkedHashSet<>(); while
> (enumeration.hasMoreElements()) {
> result.add(enumeration.nextElement()); } diff --git
> a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml index
> 5632768..dd93f38 100644 --- a/webapps/docs/changelog.xml +++
> b/webapps/docs/changelog.xml @@ -59,6 +59,10 @@ Add extension point
> to DeltaSession to improve subclassing. Patch provided by ThStock.
> (schultz) + +64166: Ensure
> that the names returned by +
> HttpServletResponse.getHeaderNames() are unique.
> (markt) + name="Coyote">
- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5Vh+EACgkQHPApP6U8
pFgXEg//S4fdqm8lAkbkQbgajds/S093BEqCXNih0aMecZgoc6EQWLXElFwnVML2
jSN4qEWlhnTHBW9i+Wt/z5FjJz5CTZpQbYYgAfKfXhC8Gg0uGoFdmpx805l4Rnhp
il9ftP6x5ZhcBkEzhUfevixsqHn8ntDyCP1kocCSrul+nXmUdgW+FFJQdDy94ec0
nS8h8koiFnY7EyFCH4a3SqC4d8ih5Z2ELi//PjfOIfCcIVblaQoKX4ZRxQsoLtYn
oW5cYBqKpRjpKQJmN2RKMkl9KCsqhVBLc0b8nHg6YZnurbnnRh2XkNJLIVY8WL1R
wDTXuQUX0n9bGQaVCkc/kYjirUlL/3xRbnyc1C4QVFMQcOUIcv9nWbjGm/iiDVib
jKlAUvXweO9ETJZnDKUBuo4hzHzKto2IiswzJ6FIVY4/QYy32ZtOUhunOc+XAndA
TvUldqY34LK0GcNvzRmBvjlXyqJTRSOsyTKYMc1gR27W/m7YBUm9AE0erz6ranEb
uZPtnTq8VLUIUrBmkJC4zV1eC3qxi8pNBGJq+gvQ8v7zmJCjenRxkPuHReJLmkZT
ex3Wvvqbs+xqncWUAAWhJ361kHmkGJz+xFeUrRJ3DDp4tXQpzuZI20Lmq0saOkx/
RTnjAwvcX66eJrOoXI7KSlUagg6IG3TCVeRrOoIxXSa2KU25+wE=
=4vzQ
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Enabling http to https redirects for tomcat.apache.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Mark,
On 2/25/20 14:34, Mark Thomas wrote:
> On 25/02/2020 15:53, Felix Schumacher wrote:
>> Hi all,
>>
>> as more and more browsers are marking http as unsecure, we
>> should redirect all http requests to tomcat.apache.org to https.
>
> I really don't like this.
>
> I'm happy to support https for those people that want to use it but
> I see no need to require https for everybody for
> tomcat.apache.org.
>
> We should not be dictating to our users what security / privacy /
> caching / performance / etc. trade-offs are appropriate for them.
> We should support as many options as possible and let our users
> decided.
>
> I'm not quite -1 on this but I am close.
https://www.troyhunt.com/heres-why-your-static-website-needs-https/
- -chris
>> We can enable that by adding a rewrite rule to the .htaccess file
>> in the xdocs folder of our site repo.
>>
>> For JMeter we used the following fragment:
>>
>> RewriteEngine On
>>
>> # Redirect http to https # From Cordova PMC Member raphinesse #
>> https://s.apache.org/An8s
>>
>> # If we receive a forwarded http request from a proxy...
>> RewriteCond %{HTTP:X-Forwarded-Proto} =http [OR]
>>
>> # ...or just a plain old http request directly from the client
>> RewriteCond %{HTTP:X-Forwarded-Proto} ="" RewriteCond %{HTTPS}
>> !=on
>>
>> # Redirect to https version RewriteRule ^
>> https://%{HTTP_HOST}%{REQUEST_URI} [L]
>>
>> Anything against adding this to our .htaccess file?
>
>
>>
>> Felix
>>
>>
>> -
>>
>>
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
>
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5Vh3kACgkQHPApP6U8
pFgktRAAh34aN6pyZaMz2n/Bha81mbNjglrMcxkrEswqMCJM0/8Wbw8hgB+3JArQ
dfIYipA2KTtjEzRgGU74qGcvDnEpTcoWi+csvmU7nwExt2RClmMF/5KqvYi67QZZ
l0klgHATRjNPrPOkvZy8Op0fFS6/bnXzvESS/lusz6aLrqiXRxqDVyDgCiBxzrXr
m2VLdE/re1CyFzcNcNmHUAUNs37/0E2WB1d11OvblE3I9eRb1Vk+FHtsfkDmNEoX
0RE7sQlr12ElMQ3OYOHsErxrxgTD2J/+CXqbMra8sWQ4pgEZPMX/7k5bGyr3IpTh
sOiSR9KNShfJtjKXp2ngJJKbEgDpr4SOYAh5FwGyUKmxflw+nqbc/Zd5bA6H4GNH
27p0Ec2ArCSDM4vlIeYbtBo8xqAuq2ArVywyUVrWog4mk0Hita2OHnp6Y8CFcZwR
hVv2fuFzd9/zueHG1TvLpB86Mr40MS8j2OelAACixECkV8CAo+64hXLLELgl5XXd
wu6J60tKXXgTlcQcoa0h9nm27D3YKLBUnH6CuOxjUGxVHwH6Bmc2OdR5l+FRNHkl
35MEkqCXThXc62/G/sBW4/Kd7bF/A0wYXT8dKYb6p/s4GXZ9yM3sgjQr9N/b0sP0
RukK+6i6vgtsY7xf8eSVtUAgYNyV4ndxpQyYBiyRHVh06nfGgHQ=
=qS1l
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Enabling http to https redirects for tomcat.apache.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Felix,
On 2/25/20 11:10, Felix Schumacher wrote:
>
> Am 25.02.20 um 16:57 schrieb Christopher Schultz:
>> Felix,
>>
>> On 2/25/20 10:53, Felix Schumacher wrote:
>>> as more and more browsers are marking http as unsecure, we
>>> should redirect all http requests to tomcat.apache.org to
>>> https.
>>
>>> We can enable that by adding a rewrite rule to the .htaccess
>>> file in the xdocs folder of our site repo.
>>
>>> For JMeter we used the following fragment:
>>
>>> RewriteEngine On
>>
>>> # Redirect http to https # From Cordova PMC Member raphinesse
>>> # https://s.apache.org/An8s
>>
>>> # If we receive a forwarded http request from a proxy...
>>> RewriteCond %{HTTP:X-Forwarded-Proto} =http [OR]
>>
>>> # ...or just a plain old http request directly from the client
>>> RewriteCond %{HTTP:X-Forwarded-Proto} ="" RewriteCond %{HTTPS}
>>> !=on
>>
>>> # Redirect to https version RewriteRule ^
>>> https://%{HTTP_HOST}%{REQUEST_URI} [L]
>>
>> Query string? Or is that part of REQUEST_URI?
>
> If I read the documentation for REQUEST_URI right, that
> QUERY_STRING is not part of it.
>
> Hm, another way to do this would probably be
>
> RewriteRule ^/?(.*) https://%{HTTP_HOST}/$1 [L]
>
> Taken partly from
> https://cwiki.apache.org/confluence/display/HTTPD/RewriteHTTPToHTTPS
>
> Do you think that would be better?
Yes. I don't think we have any pages which actually require a
query-string, but it's better to do it properly from the outset rather
than patching it ad-hoc whenever certain things don't work.
- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5VhyMACgkQHPApP6U8
pFiSGw//VRNgOb8BgzKQ/tXdyhwL5K1Qgp1mhD+Pel99dcctI2ECRXZB862LExgw
QBqDPHZjjUpY06rVznw6U1Sz4QEpmCwk/uNYwR7YplQih11GJRyNGDojxl8IWVoL
9PcIiJ5V/hl3PkTNl4/7RUttg1PIefVkLFLh00yiDJJMW0H5cnwc26HAgkO6s5dy
0mjNGShayTS8cpI1bkEqxiGMYKHoaK+XkBFWwSOCxCXbErpMxLZwfCislFyIPO6u
oxIsOrnHXiWy69rHcyCtAl5YoxykNXKzEw9Ru23Ru8GeZVEM5crRwmLjfvVhXsbq
lnIW8nsGgJE2UXscj8hDorvJNx+CJvgK3NjNeOoSMcE9vOfUpzjoQIJHSvxqqEkR
dVXHYi4ixtb0eSzdgdxEYlo9MmVFT0BtsHs186pAwITSvwQ3TY9K75DymtO0WT9U
YjXJ8NpcD8enG07TtzQ0laL9sW8YKhHLpxbhXPm2rUN9lZwNyN9L76GZIuCjB3IC
McwAi4f/I32ijDN8dO4g8c5akoGmD3C1q4lhfqd/RU6eGKFsIJJvByN3AU/bToVg
joSd1tYCD+rXxIahpsIKphxUSY6JJHEaOBooHWU1OyNkUg8qErhnV6sLH+yS1LlT
5jnpgxu+YPuXMMyreMyXhaX6ZY7he2jo2ntMGu7sFCEuTBPlJ4Y=
=7Gng
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
buildbot failure in on tomcat-7-trunk
The Buildbot has detected a new failure on builder tomcat-7-trunk while building tomcat. Full details are available at: https://ci.apache.org/builders/tomcat-7-trunk/builds/1608 Buildbot URL: https://ci.apache.org/ Buildslave for this Build: asf946_ubuntu Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-7-commit' triggered this build Build Source Stamp: [branch 7.0.x] 542e47cbd861fb26b703e1a2b5c10ea4824c3f5a Blamelist: Mark Thomas BUILD FAILED: failed compile Sincerely, -The Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
buildbot exception in on tomcat-85-trunk
The Buildbot has detected a build exception on builder tomcat-85-trunk while building tomcat. Full details are available at: https://ci.apache.org/builders/tomcat-85-trunk/builds/2179 Buildbot URL: https://ci.apache.org/ Buildslave for this Build: asf946_ubuntu Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-85-commit' triggered this build Build Source Stamp: [branch 8.5.x] 19be442046f3fb4fcf18315d460a17bd433bb9f5 Blamelist: Mark Thomas BUILD FAILED: exception compile upload_2 Sincerely, -The Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 64166] RequestDumperFilter duplicates headers
https://bz.apache.org/bugzilla/show_bug.cgi?id=64166 Mark Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Mark Thomas --- Fixed in: - master for 10.0.0-M2 onwards - 9.0.x for 9.0.32 onwards - 8.5.x for 8.5.52 onwards - 7.0.x for 7.0.101 onwards -- 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
[tomcat] branch 7.0.x updated: BZ 64166. HttpServletResponse.getHeaderNames() now returns unique names
This is an automated email from the ASF dual-hosted git repository.
markt 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 542e47c BZ 64166. HttpServletResponse.getHeaderNames() now returns
unique names
542e47c is described below
commit 542e47cbd861fb26b703e1a2b5c10ea4824c3f5a
Author: Mark Thomas
AuthorDate: Tue Feb 25 14:16:44 2020 +
BZ 64166. HttpServletResponse.getHeaderNames() now returns unique names
https://bz.apache.org/bugzilla/show_bug.cgi?id=64166
---
java/org/apache/catalina/connector/Response.java | 7 ---
webapps/docs/changelog.xml | 4
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/java/org/apache/catalina/connector/Response.java
b/java/org/apache/catalina/connector/Response.java
index 61ecf0e..072485c 100644
--- a/java/org/apache/catalina/connector/Response.java
+++ b/java/org/apache/catalina/connector/Response.java
@@ -29,8 +29,10 @@ import java.util.ArrayList;
import java.util.Arrays;
import java.util.Collection;
import java.util.Enumeration;
+import java.util.LinkedHashSet;
import java.util.List;
import java.util.Locale;
+import java.util.Set;
import javax.servlet.ServletOutputStream;
import javax.servlet.SessionTrackingMode;
@@ -915,9 +917,8 @@ public class Response implements HttpServletResponse {
@Override
public Collection getHeaders(String name) {
-Enumeration enumeration =
-getCoyoteResponse().getMimeHeaders().values(name);
-List result = new ArrayList();
+Enumeration enumeration =
getCoyoteResponse().getMimeHeaders().values(name);
+Set result = new LinkedHashSet();
while (enumeration.hasMoreElements()) {
result.add(enumeration.nextElement());
}
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index e2a2cd4..9896a36 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -72,6 +72,10 @@
HttpServlet is relied upon to generate the HEAD response
and the GET response uses chunking. (markt)
+
+64166: Ensure that the names returned by
+HttpServletResponse.getHeaderNames() are unique. (markt)
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 8.5.x updated: BZ 64166. HttpServletResponse.getHeaderNames() now returns unique names
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 8.5.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/8.5.x by this push:
new 19be442 BZ 64166. HttpServletResponse.getHeaderNames() now returns
unique names
19be442 is described below
commit 19be442046f3fb4fcf18315d460a17bd433bb9f5
Author: Mark Thomas
AuthorDate: Tue Feb 25 14:16:44 2020 +
BZ 64166. HttpServletResponse.getHeaderNames() now returns unique names
https://bz.apache.org/bugzilla/show_bug.cgi?id=64166
---
java/org/apache/catalina/connector/Response.java | 7 ---
webapps/docs/changelog.xml | 4
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/java/org/apache/catalina/connector/Response.java
b/java/org/apache/catalina/connector/Response.java
index 47d3904..97c18a5 100644
--- a/java/org/apache/catalina/connector/Response.java
+++ b/java/org/apache/catalina/connector/Response.java
@@ -30,8 +30,10 @@ import java.util.ArrayList;
import java.util.Arrays;
import java.util.Collection;
import java.util.Enumeration;
+import java.util.LinkedHashSet;
import java.util.List;
import java.util.Locale;
+import java.util.Set;
import javax.servlet.ServletOutputStream;
import javax.servlet.ServletResponse;
@@ -882,9 +884,8 @@ public class Response implements HttpServletResponse {
@Override
public Collection getHeaders(String name) {
-Enumeration enumeration =
-getCoyoteResponse().getMimeHeaders().values(name);
-List result = new ArrayList<>();
+Enumeration enumeration =
getCoyoteResponse().getMimeHeaders().values(name);
+Set result = new LinkedHashSet<>();
while (enumeration.hasMoreElements()) {
result.add(enumeration.nextElement());
}
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 32e074f..afa42bb 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -70,6 +70,10 @@
Missing store config attributes for Resources elements. (remm)
+
+64166: Ensure that the names returned by
+HttpServletResponse.getHeaderNames() are unique. (markt)
+
-
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: BZ 64166. HttpServletResponse.getHeaderNames() now returns unique names
This is an automated email from the ASF dual-hosted git repository.
markt 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 90f5f2f BZ 64166. HttpServletResponse.getHeaderNames() now returns
unique names
90f5f2f is described below
commit 90f5f2f8528612bb7f07c9fe403c5218c050bec8
Author: Mark Thomas
AuthorDate: Tue Feb 25 14:16:44 2020 +
BZ 64166. HttpServletResponse.getHeaderNames() now returns unique names
https://bz.apache.org/bugzilla/show_bug.cgi?id=64166
---
java/org/apache/catalina/connector/Response.java | 7 ---
webapps/docs/changelog.xml | 4
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/java/org/apache/catalina/connector/Response.java
b/java/org/apache/catalina/connector/Response.java
index 37515ed..3900c30 100644
--- a/java/org/apache/catalina/connector/Response.java
+++ b/java/org/apache/catalina/connector/Response.java
@@ -31,9 +31,11 @@ import java.util.ArrayList;
import java.util.Arrays;
import java.util.Collection;
import java.util.Enumeration;
+import java.util.LinkedHashSet;
import java.util.List;
import java.util.Locale;
import java.util.Map;
+import java.util.Set;
import java.util.function.Supplier;
import javax.servlet.ServletOutputStream;
@@ -878,9 +880,8 @@ public class Response implements HttpServletResponse {
@Override
public Collection getHeaders(String name) {
-Enumeration enumeration =
-getCoyoteResponse().getMimeHeaders().values(name);
-List result = new ArrayList<>();
+Enumeration enumeration =
getCoyoteResponse().getMimeHeaders().values(name);
+Set result = new LinkedHashSet<>();
while (enumeration.hasMoreElements()) {
result.add(enumeration.nextElement());
}
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 45eb1b1..1c9ad17 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -64,6 +64,10 @@
Missing store config attributes for Resources elements. (remm)
+
+64166: Ensure that the names returned by
+HttpServletResponse.getHeaderNames() are unique. (markt)
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch master updated: BZ 64166. HttpServletResponse.getHeaderNames() now returns unique names
This is an automated email from the ASF dual-hosted git repository.
markt 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 e9ee933 BZ 64166. HttpServletResponse.getHeaderNames() now returns
unique names
e9ee933 is described below
commit e9ee9338f3b4c694b7fd90b69ed468dbdeff5a76
Author: Mark Thomas
AuthorDate: Tue Feb 25 14:16:44 2020 +
BZ 64166. HttpServletResponse.getHeaderNames() now returns unique names
https://bz.apache.org/bugzilla/show_bug.cgi?id=64166
---
java/org/apache/catalina/connector/Response.java | 7 ---
webapps/docs/changelog.xml | 4
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/java/org/apache/catalina/connector/Response.java
b/java/org/apache/catalina/connector/Response.java
index fce5570..9ec0b5d 100644
--- a/java/org/apache/catalina/connector/Response.java
+++ b/java/org/apache/catalina/connector/Response.java
@@ -30,9 +30,11 @@ import java.util.ArrayList;
import java.util.Arrays;
import java.util.Collection;
import java.util.Enumeration;
+import java.util.LinkedHashSet;
import java.util.List;
import java.util.Locale;
import java.util.Map;
+import java.util.Set;
import java.util.function.Supplier;
import jakarta.servlet.ServletOutputStream;
@@ -868,9 +870,8 @@ public class Response implements HttpServletResponse {
@Override
public Collection getHeaders(String name) {
-Enumeration enumeration =
-getCoyoteResponse().getMimeHeaders().values(name);
-List result = new ArrayList<>();
+Enumeration enumeration =
getCoyoteResponse().getMimeHeaders().values(name);
+Set result = new LinkedHashSet<>();
while (enumeration.hasMoreElements()) {
result.add(enumeration.nextElement());
}
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 5632768..dd93f38 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -59,6 +59,10 @@
Add extension point to DeltaSession to improve subclassing.
Patch provided by ThStock. (schultz)
+
+64166: Ensure that the names returned by
+HttpServletResponse.getHeaderNames() are unique. (markt)
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Enabling http to https redirects for tomcat.apache.org
On 25/02/2020 15:53, Felix Schumacher wrote:
> Hi all,
>
> as more and more browsers are marking http as unsecure, we should
> redirect all http requests to tomcat.apache.org to https.
I really don't like this.
I'm happy to support https for those people that want to use it but I
see no need to require https for everybody for tomcat.apache.org.
We should not be dictating to our users what security / privacy /
caching / performance / etc. trade-offs are appropriate for them. We
should support as many options as possible and let our users decided.
I'm not quite -1 on this but I am close.
Mark
> We can enable that by adding a rewrite rule to the .htaccess file in the
> xdocs folder of our site repo.
>
> For JMeter we used the following fragment:
>
> RewriteEngine On
>
> # Redirect http to https
> # From Cordova PMC Member raphinesse
> # https://s.apache.org/An8s
>
> # If we receive a forwarded http request from a proxy...
> RewriteCond %{HTTP:X-Forwarded-Proto} =http [OR]
>
> # ...or just a plain old http request directly from the client
> RewriteCond %{HTTP:X-Forwarded-Proto} =""
> RewriteCond %{HTTPS} !=on
>
> # Redirect to https version
> RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L]
>
> Anything against adding this to our .htaccess file?
>
> Felix
>
>
> -
> 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
svn commit: r1874523 - /tomcat/site/trunk/xdocs/stylesheets/tomcat-site.xsl
Author: fschumacher Date: Tue Feb 25 19:27:27 2020 New Revision: 1874523 URL: http://svn.apache.org/viewvc?rev=1874523&view=rev Log: Substring starts on index 1 Take Konstantins note into account and let the xpath function substring start with the correct index of "1". Now we can use a shorter substring, to get the same results, so use 9 instead of 8 for the length. Modified: tomcat/site/trunk/xdocs/stylesheets/tomcat-site.xsl Modified: tomcat/site/trunk/xdocs/stylesheets/tomcat-site.xsl URL: http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/stylesheets/tomcat-site.xsl?rev=1874523&r1=1874522&r2=1874523&view=diff == --- tomcat/site/trunk/xdocs/stylesheets/tomcat-site.xsl (original) +++ tomcat/site/trunk/xdocs/stylesheets/tomcat-site.xsl Tue Feb 25 19:27:27 2020 @@ -359,7 +359,7 @@ - + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1874468 - in /tomcat/site/trunk: docs/security-8.html xdocs/security-8.xml
Am 25. Februar 2020 19:22:39 MEZ schrieb Konstantin Kolinko : >вт, 25 февр. 2020 г. в 18:26, Felix Schumacher >: >> >> >> Am 25.02.20 um 10:22 schrieb Felix Schumacher: >> >> Index: xdocs/stylesheets/tomcat-site.xsl >> === >> --- xdocs/stylesheets/tomcat-site.xsl(Revision 1874497) >> +++ xdocs/stylesheets/tomcat-site.xsl(Arbeitskopie) >> @@ -359,7 +359,7 @@ >> >> >>> select="$hashlink"/> >> - >> + >> >> >> >> >> would take care of using the substring for the text. > >The XPath documentation for substring function [1] says that character >positions in that function start with 1 (but any value less than 1 is >treated as 1, so 0 works as well). Good to know. Hadn't checked the docs on this, as it did what I wanted. Will correct it, if course. Regards Felix > >[1] https://www.w3.org/TR/1999/REC-xpath-19991116/#function-substring > >Best regards, >Konstantin Kolinko > >- >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: svn commit: r1874468 - in /tomcat/site/trunk: docs/security-8.html xdocs/security-8.xml
вт, 25 февр. 2020 г. в 18:26, Felix Schumacher : > > > Am 25.02.20 um 10:22 schrieb Felix Schumacher: > > Index: xdocs/stylesheets/tomcat-site.xsl > === > --- xdocs/stylesheets/tomcat-site.xsl(Revision 1874497) > +++ xdocs/stylesheets/tomcat-site.xsl(Arbeitskopie) > @@ -359,7 +359,7 @@ > > > select="$hashlink"/> > - > + > > > > > would take care of using the substring for the text. The XPath documentation for substring function [1] says that character positions in that function start with 1 (but any value less than 1 is treated as 1, so 0 works as well). [1] https://www.w3.org/TR/1999/REC-xpath-19991116/#function-substring Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Enabling http to https redirects for tomcat.apache.org
Am 25.02.20 um 16:57 schrieb Christopher Schultz:
> Felix,
>
> On 2/25/20 10:53, Felix Schumacher wrote:
> > as more and more browsers are marking http as unsecure, we should
> > redirect all http requests to tomcat.apache.org to https.
>
> > We can enable that by adding a rewrite rule to the .htaccess file
> > in the xdocs folder of our site repo.
>
> > For JMeter we used the following fragment:
>
> > RewriteEngine On
>
> > # Redirect http to https # From Cordova PMC Member raphinesse #
> > https://s.apache.org/An8s
>
> > # If we receive a forwarded http request from a proxy...
> > RewriteCond %{HTTP:X-Forwarded-Proto} =http [OR]
>
> > # ...or just a plain old http request directly from the client
> > RewriteCond %{HTTP:X-Forwarded-Proto} ="" RewriteCond %{HTTPS}
> > !=on
>
> > # Redirect to https version RewriteRule ^
> > https://%{HTTP_HOST}%{REQUEST_URI} [L]
>
> Query string? Or is that part of REQUEST_URI?
If I read the documentation for REQUEST_URI right, that QUERY_STRING is
not part of it.
Hm, another way to do this would probably be
RewriteRule ^/?(.*) https://%{HTTP_HOST}/$1 [L]
Taken partly from
https://cwiki.apache.org/confluence/display/HTTPD/RewriteHTTPToHTTPS
Do you think that would be better?
Felix
>
> > Anything against adding this to our .htaccess file?
>
> +1
>
> -chris
>
> -
> 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
[Bug 64155] Tomcat 7 Performance: acceptor thread bottleneck at getPoolSize() located at TaskQueue offer function
https://bz.apache.org/bugzilla/show_bug.cgi?id=64155 Mark Thomas changed: What|Removed |Added Status|REOPENED|NEEDINFO --- Comment #6 from Mark Thomas --- I've built various test cases, some load testing Tomcat, some testing ThreadPoolExecutor directly and I am unable to reproduce any results that show contention on getPoolSize(). Please provide the simplest possible test case (i.e. one that tests ThreadPoolExecutor directly) that demonstrates decreasing performance with increasing concurrency. -- 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: Enabling http to https redirects for tomcat.apache.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Felix,
On 2/25/20 10:53, Felix Schumacher wrote:
> as more and more browsers are marking http as unsecure, we should
> redirect all http requests to tomcat.apache.org to https.
>
> We can enable that by adding a rewrite rule to the .htaccess file
> in the xdocs folder of our site repo.
>
> For JMeter we used the following fragment:
>
> RewriteEngine On
>
> # Redirect http to https # From Cordova PMC Member raphinesse #
> https://s.apache.org/An8s
>
> # If we receive a forwarded http request from a proxy...
> RewriteCond %{HTTP:X-Forwarded-Proto} =http [OR]
>
> # ...or just a plain old http request directly from the client
> RewriteCond %{HTTP:X-Forwarded-Proto} ="" RewriteCond %{HTTPS}
> !=on
>
> # Redirect to https version RewriteRule ^
> https://%{HTTP_HOST}%{REQUEST_URI} [L]
Query string? Or is that part of REQUEST_URI?
> Anything against adding this to our .htaccess file?
+1
- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5VQ90ACgkQHPApP6U8
pFiTFhAAtNxy3YoFbWNNRwEOWuRIrakfFaxHYpBz0sVK0B1s/hJtI1XW4V4pMSh8
4Vbwcnkoykt1F4DpZ8x8eDlWwbdhuPmKPwSsGChf2uws/j3Sc8rCpA0Tsb21FtvD
hKmA9T+R2/HAM+0eSbWnWE906/BAhGblZrhhYGumAs62I219v5FSBsI3RYSoEEkL
Fsn76Wg1z98boii1UERn6ZTJQ/B0TDo02XVjkEmNJRUbL/IPhv0issl7ENVI5pbo
EfagIbooXuS9aNIc00Z2+dF2qQL+Ta8Bd2iSpakpeklFXBPpy0DwuZPX7ubH0Jbk
3W+P94Z/L3Eur+YFKr+6E3DGP51kZLjArvA1lcKk0q7PtiJAmcUX0UTCIiVfD0o/
3zfqibHtBCqjoB/Vkjm4dH7sxURujQO9VtcVNT9bZ8weSiMCblISubd65lAnFEyr
H87N55AcqXgAYYfsJd1aMwKYnCt2lY5X7CqBlyF5CajQrB9KW/IgQd9BVSA3vGlw
dORLhKumvm+Nlo1Jk3+1Crd5g6dCn2lbjMmeoD6RhqYmZwuSQWA51GEz7n2GVlKb
Xs/VgyeNyFUBno7/VN5izniMsNNMav/ucCC9jPzWB8vqbo6RFNL0kIgsDE8H1ySV
AKk2T+lDfRKq2KCkU6+ObNUVNy5i+Nr2ZRdm9NfQASDzfneNBJ0=
=XSel
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Enabling http to https redirects for tomcat.apache.org
Hi all,
as more and more browsers are marking http as unsecure, we should
redirect all http requests to tomcat.apache.org to https.
We can enable that by adding a rewrite rule to the .htaccess file in the
xdocs folder of our site repo.
For JMeter we used the following fragment:
RewriteEngine On
# Redirect http to https
# From Cordova PMC Member raphinesse
# https://s.apache.org/An8s
# If we receive a forwarded http request from a proxy...
RewriteCond %{HTTP:X-Forwarded-Proto} =http [OR]
# ...or just a plain old http request directly from the client
RewriteCond %{HTTP:X-Forwarded-Proto} =""
RewriteCond %{HTTPS} !=on
# Redirect to https version
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L]
Anything against adding this to our .htaccess file?
Felix
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1874468 - in /tomcat/site/trunk: docs/security-8.html xdocs/security-8.xml
Am 25.02.20 um 16:27 schrieb Felix Schumacher: > Am 25.02.20 um 16:24 schrieb Christopher Schultz: >> Felix, >> >> On 2/25/20 04:22, Felix Schumacher wrote: >>> Am 24.02.2020 22:13, schrieb Christopher Schultz: Mark, >>> On 2/24/20 15:46, Mark Thomas wrote: >> On 24/02/2020 20:31, Christopher Schultz wrote: >>> Mark, >>> Why not use the full commit id instead of a prefix? >>> Couldn't some future commit conflict with some arbitrary >>> prefix? Or do I not know what the hell I'm talking about? >> No, you are spot on. The reason I used the prefix is that I >> was transcribing the commit IDs by hand so the prefixes were >> easier. We probably should use the full ID or at least a >> longer prefix. >>> I wonder if we could script this: grab a prefix, find the (one and >>> only one) commit in the repo and expand it. If there is a conflict >>> (or more than one match), emit an error and continue without >>> changing the commit id. >>> When I do this kind of thing for $work, I like to write scripts >>> that emit sed scripts. So you process e.g. security-8.html as >>> input, but emit something like this as output: >>> s/(\b)69c5608(\b)/\169c56080fb3355507e1b55d014ec0ee6767a6150\2/g >>> ... >>> You get a script that can be inspected, re-used and, even better, >>> it doesn't directly modify the input files. So you can even do >>> something like this: >>> $ expand-git-commit-ids.pl security-*.xml > expand.sed >>> $ sed -i .bak -f expand.sed security-*.xml >>> And then if you find other files where the same kind of thing needs >>> to be done, you can re-use the expand.sed script, or even (pun >>> intended) expand the sed script if necessary. I would use the full hash in the xml and use a substring-function in the xsl to shorten the hash for readability. No need for sed here :) >> This was to initially fetch the full hashes. In the XML, now, they are >> already shortened. > See my other mail :) Changed with r1874502. Felix >> -chris >> >> - >> 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
svn commit: r1874502 - in /tomcat/site/trunk: docs/security-7.html docs/security-8.html docs/security-9.html xdocs/security-7.xml xdocs/security-8.xml xdocs/security-9.xml xdocs/stylesheets/tomcat-sit
Author: fschumacher Date: Tue Feb 25 15:46:38 2020 New Revision: 1874502 URL: http://svn.apache.org/viewvc?rev=1874502&view=rev Log: Use full hash for git links and shorten the text of the link on the fly while generating the docs with xslt. The reconstruction of the long hashes were done with the following shell/perl/sed constructs: sed -e "$(perl -M5.020 -ne 'say $1 if /hashlink hash="(\w+)"/' ../tomcat-site-trunk/xdocs/security-7.xml \ | while read i do git log --pretty="s/\\b$i\\b/%H/g;" -l 1 $i^1..$i | cat done)" -i ../tomcat-site-trunk/xdocs/security-7.xml sed -i -e 's/\(hashlink hash="\w*"\)>\w*<\/hashlink/\1\//' ../tomcat-site-trunk/xdocs/security-7.xml That was done for the three security files for tomcat 7, 8 and 9. Modified: tomcat/site/trunk/docs/security-7.html tomcat/site/trunk/docs/security-8.html tomcat/site/trunk/docs/security-9.html tomcat/site/trunk/xdocs/security-7.xml tomcat/site/trunk/xdocs/security-8.xml tomcat/site/trunk/xdocs/security-9.xml tomcat/site/trunk/xdocs/stylesheets/tomcat-site.xsl Modified: tomcat/site/trunk/docs/security-7.html URL: http://svn.apache.org/viewvc/tomcat/site/trunk/docs/security-7.html?rev=1874502&r1=1874501&r2=1874502&view=diff == --- tomcat/site/trunk/docs/security-7.html (original) +++ tomcat/site/trunk/docs/security-7.html Tue Feb 25 15:46:38 2020 @@ -82,10 +82,10 @@ will need to make small changes to their configurations as a result. This was fixed with commits - https://github.com/apache/tomcat/commit/0d633e7";>0d633e7, - https://github.com/apache/tomcat/commit/40d5d93";>40d5d93, - https://github.com/apache/tomcat/commit/b99fba5";>b99fba5 and - https://github.com/apache/tomcat/commit/f7180ba";>f7180ba. + https://github.com/apache/tomcat/commit/0d633e72ebc7b3c242d0081c23bba5e4dacd9b72";>0d633e72, + https://github.com/apache/tomcat/commit/40d5d93bd284033cf4a1f77f5492444f83d803e2";>40d5d93b, + https://github.com/apache/tomcat/commit/b99fba5bd796d876ea536e83299603443842feba";>b99fba5b and + https://github.com/apache/tomcat/commit/f7180bafc74cb1250c9e9287b68a230f0e1f4645";>f7180baf. This issue was reported to the Apache Tomcat Security Team on 3 January 2020. The issue was made public on 24 February 2020. @@ -103,7 +103,7 @@ considered unlikely. This was fixed with commit - https://github.com/apache/tomcat/commit/702bf15";>702bf15. + https://github.com/apache/tomcat/commit/702bf15bea292915684d931526d95d4990b2e73d";>702bf15b. This issue was reported to the Apache Tomcat Security Team by @ZeddYu on 25 December 2019. The issue was made public on 24 @@ -122,7 +122,7 @@ considered unlikely. This was fixed with commit - https://github.com/apache/tomcat/commit/b191a0d";>b191a0d. + https://github.com/apache/tomcat/commit/b191a0d9cf06f4e04257c221bfe41d2b108a9cc8";>b191a0d9. This issue was reported to the Apache Tomcat Security Team by @ZeddYu on 12 December 2019. The issue was made public on 24 @@ -142,7 +142,7 @@ vulnerability. This was fixed with commit - https://github.com/apache/tomcat/commit/ab72a10";>ab72a10. + https://github.com/apache/tomcat/commit/ab72a106fe5d992abddda954e30849d7cf8cc583";>ab72a106. This issue was reported to the Apache Tomcat Security Team by William Marlow (IBM) on 19 November 2019. The issue was made public on 18 @@ -172,7 +172,7 @@ vulnerability that enables this issue to be exploited remotely. This was fixed with commit - https://github.com/apache/tomcat/commit/bef3f40";>bef3f40. + https://github.com/apache/tomcat/commit/bef3f40400243348d12f4abfe9b413f43897c02b";>bef3f404. This issue was reported to the Apache Tomcat Security Team by An Trinh of Viettel Cyber Security on 10 October 2019. The issue was made public on 18 @@ -195,7 +195,7 @@ blog. This was fixed with commit - https://github.com/apache/tomcat/commit/7f0221b";>7f0221b. + https://github.com/apache/tomcat/commit/7f0221b904956359f2d739aa3a2b53f8c12ed8c7";>7f0221b9. This issue was identified by Nightwatch Cybersecurity Research and reported to the Apache Tomcat security team via the bug bounty program @@ -213,7 +213,7 @@ in a production website. This was fixed with commit - https://github.com/apache/tomcat/commit/44ec74c";>44ec74c. + https://github.com/apache/tomcat/commit/44ec74c44dcd05cd7e90967c04d40b51440ecd7e";>44ec74c4. This issue was identified by Nightwatch Cybersecurity Research and reported to the Apache Tomcat security team via the bug bounty program Modified: tomcat/site/trunk/docs/security-8.html URL: http://svn.apache.org/viewvc/tomcat/site/trunk/docs/security-8.html?rev=1874502&r1=1874501&r2=1874502&view=diff
[tomcat] branch 9.0.x updated: Update to CXF 3.3.5
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 f5c5614 Update to CXF 3.3.5 f5c5614 is described below commit f5c5614d011e239c665b46bf4a23b4e487c647a0 Author: remm AuthorDate: Tue Feb 25 16:30:50 2020 +0100 Update to CXF 3.3.5 --- modules/cxf/pom.xml| 8 modules/owb/pom.xml| 2 +- webapps/docs/changelog.xml | 3 +++ 3 files changed, 8 insertions(+), 5 deletions(-) diff --git a/modules/cxf/pom.xml b/modules/cxf/pom.xml index 23eb7e9..7d86fa1 100644 --- a/modules/cxf/pom.xml +++ b/modules/cxf/pom.xml @@ -29,14 +29,14 @@ Apache CXF for Apache Tomcat CDI Apache CXF packaged for Apache Tomcat CDI -3.3.4 +3.3.5 jar 1.0.1 1.1.4 1.0 -1.2.1 +1.2.3 @@ -96,7 +96,7 @@ org.apache.maven.plugins maven-compiler-plugin -3.5.1 +3.8.1 1.8 1.8 @@ -105,7 +105,7 @@ org.apache.maven.plugins maven-shade-plugin -3.0.0 +3.2.1 package diff --git a/modules/owb/pom.xml b/modules/owb/pom.xml index 996d4e8..19060af 100644 --- a/modules/owb/pom.xml +++ b/modules/owb/pom.xml @@ -86,7 +86,7 @@ org.apache.maven.plugins maven-compiler-plugin -3.5.1 +3.8.1 1.8 1.8 diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml index cc261a6..45eb1b1 100644 --- a/webapps/docs/changelog.xml +++ b/webapps/docs/changelog.xml @@ -125,6 +125,9 @@ Update the OWB module to Apache OpenWebBeans 2.0.15. (remm) + +Update the CXF module to Apache CXF 3.3.5. (remm) + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1874468 - in /tomcat/site/trunk: docs/security-8.html xdocs/security-8.xml
Am 25.02.20 um 16:24 schrieb Christopher Schultz: > Felix, > > On 2/25/20 04:22, Felix Schumacher wrote: > > Am 24.02.2020 22:13, schrieb Christopher Schultz: Mark, > > > On 2/24/20 15:46, Mark Thomas wrote: > On 24/02/2020 20:31, Christopher Schultz wrote: > > Mark, > > > Why not use the full commit id instead of a prefix? > > Couldn't some future commit conflict with some arbitrary > > prefix? Or do I not know what the hell I'm talking about? > > No, you are spot on. The reason I used the prefix is that I > was transcribing the commit IDs by hand so the prefixes were > easier. We probably should use the full ID or at least a > longer prefix. > > > I wonder if we could script this: grab a prefix, find the (one and > > only one) commit in the repo and expand it. If there is a conflict > > (or more than one match), emit an error and continue without > > changing the commit id. > > > When I do this kind of thing for $work, I like to write scripts > > that emit sed scripts. So you process e.g. security-8.html as > > input, but emit something like this as output: > > > s/(\b)69c5608(\b)/\169c56080fb3355507e1b55d014ec0ee6767a6150\2/g > > ... > > > You get a script that can be inspected, re-used and, even better, > > it doesn't directly modify the input files. So you can even do > > something like this: > > > $ expand-git-commit-ids.pl security-*.xml > expand.sed > > > $ sed -i .bak -f expand.sed security-*.xml > > > And then if you find other files where the same kind of thing needs > > to be done, you can re-use the expand.sed script, or even (pun > > intended) expand the sed script if necessary. > > >> I would use the full hash in the xml and use a substring-function > >> in the xsl to shorten the hash for readability. > > >> No need for sed here :) > > This was to initially fetch the full hashes. In the XML, now, they are > already shortened. See my other mail :) > > -chris > > - > 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
[tomcat] branch master updated: Update CDI and CXF support
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 8c60d0e Update CDI and CXF support 8c60d0e is described below commit 8c60d0e573c5745ec8100a7814216b9b92596cfc Author: remm AuthorDate: Tue Feb 25 16:27:19 2020 +0100 Update CDI and CXF support Document support in Tomcat 10 after testing it, the tool works out. CDI shade JAR should be migrated to Jakarta by the tool. A MP webapp should go through the tool as a whole. --- modules/cxf/pom.xml| 10 ++ modules/owb/pom.xml| 6 +++--- webapps/docs/cdi.xml | 8 +++- webapps/docs/changelog.xml | 10 ++ 4 files changed, 26 insertions(+), 8 deletions(-) diff --git a/modules/cxf/pom.xml b/modules/cxf/pom.xml index 2015ff0..a8d54c5 100644 --- a/modules/cxf/pom.xml +++ b/modules/cxf/pom.xml @@ -29,14 +29,14 @@ Apache CXF for Apache Tomcat CDI Apache CXF packaged for Apache Tomcat CDI -3.3.4 +3.3.5 jar 1.0.1 1.1.4 1.0 -1.2.1 +1.2.3 @@ -96,7 +96,7 @@ org.apache.maven.plugins maven-compiler-plugin -3.5.1 +3.8.1 1.8 1.8 @@ -105,7 +105,7 @@ org.apache.maven.plugins maven-shade-plugin -3.0.0 +3.2.1 package @@ -127,6 +127,8 @@ jakarta.annotation:jakarta.annotation-api jakarta.el:* + javax.annotation:javax.annotation-api +javax.el:* javax.enterprise:cdi-api javax.inject:* javax.interceptor:* diff --git a/modules/owb/pom.xml b/modules/owb/pom.xml index 087bc07..4f512c1 100644 --- a/modules/owb/pom.xml +++ b/modules/owb/pom.xml @@ -29,14 +29,14 @@ Apache Tomcat CDI 2 support Apache Tomcat CDI 2 support using Apache OpenWebBeans -2.0.13 +2.0.15 jar 1.0 1.0 1.0.1 -9.0.30 +10.0.0-M1 @@ -86,7 +86,7 @@ org.apache.maven.plugins maven-compiler-plugin -3.5.1 +3.8.1 1.8 1.8 diff --git a/webapps/docs/cdi.xml b/webapps/docs/cdi.xml index e9cea2c..5c814c2 100644 --- a/webapps/docs/cdi.xml +++ b/webapps/docs/cdi.xml @@ -59,7 +59,8 @@ mvn clean && mvn package]]> The resulting JAR at target/tomcat-owb-x.y.z.jar (where x.y.z depends on the Apache OpenWebBeans version used during the build) -should then be placed into the lib folder of the Tomcat +should be processed by the Tomcat migration tool for Jakarta EE, and +then be placed into the lib folder of the Tomcat installation. CDI support can then be enabled for all webapps in the container by adding the following listener in server.xml nested inside the @@ -107,6 +108,11 @@ mvn clean && mvn package]]> desired root path where JAX-RS resources will be available. + +The webapp as a whole should be processed by the Tomcat migration tool for +Jakarta EE. + + diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml index cb4b51f..5632768 100644 --- a/webapps/docs/changelog.xml +++ b/webapps/docs/changelog.xml @@ -85,6 +85,16 @@ + + + +Update the OWB module to Apache OpenWebBeans 2.0.15. (remm) + + +Update the CXF module to Apache CXF 3.3.5. (remm) + + + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1874468 - in /tomcat/site/trunk: docs/security-8.html xdocs/security-8.xml
Am 25.02.20 um 10:22 schrieb Felix Schumacher: > Am 24.02.2020 22:13, schrieb Christopher Schultz: > Mark, > > On 2/24/20 15:46, Mark Thomas wrote: > >>> On 24/02/2020 20:31, Christopher Schultz wrote: > Mark, > >>> > Why not use the full commit id instead of a prefix? Couldn't > some future commit conflict with some arbitrary prefix? Or do I > not know what the hell I'm talking about? > >>> > >>> No, you are spot on. The reason I used the prefix is that I was > >>> transcribing the commit IDs by hand so the prefixes were easier. > >>> We probably should use the full ID or at least a longer prefix. > > I wonder if we could script this: grab a prefix, find the (one and > only one) commit in the repo and expand it. If there is a conflict (or > more than one match), emit an error and continue without changing the > commit id. > > When I do this kind of thing for $work, I like to write scripts that > emit sed scripts. So you process e.g. security-8.html as input, but > emit something like this as output: > > s/(\b)69c5608(\b)/\169c56080fb3355507e1b55d014ec0ee6767a6150\2/g > ... > > You get a script that can be inspected, re-used and, even better, it > doesn't directly modify the input files. So you can even do something > like this: > > $ expand-git-commit-ids.pl security-*.xml > expand.sed > > $ sed -i .bak -f expand.sed security-*.xml > > And then if you find other files where the same kind of thing needs to > be done, you can re-use the expand.sed script, or even (pun intended) > expand the sed script if necessary. > > > I would use the full hash in the xml and use a substring-function in > the xsl to shorten the hash for readability. > > > No need for sed here :) Now - that I re-read Chris answer - I see what he had in mind. I think we can combine the two things. First use a script to convert the hashes to the full version and second, adapt the xslt to emit a shorter version for the text of the link. perl -M5.020 -ne 'say $1 if /hashlink hash="(\w+)"/' ../tomcat-site-trunk/xdocs/security-9.xml | while read i; do git log --pretty="s/\\b$i\\b/%H/g" -l 1 $i^1..$i | cat; done That would generate the sed script for security-9.xml And Index: xdocs/stylesheets/tomcat-site.xsl === --- xdocs/stylesheets/tomcat-site.xsl (Revision 1874497) +++ xdocs/stylesheets/tomcat-site.xsl (Arbeitskopie) @@ -359,7 +359,7 @@ - + would take care of using the substring for the text. We would loose the ability to use arbitrary text in the link, but it wasn't used anyway. Felix > > > Felix > > > -chris >> >> - >> 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: svn commit: r1874468 - in /tomcat/site/trunk: docs/security-8.html xdocs/security-8.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Felix, On 2/25/20 04:22, Felix Schumacher wrote: > Am 24.02.2020 22:13, schrieb Christopher Schultz: Mark, > > On 2/24/20 15:46, Mark Thomas wrote: On 24/02/2020 20:31, Christopher Schultz wrote: > Mark, > Why not use the full commit id instead of a prefix? > Couldn't some future commit conflict with some arbitrary > prefix? Or do I not know what the hell I'm talking about? No, you are spot on. The reason I used the prefix is that I was transcribing the commit IDs by hand so the prefixes were easier. We probably should use the full ID or at least a longer prefix. > > I wonder if we could script this: grab a prefix, find the (one and > only one) commit in the repo and expand it. If there is a conflict > (or more than one match), emit an error and continue without > changing the commit id. > > When I do this kind of thing for $work, I like to write scripts > that emit sed scripts. So you process e.g. security-8.html as > input, but emit something like this as output: > > s/(\b)69c5608(\b)/\169c56080fb3355507e1b55d014ec0ee6767a6150\2/g > ... > > You get a script that can be inspected, re-used and, even better, > it doesn't directly modify the input files. So you can even do > something like this: > > $ expand-git-commit-ids.pl security-*.xml > expand.sed > > $ sed -i .bak -f expand.sed security-*.xml > > And then if you find other files where the same kind of thing needs > to be done, you can re-use the expand.sed script, or even (pun > intended) expand the sed script if necessary. > >> I would use the full hash in the xml and use a substring-function >> in the xsl to shorten the hash for readability. > >> No need for sed here :) This was to initially fetch the full hashes. In the XML, now, they are already shortened. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5VPDUACgkQHPApP6U8 pFiOxQ/+K+R+H49bxxvq9Ly9fmyOJN/Q8VHG5Tx8Wj9zT890j1Dc8g+BvCIFxVCw 8ZUrl7P5kcQJh8M4UJ0InwmdFTPvZoQi8+Dks2WFztWTmiJH5yNxYFWFroV/hNRe PPns6wlgLg7juNB2C3HuVThlLGOL3wK3esxb1m7ufklTHAfWr1wywxOZhyfVnzWU e/On217dnVn4rnVCXGrAVix6noCyLz98ZaHVX3PQgNToN50hQDVxqA/pMgb3hX// izZg6Na3P8XNXtz1JWaU+I5cLnOH4D+ce9YXxeBiCZKH9D6EbMa99pdfFHm+Pn54 Sip0p5shv3VPETzOtR1e4ZrdG7QM5Yrdl6yjryhBq4fz4ktsE10fQG7NzGrPgElk Rz0cRbMZBhJmCs81FSvwpOlExiRlDsB5AR+ZnPJ0H3ptuBIkjOnF/JieTJseTc0l ybSyMa6J40xbco5YdLNYhgXozE8mxXpiLdvJPG4P4gnUUyQ2n2cUSmKfcUY1tJk6 XHs/iQWoRQEDaM/lSjTrHz70DOEKyw2hzWmrJhz2C7nA3Oo7+KXCTWMjq5rbj/jh HWt92/irSKTy4SQy8XvFNesOcRSkRxlvriWTy0iAgebpvYnaLecYnVAFcGy8RhYI Amq5+2X+D50+TL+0IyaWHdm3803jORI/K4/tQDvKK1i5X6eWxt8= =MAUE -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 64166] RequestDumperFilter duplicates headers
https://bz.apache.org/bugzilla/show_bug.cgi?id=64166 Mark Thomas changed: What|Removed |Added OS||All --- Comment #1 from Mark Thomas --- I'm thinking that the return value for getHeaderNames() should be de-duplicated. The only scenarios I can think of where that would cause issues, the client is doing something unreasonable. -- 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
[tomcat] branch master updated: Update to reflect changes in planned version numbering.
This is an automated email from the ASF dual-hosted git repository. markt 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 699d14a Update to reflect changes in planned version numbering. 699d14a is described below commit 699d14a274dd15a0f44db4d1445788acfea9f13d Author: Mark Thomas AuthorDate: Tue Feb 25 12:36:18 2020 + Update to reflect changes in planned version numbering. --- TOMCAT-NEXT.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/TOMCAT-NEXT.txt b/TOMCAT-NEXT.txt index 5751a5b..ab47a46 100644 --- a/TOMCAT-NEXT.txt +++ b/TOMCAT-NEXT.txt @@ -25,7 +25,7 @@ Items carried over from the 9.0.x list: 2. Reduce instances of setters and getters for the same property existing on an object and its parent. This may require new objects to be exposed via JMX. -New items for 10.0.0.x onwards: +New items for 10.0.x onwards: 1. Remove APR connector. @@ -47,7 +47,7 @@ New items for 10.0.0.x onwards: 7. Refactor DefaultServlet to use Ranges in parseRanges(). -Deferred until 10.0.x: +Deferred until 10.1.x: 1. Remove the ExtensionValidator and associated classes (assuming that the minimum Java version is Java 9 or later). - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 64158] Tomcat 7 performance: remove enforcement that disable keep-alive when busy threads go above disable-keep-alive-percentage
https://bz.apache.org/bugzilla/show_bug.cgi?id=64158 Remy Maucherat changed: What|Removed |Added Resolution|--- |WONTFIX OS||All Status|NEW |RESOLVED --- Comment #2 from Remy Maucherat --- The patch is not a good move. If you have a problem with this, you can disable it and recompile as you did, but in practice the solution is to not use java.io. As there is no good solution here, I'm closing the issue. -- 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 64157] Tomcat 7 performance: enable tomcat to pre-start pool of min spare threads optionally
https://bz.apache.org/bugzilla/show_bug.cgi?id=64157 Remy Maucherat changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #2 from Remy Maucherat --- I don't understand why maintaining the set of min spare threads is bad or how it affects performance. Please provide metrics. -- 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: svn commit: r1874468 - in /tomcat/site/trunk: docs/security-8.html xdocs/security-8.xml
Am 24.02.2020 22:13, schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 2/24/20 15:46, Mark Thomas wrote: On 24/02/2020 20:31, Christopher Schultz wrote: Mark, Why not use the full commit id instead of a prefix? Couldn't some future commit conflict with some arbitrary prefix? Or do I not know what the hell I'm talking about? No, you are spot on. The reason I used the prefix is that I was transcribing the commit IDs by hand so the prefixes were easier. We probably should use the full ID or at least a longer prefix. I wonder if we could script this: grab a prefix, find the (one and only one) commit in the repo and expand it. If there is a conflict (or more than one match), emit an error and continue without changing the commit id. When I do this kind of thing for $work, I like to write scripts that emit sed scripts. So you process e.g. security-8.html as input, but emit something like this as output: s/(\b)69c5608(\b)/\169c56080fb3355507e1b55d014ec0ee6767a6150\2/g ... You get a script that can be inspected, re-used and, even better, it doesn't directly modify the input files. So you can even do something like this: $ expand-git-commit-ids.pl security-*.xml > expand.sed $ sed -i .bak -f expand.sed security-*.xml And then if you find other files where the same kind of thing needs to be done, you can re-use the expand.sed script, or even (pun intended) expand the sed script if necessary. I would use the full hash in the xml and use a substring-function in the xsl to shorten the hash for readability. No need for sed here :) Felix - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5UPJMACgkQHPApP6U8 pFieGBAAmLLPqCvkLguhEr0aXmDfNmjYsiO6FssEHV2zjmqjM1zzDfgjI+WDwogs ctGkcCvITq1BYCVlGxMrkMyYkTI9a8i6lILMpAOIUwNvTVKDF3AGKaMB+EMNqyY9 8qiCrWaDbVLqpsSuGn5OhRqPui7yv8diik1cWnUKABqC/unkJqbRSEmkY9gVW8DJ P+rdC6PUK9osqNRttnJ7AKSuQJFBV4RGnQKDfVWFB7pnFAf9Dxy3W9xoy21NJAc5 GHB+AA/9PiNi1TUYClGI4LQnp/kMlGSeRGdtn0xRhVky/DqJehfHkZmUr8ec2Y1t eOBTLa7aP+Y19aaYiXZco3mXrbvsGGAJaeM+gX5CKpZHjFNAJV122FbP9smv+l/T Jdk10J2LJe3WtSR/ScKCPE4/ZXFG8pnEcNf3clT0nd8y2nuIdX6uOGPwyHMX5Cwr /IDFnuJDzy2/O5pfojFUGAfaVN+gzKRv7N2TaYXJt42FBKWfto1BFGvCxqmIIJCu xJDw+mLcGMfG6lximvc0mrmtOmd2CRjWfo6w12vp0/4pKyj39ZShgIT3lEg05hrC bLcYn+sHkoFgN8uiGjbDgpPZCsYn74HR/eoqZBgSfF0rBpOkNYfkfW4Yy8aUo8m3 ilpJrf/Oqn54ilkD4/v18rCIju+jd4XEiQdhjKao+Bj4zP6dGbg= =GeOn -END PGP SIGNATURE- - 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
