Re: Possible bug in Http11Processor/SocketWrapperBase

2019-10-11 Thread Mark Thomas
On 11/10/2019 13:21, Michael Osipov wrote:
> Folks,
> 
> while working on BZ-63835 I have noticed an odd thing and I'd like
> someone to review whether my code/understanding is wrong or the one
> already present in Tomcat.



> we have a total of 100 requests (HTTP/1.1 302).

That is consistent with the docs that state there will be
maxKeepAliveRequests before the connection is closed.

> I'd assume the
> connection to sustain 100 requests and on the n+1 requests to be closed.

That assumption is not consistent with the documentation (which has been
the same for as long as I can remember).

> The expired header proposal says:
>>    The value of the "max" parameter counts the number of requests since
>>    the connection was created.

The same proposal also states that the use of the max parameter is
deprecated.

Mark


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



Re: [tomcat] branch BZ-63835/8.5.x created (now 6ff2233)

2019-10-11 Thread Mark Thomas
On 11/10/2019 14:10, Rémy Maucherat wrote:
> On Fri, Oct 11, 2019 at 1:51 PM Michael Osipov  <mailto:micha...@apache.org>> wrote:
> 
> Am 2019-10-11 um 11:32 schrieb Rémy Maucherat:
> > On Fri, Oct 11, 2019 at 10:43 AM Mark Thomas  <mailto:ma...@apache.org>> wrote:
> >
> >> On 11/10/2019 09:30, micha...@apache.org
> <mailto:micha...@apache.org> wrote:
> >>> This is an automated email from the ASF dual-hosted git repository.
> >>>
> >>> michaelo pushed a change to branch BZ-63835/8.5.x
> >>
> >> New features should be implemented against master and then
> back-ported
> >> (assuming the community accepts them).
> >>
> >
> > I also (still) prefer either PRs (it allows comments) or in master.
> 
> This is a first draft, nothing PR worthy. As soon as I see the code
> working, I will create the PR by then and when approved in general I
> will add tests and re-request review. So please be patient.
> 
> 
> For this use I'd recommend using your own forked repository then. Using
> a branch for that doesn't work for me, it sends way too many emails that
> are not actually useful to dev to the dev mailing list. I tried for a
> while, it didn't work, sorry :(
> 
> So either:
> - a PR
> - directly in master

master is fine when you are fairly sure the code is right. It isn't the
place for experiments since we release 9.0.x off master.

> - your git fork

I use the fork approach.

I have a local checkout of my fork with the apache/tomcat github mirror
configured as an additional remote called "upstream".

Most of the time I work on upstream but occasionally, I'll push
something to the fork and generate a PR to obtain feedback.

I also use the fork if I need to share in-progress work between my
desktop and laptop.

I use upstream so much I should probably reconfigure the names of the
remotes in my checkout:
origin -> fork
upstream -> origin

Mark

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



[VOTE][RESULT] Release Apache Tomcat 8.5.47

2019-10-11 Thread Mark Thomas
The following votes were cast:

Binding:
+1: remm, michaelo, kkolinko, markt

No other votes were cast.

This vote therefore passes.

Thanks to everyone who contributed to this release.

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

2019-10-11 Thread Mark Thomas
On 07/10/2019 14:58, Mark Thomas wrote:

> The proposed 8.5.47 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 8.5.47

Unit tests pass for NIO, NIO2 and APR/native with Tomcat Native 1.2.23
on Linux, Windows and MacOS.

Mark

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



Re: [tomcat] branch BZ-63835/8.5.x created (now 6ff2233)

2019-10-11 Thread Mark Thomas
On 11/10/2019 09:30, micha...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git repository.
> 
> michaelo pushed a change to branch BZ-63835/8.5.x

New features should be implemented against master and then back-ported
(assuming the community accepts them).

Mark


> in repository https://gitbox.apache.org/repos/asf/tomcat.git.
> 
> 
>   at 6ff2233  First draft
> 
> This branch includes the following new commits:
> 
>  new 6ff2233  First draft
> 
> The 1 revisions listed above as "new" are entirely new to this
> repository and will be described in separate emails.  The revisions
> listed as "add" were already present in the repository and have only
> been added to this reference.
> 
> 
> 
> -
> 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



[VOTE][RESULT] Release Apache Tomcat 9.0.27

2019-10-11 Thread Mark Thomas
The following votes were cast:

Binding:
+1: remm, ebourg, csutherl, mgrigorov, kkolinko, markt

No other votes were cast.

The vote therefore passes.

Thanks to everyone who contributed to this release.

Mark

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

2019-10-11 Thread Mark Thomas
On 07/10/2019 12:51, Mark Thomas wrote:

> The proposed 9.0.27 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 9.0.27

Unit tests pass for NIO, NIO2 and APR/native with Tomcat Native 1.2.23
on Linux, Windows and MacOS.

Mark

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



Re: [tomcat] branch master updated: Use consistent format

2019-10-10 Thread Mark Thomas
On 10/10/2019 18:21, Christopher Schultz wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Mark,
> 
> Should we just make this into an SVG and call it a day? ASCII art is
> great and all, but ...

As much as I like that piece of ASCII art, I agree we need to do something.

As a result of the couple of Async bugs raised recently I've been
reviewing that diagram, the implementation and the spec. There are some
inconsistencies around some of the edge cases - especially error
handling which isn't that well specified to start with.

My current thinking is that we should replace it with a table. List
starting state down the left hand side and events (complete(),
dispatch() etc) across the top. Each cell would show the resulting state
for the given start state and event combination with some marked as N/A
(which would trigger ISE in the code). I have this mocked up in a
spreadsheet at the moment that I am using to track what I need to work
on next.

Getting a little off-topic but error handling needs an overhaul. I need
to go through the spec and get the intent clear(er) in my mind. Things
get particularly "interesting" if errors occur during the transition
from async to non-async. Hopefully, fixes for the two async BZ issues
will fall out of that.

Mark



> 
> - -chris
> 
> On 10/10/19 03:58, 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 bdbc534  Use consistent format bdbc534 is described
>> below
>>
>> commit bdbc534b6725197e666540eeadb0aa4dbb987f91 Author: Mark Thomas
>>  AuthorDate: Wed Oct 9 11:49:04 2019 +0100
>>
>> Use consistent format ---
>> java/org/apache/coyote/AsyncStateMachine.java | 2 +- 1 file
>> changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/java/org/apache/coyote/AsyncStateMachine.java
>> b/java/org/apache/coyote/AsyncStateMachine.java index
>> 29b0caf..d9a887a 100644 ---
>> a/java/org/apache/coyote/AsyncStateMachine.java +++
>> b/java/org/apache/coyote/AsyncStateMachine.java @@ -119,7 +119,7 @@
>> import org.apache.tomcat.util.security.PrivilegedSetTccl; * |   |
>> |   |post() ||  |  | timeout()|
>> |  |  |   error()| * |   |  |   |dispatched()   |   \|/\|/
>> \|/ |  dispatch()|  |  |-»| * |   |  |
>> |---«-- | ---DISPATCHING«-«-- | --«|  | - *
>> |   |  |   | |^  |
>> | + * |   |  |   | |   /|\
>> |   | * |   |  |   | ||
>> |   | * |   |  |   |
>> timeout()|   | * |   |  |
>> | |   |
>>
>>
>> -
>>
>>
> 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/
> 
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2faKQACgkQHPApP6U8
> pFjM5Q//epa0QRqu7FdFp3ion2HJ3Mh3pIfB1rOXMd574ezkTdEfWprRaPM3zeWU
> qr5cseOqa3Ld3KW1FY5ZXeicKOfgRw5NJ/+fTU/cjXiaLrKlMnyX7GlWawZ/Sb4H
> Pl/XevFryr25n3jQ2j7hB0I53hoUmKjYcdev+btcHX0W2otTI2b+UZ1P8d8zAZHQ
> FdbVerma1Y3OR0x7CXErIb5Vly8YEGVpmrXvch7LYcaWu6Zdp5B9SP4DGQJOBel3
> 8Qw1CR5llkTdiRNZKOn1S/olBeOC8bKgVGSwu233vYIwsXRVIzU6tEsMsQLuhvqn
> 6VKThOEk/k7a0GJpN+XzjTOysuEMFB2oWMErgaLjDSK4U6PWqaRycJl6fPRsHJ2k
> 5FPquxtyTej0iUW+pkYY9CQfwf1SCr93LyJhuyhR890kH2vcke/2JPhqKICasn0y
> RhHNIIHj6yoa5HjZ/8DpikY0GQ3ELqNwPx8uBpfllHzWcESFUYWN1kJTAweTy0sK
> 2q7PDmijC8O3ZOciM8ainkozeX4OjxU0z31o0jeIfcsyLDqZbXScmsUi3qfFJnY2
> Tl1vT/FFV3zEqN7zyyKqPWUYmr1xKxnBWTm8dh8FWPeXLY5CxDkPmU741mWrJSs9
> Vk8i8iIOxgLaOjppnZuDRpW4bk9q1m7lPskgh4eFdZomVOOIdf4=
> =i7JK
> -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



Re: Possible bugs in Http11Processor

2019-10-09 Thread Mark Thomas
On 09/10/2019 22:03, Michael Osipov wrote:
> Am 2019-10-09 um 19:08 schrieb Mark Thomas:
>> On 09/10/2019 16:58, Michael Osipov wrote:
>>> Folks,
>>>
>>> while working on an improvement for Http11Processor I have noticed there
>>> constructs:
>>>
>>>> if ((contentEncodingMB != null)
>>>>     (contentEncodingMB.indexOf("gzip") != -1))
>>
>> The parsing of this is much tighter on input. For output I think this is
>> a reasonable trade-off. The worst that will happen is that Tomcat won't
>> compress something it might have been able to.
> 
> I agree on output, but there is at least on counter example:
> 
>>     // Check if browser support gzip encoding
>>     MessageBytes acceptEncodingMB =
>>     request.getMimeHeaders().getValue("accept-encoding");
>>
>>     if ((acceptEncodingMB == null)
>>     || (acceptEncodingMB.indexOf("gzip") == -1)) {
>>     return false;
>>     }
> 
> It would even accept "Accept-Encoding: figzip" as valid input.

That isn't there in 9.0.x. I wonder why the new CompressionConfig class
isn't being used in 8.5.x (that parses this correctly). I have a vague
recollection of backwards compatibility issues with the back-port but it
is worth revisiting that.

Mark


> 
>>>> if (findBytes(connectionValueBC, Constants.CLOSE_BYTES) != -1) {
>>>>  keepAlive = false;
>>>> } else if (findBytes(connectionValueBC,
>>>>  Constants.KEEPALIVE_BYTES) != -1) {
> 
> In this specific case I said via curl: "Connection: close2" and it still
> matched.
> 
>>> and on likely other spots. I believe they are wrong.
>>
>> Yes, but. Is the cost of parsing that header (and any similar headers)
>> fully worth the benefit? The header parser is reasonably efficient so it
>> might be OK.
>>
>> I'd suggest creating a BZ issue for this.
> 
> Will do!
> 
> 
> -
> 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: [PROPOSAL] Tomcat 10: Remove WebDAV

2019-10-09 Thread Mark Thomas
On 09/10/2019 21:42, Michael Osipov wrote:
> Am 2019-10-09 um 21:35 schrieb Christopher Schultz:



>>> The only drawback I see with the current servlet is that I cannot
>>> have arbitrary paths of my context served by this servlet. It
>>> serves either the entire app or nothing. That's why I have resorted
>>> to mod_dav.
>>
>> Okay, so someone who really wants to make DAV work has decided that
>> Tomcat's implementation won't cut it. I fee that as further evidence
>> that Tomcat's implementation can just die.
> 
> As you might know, people will only complain when something is
> gone/broken and not when it is working well.

If arbitrary path mapping would be useful then please add that as an
enhancement to Bugzilla. From memory, the path handling for WebDav is
"interesting" so I'm not sure how easy this would be to implement.

Mark

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

2019-10-09 Thread Mark Thomas
On 09/10/2019 21:35, Michael Osipov wrote:
> Am 2019-10-09 um 18:55 schrieb Mark Thomas:
>> On 09/10/2019 16:48, Michael Osipov wrote:
>>> and
>>>
>>>> Testcase: testMultipleHostHeaders took 1,385 sec
>>>>  FAILED
>>>> expected:<...content-length]-[112[7]
>>>> 1-Header-[date]-[Wed, 11 Nov 2015 19:18:42 GMT]
>>>> 1-HeadersEnd
>>>> 1-Body-1127]
>>>> 1-EndOfStream
>>>>> but was:<...content-length]-[112[8]
>>>> 1-Header-[date]-[Wed, 11 Nov 2015 19:18:42 GMT]
>>>> 1-HeadersEnd
>>>> 1-Body-1128]
>>>> 1-EndOfStream
>>>>>
>>>> junit.framework.AssertionFailedError:
>>>> expected:<...content-length]-[112[7]
>>>> 1-Header-[date]-[Wed, 11 Nov 2015 19:18:42 GMT]
>>>> 1-HeadersEnd
>>>> 1-Body-1127]
>>>> 1-EndOfStream
>>>>> but was:<...content-length]-[112[8]
>>>> 1-Header-[date]-[Wed, 11 Nov 2015 19:18:42 GMT]
>>>> 1-HeadersEnd
>>>> 1-Body-1128]
>>>> 1-EndOfStream
>>>>>
>>>>  at
>>>> org.apache.coyote.http2.Http2TestBase.validateHttp2InitialResponse(Http2TestBase.java:129)
>>>>
>>>>
>>>>  at
>>>> org.apache.coyote.http2.Http2TestBase.http2Connect(Http2TestBase.java:111)
>>>>
>>>>
>>>>  at
>>>> org.apache.coyote.http2.TestHttp2InitialConnection.testMultipleHostHeaders(TestHttp2InitialConnection.java:55)
>>>>
>>>>
>>>>
>>>> Testcase: testValidHostHeader took 0,143 sec
>>>> Testcase: testNoHostHeader took 0,185 sec
>>>>  FAILED
>>>> expected:<...content-length]-[112[7]
>>>> 1-Header-[date]-[Wed, 11 Nov 2015 19:18:42 GMT]
>>>> 1-HeadersEnd
>>>> 1-Body-1127]
>>>> 1-EndOfStream
>>>>> but was:<...content-length]-[112[8]
>>>> 1-Header-[date]-[Wed, 11 Nov 2015 19:18:42 GMT]
>>>> 1-HeadersEnd
>>>> 1-Body-1128]
>>>> 1-EndOfStream
>>
>> Hmm. Those are odd. I wonder why the content length is off. Some sort of
>> line ending issue maybe?
> 
> I assume so. I will look into it.

Thanks.

>>> and the last one is a locale issue with the resource bundles:
>>>
>>>> 08-Oct-2019 11:24:51.852 INFORMATION [main]
>>>> org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler
>>>> ["http-apr-127.0.0.1-auto-24-26939"]
>>>> -  ---
>>>>
>>>> Testcase: testHeaderLimits100x32 took 1,391 sec
>>>> Testcase: testHeaderLimits101x32 took 0,411 sec
>>>> Testcase: testHeaderLimits1x128k took 0,416 sec
>>>>  FAILED
>>>>
>>>> Expected: match to regular expression pattern
>>>> [0-Goaway-\[1\]-\[11\]-\[Connection \[\d++\], Stream \[3\], .*]
>>>>   but: was "0-Goaway-[1]-[11]-[Verbindung [2], Stream [3],
>>>> Gesamt-Header-Größe zu groß]"
>>>> junit.framework.AssertionFailedError:
>>>> Expected: match to regular expression pattern
>>>> [0-Goaway-\[1\]-\[11\]-\[Connection \[\d++\], Stream \[3\], .*]
>>>>   but: was "0-Goaway-[1]-[11]-[Verbindung [2], Stream [3],
>>>> Gesamt-Header-Größe zu groß]"
>>>>  at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
>>>>  at
>>>> org.apache.coyote.http2.TestHttp2Limits.doTestHeaderLimits(TestHttp2Limits.java:259)
>>>>
>>>>
>>>>  at
>>>> org.apache.coyote.http2.TestHttp2Limits.doTestHeaderLimits(TestHttp2Limits.java:170)
>>>>
>>>>
>>>>  at
>>>> org.apache.coyote.http2.TestHttp2Limits.doTestHeaderLimits(TestHttp2Limits.java:164)
>>>>
>>>>
>>>>  at
>>>> org.apache.coyote.http2.TestHttp2Limits.doTestHeaderLimits(TestHttp2Limits.java:158)
>>>>
>>>>
>>>>  at
>>>> org.apache.coyote.http2.TestHttp2Limits.testHeaderLimits1x128k(TestHttp2Limits.java:138)
>>>>
>>
>> We should find a way to fix that one.
> 
> Either exclude the resource JARs from the classpath or change the code.
> Shall I file an issue here?

Yes please.

I was thinking of using StringManager to obtain the i18n version of the
string for the test. I haven't look to see whether that is practical or not.

Mark

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



Re: Unbundling Commons Daemon and tcnative

2019-10-09 Thread Mark Thomas
On 09/10/2019 21:34, Michael Osipov wrote:
> Am 2019-10-09 um 19:14 schrieb Mark Thomas:
>> On 09/10/2019 17:36, Michael Osipov wrote:
>>> I have been wondering recently why are we bundling
>>> commons-daemon-native.tar.gz and tomcat-native.tar.gz every time with a
>>> new release at all?
>>
>> Because users find it convenient to have the latest versions available.
> 
> I already expected this, but any other reason?

None that I can think of at the moment.

>> On Windows I think there is a case for not shipping the native sources
>> since the binaries are already present. Asking a user who wants them to
>> download them seems reasonable in that instance.
> 
> Shall I create an enhancement request for this?

Yes please.

Thanks,

Mark

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



Re: Possible bugs in Http11Processor

2019-10-09 Thread Mark Thomas



On 09/10/2019 17:49, Michael Osipov wrote:
> Just found another bug:
>>     private static boolean isConnectionClose(MimeHeaders headers) {
>>     MessageBytes connection = headers.getValue(Constants.CONNECTION);
>>     if (connection == null) {
>>     return false;
>>     }
>>     return connection.equals(Constants.CLOSE);
>>     }
> 
> 
> RFC 7230, section 6.1. says:
>> Connection options are case-insensitive.

-> bugzilla.

Mark


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



Re: Unbundling Commons Daemon and tcnative

2019-10-09 Thread Mark Thomas
On 09/10/2019 17:36, Michael Osipov wrote:
> I have been wondering recently why are we bundling
> commons-daemon-native.tar.gz and tomcat-native.tar.gz every time with a
> new release at all?

Because users find it convenient to have the latest versions available.

> There are two scenarios where people don't require to use it from the
> tarball:
> 
> 1. Tomcat Native and Commons Daemon are installed through OS package or
> port. Thus making the bundling redundant. E.g., on RHEL, Fedora, *BSD,
> etc. => OS managed

In that case I'd expect Tomcat to be installed via an OS package or port
which makes any redundancy the packager's responsibility. If users want
to mix packaged and direct download then I think it is fair to expect
them to deal with a little redundancy - especially when they just have
to ignore/delete a couple of files.

> 2. Both are compiled from source and survive Tomcat updates because
> there are installed outside of Tomcat, e.g., in /usr/local or
> /opt/ports, etc. These people don't need those tarballs too because they
> get them from dist.apache.org. => manually managed
> 
> I do both approaches on different operating systems.
> 
> We can say/document that Tomcat release T requires libtcnative x.y.z and
> Commons Daemon a.b.c to run, get your own from dist.apache.org if you do
> it manually.

I think that is less convenient for users.

> More confusing is that apache-tomcat-8.5.48-dev-windows-*.zip bundles
> tcnative-1.dll (which is huge in size, OpenSSL statically linked?)

Yes, OpenSSL (as well as APR) is statically linked.

> *and* the source tarball, same for Commons Daemon. Why?

On Windows I think there is a case for not shipping the native sources
since the binaries are already present. Asking a user who wants them to
download them seems reasonable in that instance.

Mark


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



Re: Possible bugs in Http11Processor

2019-10-09 Thread Mark Thomas
On 09/10/2019 16:58, Michael Osipov wrote:
> Folks,
> 
> while working on an improvement for Http11Processor I have noticed there
> constructs:
> 
>> if ((contentEncodingMB != null)
>>    (contentEncodingMB.indexOf("gzip") != -1))

The parsing of this is much tighter on input. For output I think this is
a reasonable trade-off. The worst that will happen is that Tomcat won't
compress something it might have been able to.

>> if (connectionValue != null)
>>     foundUpgrade =
>> connectionValue.toLowerCase(Locale.ENGLISH).contains("upgrade");
> 
>> if (findBytes(connectionValueBC, Constants.CLOSE_BYTES) != -1) {
>>     keepAlive = false;
>> } else if (findBytes(connectionValueBC,
>>     Constants.KEEPALIVE_BYTES) != -1) {
> 
> and on likely other spots. I believe they are wrong.

Yes, but. Is the cost of parsing that header (and any similar headers)
fully worth the benefit? The header parser is reasonably efficient so it
might be OK.

I'd suggest creating a BZ issue for this.

Mark


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

2019-10-09 Thread Mark Thomas
On 09/10/2019 16:48, Michael Osipov wrote:



> Though I see some minor failures I have not investigated yet



> with
> 
>> Testcase: testNonBlockingWriteError took 33,493 sec
>>     FAILED
>> Uri: /, Status: 500, Time: 33456 duration is not < 30600
>> junit.framework.AssertionFailedError: Uri: /, Status: 500, Time: 33456
>> duration is not < 30600
>>     at
>> org.apache.catalina.valves.TesterAccessLogValve.validateAccessLog(TesterAccessLogValve.java:92)
>>
>>     at
>> org.apache.catalina.nonblocking.TestNonBlockingAPI.testNonBlockingWriteError(TestNonBlockingAPI.java:380)

Timing issues like this are generally safe to ignore. We see sporadic
failures with these, especially on loaded systems.

> and
> 
>> Testcase: testMultipleHostHeaders took 1,385 sec
>>     FAILED
>> expected:<...content-length]-[112[7]
>> 1-Header-[date]-[Wed, 11 Nov 2015 19:18:42 GMT]
>> 1-HeadersEnd
>> 1-Body-1127]
>> 1-EndOfStream
>>> but was:<...content-length]-[112[8]
>> 1-Header-[date]-[Wed, 11 Nov 2015 19:18:42 GMT]
>> 1-HeadersEnd
>> 1-Body-1128]
>> 1-EndOfStream
>>>
>> junit.framework.AssertionFailedError:
>> expected:<...content-length]-[112[7]
>> 1-Header-[date]-[Wed, 11 Nov 2015 19:18:42 GMT]
>> 1-HeadersEnd
>> 1-Body-1127]
>> 1-EndOfStream
>>> but was:<...content-length]-[112[8]
>> 1-Header-[date]-[Wed, 11 Nov 2015 19:18:42 GMT]
>> 1-HeadersEnd
>> 1-Body-1128]
>> 1-EndOfStream
>>>
>>     at
>> org.apache.coyote.http2.Http2TestBase.validateHttp2InitialResponse(Http2TestBase.java:129)
>>
>>     at
>> org.apache.coyote.http2.Http2TestBase.http2Connect(Http2TestBase.java:111)
>>
>>     at
>> org.apache.coyote.http2.TestHttp2InitialConnection.testMultipleHostHeaders(TestHttp2InitialConnection.java:55)
>>
>>
>> Testcase: testValidHostHeader took 0,143 sec
>> Testcase: testNoHostHeader took 0,185 sec
>>     FAILED
>> expected:<...content-length]-[112[7]
>> 1-Header-[date]-[Wed, 11 Nov 2015 19:18:42 GMT]
>> 1-HeadersEnd
>> 1-Body-1127]
>> 1-EndOfStream
>>> but was:<...content-length]-[112[8]
>> 1-Header-[date]-[Wed, 11 Nov 2015 19:18:42 GMT]
>> 1-HeadersEnd
>> 1-Body-1128]
>> 1-EndOfStream

Hmm. Those are odd. I wonder why the content length is off. Some sort of
line ending issue maybe?

> and the last one is a locale issue with the resource bundles:
> 
>> 08-Oct-2019 11:24:51.852 INFORMATION [main]
>> org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler
>> ["http-apr-127.0.0.1-auto-24-26939"]
>> -  ---
>>
>> Testcase: testHeaderLimits100x32 took 1,391 sec
>> Testcase: testHeaderLimits101x32 took 0,411 sec
>> Testcase: testHeaderLimits1x128k took 0,416 sec
>>     FAILED
>>
>> Expected: match to regular expression pattern
>> [0-Goaway-\[1\]-\[11\]-\[Connection \[\d++\], Stream \[3\], .*]
>>  but: was "0-Goaway-[1]-[11]-[Verbindung [2], Stream [3],
>> Gesamt-Header-Größe zu groß]"
>> junit.framework.AssertionFailedError:
>> Expected: match to regular expression pattern
>> [0-Goaway-\[1\]-\[11\]-\[Connection \[\d++\], Stream \[3\], .*]
>>  but: was "0-Goaway-[1]-[11]-[Verbindung [2], Stream [3],
>> Gesamt-Header-Größe zu groß]"
>>     at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
>>     at
>> org.apache.coyote.http2.TestHttp2Limits.doTestHeaderLimits(TestHttp2Limits.java:259)
>>
>>     at
>> org.apache.coyote.http2.TestHttp2Limits.doTestHeaderLimits(TestHttp2Limits.java:170)
>>
>>     at
>> org.apache.coyote.http2.TestHttp2Limits.doTestHeaderLimits(TestHttp2Limits.java:164)
>>
>>     at
>> org.apache.coyote.http2.TestHttp2Limits.doTestHeaderLimits(TestHttp2Limits.java:158)
>>
>>     at
>> org.apache.coyote.http2.TestHttp2Limits.testHeaderLimits1x128k(TestHttp2Limits.java:138)

We should find a way to fix that one.

Mark


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



Re: org.apache.tomcat.jni.TestSocketServer timeout test failures (was: VOTE 9.0.27)

2019-10-09 Thread Mark Thomas
On 09/10/2019 00:51, Konstantin Kolinko wrote:
> Hi!
> 
> Splitting from "VOTE 9.0.27" thread.
> 
> вт, 8 окт. 2019 г. в 21:00, Mark Thomas :
>>
>> On 08/10/2019 17:49, Mark Thomas wrote:
>>> On 07/10/2019 17:40, Igal Sapir wrote:
>>>
>>> 
>>>
>>>> TEST-org.apache.tomcat.jni.TestSocketServer.NIO2.txt:   FAILED
>>>> TEST-org.apache.tomcat.jni.TestSocketServer.NIO2.txt-Socket.timeoutSet
>>>> failed (<1s) [999760800] +-[400]
>>>> TEST-org.apache.tomcat.jni.TestSocketServer.NIO2.txt-junit.framework.AssertionFailedError:
>>>> Socket.timeoutSet failed (<1s) [999760800] +-[400]
>>>> TEST-org.apache.tomcat.jni.TestSocketServer.NIO2.txt-   at
>>>> org.apache.tomcat.jni.TestSocketServer.testBlockingReadFromClientWithTimeout(TestSocketServer.java:111)
>>>>
>>>> TEST-org.apache.tomcat.jni.TestSocketServer.NIO2.txt-
>>>> TEST-org.apache.tomcat.jni.TestSocketServer.NIO2.txt-Testcase: testPort
>>>> took 0.001 sec
>>>
>>> That is a false positive. The timing variance is significantly greater
>>> than the error margin. It looks like we need to adjust that. Interesting
>>> that the socket waited a little less than a second to timeout. We'd need
>>> to increase the error margin by 3 orders of magnitude (400ns to 0.4ms)
>>> for that test to pass.
>>>
>>> I'll start looking into these but more eyes are always welcome.
> 
> Running on Windows 10, AdoptOpenJDK Java 8u222, I also observe this
> test failing (and saw it for similar runs for older release as well).
> 
> In my case the numbers are:
> 
> Testcase: testBlockingReadFromClientWithTimeout took 1,032 sec
> FAILED
> Socket.timeoutSet failed (<1s) [998666400] +-[200]
> junit.framework.AssertionFailedError: Socket.timeoutSet failed (<1s)
> [998666400] +-[200]
> at 
> org.apache.tomcat.jni.TestSocketServer.testBlockingReadFromClientWithTimeout(TestSocketServer.java:111)
> 
> Socket.timeoutSet failed (<1s) [987526600] +-[200]
> Socket.timeoutSet failed (<1s) [991705200] +-[200]
> 
> Digging into this, I see that
> - Socket.timeoutSet is essentially a direct wrapper around
> apr_socket_timeout_set
> - Socket.recv is essentially a direct wrapper around apr_socket_recv
> and those APR methods a wrappers around Windows Socket API
> (setsockopt for setting timeout, WSARecv for reading)
> 
> https://svn.apache.org/viewvc/apr/apr/branches/1.6.x/network_io/win32/
> https://docs.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-setsockopt
> https://docs.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-wsarecv
> 
> I think that [998666400] for practical purposes is the same as 1s (as
> far as we are verifying our own API), and we cannot improve how
> precise is socket timeout handling in Windows.
> 
> Thus let's increase the error margin.
> 
> BTW,
> setsockopt method in Windows accepts a value in milliseconds. I do not
> know what clock it uses to measure the timeout. In my example of
> [987526600] the difference from expected value is 14 msecs. It seems
> similar to the granularity of System.currentTimeMillis().
> 
> How about a margin of 100 msec?

When I wrote the test I made the (clearly incorrect) assumption that the
resolution of System.nanoTime() was going to be the same as the
resolution of the mechanism that manages socket timeouts.

Given your research above, 100ms seems perfectly reasonable to me.

Mark

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

2019-10-08 Thread Mark Thomas
On 08/10/2019 17:19, Igal Sapir wrote:
> On 10/7/2019 6:58 AM, Mark Thomas wrote:
>> The proposed Apache Tomcat 8.5.47 release is now available for voting.
>>
>> The major changes compared to the 8.5.46 release are:
> 
> I'm getting similar test failures as I did for 9.0.27 on that same
> Windows machine:

These also look like timing issues.

I see TestAsyncContextImpl test failures like this fairly frequently on VMs.

The other failures look to be the same as the 9.0.x tests.

Mark

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

2019-10-08 Thread Mark Thomas
On 08/10/2019 17:49, Mark Thomas wrote:
> On 07/10/2019 17:40, Igal Sapir wrote:
>> Mark,
>>
>> On 10/7/2019 4:51 AM, Mark Thomas wrote:
>>> The proposed Apache Tomcat 9.0.27 release is now available for voting.
>>
>> I'm getting the failures below [1] for unit tests on Windows 10 with
>> Java 1.8u181.  False positives?
> 
> Don't know yet. I didn't get the same failures on Windows but I was
> using a different OS and a different JRE.
> 
>> TEST-org.apache.coyote.http2.TestStreamProcessor.APR.txt: FAILED
>> TEST-org.apache.coyote.http2.TestStreamProcessor.APR.txt-expected:<...3-Header-[:status]-[[304]
>> TEST-org.apache.coyote.http2.TestStreamProcessor.APR.txt-3-Header-[etag]-[W/"957-1447269522000"]]
>> TEST-org.apache.coyote.http2.TestStreamProcessor.APR.txt-3-Header-[date]-[W...>
>> but was:<...3-Header-[:status]-[[200]
>> TEST-org.apache.coyote.http2.TestStreamProcessor.APR.txt-3-Header-[accept-ranges]-[bytes]
>> TEST-org.apache.coyote.http2.TestStreamProcessor.APR.txt-3-Header-[etag]-[W/"957-1447269522000"]
> 
> This is TestStreamProcessor.testPrepareHeaders() failing for each connector.

I think the machine you are using for testing has some sort of issue
with its clock.

The above test will fail like that if the last modified time of the file
being requested is ahead of the current time. I don't see how that can
happen - even if the tests have just been checked out - unless the clock
moves back in time for some reason.

Overall, I'm not concerned about these failures although I am interested
to hear of you find out what is going on.

Mark

> 
> 
> 
>> TEST-org.apache.tomcat.jni.TestSocketServer.NIO2.txt:   FAILED
>> TEST-org.apache.tomcat.jni.TestSocketServer.NIO2.txt-Socket.timeoutSet
>> failed (<1s) [999760800] +-[400]
>> TEST-org.apache.tomcat.jni.TestSocketServer.NIO2.txt-junit.framework.AssertionFailedError:
>> Socket.timeoutSet failed (<1s) [999760800] +-[400]
>> TEST-org.apache.tomcat.jni.TestSocketServer.NIO2.txt-   at
>> org.apache.tomcat.jni.TestSocketServer.testBlockingReadFromClientWithTimeout(TestSocketServer.java:111)
>>
>> TEST-org.apache.tomcat.jni.TestSocketServer.NIO2.txt-
>> TEST-org.apache.tomcat.jni.TestSocketServer.NIO2.txt-Testcase: testPort
>> took 0.001 sec
> 
> That is a false positive. The timing variance is significantly greater
> than the error margin. It looks like we need to adjust that. Interesting
> that the socket waited a little less than a second to timeout. We'd need
> to increase the error margin by 3 orders of magnitude (400ns to 0.4ms)
> for that test to pass.
> 
> I'll start looking into these but more eyes are always welcome.
> 
> Mark
> 
> -
> 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: [VOTE] Release Apache Tomcat 9.0.27

2019-10-08 Thread Mark Thomas
On 07/10/2019 17:40, Igal Sapir wrote:
> Mark,
> 
> On 10/7/2019 4:51 AM, Mark Thomas wrote:
>> The proposed Apache Tomcat 9.0.27 release is now available for voting.
> 
> I'm getting the failures below [1] for unit tests on Windows 10 with
> Java 1.8u181.  False positives?

Don't know yet. I didn't get the same failures on Windows but I was
using a different OS and a different JRE.

> TEST-org.apache.coyote.http2.TestStreamProcessor.APR.txt: FAILED
> TEST-org.apache.coyote.http2.TestStreamProcessor.APR.txt-expected:<...3-Header-[:status]-[[304]
> TEST-org.apache.coyote.http2.TestStreamProcessor.APR.txt-3-Header-[etag]-[W/"957-1447269522000"]]
> TEST-org.apache.coyote.http2.TestStreamProcessor.APR.txt-3-Header-[date]-[W...>
> but was:<...3-Header-[:status]-[[200]
> TEST-org.apache.coyote.http2.TestStreamProcessor.APR.txt-3-Header-[accept-ranges]-[bytes]
> TEST-org.apache.coyote.http2.TestStreamProcessor.APR.txt-3-Header-[etag]-[W/"957-1447269522000"]

This is TestStreamProcessor.testPrepareHeaders() failing for each connector.



> TEST-org.apache.tomcat.jni.TestSocketServer.NIO2.txt:   FAILED
> TEST-org.apache.tomcat.jni.TestSocketServer.NIO2.txt-Socket.timeoutSet
> failed (<1s) [999760800] +-[400]
> TEST-org.apache.tomcat.jni.TestSocketServer.NIO2.txt-junit.framework.AssertionFailedError:
> Socket.timeoutSet failed (<1s) [999760800] +-[400]
> TEST-org.apache.tomcat.jni.TestSocketServer.NIO2.txt-   at
> org.apache.tomcat.jni.TestSocketServer.testBlockingReadFromClientWithTimeout(TestSocketServer.java:111)
> 
> TEST-org.apache.tomcat.jni.TestSocketServer.NIO2.txt-
> TEST-org.apache.tomcat.jni.TestSocketServer.NIO2.txt-Testcase: testPort
> took 0.001 sec

That is a false positive. The timing variance is significantly greater
than the error margin. It looks like we need to adjust that. Interesting
that the socket waited a little less than a second to timeout. We'd need
to increase the error margin by 3 orders of magnitude (400ns to 0.4ms)
for that test to pass.

I'll start looking into these but more eyes are always welcome.

Mark

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



Re: [tomcat] branch 7.0.x updated: 63814: Do not set server socket timeout with negative values in NIO

2019-10-08 Thread Mark Thomas
On 08/10/2019 12:31, r...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git repository.
> 
> remm 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 0a18642  63814: Do not set server socket timeout with negative 
> values in NIO
> 0a18642 is described below
> 
> commit 0a18642108a637b9800042f4202d284da93a9682
> Author: remm 
> AuthorDate: Tue Oct 8 13:31:30 2019 +0200
> 
> 63814: Do not set server socket timeout with negative values in NIO
> ---
>  java/org/apache/tomcat/util/net/NioEndpoint.java | 4 +++-
>  webapps/docs/changelog.xml   | 8 
>  2 files changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/java/org/apache/tomcat/util/net/NioEndpoint.java 
> b/java/org/apache/tomcat/util/net/NioEndpoint.java
> index 2f25ee4..33a7d18 100644
> --- a/java/org/apache/tomcat/util/net/NioEndpoint.java
> +++ b/java/org/apache/tomcat/util/net/NioEndpoint.java
> @@ -474,7 +474,9 @@ public class NioEndpoint extends 
> AbstractEndpoint {
>  InetSocketAddress addr = (getAddress()!=null?new 
> InetSocketAddress(getAddress(),getPort()):new InetSocketAddress(getPort()));
>  serverSock.socket().bind(addr,getBacklog());
>  serverSock.configureBlocking(true); //mimic APR behavior
> -
> serverSock.socket().setSoTimeout(getSocketProperties().getSoTimeout());
> +if (getSocketProperties().getSoTimeout() > 0) {
> +
> serverSock.socket().setSoTimeout(getSocketProperties().getSoTimeout());
> +}

Shouldn't this be >= 0 to allow for infinite timeouts?

Mark

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



Re: Migrating Tomcat Connectors to Git

2019-10-08 Thread Mark Thomas
On 08/10/2019 13:32, Rainer Jung wrote:
> Am 08.10.2019 um 13:39 schrieb Rainer Jung:
>> Am 08.10.2019 um 13:09 schrieb Mark Thomas:
>>> Hi all,
>>>
>>> Tomcat Connectors (mod_jk, isapi_redirect) are currently in svn. There
>>> hasn't been much activity on these over the last year or so so there has
>>> been no reason to migrate the project to Git.
>>>
>>> I've recently fixed a mod_jk bug and I have a patch ready to fix a
>>> second. These seems like a good time to migrate Tomcat Connectors to
>>> git. Therefore, I intend to start this today.
>>
>> OK for me.
>>
>> You are probably already aware of the fact, that tools/jkrelease.sh
>> has some svn foo in it. To make migration easier, we could comment out
>> the features to release from trunk (dev tarball), a branch (also dev
>> tarball) or a local directory and for now just keep the part using a
>> tag. That makes adjusting the script much easier, especially due to a
>> simplification I just committed.
> 
> I have committed a first attempt at making the release skript svn plus
> git compatible. We can siplify back, once the switch to git is final.
> 
> When using it with git, there is no support yet for releasing from a
> branch, from a (non-verion) tag, from trunk or from a local checkout. I
> think these are a not immediately critical.

Thanks for this. Tomcat Native has similar code. We can probably use
that as a basis for a solution those additional features.

Mark

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



Migrating Tomcat Connectors to Git

2019-10-08 Thread Mark Thomas
Hi all,

Tomcat Connectors (mod_jk, isapi_redirect) are currently in svn. There
hasn't been much activity on these over the last year or so so there has
been no reason to migrate the project to Git.

I've recently fixed a mod_jk bug and I have a patch ready to fix a
second. These seems like a good time to migrate Tomcat Connectors to
git. Therefore, I intend to start this today.

Mark

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



Re: [PROPOSAL] Tomcat 10: Remove CGI Servlet

2019-10-07 Thread Mark Thomas
> All,
> 
> I recently gave a presentation on locking-down Apache Tomcat[1] and I
> briefly discussed the "sharp edges" present in Tomcat. Some of them
> are unnecessarily sharp and may be actually unnecessary. I'm going to
> make a few proposals to remove functions from Tomcat.
> 
> Proposal: Remove CGI Servlet

-1. Not a veto, just a -1.

> Justification:
> 
> The CGIServlet is another component, like server-side-includes, which
> is a remote-code execution (RCE) vulnerability as a feature. It is
> very easy to misconfigure. It is arguably not possible to secure it on
> Windows[2].

I disagree. That is an edge case.

> There are better solutions if you want to run Perl,
> Python, PHP, or whatever on your server in the form of the many fine
> web-server products out there.

Yes, but that isn't the only use of CGI. It is essentially, a fairly
easy way to integrate any executable into a web application. My sense
that this use remains sufficiently widespread that we should not
discontinue it.

Maybe a topic for discussion on users@ ?

Mark

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



Re: [PROPOSAL] Tomcat 10: Remove WebDAV

2019-10-07 Thread Mark Thomas
> All,
> 
> I recently gave a presentation on locking-down Apache Tomcat[1] and I
> briefly discussed the "sharp edges" present in Tomcat. Some of them
> are unnecessarily sharp and may be actually unnecessary. I'm going to
> make a few proposals to remove functions from Tomcat.
> 
> Proposal: Remove WebDAV
> 
> Justification:
> 
> WebDAV is a protocol that never really took off[2]. Read-only WebDAV
> can practically be replaced by standard HTTP GET and read-write WebDAV
> has a host of security problems. There are better solutions to
> supporting WebDAV than using the Tomcat module.
> 
> A recent search of the users mailing list shows only 10 threads
> regarding WebDAV in the past 6 years.

I'm not so sure on this one. There are times when being able to set up a
platform independent read/write file share can be useful. Generally,
inside trusted environments.

Mark

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



Re: [PROPOSAL] Tomcat 10: Remove Server-Side Includes (SSI)

2019-10-07 Thread Mark Thomas
> All,
> 
> I recently gave a presentation on locking-down Apache Tomcat[1] and I
> briefly discussed the "sharp edges" present in Tomcat. Some of them
> are unnecessarily sharp and may be actually unnecessary. I'm going to
> make a few proposals to remove functions from Tomcat.
> 
> Proposal: Remove Server-Side Includes

+1

> If the packaging of Tomcat could be tweaked a bit to move the SSI
> components into a separate JAR file (e.g. move
> org/apache/catalina/ssi/* to catalina-ssi.jar) and if the SSI
> components don't rely on any Tomcat specific capabilities or
> internals, then the cattalina-ssi.jar file could be used between
> Tomcat versions. For example, a user of Tomcat 10 who still needs SSI
> could get the SSI module from a distribution of Tomcat 8.5.x or 9.x.

Even if it depends on Tomcat internals, as long as those internals are
there in 10.0.x (and the same as 9.0.x) that would be an option. This is
something we could be looking at now.

Mark

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



Re: [PROPOSAL] Tomcat 10: Drop APR Connector

2019-10-07 Thread Mark Thomas
> All,
> 
> I recently gave a presentation on locking-down Apache Tomcat[1] and I
> briefly discussed the "sharp edges" present in Tomcat. Some of them
> are unnecessarily sharp and may be actually unnecessary. I'm going to
> make a few proposals to remove functions from Tomcat.
> 
> Proposal: Remove APR connector

+1

> This proposal does not recommend the removal of libtcnative. Only the
> removal of the APR connector, the APR lifecycle listener, and the
> associated native code required to support those components.

Yes, we'd need to keep that library going until at least 9.0.x is EOL.

There is then an argument for a new native library that simply wraps
OpenSSL (or ideally any OpenSSL clone). Project Panama may prove useful:
https://openjdk.java.net/projects/panama/

Mark

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



[VOTE] Release Apache Tomcat 8.5.47

2019-10-07 Thread Mark Thomas
The proposed Apache Tomcat 8.5.47 release is now available for voting.

The major changes compared to the 8.5.46 release are:

- Update to Commons Daemon 1.2.2 to pick up the fix for a regression in
  Commons Daemon 1.2.0 and 1.2.1 that triggered a crash on startup when
  running on a Windows OS that had not been fully updated.

- Fix some edge cases with NIO2 and TLS that could has a request to
  hang.


Along with lots of other bug fixes and improvements.

For full details, see the changelog:
https://ci.apache.org/projects/tomcat/tomcat85/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.47/

The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1234/

The tag is:
https://github.com/apache/tomcat/tree/8.5.47
14bdacea996993a3b94ec0972cea92370e42ae4d

The proposed 8.5.47 release is:
[ ] Broken - do not release
[ ] Stable - go ahead and release as 8.5.47

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



[VOTE] Release Apache Tomcat 9.0.27

2019-10-07 Thread Mark Thomas
The proposed Apache Tomcat 9.0.27 release is now available for voting.

The major changes compared to the 9.0.26 release are:

- Update to Commons Daemon 1.2.2 to pick up the fix for a regression in
  Commons Daemon 1.2.0 and 1.2.1 that triggered a crash on startup when
  running on a Windows OS that had not been fully updated.

- Fix some edge cases with NIO2 and TLS that could has a request to
  hang.

- Fix a memory leak introduced by the HTTP/2 timeout refactoring in
  9.0.23 that could occur when HTTP/2 or WebSocket was used.


Along with lots of other bug fixes and improvements.

For full details, see the changelog:
https://ci.apache.org/projects/tomcat/tomcat9/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.27/
The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1233/
The tag is:
https://github.com/apache/tomcat/tree/9.0.27


The proposed 9.0.27 release is:
[ ] Broken - do not release
[ ] Stable - go ahead and release as 9.0.27

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



Re: JDK 14 - Early Access build 17 is available

2019-10-07 Thread Mark Thomas
On 04/10/2019 10:30, Rory O'Donnell wrote:
> Hi Mark,
> 
> *OpenJDK builds  *- JDK 14 - Early Access build 17 is available at
> http://jdk.java.net/14/

9.0.x builds without error
9.0.x runs and passes a simple smoke test
9.0.x unit tests all pass

No concerns at this point.

Mark

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



Re: [Bug 63804] New: Problems with shutting down Apache Tomcat

2019-10-05 Thread Mark Thomas
> All,
> 
> On 10/4/19 11:39, bugzi...@apache.org wrote:
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=63804
> 
>> [snip]
> 
>> Is this by-definition a bug in Tomcat?
> 
> 
> 
>> Matt [spammy URLs gratuitously added to the end of he bug report
>> here]
> I think maybe we should remove those URLs from the bug report.
> 
> Who has karma to edit other users' comments in BZ?

No-one (directly). Comment editing isn't a feature Bugzilla provides.
You have to edit the database directly.

Given the lack of follow-up on the users list I'm inclined to treat the
while issue as spam, delete it and disable the associated user account.

Mark

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



Re: [Bug 63781] Prevent illegal reflective access warnings / errors from BeanELResolver

2019-10-04 Thread Mark Thomas
Hi,

Just a heads up the running the unit tests with later versions of Java
has highlighted an edge case that needs to be properly handled. I should
have it fixed soon(ish).

Mark


On 04/10/2019 17:58, bugzi...@apache.org wrote:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=63781
> 
> Mark Thomas  changed:
> 
>What|Removed |Added
> 
>  Status|NEW |RESOLVED
>  Resolution|--- |FIXED
> 
> --- Comment #4 from Mark Thomas  ---
> Fixed in:
> - master for 9.0.27 onwards
> - 8.5.x for 8.5.47 onwards
> - 7.0.x for 7.0.97 onwards
> 


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



Re: Tag Tomcat 7

2019-10-02 Thread Mark Thomas
On 01/10/2019 12:18, Mark Thomas wrote:
> On 01/10/2019 12:17, Violeta Georgieva wrote:
>> Hi Mark,
>>
>> На вт, 1.10.2019 г. в 13:58 ч. Mark Thomas > <mailto:ma...@apache.org>> написа:
>>>
>>> On 01/10/2019 11:09, Violeta Georgieva wrote:
>>>> Hi,
>>>>
>>>> I'm planning to tag Tomcat 7 later today.
>>>> If you want to include something please reply here.
>>>
>>> I am just looking at PR #170 that should backport to 7.0.x. I should be
>>> done in less than an hour.
>>>
>>> If you could delay the tag until after I have completed the back-port
>>> that would be great. Don't worry if not.
>>
>> Ok
>> Just let me know when you are ready.
> 
> Thanks. I'm done.

Actually...

Do you want to wait for the Commons Daemon 1.2.2 release?

Mark

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



Re: [tomcat] branch master updated: Add logging

2019-10-01 Thread Mark Thomas
On 01/10/2019 13:01, Rémy Maucherat wrote:
> On Tue, Oct 1, 2019 at 1:54 PM  <mailto: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 d8063b3  Add logging
> d8063b3 is described below
> 
> commit d8063b35b0a10afa3c8c666c135f13b801071555
> Author: Mark Thomas mailto:ma...@apache.org>>
> AuthorDate: Tue Oct 1 12:54:00 2019 +0100
> 
>     Add logging
> ---
>  java/org/apache/tomcat/util/compat/Jre9Compat.java         | 2 ++
>  java/org/apache/tomcat/util/compat/LocalStrings.properties | 2 ++
>  2 files changed, 4 insertions(+)
> 
> diff --git a/java/org/apache/tomcat/util/compat/Jre9Compat.java
> b/java/org/apache/tomcat/util/compat/Jre9Compat.java
> index 193ea5b..8d8af88 100644
> --- a/java/org/apache/tomcat/util/compat/Jre9Compat.java
> +++ b/java/org/apache/tomcat/util/compat/Jre9Compat.java
> @@ -104,8 +104,10 @@ class Jre9Compat extends JreCompat {
> 
>          } catch (ClassNotFoundException e) {
>              // Must be Java 8
> +            log.debug("jre9Compat.java8", e);
>          } catch (ReflectiveOperationException |
> IllegalArgumentException e) {
>              // Should never happen
> +            log.error("jre9Compat.unexpected", e);
> 
> 
> sm.getString is missing in both places. (since it's debug, it doesn't
> have to have i18n anyway imo)

Thanks. I'll fix that.

Fair point about debug. If it isn't translated it will use the English
so nothing is lost.

Mark


> 
> Rémy
>  
> 
>          }
> 
>          inaccessibleObjectExceptionClazz = c1;
> diff --git
> a/java/org/apache/tomcat/util/compat/LocalStrings.properties
> b/java/org/apache/tomcat/util/compat/LocalStrings.properties
> index 7d53957..b385a35 100644
> --- a/java/org/apache/tomcat/util/compat/LocalStrings.properties
> +++ b/java/org/apache/tomcat/util/compat/LocalStrings.properties
> @@ -14,6 +14,8 @@
>  # limitations under the License.
> 
>  jre9Compat.invalidModuleUri=The module URI provided [{0}] could not
> be converted to a URL for the JarScanner to process
> +jre9Compat.java8=Class not found so assuming code is running on Java 8
> +jre9Compat.unexpected=Failed to create references to Java 9 classes
> and methods
> 
>  jreCompat.noApplicationProtocol=Java Runtime does not support
> SSLEngine.getApplicationProtocol(). You must use Java 9 to use this
> feature.
>  jreCompat.noApplicationProtocols=Java Runtime does not support
> SSLParameters.setApplicationProtocols(). You must use Java 9 to use
> this feature.
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> <mailto:dev-unsubscr...@tomcat.apache.org>
> For additional commands, e-mail: dev-h...@tomcat.apache.org
> <mailto: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: Tag Tomcat 7

2019-10-01 Thread Mark Thomas
On 01/10/2019 12:17, Violeta Georgieva wrote:
> Hi Mark,
> 
> На вт, 1.10.2019 г. в 13:58 ч. Mark Thomas  <mailto:ma...@apache.org>> написа:
>>
>> On 01/10/2019 11:09, Violeta Georgieva wrote:
>> > Hi,
>> >
>> > I'm planning to tag Tomcat 7 later today.
>> > If you want to include something please reply here.
>>
>> I am just looking at PR #170 that should backport to 7.0.x. I should be
>> done in less than an hour.
>>
>> If you could delay the tag until after I have completed the back-port
>> that would be great. Don't worry if not.
> 
> Ok
> Just let me know when you are ready.

Thanks. I'm done.

Mark

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



Re: Tag Tomcat 7

2019-10-01 Thread Mark Thomas
On 01/10/2019 11:09, Violeta Georgieva wrote:
> Hi,
> 
> I'm planning to tag Tomcat 7 later today.
> If you want to include something please reply here.

I am just looking at PR #170 that should backport to 7.0.x. I should be
done in less than an hour.

If you could delay the tag until after I have completed the back-port
that would be great. Don't worry if not.

Mark

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



Re: buildbot failure in on tomcat-7-trunk

2019-09-27 Thread Mark Thomas
On 27/09/2019 13:02, Rémy Maucherat wrote:
> On Fri, Sep 27, 2019 at 12:49 PM Mark Thomas  <mailto:ma...@apache.org>> wrote:
> 
> On 26/09/2019 23:04, build...@apache.org
> <mailto:build...@apache.org> wrote:
> > 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/1465
> >
> > 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]
> d0685f927186da2e0be56c28371e5207ee09ed20
> > Blamelist: Mark Thomas mailto:ma...@apache.org>>
> >
> > BUILD FAILED: failed compile_1
> 
> That was unexpected. This appears to have been triggered by:
> 
> https://github.com/apache/tomcat/commit/247c8c32c44f65ce7bf3035541eedb8ffc97d5d0
> 
> Why this is the case isn't immediately obvious to me. I'm currently
> investigating.
> 
> The test seems to modify the listener array returned (it likely doesn't
> work now since it's a copy on write array following that commit), you
> apparently refactored that away in the new branches like 8.5 and the
> test looks much cleaner there.
> https://github.com/apache/tomcat/blob/master/test/org/apache/catalina/core/TestStandardContextResources.java#L128
> vs
> https://github.com/apache/tomcat/blob/7.0.x/test/org/apache/catalina/core/TestStandardContextResources.java#L132

Thanks. It hadn't even occurred to me to check what the test was doing.

I'll back-port the test refactoring from 8.5.x.

Mark

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



Re: buildbot failure in on tomcat-7-trunk

2019-09-27 Thread Mark Thomas
On 26/09/2019 23:04, build...@apache.org wrote:
> 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/1465
> 
> 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] d0685f927186da2e0be56c28371e5207ee09ed20
> Blamelist: Mark Thomas 
> 
> BUILD FAILED: failed compile_1

That was unexpected. This appears to have been triggered by:
https://github.com/apache/tomcat/commit/247c8c32c44f65ce7bf3035541eedb8ffc97d5d0

Why this is the case isn't immediately obvious to me. I'm currently
investigating.

Mark

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



Re: [tomcat] branch master updated: Fix test failures with APR/native.

2019-09-25 Thread Mark Thomas
On 25/09/2019 21:39, 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 bfff085  Fix test failures with APR/native.
> bfff085 is described below

My ideas with the blocking status locks didn't work as well as I hoped.
I could only fix the error if shutdown waited for all in-progress
blocking reads to complete or timeout. Given there are some WebSocket
scenarios that have very long blocking reads that didnlt seem like a
good idea.

I think the best thing to do is aim to minimise the chances of this
crash as much as practical. Given the tentative plan to remove native
I/O in Tomcat 10 I don't think it is worth spending time on the
significant refactoring that would be required for a more reliable solution.

Mark

> 
> commit bfff085526f4c3625316be311ca5b3dee41d83b3
> Author: Mark Thomas 
> AuthorDate: Wed Sep 25 21:39:30 2019 +0100
> 
> Fix test failures with APR/native.
> ---
>  test/org/apache/coyote/http11/filters/TestChunkedInputFilter.java | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git 
> a/test/org/apache/coyote/http11/filters/TestChunkedInputFilter.java 
> b/test/org/apache/coyote/http11/filters/TestChunkedInputFilter.java
> index 86e574e..a3a22d9 100644
> --- a/test/org/apache/coyote/http11/filters/TestChunkedInputFilter.java
> +++ b/test/org/apache/coyote/http11/filters/TestChunkedInputFilter.java
> @@ -404,6 +404,7 @@ public class TestChunkedInputFilter extends 
> TomcatBaseTest {
>  client.connect();
>  try {
>  client.processRequest();
> +client.disconnect();
>  } catch (Exception e) {
>  // Socket was probably closed before client had a chance to read
>  // response
> 
> 
> -
> 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: Performance bottleneck in WebappClassLoaderBase

2019-09-25 Thread Mark Thomas
This is a question, to start with at least, for the users mailing list.

Mark

On 25/09/2019 11:46, Gunnar Brand wrote:
> Hello.
> 
>  
> 
> Recently we received complaints from a customer about slow response
> times (45 seconds) every morning. Every morning starting a fresh session
> in the browser would require a long wait time for the first user, but
> once this hurdle had been taken everything seemed to work fine.
> 
> We could reproduce this in house, and doing a thread dump during this
> time span showed the class loader trying to open a jar file. Immediately
> we suspected a virus scanner slowing access to jar files (and since
> signatures are updated daily, this happened daily). Blocking the virus
> scanner from the tomcat folder helped but this is just alleviating the
> symptoms, not the cure. Doing a full trace log of the class loader
> package showed the problem:
> 
> For any unknown resource or class the class loader seems to populate all
> known jars, and either finds it, then loads it, and keeps a cache entry
> (with the class for classes), or if it can’t find it, asks the parent
> class loader (this is the spec order of things).
> 
> The log was filled classes and resources that couldn’t be found and were
> delegated to the parent. Over and over again. Each and every one of
> theses requests scans all jar files. Clear the OS cache and the problem
> appears, too.
> 
>  
> 
> For classes one would believe this cannot be, once a class is loaded,
> it’s loaded. But with dynamic script languages, they often use
> Class.forName() and for example Rhino even does that for packages (that
> might not even exist!).
> 
> We fixed at least Rhino with an application wide global top level , so
> for classes this problem did go away (there might be other, unless they
> implement their own caching, there is a risk).
> 
> Resources are still a problem, our log is filled with
> 
> 24-Sep-2019 17:22:55.482 FINE [http-nio-8080-exec-6]
> org.apache.catalina.loader.WebappClassLoaderBase.findResources
> findResources(META-INF/services/javax.xml.parsers.DocumentBuilderFactory)
> 
> 24-Sep-2019 17:22:55.484 FINE [http-nio-8080-exec-6]
> org.apache.catalina.loader.WebappClassLoaderBase.getResourceAsStream
> getResourceAsStream(META-INF/services/org.apache.xerces.xni.parser.XMLParserConfiguration)
> 
> 24-Sep-2019 17:22:55.484 FINE [http-nio-8080-exec-6]
> org.apache.catalina.loader.WebappClassLoaderBase.getResourceAsStream  
> Searching local repositories
> 
> 24-Sep-2019 17:22:55.485 FINE [http-nio-8080-exec-6]
> org.apache.catalina.loader.WebappClassLoaderBase.getResourceAsStream  
> Delegating to parent classloader unconditionally
> java.net.URLClassLoader@578486a3
> 
> 24-Sep-2019 17:22:55.485 FINE [http-nio-8080-exec-6]
> org.apache.catalina.loader.WebappClassLoaderBase.getResourceAsStream  
> --> Resource not found, returning null
> 
> If there is only a single repeated “Searching local repositories” for a
> certain URL, the problem is there (doesn’t matter if the resource or
> class exists  or not).
> 
>  
> 
> It’s obviously a bad idea to scan the filesystem or jars every time.
> 
> The WebappClassLoaderBase keeps information about every resource and
> class it finds, so repeated calls for these do not cost that much time,
> especially for classes that are stored in the cache.
> 
> I believe it might work to keep a negative entry for classes it doesn’t
> find but the parent class loader knows and immediately ask the parent
> class loader. Maybe also for resources. But I don’t know what is
> supposed to happen if somebody overwrites a resource (or class) later.
> 
> Even worse if the class/resource does not exist yet. Maybe populating
> the whole resource tree in memory is the only solution (with background
> update?!) .
> 
>  
> 
> I mainly wanted to raise awareness of this problem, I am not well versed
> with class loading, so I can’t really help there.
> 
>  
> 
> Sincerely,
> 
> Gunnar Brand
> 
>  
> 
>  
> 
>  
> 
> Gunnar Brand | Softwareentwickler
> 
> interface projects GmbH | www.intergator.de
> 
> Zwinglistraße 11/13 | 01277 Dresden | Deutschland
> 
> Tel: +49-351-31809-41 | Fax: +49-351-31809-33
> 
>  
> 
> Folgen Sie intergator auf:
> 
> Twitter : https://twitter.com/intergator
> 
> xing    : https://www.xing.com/companies/interfaceprojectsgmbh
> 
> LinkedIn: http://www.linkedin.com/company/interface-projects-gmbh
> 
> YouTube : http://www.youtube.com/user/TheEnterpriseSearch?feature=watch
> 
> Facebook: https://www.facebook.com/intergator/
> 
> RSS : https://www.intergator.de/feed/
> 
>  
> 
> Geschäftsführer: Dr. Uwe Crenze, Eduard Daoud
> 
> Amtsgericht Dresden HRB 8740
> 
>  
> 
> Haftungsausschluss / Disclaimer
> 
> http://www.intergator.de/email-disclaimer.shtml
> 
>  
> 


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



Re: buildbot failure in on tomcat-trunk

2019-09-24 Thread Mark Thomas
On 24/09/2019 17:36, build...@apache.org wrote:
> The Buildbot has detected a new failure on builder tomcat-trunk while 
> building tomcat. Full details are available at:
> https://ci.apache.org/builders/tomcat-trunk/builds/4625
> 
> Buildbot URL: https://ci.apache.org/
> 
> Buildslave for this Build: asf946_ubuntu
> 
> Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-commit' 
> triggered this build
> Build Source Stamp: [branch master] 709978183d763b27009b0d02908ae1eda50308dd
> Blamelist: Mark Thomas ,remm 
> 
> BUILD FAILED: failed compile_1

This is back now I have reverted the incorrect that just changed the
timing enough to reduce the chances of this.

Still working on a proper fix.

Mark

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



[ANN] Apache Tomcat 8.5.46 available

2019-09-20 Thread Mark Thomas
The Apache Tomcat team announces the immediate availability of Apache
Tomcat 8.5.46.

Apache Tomcat 8 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and Java Authentication Service Provider Interface for
Containers technologies.

Apache Tomcat 8.5.x replaces 8.0.x and includes new features pulled
forward from the 9.0.x branch. The notable changes since 8.5.45 include:

- Update to Commons Daemon 1.2.1 to pick up fixes for regressions in
  Commons Daemon 1.2.0, most notably a failure to start when using
  a 32-bit JVM on Windows.

- Avoid an NPE when accessing an https port using http.

- Fix a potential hang when using HTTP/2 with the asynchronous Servlet
  API.

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

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

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

Enjoy!

- The Apache Tomcat team


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



[ANN] Apache Tomcat 9.0.26 available

2019-09-20 Thread Mark Thomas
The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.26.

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

Apache Tomcat 9.0.26 is a bugfix and feature release. The notable
changes compared to 9.0.24 include:


- Update to Commons Daemon 1.2.1 to pick up fixes for regressions in
  Commons Daemon 1.2.0, most notably a failure to start when using
  a 32-bit JVM on Windows.

- Avoid an NPE when accessing an https port using http.

- Correct the invalid automatic module names for the embedded JARs.

- Fix a potential hang when using HTTP/2 with the asynchronous Servlet
  API.

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


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

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

Enjoy!

- The Apache Tomcat team


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



Re: [tomcat] branch master updated: Fix test failures caused by APR crash during shutdown

2019-09-20 Thread Mark Thomas
On 19/09/2019 20:39, Mark Thomas wrote:
> On 19/09/2019 19:57, 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 9825246  Fix test failures caused by APR crash during shutdown
>> 9825246 is described below
>>
>> commit 9825246d0ce833552a3745ac3b02a44551789caa
>> Author: Mark Thomas 
>> AuthorDate: Thu Sep 19 19:56:23 2019 +0100
>>
>> Fix test failures caused by APR crash during shutdown
>> 
>> When a request thread was still trying to read/write from/to the socket,
>> the socket wrapper was not marked as closed so the thread tried to use
>> an APR socket that the POller then closed. Trying to read/write from a
>> closed APR socket will nearly always trigger a crash.
> 
> Hmm. Maybe not as successful as I had hoped. The chances of a crash
> appear to have reduced but crashes do still occur. It looks like one
> root cause has been fixed but that there is still at least one more root
> cause to track down. I'll take another look.

Looking at this more closely, this isn't fixing a root cause it is just
altering the timing slightly - enough to reduce the chance of the issue
occurring.

I intend to revert the above fix and work on an alternative.

Mark

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



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

2019-09-19 Thread Mark Thomas
The following votes were cast:

Binding:

+1: michaelo, remm, isapir, fschumacher, markt

No other votes were cast. The vote therefore passes.

Thanks to everyone who contributed towards this release.

Mark

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

2019-09-19 Thread Mark Thomas
On 16/09/2019 19:46, Mark Thomas wrote:
> The proposed 8.5.46 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 8.5.46

Unit tests passed for NIO, NIO2 and APR with Tomcat Native 1.2.23 on
Linux, Windows and MacOS.

Mark

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



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

2019-09-19 Thread Mark Thomas
The following votes were cast:

Binding:
+1: ebourg, isapir, remm, fschumacher, markt

No other votes were cast.

The vote therefore passes.

Thanks to everyone who contributed to this release.

Mark



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

2019-09-19 Thread Mark Thomas
On 16/09/2019 17:15, Mark Thomas wrote:
> The proposed 9.0.26 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 9.0.26

Unit tests pass on Linux, MacOS and Windows with Tomcat Native 1.2.23
for NIO, NIO2 and APR.

Mark

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



Re: [tomcat] branch master updated: Fix test failures caused by APR crash during shutdown

2019-09-19 Thread Mark Thomas
On 19/09/2019 19:57, 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 9825246  Fix test failures caused by APR crash during shutdown
> 9825246 is described below
> 
> commit 9825246d0ce833552a3745ac3b02a44551789caa
> Author: Mark Thomas 
> AuthorDate: Thu Sep 19 19:56:23 2019 +0100
> 
> Fix test failures caused by APR crash during shutdown
> 
> When a request thread was still trying to read/write from/to the socket,
> the socket wrapper was not marked as closed so the thread tried to use
> an APR socket that the POller then closed. Trying to read/write from a
> closed APR socket will nearly always trigger a crash.

Hmm. Maybe not as successful as I had hoped. The chances of a crash
appear to have reduced but crashes do still occur. It looks like one
root cause has been fixed but that there is still at least one more root
cause to track down. I'll take another look.

Mark


> ---
>  java/org/apache/tomcat/util/net/AprEndpoint.java | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/java/org/apache/tomcat/util/net/AprEndpoint.java 
> b/java/org/apache/tomcat/util/net/AprEndpoint.java
> index 46c7047..6dde69c 100644
> --- a/java/org/apache/tomcat/util/net/AprEndpoint.java
> +++ b/java/org/apache/tomcat/util/net/AprEndpoint.java
> @@ -1126,8 +1126,11 @@ public class AprEndpoint extends 
> AbstractEndpoint implements SNICallB
>  // Close all sockets in the add queue
>  info = addList.get();
>  while (info != null) {
> -// Make sure the  socket isn't in the poller before we close 
> it
> +// Make sure the socket isn't in the poller before we close 
> it
>  removeFromPoller(info.socket);
> +// Close the SocketWrapper to prevent any still running 
> application
> +// threads from trying to use the socket
> +connections.get(Long.valueOf(info.socket)).close();
>  // Poller isn't running at this point so use destroySocket()
>  // directly
>  destroySocket(info.socket);
> 
> 
> -
> 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: Better support for OpenJSSE?

2019-09-19 Thread Mark Thomas
On 19/09/2019 09:27, Rainer Jung wrote:



> I made a patch to detect ALPN support at runtime using reflection.
> Please have a look. Feedback welcome, whether we want to include that or
> whether we want to stick with the simpler approach we currently use.

Past experience suggests a lot of users will be on Java 8 for quite some
time. I think it makes sense to support this.

> Of
> course the windows for Java 8 plus OpenJSSE is getting smaller over
> time, and users could also use tcnative to get TLS 1.3 and HTTP/2. On
> the other hand integration of OpenJSSE is pretty simple and some users
> don't like native code in their JVM (and its maintenance). IMHO support
> for OpenJSSE (including HTTP/2) would be a nice addition.
> 
> My TC 9 patch is available under:
> 
> http://home.apache.org/~rjung/patches/tc9-openjsse.patch
> 
> It moves the ALPN detection from classes Jre(9)Compat to class TLS in
> the same package and uses the same approach that we use for other
> runtime detection. It needs to make one method accessible, because under
> Java 9+ the implementation class SSLEngineImpl is no longer a public
> class. Since it is accessed normally via SSLEngine, direct method calls
> still work, but reflective calls no longer.

Currently TLS.java is only used by the unit tests.

We only need to use reflection on Java 8 since we know ALPN is available
on Java 9 onwards.

The module system adds additional restrictions to calling
setAccessible() that might cause problems in the future.

I wonder if a cleaner solution might be:

- Move isTlsv13Available to TesterSupport and deprecate TLS.java

- Add isAlpnAvailable() to JreCompat where:
  - Java 7 (for 8.5.x) hard codes to false
  - Java 8 uses reflection
  - Java 9 hard codes to true

Mark

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



Re: [Bug 61441] daemon.sh's auto-detection fails on linux system's where java is installed via an RPM

2019-09-19 Thread Mark Thomas
On 19/09/2019 08:07, Felix Schumacher wrote:
> That is obviously spam.

When discussing spam please don't quote the material - particularly any
links - as getting the links published as many times as possible is the
aim of the spam.

> My question here is, what is the official way to
> get rid of such entries?

Officially, the process is email bugzilla-admin@a.o and ask them to:
- disable the account
- delete the spam comment

Since that email lands in my inbox I tend to skip the sending the email
bit ;)

If you want to help out - help is always appreciated - I can give you
the BZ karma necessary to disable accounts. You usually need to do a
little poking around to see if they have created any other comments as
they tend to spread them over several projects.

Deleting the comments requires executing SQL directly on the database.

Mark

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



Re: Tomcat 7.0.96 - Issue with Kerberos Authentication

2019-09-18 Thread Mark Thomas
This is a question for the users list.

And a review of the recent archives for that list will find a similar
question along with a solution.

Mark


On 18/09/2019 11:35, Mehta, Vipul wrote:
> In case of Kerberos authentication of user with tomcat webapp via
> browser, we are facing issue with following class in tomcat version 7.0.96:
> 
> https://github.com/apache/tomcat/blob/7.0.x/java/org/apache/catalina/connector/Request.java
> 
>  
> 
> public Principal getUserPrincipal()
> 
> => return ((GenericPrincipal) userPrincipal).getUserPrincipal(); #LINE-2650
> 
>  
> 
> This returns javax.security.auth.kerberos.KerberosPrincipal instance
> using which it is not possible to get the actual delegated credential.
> 
> Shouldn’t it simply return GenericPrincipal instance which contains
> KerberosPrincipal as well as delegated GSSCredential ?
> 
>  
> 
> We are using following realm config in server.xml:
> 
>  className="org.apache.catalina.realm.JAASRealm"
> roleClassNames="org.apache.catalina.realm.GenericPrincipal"
> stripRealmForGss="false" useContextClassLoader="false"
> userClassNames="org.apache.catalina.realm.GenericPrincipal,
> javax.security.auth.kerberos.KerberosPrincipal"/>
> 
>  
> 
>  
> 
> Thanks,
> 
> Vipul
> 
>  
> 


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

2019-09-17 Thread Mark Thomas
On 17/09/2019 19:46, Igal Sapir wrote:
> On 9/16/2019 9:15 AM, Mark Thomas wrote:
>> The proposed Apache Tomcat 9.0.26 release is now available for voting.
>>
>> The major changes compared to the 9.0.24 release are:
>>
>> - Update to Commons Daemon 1.2.1 to pick up fixes for regressions in
>>   Commons Daemon 1.2.0, most notably a failure to start when using
>>   a 32-bit JVM on Windows.
>>
>> - Avoid an NPE when accessing an https port using http.
>>
>> - Correct the invalid automatic module names for the embedded JARs.
>>
>> - Fix a potential hang when using HTTP/2 with the asynchronous Servlet
>>   API.
>>
>> 
>>
>> The proposed 9.0.26 release is:
>> [ ] Broken - do not release
>> [X] Stable - go ahead and release as 9.0.26
> 
> Tested with Ubuntu and Windows.
> 
> On Windows I received an error on
> org.apache.catalina.core.TestAsyncContextImpl which tests bug 50753.  I
> think it is a fluke in the test case though.  Details below [1].
> 
> Igal
> 
> [1] Testsuite: org.apache.catalina.core.TestAsyncContextImpl
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0 sec
> 
> Testcase: testBug50753 took 0.004 sec
>   Caused an ERROR
> Forked Java VM exited abnormally. Please note the time in the report does not 
> reflect the time until the VM exit.
> junit.framework.AssertionFailedError: Forked Java VM exited abnormally. 
> Please note the time in the report does not reflect the time until the VM 
> exit.
>   at java.lang.Thread.run(Thread.java:748)

That usually indicates an APR/native crash during Windows shutdown. It
means we have a (possibly timing related) bug in the APR/native code we
still haven't tracked down. That they aren't easy to reproduce makes
fixing bugs like this tricky.

Mark

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



Re: [tomcat] branch master updated: Only decode in standard mode.

2019-09-17 Thread Mark Thomas
On 01/08/2019 22:55, 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 9fd972c  Only decode in standard mode.
> 9fd972c is described below
> 
> commit 9fd972c931cf3ce8829a69437b7340f9b0e1e731
> Author: Mark Thomas 
> AuthorDate: Thu Aug 1 22:54:41 2019 +0100
> 
> Only decode in standard mode.
> 
> The seamless decoding of both standard and URL-safe mode no longer works
> as expected in some cases when one of the two characters from the other
> mode appear in the encoded data. This is because rather than ignoring
> the unexpected "-" or "_" it gets decoded and if the result is invalid
> an exception is thrown due to the fix for CODEC-134.
> Tomcat doesn't use URL-safe mode so simply disable it.

I've discovered some TCK failures as a result of this change. The
HTTP2-Settings header present in an HTTP upgrade for h2c uses the
URL-safe form of base64 encoding.

The good news is that it is only h2c that is affected so the impact on
end users should be minimal.

I think I am going to have to tweak the codec so that users can opt for
standard or URL-safe mode as required. That looks doable without too
invasive a change. I'll look into applying the fix upstream.

Mark

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



[VOTE] Release Apache Tomcat 8.5.46

2019-09-16 Thread Mark Thomas
The proposed Apache Tomcat 8.5.46 release is now available for voting.

The major changes compared to the 8.5.45 release are:

- Update to Commons Daemon 1.2.1 to pick up fixes for regressions in
  Commons Daemon 1.2.0, most notably a failure to start when using
  a 32-bit JVM on Windows.

- Avoid an NPE when accessing an https port using http.

- Fix a potential hang when using HTTP/2 with the asynchronous Servlet
  API.

Along with lots of other bug fixes and improvements.

For full details, see the changelog:
https://ci.apache.org/projects/tomcat/tomcat85/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.46/

The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1231/

The tag is:
https://github.com/apache/tomcat/tree/8.5.46
914f68b45127207170dff894e03ec31732cac898

The proposed 8.5.46 release is:
[ ] Broken - do not release
[ ] Stable - go ahead and release as 8.5.46

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



[VOTE] Release Apache Tomcat 9.0.26

2019-09-16 Thread Mark Thomas
The proposed Apache Tomcat 9.0.26 release is now available for voting.

The major changes compared to the 9.0.24 release are:

- Update to Commons Daemon 1.2.1 to pick up fixes for regressions in
  Commons Daemon 1.2.0, most notably a failure to start when using
  a 32-bit JVM on Windows.

- Avoid an NPE when accessing an https port using http.

- Correct the invalid automatic module names for the embedded JARs.

- Fix a potential hang when using HTTP/2 with the asynchronous Servlet
  API.

Along with lots of other bug fixes and improvements.

For full details, see the changelog:
https://ci.apache.org/projects/tomcat/tomcat9/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.26/
The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1230/
The tag is:
https://github.com/apache/tomcat/tree/9.0.26


The proposed 9.0.26 release is:
[ ] Broken - do not release
[ ] Stable - go ahead and release as 9.0.26

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



[VOTE][CANCELLED] Release Apache Tomcat 9.0.25

2019-09-16 Thread Mark Thomas
I messed up the tagging procedure again.

I need to re-tag.

Sorry.

Mark

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



Re: [tomcat] 01/01: Tag 9.0.25

2019-09-16 Thread Mark Thomas
On 16/09/2019 14:23, Rainer Jung wrote:
> The BOM in changelog.xml is back, at least in the tag, letting
> checkstyle fail. See below.

Thanks for spotting this. I thought I checked that. Obviously not
carefully enough.

I'll re-roll the release.

Mark


> 
> Am 16.09.2019 um 13:55 schrieb ma...@apache.org:
>> This is an automated email from the ASF dual-hosted git repository.
>>
>> markt pushed a commit to tag 9.0.25
>> in repository https://gitbox.apache.org/repos/asf/tomcat.git
>>
>> commit fad275b0541595ea89e59f5cb024ada531d5dbe4
>> Author: Mark Thomas 
>> AuthorDate: Mon Sep 16 12:54:37 2019 +0100
>>
>>  Tag 9.0.25
>> ---
>>   build.properties.default   | 2 +-
>>   webapps/docs/changelog.xml | 4 ++--
>>   2 files changed, 3 insertions(+), 3 deletions(-)
>>
> ...
>> diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
>> index c223a4c..d5328c9 100644
>> --- a/webapps/docs/changelog.xml
>> +++ b/webapps/docs/changelog.xml
>> @@ -1,4 +1,4 @@
>> -
>> +
> 
> I think that hunk points to where the BOM reappeared.
> 
>>    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



[VOTE] Release Apache Tomcat 9.0.25

2019-09-16 Thread Mark Thomas
The proposed Apache Tomcat 9.0.25 release is now available for voting.

The major changes compared to the 9.0.24 release are:

- Update to Commons Daemon 1.2.1 to pick up fixes for regressions in
  Commons Daemon 1.2.0, most notably a failure to start when using
  a 32-bit JVM on Windows.

- Avoid an NPE when accessing an https port using http.

- Correct the invalid automatic module names for the embedded JARs.

- Fix a potential hang when using HTTP/2 with the asynchronous Servlet
  API.

Along with lots of other bug fixes and improvements.

For full details, see the changelog:
https://ci.apache.org/projects/tomcat/tomcat9/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.25/
The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1229/
The tag is:
https://github.com/apache/tomcat/tree/9.0.25


The proposed 9.0.25 release is:
[ ] Broken - do not release
[ ] Stable - go ahead and release as 9.0.25

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



[CONF] Apache Tomcat > Security

2019-09-16 Thread Mark Thomas (Confluence)
Title: Message Title



 
 
 
There's 2 new edits on this page 
 
 
 
 
 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Security 
 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
Mark Thomas edited this page 
 
 
  
 
 

 
 
 
  
 
 
  
 
 
  
 
 
 
 
 
 
 
 
 
 
Here's the version comment 
 
 
 
 
 
 
 
 
 
 
 
 
 
  
 
 
  
 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
Mark Thomas edited at 08:27 AM 
 
 
  
 
 

 
 
 
 
 
 
 
 
 Removed links to deleted pages  
 
 
  
 
 
  
 
 

 
 
 
  
 
 
  
 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Here's what changed: 
 
 
 
 
 
 
 
 
 
 
 ... 
 
 How do I use OpenSSL to set up my own Certificate Authority (CA)?  
 Oh no! Port 8005 is available for anyone on localhost to shutdown my tomcat!  
 What about Tomcat running as root?  
 How do I force all my pages to run under HTTPS?  
 What is the default login for the manager and admin app?  
 How do I restrict access by ip address or remote host?  
 How do I use jsvc/procrun to run Tomcat on port 80 securely?  
 Has Tomcat's security been independently analyzed or audited?  
 How do I change the Server header in the response?  
 Why are passwords in plain text?  
 How can I restrict the list of ciphers used for HTTPS?  
 Is Tomcat vulnerable to Heartbleed bug?  
 Is Tomcat vulnerable to POODLE attack?  
 Which cipher suites should I use?  
 ... We have a page dedicated to this topic. FAQ/ Password   
 
 
 
 Anchor 
 
 
 
 
 
 
 
 
 
Q11 
 
 
 
Q11 
 
 
  
 
 
  How can I restrict the list of ciphers used for HTTPS? See HowTo SSLCiphers.  
 
 
 
 Anchor 
 
 
 
 
 
 
 
 
 
Q12 
 
 
 
Q12 
 
 
  
 
 
   Is Tomcat vulnerable to Heartbleed bug?   See Security/Heartbleed.  ...  Is Tomcat vulnerable to POODLE attack?   See Security/POODLE.  ... Which cipher suites should I use? ...  
 
 
  
 
 
  
 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Go to page history 
 
 
  
 
 
  
 
 
  
 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
View page 
 
 
  
 
 
  
 
 
  
 
 
  
 
 
 
 
 
 
 
 
 
 
Stop watching space
• 
 
 
 
 
 
 
Manage notifications 
 
 
 
 
 
 
 
 
 
 
  
 
 
This message was sent by Atlassian Confluence 6.15.8  
 
 
  
 
 
 
 
 
 
 
 
 




Re: [tomcat] 02/02: Additional changes required to enable EnvironmentPropertySource

2019-09-15 Thread Mark Thomas
On 14/09/2019 20:01, Felix Schumacher wrote:
> 
> Am 12.09.19 um 22:40 schrieb ma...@apache.org:
>> 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
>>
>> commit cae17a52598393680952aa21cee0e27b13a73455
>> Author: Mark Thomas 
>> AuthorDate: Thu Sep 12 15:31:26 2019 +0100
>>
>> Additional changes required to enable EnvironmentPropertySource
>> ---
>>  .../org/apache/tomcat/util/IntrospectionUtils.java | 49 
>> --
>>  java/org/apache/tomcat/util/digester/Digester.java | 33 ++-
>>  webapps/docs/changelog.xml |  4 +-
>>  3 files changed, 69 insertions(+), 17 deletions(-)
>>
>> diff --git a/java/org/apache/tomcat/util/IntrospectionUtils.java 
>> b/java/org/apache/tomcat/util/IntrospectionUtils.java
>> index 3ffa702..f6ac737 100644
>> --- a/java/org/apache/tomcat/util/IntrospectionUtils.java
>> +++ b/java/org/apache/tomcat/util/IntrospectionUtils.java
>> @@ -476,9 +499,27 @@ public final class IntrospectionUtils {
>>  // This provides a layer of abstraction
>>  
>>  public static interface PropertySource {
>> -
>>  public String getProperty(String key);
>> -
>>  }
>>  
>> +
>> +public static interface PropertySourceSecure extends PropertySource {
> 
> I think a better name would be SecurePropertySource or
> ClassloaderAwarePropertySource. The thing that it represents should be
> at the end of the name IMHO.

Fair enough. I prefer "SecurePropertySource" so I'll go with that before
I tag.

> At work I prototyped a similar approach and introduced a
> NamespaceAwarePropertySource. It is basically an interface that has a
> getNamespace() method that returns a prefix for the keys. I think that
> it would be nice if these two approaches.

Sorry, I'm not quite understanding how this works or the use case it is
trying to address. Could you provide a simple example?

> My prototype didn't try to
> call a security manager, but with this commit it would be easy to add.
> 
> On the other hand it uses a ServiceLoader approach to automatically find
> all NamespaceAwarePropertySources. Do you think this would be a good
> addition for Tomcat?

There is an entry in TOMCAT-NEXT around reducing the use of system
properties. A ServiceLoader approach may be a good solution for some of
those.

Mark

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



Tagging 9.0.x

2019-09-02 Thread Mark Thomas
Hi all,

It is a new month so I am thinking about the next tag. It looks like we
have got to the bottom of the 32-bit crashes with Commons Daemon so my
rough plan is:

- fix the 32-bit crash
- fix a couple of other minor regressions
- release Commons Daemon 1.2.1
- update 9.0.x, 8.5.x and 7.0.x to Commons Daemon 1.2.1
- tag 9.0.x and 8.5.x

While I am waiting for the Commons Daemon release vote, I plan to work
on the open Tomcat issues. Best guess is that I'll tag around the middle
of next week.

Mark

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



Re: [Bug 63699] craigwende...@gmail.com

2019-08-30 Thread Mark Thomas
On 30/08/2019 05:25, bugzi...@apache.org wrote:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=63699

And this idiot has been blocked from Bugzilla.

Mark


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



Re: [GitHub] [tomcat] sk8k opened a new pull request #198: commit desi.test

2019-08-30 Thread Mark Thomas
On 29/08/2019 22:00, GitBox wrote:
> sk8k opened a new pull request #198: commit desi.test
> URL: https://github.com/apache/tomcat/pull/198

This idiot has been blocked from ASF repos and reported to GitHub.

Mark


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



Re: Malicious bugzilla attachment? [Was: [Bug 63695] session_cookie attribute does not work?]

2019-08-29 Thread Mark Thomas
On August 29, 2019 8:52:57 AM UTC, Rainer Jung  wrote:
>Am 29.08.2019 um 09:55 schrieb Mark Thomas:
>> That looks suspicious on multiple levels.
>> 
>> I'll block the user account and delete the attachment. I'm also
>tempted
>> to resolve the issue as invalid. Any objections?
>
>Thanks for taking actions. I have replied in the ticket, because I
>think 
>it's a misconfiguration. I would give the user a chance to report back,
>
>because apart from the broken attachment he provided reasonable info,
>so 
>I think the ticket is not fake. If it turns out to be a 
>misconfiguration, then of course it is invalid. If we would have 
>responded sooner as we did now, we would have pointed him to the users 
>list. But since he actually tried to dig into it, I would find it more 
>friendly to give him a final chance to check my hint how to fix the
>config.


Ack. I'll need to unblock the account. Should be done is 5 to 10 mins.

Mark


>Regards,
>
>Rainer
>
>> Mark
>> 
>> 
>> On 29/08/2019 10:47, Rainer Jung wrote:
>>> I don't know whether this attachment is just broken or some kind of
>>> attack. We might want to delete it if possible.
>>>
>>> It has suffix .pptx but neither Ooo, nor LibreOffice or Powerpoint
>show
>>> correct content. The file starts with a magic header "NASCA DRM FILE
>-
>>> VER1.00".
>>>
>>> Regards,
>>>
>>> Rainer
>>>
>>> Am 29.08.2019 um 09:23 schrieb bugzi...@apache.org:
>>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=63695
>>>>
>>>> --- Comment #3 from kimc@gmail.com ---
>>>> Created attachment 36741
>>>>     -->
>https://bz.apache.org/bugzilla/attachment.cgi?id=36741=edit
>>>> jk_lb_worker.c modification
>>>>
>>>> Showing how I modified the source code
>
>-
>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: Malicious bugzilla attachment? [Was: [Bug 63695] session_cookie attribute does not work?]

2019-08-29 Thread Mark Thomas
That looks suspicious on multiple levels.

I'll block the user account and delete the attachment. I'm also tempted
to resolve the issue as invalid. Any objections?

Mark


On 29/08/2019 10:47, Rainer Jung wrote:
> I don't know whether this attachment is just broken or some kind of
> attack. We might want to delete it if possible.
> 
> It has suffix .pptx but neither Ooo, nor LibreOffice or Powerpoint show
> correct content. The file starts with a magic header "NASCA DRM FILE -
> VER1.00".
> 
> Regards,
> 
> Rainer
> 
> Am 29.08.2019 um 09:23 schrieb bugzi...@apache.org:
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=63695
>>
>> --- Comment #3 from kimc@gmail.com ---
>> Created attachment 36741
>>    --> https://bz.apache.org/bugzilla/attachment.cgi?id=36741=edit
>> jk_lb_worker.c modification
>>
>> Showing how I modified the source code
> 
> -
> 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: buildbot failure in on tomcat-7-trunk

2019-08-23 Thread Mark Thomas
To save others digging:

https://ci.apache.org/projects/tomcat/tomcat7/logs/1431/TEST-org.apache.catalina.connector.TestCoyoteAdapterRequestFuzzing.APR.txt

One of the fuzzing tests triggered a connection reset rather than a
clean close. Worth digging into why but not a major issue.

Mark


On 22/08/2019 10:40, build...@apache.org wrote:
> 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/1431
> 
> 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] 29fd3a45b909ba2a10792f9641b50ac81c285762
> Blamelist: Mark Thomas 
> 
> BUILD FAILED: failed compile_1
> 
> Sincerely,
>  -The Buildbot
> 
> 
> 
> 
> -
> 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



[ANN] Apache Tomcat 8.5.45 available

2019-08-22 Thread Mark Thomas
The Apache Tomcat team announces the immediate availability of Apache
Tomcat 8.5.45.

Apache Tomcat 8 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and Java Authentication Service Provider Interface for
Containers technologies.

Apache Tomcat 8.5.x replaces 8.0.x and includes new features pulled
forward from the 9.0.x branch. The notable changes since 8.5.43 include:

- Expand the HTTP/2 excessive overhead protection to cover various forms
  of abusive client behaviour and close the connection if any such
  behaviour is detected.

- Security improvements to the Windows installer including a change in
  the default user from Local System to Local Service.


- Improve handling of invalid requests so that 400 responses are
  returned to the client rather than 500 responses.


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

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

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

Enjoy!

- The Apache Tomcat team


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



[VOTE][RESULT] Release Apache Tomcat 8.5.45

2019-08-21 Thread Mark Thomas
The following votes were cast:

Binding:
+1: isapir, markt, michaelo, mgrigorov

No other votes were cast.

The vote therefore passes.

Thanks to everyone who contributed to this release.

Mark


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



[ANN] Apache Tomcat 9.0.24 available

2019-08-19 Thread Mark Thomas
The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.24.

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

Apache Tomcat 9.0.24 is a bugfix and feature release. The notable
changes compared to 9.0.22 include:

- Expand Graal native image support to include JNDI, JSPs and JULI

- Expand the HTTP/2 excessive overhead protection to cover various forms
  of abusive client behaviour and close the connection if any such
  behaviour is detected.

- Security improvements to the Windows installer including a change in
  the default user from Local System to Local Service.

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


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

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

Enjoy!

- The Apache Tomcat team


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



[VOTE][RESULT] Release Apache Tomcat 9.0.24

2019-08-17 Thread Mark Thomas
The following votes were cast:

Binding:
+1: mgrigorov, isapir, markt, remm

No other votes were cast.

The vote therefore passes.

Thanks to everyone who contributed to this release.


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

2019-08-15 Thread Mark Thomas
On 14/08/2019 23:48, Mark Thomas wrote:
> The proposed Apache Tomcat 8.5.45 release is now available for voting.
> 
> The major changes compared to the 8.5.43 release are:
> 
> - Expand the HTTP/2 excessive overhead protection to cover various forms
>   of abusive client behaviour and close the connection if any such
>   behaviour is detected.
> 
> - Security improvements to the Windows installer including a change in
>   the default user from Local System to Local Service.
> 
> - Improve handling of invalid requests so that 400 responses are
>   returned to the client rather than 500 responses.
> 
> Along with lots of other bug fixes and improvements.
> 
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat85/docs/changelog.html
> 
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.45/
> 
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1228/
> 
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.45
> 46d444a14cdac3e7e1f011a02cbdac9e5a80631c
> 
> The proposed 8.5.45 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 8.5.45

Tested NIO, NIO2 and APR/Native (1.2.23) on Linux MacOS and Windows.

All tests passed.

Mark

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

2019-08-15 Thread Mark Thomas
On 14/08/2019 22:45, Mark Thomas wrote:



> The proposed 9.0.24 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 9.0.24

Tested NIO, NIO2 and APR/Native (1.2.23) on Linux MacOS and Windows.

All tests passed.

Mark

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



[VOTE] Release Apache Tomcat 8.5.45

2019-08-14 Thread Mark Thomas
The proposed Apache Tomcat 8.5.45 release is now available for voting.

The major changes compared to the 8.5.43 release are:

- Expand the HTTP/2 excessive overhead protection to cover various forms
  of abusive client behaviour and close the connection if any such
  behaviour is detected.

- Security improvements to the Windows installer including a change in
  the default user from Local System to Local Service.

- Improve handling of invalid requests so that 400 responses are
  returned to the client rather than 500 responses.

Along with lots of other bug fixes and improvements.

For full details, see the changelog:
https://ci.apache.org/projects/tomcat/tomcat85/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.45/

The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1228/

The tag is:
https://github.com/apache/tomcat/tree/8.5.45
46d444a14cdac3e7e1f011a02cbdac9e5a80631c

The proposed 8.5.45 release is:
[ ] Broken - do not release
[ ] Stable - go ahead and release as 8.5.45

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

2019-08-14 Thread Mark Thomas
On 14/08/2019 22:56, Guild, Jason A (DOT) wrote:
> Hi Mark:
> 
> Glad to see the privilege reduction.
> 
> I don't use the Windows installer.
> WRT the change below, I am wondering if this will also be the case for 
> service installation by tomcat9.exe via the bin\service.bat script.
> 
> I am hoping the tomcat9.exe will somehow be doing the equivalent of:
> sc config my-tomcat-service-name obj= "NT AUTHORITY\LocalService" 
> password= ""
> 
> Any info you can provide is appreciated.

Yes, the default service user should apply when installed via
service.bat as well as by the Windows installer.

Mark


> 
> Thanks,
> Jason
> 
> On 8/14/2019 1:45 PM, Mark Thomas wrote:
>> The major changes compared to the 9.0.22 release are:
>>
>> - Security improvements to the Windows installer including a change in
>>the default user from Local System to Local Service.
> 
> 
> -
> 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



[VOTE] Release Apache Tomcat 9.0.24

2019-08-14 Thread Mark Thomas
The proposed Apache Tomcat 9.0.24 release is now available for voting.

The major changes compared to the 9.0.22 release are:

- Expand Graal native image support to include JNDI, JSPs and JULI

- Expand the HTTP/2 excessive overhead protection to cover various forms
  of abusive client behaviour and close the connection if any such
  behaviour is detected.

- Security improvements to the Windows installer including a change in
  the default user from Local System to Local Service.

Along with lots of other bug fixes and improvements.

For full details, see the changelog:
https://ci.apache.org/projects/tomcat/tomcat9/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.24/
The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1227/
The tag is:
https://github.com/apache/tomcat/tree/9.0.24


The proposed 9.0.24 release is:
[ ] Broken - do not release
[ ] Stable - go ahead and release as 9.0.24

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



[VOTE][CANCELLED] Release Apache Tomcat 9.0.23

2019-08-14 Thread Mark Thomas
I'm cancelling the vote and re-tagging due to an issue with the changelog.

Mark


On 14/08/2019 12:57, Mark Thomas wrote:
> The proposed Apache Tomcat 9.0.23 release is now available for voting.
> 
> The major changes compared to the 9.0.22 release are:
> 
> - Various improvements to the Kubernetes cluster membership service
> 
> - Expand the HTTP/2 excessive overhead protection to cover various forms
>   of abusive client behaviour and close the connection if any such
>   behaviour is detected.
> 
> - Security improvements to the Windows installer including a change in
>   the default user from Local System to Local Service.
> 
> Along with lots of other bug fixes and improvements.
> 
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat9/docs/changelog.html
> 
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.23/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1225/
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.23
> bd48c597e3cb280d73d9c9279babcaf75b6879c0
> 
> The proposed 9.0.23 release is:
> [ ] Broken - do not release
> [ ] Stable - go ahead and release as 9.0.23
> 
> -
> 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



[VOTE][CANCELLED] Release Apache Tomcat 8.5.44

2019-08-14 Thread Mark Thomas
I'm cancelling the vote and re-tagging due to an issue with the changelog.

Mark


On 14/08/2019 17:38, Mark Thomas wrote:
> The proposed Apache Tomcat 8.5.44 release is now available for voting.
> 
> The major changes compared to the 8.5.43 release are:
> 
> - Expand the HTTP/2 excessive overhead protection to cover various forms
>   of abusive client behaviour and close the connection if any such
>   behaviour is detected.
> 
> - Security improvements to the Windows installer including a change in
>   the default user from Local System to Local Service.
> 
> - Improve handling of invalid requests so that 400 responses are
>   returned to the client rather than 500 responses.
> 
> Along with lots of other bug fixes and improvements.
> 
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat85/docs/changelog.html
> 
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.44/
> 
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1226/
> 
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.44
> 593f3797c2de532988387692bb5f9a283c6182c5
> 
> The proposed 8.5.44 release is:
> [ ] Broken - do not release
> [ ] Stable - go ahead and release as 8.5.44
> 
> -
> 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] 01/01: Tag 9.0.23

2019-08-14 Thread Mark Thomas
On 14/08/2019 18:48, Rainer Jung wrote:
> Hi there,
> 
> this commit introduced a BOM at the beginning of the changelog.xml file,
> which leads to a checkstyle validation failure during building 9.0.23
> (when validation is actiive).
> 
> The BOM isn't shown in the below mail, but one can see the leading ef bb
> bf wit any binary editor. I first thought the failure was due to the
> checkstyle update, but it is just the BOM.
> 
> That's no functional problem, but people trying to build 9.0.23 with
> validation on will fail and wonder. Not sure whether that warrants a
> retag. I can see the BOM in the 8.5.44 file as well.

I'll re-tag both of them.

I think I edited the file with notepad rather than vi this time around
which is probably how this happened.

Apologies for the hassle.

Mark

> 
> Regards,
> 
> Rainer
> 
> Am 14.08.2019 um 13:10 schrieb ma...@apache.org:
>> This is an automated email from the ASF dual-hosted git repository.
>>
>> markt pushed a commit to tag 9.0.23
>> in repository https://gitbox.apache.org/repos/asf/tomcat.git
>>
>> commit bd48c597e3cb280d73d9c9279babcaf75b6879c0
>> Author: Mark Thomas 
>> AuthorDate: Wed Aug 14 12:10:06 2019 +0100
>>
>>  Tag 9.0.23
>> ---
>>   build.properties.default   | 2 +-
>>   webapps/docs/changelog.xml | 4 ++--
>>   2 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/build.properties.default b/build.properties.default
>> index 14ef092..3146ccb 100644
>> --- a/build.properties.default
>> +++ b/build.properties.default
>> @@ -27,7 +27,7 @@ version.major=9
>>   version.minor=0
>>   version.build=23
>>   version.patch=0
>> -version.suffix=-dev
>> +version.suffix=
>>     # - Build control flags -
>>   # Note enabling validation uses Checkstyle which is LGPL licensed
>> diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
>> index 0cbf970..15646db 100644
>> --- a/webapps/docs/changelog.xml
>> +++ b/webapps/docs/changelog.xml
>> @@ -1,4 +1,4 @@
>> -
>> +
>>   
>> -
>> +
>>     
>>   
>>     
> 
> -
> 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



[VOTE] Release Apache Tomcat 8.5.44

2019-08-14 Thread Mark Thomas
The proposed Apache Tomcat 8.5.44 release is now available for voting.

The major changes compared to the 8.5.43 release are:

- Expand the HTTP/2 excessive overhead protection to cover various forms
  of abusive client behaviour and close the connection if any such
  behaviour is detected.

- Security improvements to the Windows installer including a change in
  the default user from Local System to Local Service.

- Improve handling of invalid requests so that 400 responses are
  returned to the client rather than 500 responses.

Along with lots of other bug fixes and improvements.

For full details, see the changelog:
https://ci.apache.org/projects/tomcat/tomcat85/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.44/

The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1226/

The tag is:
https://github.com/apache/tomcat/tree/8.5.44
593f3797c2de532988387692bb5f9a283c6182c5

The proposed 8.5.44 release is:
[ ] Broken - do not release
[ ] Stable - go ahead and release as 8.5.44

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

2019-08-14 Thread Mark Thomas
On 14/08/2019 12:57, Mark Thomas wrote:



> The proposed 9.0.23 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 9.0.23

The unit tests pass on Windows, Linux and MacOS for NIO, NIO2 and
APR/Native with Tomcat Native 1.2.23

Mark

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



[VOTE] Release Apache Tomcat 9.0.23

2019-08-14 Thread Mark Thomas
The proposed Apache Tomcat 9.0.23 release is now available for voting.

The major changes compared to the 9.0.22 release are:

- Various improvements to the Kubernetes cluster membership service

- Expand the HTTP/2 excessive overhead protection to cover various forms
  of abusive client behaviour and close the connection if any such
  behaviour is detected.

- Security improvements to the Windows installer including a change in
  the default user from Local System to Local Service.

Along with lots of other bug fixes and improvements.

For full details, see the changelog:
https://ci.apache.org/projects/tomcat/tomcat9/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.23/
The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1225/
The tag is:
https://github.com/apache/tomcat/tree/9.0.23
bd48c597e3cb280d73d9c9279babcaf75b6879c0

The proposed 9.0.23 release is:
[ ] Broken - do not release
[ ] Stable - go ahead and release as 9.0.23

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



HTTP/2 DoS issues announced today - Impact for Apache Tomcat

2019-08-13 Thread Mark Thomas
Today Netflix has published a report highlighting various potential DoS
attacks against HTTP/2 implementations [1].

No immediate action is required for Tomcat users since none of the
described attacks result in a DoS with Apache Tomcat.

The Tomcat Security Team has reviewed the impact on Tomcat of each of
these attacks. The load generated by the attacks is comparable to the
load generated by a similar amount of valid client traffic. Therefore,
these requests are not viewed as a DoS by the Tomcat Security Team. We
did look a little harder at the CVE-2019-9513 "Resource Loop" attack as
came closest to exceeding the load generated by valid traffic.

While we do not consider the described attacks to represent a DoS for
Apache Tomcat, they do all represent abusive client behaviour. In
response to these reports we will be expanding the overhead protection
already in place to detect these abusive behaviours and to close the
connection when they are detected.

The expanded overhead detection will be configurable, including the
option to disable it. The configuration will be provided with what we
consider to be reasonable defaults although there is the possibility
that these defaults will be adjusted based on user feedback in future
versions.

This additional protection will be in the next releases of 9.0.x and
8.5.x, currently expected to be 9.0.23 and 8.5.44. The release process
for these versions is expected to start later today.

Mark
on behalf of the Tomcat Security Team




[1]
https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-002.md

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



Re: JDK 13 is now in the Release Candidate Phase

2019-08-12 Thread Mark Thomas
Latest Tomcat 9.0.x builds and completes unit tests with both without
any issues.

Mark


On 10/08/2019 11:23, Rory O'Donnell wrote:
> Hi Mark,
> 
> *JDK 13 is now in the Release Candidate Phase - if you are aware of any
> issues, please let us know.
> *
> 
> Per the JDK 13 schedule [1], we are now in the Release Candidate phase.
> The stabilization repository, jdk/jdk13, is open for P1 bug fixes per
> the JDK Release Process (JEP 3) [2].
> All changes require approval via the Fix-Request Process [3].
> 
> For more details, see Mark Reinhold's email to jdk-dev mailing list [4] 
> 
>   * Milestone Schedule:
>   o Initial RC Build 33 - Aug 9, 2019
>   o GAC - Aug 22, 2019
>   o GAR - Sept 5, 2019
>   o GA - Sept 17, 2019
> 
> *OpenJDK 13 build 33 is available at http://jdk.java.net/13/*
> 
>   * These early access, open source builds are provided under the GNU
> General Public License, version 2, with the Classpath Exception
> .
>   * Schedule, status & features
>   o http://openjdk.java.net/projects/jdk/13/
>   * Release Notes
>   o http://jdk.java.net/13/release-notes
>   * Bug fixes reported by Open Source Projects  :
>   o JDK-8228764 - fixed in b32 -reported by Apache Tomcat
> 
> **OpenJDK 14 *EA build 9 is now available at **http://jdk.java.net/14**
> *
> 
>   * These early access, open source builds are provided under the GNU
> General Public License, version 2, with the Classpath Exception
> .
>   * Release Notes
>   o http://jdk.java.net/14/release-notes
>   * JEPs targeted to JDK 14
>   o JEP 352  - Non-Volatile Mapped
> Byte Buffers
>   * Changes in this build
> 
> 
>   * Bug fixes reported by Open Source Projects  :
>   o JDK-8227170 - fixed in b8 -reported by Apache Ant
>   o JDK-8228485 - fixed in b8 -reported by JaCoCo
>   o JDK-8222791 - fixed in b7 -reported by Apache Lucene
> 
> *Project Panama Early-Access Builds*
> 
>   * Build jdk-14-panama+1-15 (2019/8/8) is available at
> http://jdk.java.net/panama/
>   * These early-access, open-source builds are provided under the GNU
> General Public License, version 2, with the Classpath Exception
> .
> 
> Regards,
> Rory
> 
> [1] https://openjdk.java.net/projects/jdk/13/#Schedule
> [2] https://openjdk.java.net/jeps/3
> [3] https://openjdk.java.net/jeps/3#Fix-Request-Process
> [4] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-August/003250.html
> 
> -- 
> Rgds,Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA , Dublin, Ireland 
> 


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



Re: [tomcat] 02/02: Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63285

2019-08-12 Thread Mark Thomas


>> How about this as a modified approach:
> 
>> - Keep renaming back to Tomcat9[w].exe on remove. That won't
>> impact existing service.bat users but will help users that install
>> via the installer (e.g. they'll be able to change the service
>> name).
> 
> Aha. I'm sure that has something to do with the answer to "who is
> broken" question.
> 
>> - Change the option to --rename and only rename on install when 
>> explicitly requested. Current service.bat users would be
>> unaffected and installer users would need to use this option if
>> they used service.bat to uninstall and reinstall the service (e.g.
>> to rename it)
> 
> I think I like the --no-rename -> --rename option is the best because
> it makes the smallest change. Only currently-affected users will need
> to modify their behavior, instead of most users having to modify their
> behavior.
> 
>> That should fix the reported issue while removing the impact on
>> the existing service.bat users.
> 
>> Thoughts?
> 
>> Mark
> 
> 
>> P.S. I know the 9.0.x and 8.5.x tags are overdue but I'd rather
>> wait a few more days to make sure we are happy with this change
>> before tagging and committing us to an approach.
> 
> +1
> 
> I wouldn't want to put out a release where the rules are different
> from every other release if we are going to change --no-rename ->
> --rename.
> 
> In case it's not clear, I'm fully in favor of changing --no-rename ->
> --rename instead of the current patch.

Done.

I have a few bits and pieces I want to look at before the tag so I
probably won't tag until tomorrow / Wednesday.

Mark

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



Re: [tomcat] 02/02: Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63285

2019-08-09 Thread Mark Thomas
> Mark,
> 
> On 8/8/19 08:19, 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
> 
>> commit 7ac5fc8a59c10e7de1ee6d4b85c1ee797942a1e7 Author: Mark Thomas
>>  AuthorDate: Thu Aug 8 13:17:29 2019 +0100
> 
>> Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63285
> 
>> Align the behaviour of service.bat with the Windows installer and
>> rename the executables on installation (and restore on removal).
> 
> If I understand this patch, I might need to veto it for Tomcat 9.
> Changing for TC 10 will be okay.
> 
> Re-naming the Tomcat .exe files on Windows will be a very surprising
> change for a point-release. Every installation I've ever worked on has
> multiple services running off the same Tomcat installation. If any of
> them is upgraded without adding the "--no-rename" option to an
> invocation of the service.bat script, all automation will begin to
> fail.

As soon as a new service is installed, yes.

> That includes services which *are not* reconfigured because the
> TomcatX.exe file will be renamed and still referenced in various
> service definitions.

Yes.

This is one of those cases where something is going to be broken
whatever we do. Happy to discuss options to try and minimise how much
gets broken.

How about this as a modified approach:

- Keep renaming back to Tomcat9[w].exe on remove. That won't impact
  existing service.bat users but will help users that install via the
  installer (e.g. they'll be able to change the service name).

- Change the option to --rename and only rename on install when
  explicitly requested. Current service.bat users would be unaffected
  and installer users would need to use this option if they used
  service.bat to uninstall and reinstall the service (e.g. to rename it)

That should fix the reported issue while removing the impact on the
existing service.bat users.

Thoughts?

Mark


P.S. I know the 9.0.x and 8.5.x tags are overdue but I'd rather wait a
few more days to make sure we are happy with this change before tagging
and committing us to an approach.

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



Re: h2 priorities

2019-08-09 Thread Mark Thomas
On 07/08/2019 17:42, Mark Thomas wrote:
> Just a quick update.
> 
> I started to make some progress but I have been side-tracked by the
> HTTP/2 timeout issue raised on users. I've been able to get the clean-up
> in but the priority changes aren't going to make the next set of releases.

With the HTTP/2 timeout issue resolved, I thought I'd take a quick look
at this again in case I could make progress.

I had some success in that the test at https://ishttp2fastyet.com shows
some improvements with my priority changes but there are some issues:

1. The HTTP/2 unit tests are ~50% slower. This looks to be a small
   number timing out. I suspect a timing issue in the patch.

2. I haven't looked at how to handle non-blocking I/O

3. Ignoring the 2 issues above, the patch shows some clear improvement.
   However, the result is far from the ideal. The root cause is Tomcat
   does not prioritize HTTP/2 reads over HTTP/2 writes and it really
   needs to for prioritisation to work as intended.

I'm planning on switching focus for the priority work and will look at
mechanisms for prioritizing HTTP/2 reads.

Mark


> On 01/08/2019 09:19, Mark Thomas wrote:
>> My general thinking is some sort of priority manager where multiple
>> implementations are available. Something like:
>> - NO-OP (current behaviour)
>> - dependencies only (takes account of dependencies for write
>>   ordering but not weights
>> - full (takes account of dependencies and weights for write ordering)
>>
>> I'm not sure the 'full' implementation is viable for a Servlet
>> container. What is doable for a single thread managing the writes for
>> multiple static resources gets a lot more complicated when you have one
>> thread per resource generating those resources dynamically.

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



Re: h2 priorities

2019-08-07 Thread Mark Thomas
Just a quick update.

I started to make some progress but I have been side-tracked by the
HTTP/2 timeout issue raised on users. I've been able to get the clean-up
in but the priority changes aren't going to make the next set of releases.

Mark


On 01/08/2019 09:19, Mark Thomas wrote:
> Hi all,
> 
> One of the things that I took away from the HTTP workshop was that we
> weren't doing as much with h2 priorities as we could.
> 
> If the connection window is at capacity, the code does a reasonable job
> of allocating any additional capacity to waiting streams based on the h2
> priority tree.
> 
> However, if the connection window is not at capacity, Tomcat essentially
> ignores the priority tree. I'd like to see if I can improve this.
> 
> My general thinking is some sort of priority manager where multiple
> implementations are available. Something like:
> - NO-OP (current behaviour)
> - dependencies only (takes account of dependencies for write
>   ordering but not weights
> - full (takes account of dependencies and weights for write ordering)
> 
> I'm not sure the 'full' implementation is viable for a Servlet
> container. What is doable for a single thread managing the writes for
> multiple static resources gets a lot more complicated when you have one
> thread per resource generating those resources dynamically.
> 
> I am currently still trying to get my head around various locking /
> ordering / synchronization issues and I don't yet have anything that
> works. I have stumbled across a couple of places where the code could be
> usefully cleaned up. I'll try and extract those into separate commits
> and get them applied. Hopefully this week but certainly before I tag.
> 
> If I can solve this fairly quickly, my plan is to have the "NO-OP"
> implementation as the default for now so there should be no change in
> behaviour.
> 
> Mark
> 
> -
> 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: Proposal: use Files.move instead of File.renameTo in FarmWarDeployer

2019-08-07 Thread Mark Thomas
On 06/08/2019 21:05, Christopher Schultz wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> All,
> 
> Someone recently had a problem where the FarmWarDeployer wouldn't work
> on a secondary node because File.renameTo was failing -- likely due to
> the underlying Java/OS refusing to re-name a file across filesystems.
> 
> I propose that we switch to using Files.move which will either re-name
> or move depending upon what is necessary. It also throws an exception
> if it can't do its work, rather than failing and returning false.
> 
> Code patch below. I would also remove all of the
> "farmWarDeployer.renameFail" error message keys from the resource bundle
> s.

+1. Might be worth a wider review of where else File.renameTo() is used.

This is Java 7 so it can also be back-ported to 8.5.x.

Mark


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



Re: buildbot failure in on tomcat-trunk

2019-08-01 Thread Mark Thomas
On 01/08/2019 21:39, build...@apache.org wrote:
> The Buildbot has detected a new failure on builder tomcat-trunk while 
> building tomcat. Full details are available at:
> https://ci.apache.org/builders/tomcat-trunk/builds/4526
> 
> Buildbot URL: https://ci.apache.org/
> 
> Buildslave for this Build: asf946_ubuntu
> 
> Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-commit' 
> triggered this build
> Build Source Stamp: [branch master] bb0befeebe18a9b8ff50e686a3d06e84ccdfb108
> Blamelist: Mark Thomas 
> 
> BUILD FAILED: failed compile_1

This has been caused by the changes to o.a.t.u.codec.binary.Base64

It looks like I'm going to need to dig into the RFC to figure out what
the root cause is.

Mark

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



Re: [tomcat] branch 7.0.x updated: Fix broken test

2019-08-01 Thread Mark Thomas
On 01/08/2019 11:38, Michael Osipov wrote:
> 
> 
>> Gesendet: Donnerstag, 01. August 2019 um 12:16 Uhr
>> Von: ma...@apache.org
>> An: "dev@tomcat.apache.org" 
>> Betreff: [tomcat] branch 7.0.x updated: Fix broken test
>>
>> 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 bb618dc  Fix broken test
>> bb618dc is described below
>>
>> commit bb618dceba4c37e167e12aef3e852fe571ff5190
>> Author: Mark Thomas 
>> AuthorDate: Thu Aug 1 11:16:33 2019 +0100
>>
>> Fix broken test
>> ---
>>  .../apache/catalina/authenticator/TestAuthInfoResponseHeaders.java| 4 
>> ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git 
>> a/test/org/apache/catalina/authenticator/TestAuthInfoResponseHeaders.java 
>> b/test/org/apache/catalina/authenticator/TestAuthInfoResponseHeaders.java
>> index 9004744..6ce7fd8 100644
>> --- a/test/org/apache/catalina/authenticator/TestAuthInfoResponseHeaders.java
>> +++ b/test/org/apache/catalina/authenticator/TestAuthInfoResponseHeaders.java
>> @@ -16,7 +16,6 @@
>>   */
>>  package org.apache.catalina.authenticator;
>>
>> -import java.nio.charset.StandardCharsets;
>>  import java.util.ArrayList;
>>  import java.util.HashMap;
>>  import java.util.List;
>> @@ -36,6 +35,7 @@ import org.apache.catalina.startup.TesterServlet;
>>  import org.apache.catalina.startup.Tomcat;
>>  import org.apache.catalina.startup.TomcatBaseTest;
>>  import org.apache.catalina.valves.RemoteIpValve;
>> +import org.apache.tomcat.util.buf.B2CConverter;
>>  import org.apache.tomcat.util.buf.ByteChunk;
>>  import org.apache.tomcat.util.codec.binary.Base64;
>>
>> @@ -67,7 +67,7 @@ public class TestAuthInfoResponseHeaders extends 
>> TomcatBaseTest {
>>  password = aPassword;
>>  String userCredentials = username + ":" + password;
>>  byte[] credentialsBytes =
>> -userCredentials.getBytes(StandardCharsets.ISO_8859_1);
>> +userCredentials.getBytes(B2CConverter.ISO_8859_1);
>>  String base64auth = Base64.encodeBase64String(credentialsBytes);
>>  credentials= method + " " + base64auth;
>>  }
> 
> 
> Thanks for the fix, but I do not understand why this has happened.
> I ran "ant clean" and "ant test". Why didn't it fail for me?

No problem. I break Tomcat 7 like this all the time.

You need to build with Java 6 to see that problem. If you build with
Java 7 or later you won't see it.

Tomcat 7 has a spec mandated requirement to run on Java 6 or later so
the CI system is configured to build with Java 6 as an easy way to catch
issues like this.

Mark

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



h2 priorities

2019-08-01 Thread Mark Thomas
Hi all,

One of the things that I took away from the HTTP workshop was that we
weren't doing as much with h2 priorities as we could.

If the connection window is at capacity, the code does a reasonable job
of allocating any additional capacity to waiting streams based on the h2
priority tree.

However, if the connection window is not at capacity, Tomcat essentially
ignores the priority tree. I'd like to see if I can improve this.

My general thinking is some sort of priority manager where multiple
implementations are available. Something like:
- NO-OP (current behaviour)
- dependencies only (takes account of dependencies for write
  ordering but not weights
- full (takes account of dependencies and weights for write ordering)

I'm not sure the 'full' implementation is viable for a Servlet
container. What is doable for a single thread managing the writes for
multiple static resources gets a lot more complicated when you have one
thread per resource generating those resources dynamically.

I am currently still trying to get my head around various locking /
ordering / synchronization issues and I don't yet have anything that
works. I have stumbled across a couple of places where the code could be
usefully cleaned up. I'll try and extract those into separate commits
and get them applied. Hopefully this week but certainly before I tag.

If I can solve this fairly quickly, my plan is to have the "NO-OP"
implementation as the default for now so there should be no change in
behaviour.

Mark

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



Plans for 9.0.23 and 8.5.44

2019-08-01 Thread Mark Thomas
Hi all,

It is the start of a new month so I am thinking about releases.

There are a couple of things I really want to look at before tagging.
They are:
- updating forked Commons libraries, particularly Pool2 and DBCP2
- h2 priorities (more on this in a a separate thread)

I suspect I'm not going to be tagging until the beginning of next week
at the earliest.

Mark

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



Re: tomcat wiki edit access request

2019-07-31 Thread Mark Thomas
Done.

Thanks for contributing and happy editing.

Mark


On 31/07/2019 17:09, Guild, Jason A (DOT) wrote:
> Hi there,
> I have some minor additions for the wiki that I'd like to add.
> May I please have edit access in Apache Confluence under my login 'jaguild'?
> Thanks,
> Jason
> 
> 
> -
> 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: [VOTE] Release Apache Tomcat 7.0.96

2019-07-29 Thread Mark Thomas
On 29/07/2019 09:57, Violeta Georgieva wrote:
> На сб, 27.07.2019 г. в 1:06 ч. Rainer Jung 

>> The test seems to set a socket timeout to -1, which is no longer allowed
>> by the following change:
>>
>>
> https://github.com/unofficial-openjdk/openjdk/commit/3a77350f194df226cb6d618589a59d36fae9dc9c
>>
>> in JDK 13+.
>>
>> The magic value -1 for timeouts are mor efrequent in our code, but I
>> don't know which of these might end up in a setSoTimeout() call.
> 
> I don't think this is a showstopper for Tomcat 7 and I'm thinking about
> promoting this release candidate.

+1

Mark

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



Re: [Bug 63555] embedded jar manifests missing automatic module names

2019-07-26 Thread Mark Thomas
On 26/07/2019 16:27, Raymond Auge wrote:
> .. maybe I can play with it over the next months.

Thanks. Much appreciated. We'll at least need to wait for a bnd 4.3.0
release. Although I suspect that will happen before Jakarta EE makes any
decision regarding JPMS.

Cheers,

Mark


> 
> - Ray
> 
> On Fri, Jul 26, 2019 at 11:24 AM  > wrote:
> 
> https://bz.apache.org/bugzilla/show_bug.cgi?id=63555
> 
> --- Comment #3 from Raymond Augé  > ---
> When you get back to this let me know if I can help with bnd.
> 
> -- 
> 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
> 
> 
> 
> 
> -- 
> *Raymond Augé*
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.*
>  (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)


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



Re: [VOTE] Release Apache Tomcat 7.0.96

2019-07-25 Thread Mark Thomas
On 24/07/2019 14:56, Violeta Georgieva wrote:
> The proposed Apache Tomcat 7.0.96 release is now available for voting.
> 
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat7/docs/changelog.html
> 
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.96/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1224/
> The git tag is:
> https://github.com/apache/tomcat/tree/7.0.96
> 5277b175db2e575022672856797240976ad23bcf
> 
> The proposed 7.0.96 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 7.0.96 Stable

Builds with Java 6 (with a bit of 7)
Starts cleanly under a security manager
Unit tests pass on Linux


Mark

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



Re: H2 protocol validation

2019-07-24 Thread Mark Thomas
On 24/07/2019 13:32, Mark Thomas wrote:
> On 24/07/2019 09:18, jean-frederic clere wrote:



>> Something like:
>> +++
>> index 637e690c65..255883fb93 100644
>> --- a/java/org/apache/coyote/http2/HPackHuffman.java
>> +++ b/java/org/apache/coyote/http2/HPackHuffman.java
>> @@ -380,7 +380,8 @@ public class HPackHuffman {
>>  int treePos = 0;
>>  boolean eosBits = true;
>>  int eosBitCount = 0;
>> -for (int i = 0; i < length; ++i) {
>> +int i = 0;
>> +for (; i < length; ++i) {
> 
> Note sure why the above is necessary.
> 
>>  byte b = data.get();
>>  int bitPos = 7;
>>  while (bitPos >= 0) {
>> @@ -406,6 +407,9 @@ public class HPackHuffman {
>>  } else {
>>  target.append((char) ((val >> 16) & LOW_MASK));
>>  treePos = 0;
>> +if (eosBitCount != 0) {
>> +throw new HpackException("Oops... JFC");
>> +}
>>  eosBits = true;
>>  }
>>  }
>> +++
>> Seems to make the test suite happy, comments?

I can reproduce the failure and can confirm that the fix is correct. My
local copy has an i18n message so I intend to commit that (with credit
to you) shortly.

Mark

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



Re: H2 protocol validation

2019-07-24 Thread Mark Thomas
On 24/07/2019 09:18, jean-frederic clere wrote:
> On 23/07/2019 11:27, Mark Thomas wrote:
>> On 23/07/2019 09:40, jean-frederic clere wrote:
>>> Hi,
>>>
>>> I have tried to run summerwind/h2spec (docker (1)) to validate tomcat
>>> master (using the apr connector and java8) and I have a bunch of errors.
>>>
>>> Does someone validate our code against another test suite?
>>>
>>> (1) https://github.com/summerwind/h2spec
>>
>> That is the one I have been using.

The last version I tested was 2.1.0. h2spec is now up to 2.3.0.

I'm re-running my tests now.

>> >From memory, there was one (maybe two?) explainable failures once Tomcat
>> was configured appropriately - mainly (only?) turning off server
>> initiated pings.



> Something like:
> +++
> index 637e690c65..255883fb93 100644
> --- a/java/org/apache/coyote/http2/HPackHuffman.java
> +++ b/java/org/apache/coyote/http2/HPackHuffman.java
> @@ -380,7 +380,8 @@ public class HPackHuffman {
>  int treePos = 0;
>  boolean eosBits = true;
>  int eosBitCount = 0;
> -for (int i = 0; i < length; ++i) {
> +int i = 0;
> +for (; i < length; ++i) {

Note sure why the above is necessary.

>  byte b = data.get();
>  int bitPos = 7;
>  while (bitPos >= 0) {
> @@ -406,6 +407,9 @@ public class HPackHuffman {
>  } else {
>  target.append((char) ((val >> 16) & LOW_MASK));
>  treePos = 0;
> +if (eosBitCount != 0) {
> +throw new HpackException("Oops... JFC");
> +}
>  eosBits = true;
>  }
>  }
> +++
> Seems to make the test suite happy, commments?

Making the test suite happy in 90% of the battle. Once I can reproduce
this I was planning on looking at the spec to confirm the above fix.
Should be able to do that in the next few hours.

Mark

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



Re: [Bug 61180] Change log level of sessionIdGeneratorBase.createRandom to warn rather than info

2019-07-24 Thread Mark Thomas
On 24/07/2019 07:58, bugzi...@apache.org wrote:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=61180
> 
> --- Comment #8 from Oscar Dawson  ---

Another idiot blocked and the spam deleted.

FYI, Infra have made some config changes that should reduce the level of
spam.

Mark

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



  1   2   3   4   5   6   7   8   9   10   >