Tomcat web socket not sending more than one message to the client

[Christoph Mertins]

Hello,

I have a problem with Tomcat only sending the first message to the client and 
then no message anymore till the client reconnects.

The code was working for some versions but then stopped working:

public void handleEvent(EventObject eventObject) {
Enumeration keySet = userSessions.keys();

while (keySet.hasMoreElements()) {
String key = keySet.nextElement();

Session session = userSessions.get(key);

synchronized (session) {

if (session.isOpen()) {
try {
Semaphore semaphore = new 
Semaphore(1);
Async async = 
session.getAsyncRemote();
SendHandler handler = new 
SemaphoreSendHandler(semaphore, async);

String text = 
eventTranscoder.encode(eventObject);


LogManager.getLogger(this.getClass())
.info("Eventbus 
Sending to " + session.getId() + " key: " + key + " text: " + text);

if (async.getBatchingAllowed()) 
{

async.setBatchingAllowed(false);
}


semaphore.acquireUninterruptibly();

async.sendText(text, handler);
async.flushBatch();

// 
session.getBasicRemote().sendObject(eventObject);
} catch (IllegalStateException | 
EncodeException | IOException e) {

LogManager.getLogger(this.getClass()).info("Sending failed", e);
// userSessions.remove(key);
}
} else {

LogManager.getLogger(this.getClass()).info("Session not open" + key);
// userSessions.remove(key);
}
}
}
}

private class SemaphoreSendHandler implements SendHandler {

private final Semaphore semaphore;
private RemoteEndpoint remoteEndpoint;

private SemaphoreSendHandler(Semaphore semaphore, 
RemoteEndpoint remoteEndpoint) {
this.semaphore = semaphore;
this.remoteEndpoint = remoteEndpoint;
}

@Override
public void onResult(SendResult result) {

LogManager.getLogger(EventBusEndpoint.class).info("Eventbus Sent ok: " + 
result.isOK());
try {
remoteEndpoint.flushBatch();
remoteEndpoint.sendPing(ByteBuffer.wrap(new 
byte[0]));
} catch (IOException e) {

LogManager.getLogger(this.getClass()).info("Flushing failed", e);
}

semaphore.release();
}
}

I can see the SemaphoreSendHandler putting out a true for the result.isOK() 
call.

But I can’t see any network traffic and no message on the client side. I am 
checking the with a Chrome Extension (Simple Web Socket Client) on Chrome 61 
and 62.

Versions:

Tomcat 8.5.21
Java: Oracle JDK 1.8 151 (tested 131 too)
OS: Raspbian Stretch

I cannot see any reason why this is not working.

Kind Regards,
Christoph
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Consecutive double slashes in URLs

[Mark Thomas]

On 18/10/17 22:23, Maor Shiffman wrote:
> On Wed, Oct 18, 2017 at 11:58 PM, Mark Thomas  wrote:
> 
>> On 18/10/17 21:49, Maor Shiffman wrote:
>>
>>> Hi,
>>>
>>> ​Attached are two war files that demonstrate the issue - ROOT.war and
>>> context2.war.
>>> There are two contexts - ROOT, that uses a url rewrite filter (tuckey)​
>>> to forward all requests to the second context - context2 (which also
>>> uses a rewrite filter).
>>> Using 8.0.44 and the url http://localhost:8080/index//index.html
>>> everything works ok (note the double slash).
>>> Using 8.0.45 with the same url returns 404.
>>> Also getting a 404 with 8.0.47.
>>
>> The mailing list strips attachments.
>>
>> Please create a Bugzilla entry and add them there. Please ensure that
>> you include the source.
>>
>> Mark
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
> ​Submitted: https://bz.apache.org/bugzilla/show_bug.cgi?id=61634

Thanks.

TL;DR - not a Tomcat bug. See the issue for the full explanation.

Mark

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

Re: TLS support: consider bundling native libs in JARs

[Brian Clozel]

Hi Mark, Christopher,

On Thu, Oct 19, 2017 at 7:32 PM, Christopher Schultz
 wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Mark,
>
> On 10/19/17 1:22 PM, Mark Thomas wrote:
> > On 19/10/17 16:56, Mark Thomas wrote:
> >> On 19 October 2017 15:11:19 BST, Brian Clozel
> >>  wrote:
> >>> Hi,
> >>>
> >>> More and more servers are choosing to make available one or
> >>> more solutions to use TLS native stacks by shipping them as
> >>> JARs:
> >>>
> >>> * Netty has quite a few options there
> >>> http://netty.io/wiki/forked-tomcat-native.html * Jetty is now
> >>> shipping a conscrypt support as well
> >>> https://webtide.com/conscrypting-native-ssl-for-jetty/
> >>>
> >>
> >> How does shipping a native library in a JAR work? What makes it
> >> simpler than building from source?
> >
> > Found the answer to my own question. Netty unpacks the native
> > library into a temporary directory and loads it from there.
> >
> > Packaging in a JAR is simply a convenience to enable end users to
> > use their build tool of choice to pull in the library.
>
> ... and completely unnecessary for users using a packaged Tomcat,
> since part of the "installation process" (either .exe "installer" for
> Windows, or unzip/untar for anyone else) drops any packaged binaries
> in the right place already. The problem is lack of binaries.
>
> > For Tomcat, this would be useful for the embedded scenario.
>
> Yes. The problem with Tomcat self-extracting a native library would be
> that an embedded environment could have all kinds of problems with
> that. If Tomcat extracted a native library to $TMPDIR and then allowed
> the JVM to load from there, wouldn't that scare the hell out of a
> developer or end-user who wasn't expecting that kind of thing? If
> embedded users (developers) want to package Tomcat in that way, that's
> fine, but Tomcat doing it without instructions seems like a horrible
> mistake.
>
> There is room for improving support for such a thing, but having
> Tomcat provide a magic JAR file is something I'm very much -1 on doing.
>

Indeed, it's mostly useful for the embedded scenario, even more for a
12 factor app deployed on a PaaS (disclaimer: I'm a Spring Boot team
member).
In those cases, the typical application is an uber JAR that you expect
to be deployed in many environments - and you can't really expect that
infrastructure
to peek into your app and guess which version of libtcnative/openssl
it should install.

In my opinion, dealing with native libraries "manually" is harder than
using a server that uses the bootclasspath/java agent trick to support
ALPN.
Of course, that's if your primary goal is to support http/2 on JDK8.

Netty, Conscrypt and others extract libs to a temp folder, and from a
Java server application point of view, I don't see how it changes the
trust relationship you already have with the host operating system. At
least doing so would save a lot of pain to all embedded users (setting
up the native libs, choosing the right version set, reproducing the
same conditions on their laptop).
You can then run applications without worrying about the Tomcat
version and locally compiled libraries.

> > The full binary distributions could leverage the same mechanism or
> > they could do something different. That would increase the number
> > of binary builds we needed to do for a release.
>
> ... and therein lies the challenge. We intentionally stopped
> publishing binaries because it's such a PITA. We only produce binaries
> for Microsoft Windows because (a) most Windows environment don't have
> access to a compiler (sadly) and (b) there are only two artifacts to
> produce: amd32 and amd64 builds.
>
> If someone wants to volunteer to build every combination of
> architecture, OS, and web server out there, I'm sure we'd appreciate
> the contribution. Just be aware that it is a slippery slope. Next
> thing you know, James Lampert will be asking us to produce AS/400
> builds. (*ducks*)
>
> - -chris

Now I totally get how this can turn into a distribution nightmare. I
can also see the irony in asking **you** to deal with a build
nightmare when it's **us** being too lazy to compile things :-)
Worse, I'm wondering if packing openssl in a JAR could somehow link a
tomcat version with openssl CVEs...

Would supporting Conscrypt then could be an option? As an external,
optional dependency, you wouldn't have to deal with all of this -
"just" coding against their JSSE provider.
Of course, I have zero idea about the efforts required for that - I
vaguely followed what the Jetty team is currently doing (the current
4.3.8 SNAPSHOTs are already working with http/2 and Conscrypt).

This could be a good alternative for people who can't introduce
libtcnative/openssl or JDK9 in their infrastructure right now - and
could drive http/2 adoption on existing systems.
That comes of course with a price: a heavier JAR if you wish to ship
the conscrypt uberjar with your app.

> 

TLS support: consider bundling native libs in JARs

[Brian Clozel]

Hi,

More and more servers are choosing to make available one or more solutions
to use TLS native stacks by shipping them as JARs:

* Netty has quite a few options there
http://netty.io/wiki/forked-tomcat-native.html
* Jetty is now shipping a conscrypt support as well
https://webtide.com/conscrypting-native-ssl-for-jetty/

I know there are other solutions for that, like changing the boot classpath
or installing native libraries directly on the host operating system. But
those solutions aren't always super easy to achieve in cloud environments;
there are also questions on this mailing list around
tomcat+tcnative+openssl versions compatibility.

Would the Tomcat community consider shipping JARs (with classifier and uber
JARs) containing the required native libraries (libtcnative + openssl +
apr)?
Bonus question: would you consider supporting boringssl or libressl?

Thanks,
--
Brian Clozel

The origin server did not find a current representation for the target resource or is not willing to disclose that one exists.

[Karen Goh]

Dear expert,

Today I receive an error message that I have never come across.

"Https status 404 - not found "
"The origin server did not find a current representation for the target 
resource or is not willing to disclose that one exists."

I have googled but there is no solution that can help me.

So far, I have delete the server and add a new one but it is not helpful.

So far, my context.xml is correct so rightfully, the tutorRegister.jsp page 
should appear.

Here's my context.xml and I am running on Eclipse NEON 3 with Maven and it is a 
dynamic web project.

http://xmlns.jcp.org/xml/ns/javaee;
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee 
 http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd;
 version="3.1">
  Hi5S
  
tutorRegister.jsp
  
  
mydb
jdbc/hi5
javax.sql.DataSource
Container
  


Hope someone could help. Tks.

Regards,
Karen

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

Re: Tomcat web socket not sending more than one message to the client

[Christoph Mertins]

Hello,

after waiting 35 minutes suddenly some events get forwarded for a second or
two and then again silence.
This is really strange.

Kind Regards,
Christoph

Mit freundlichen Grüßen
Christoph Mertins

On Thu, Oct 19, 2017 at 10:21 AM, Christoph Mertins 
wrote:

> Hello,
>
> I have a problem with Tomcat only sending the first message to the client
> and then no message anymore till the client reconnects.
>
> The code was working for some versions but then stopped working:
>
> public void handleEvent(EventObject eventObject) {
> Enumeration keySet = userSessions.keys();
>
> while (keySet.hasMoreElements()) {
> String key = keySet.nextElement();
>
> Session session = userSessions.get(key);
>
> synchronized (session) {
>
> if (session.isOpen()) {
> try {
> Semaphore semaphore = new
> Semaphore(1);
> Async async =
> session.getAsyncRemote();
> SendHandler handler = new
> SemaphoreSendHandler(semaphore, async);
>
> String text =
> eventTranscoder.encode(eventObject);
>
> LogManager.getLogger(this.
> getClass())
>
> .info("Eventbus Sending to " + session.getId() + " key: " + key + " text: "
> + text);
>
> if
> (async.getBatchingAllowed()) {
>
> async.setBatchingAllowed(false);
> }
>
> semaphore.
> acquireUninterruptibly();
>
> async.sendText(text,
> handler);
> async.flushBatch();
>
> //
> session.getBasicRemote().sendObject(eventObject);
> } catch (IllegalStateException |
> EncodeException | IOException e) {
> 
> LogManager.getLogger(this.getClass()).info("Sending
> failed", e);
> //
> userSessions.remove(key);
> }
> } else {
> 
> LogManager.getLogger(this.getClass()).info("Session
> not open" + key);
> // userSessions.remove(key);
> }
> }
> }
> }
>
> private class SemaphoreSendHandler implements SendHandler {
>
> private final Semaphore semaphore;
> private RemoteEndpoint remoteEndpoint;
>
> private SemaphoreSendHandler(Semaphore semaphore,
> RemoteEndpoint remoteEndpoint) {
> this.semaphore = semaphore;
> this.remoteEndpoint = remoteEndpoint;
> }
>
> @Override
> public void onResult(SendResult result) {
> LogManager.getLogger(
> EventBusEndpoint.class).info("Eventbus Sent ok: " + result.isOK());
> try {
> remoteEndpoint.flushBatch();
> remoteEndpoint.sendPing(ByteBuffer.wrap(new
> byte[0]));
> } catch (IOException e) {
> 
> LogManager.getLogger(this.getClass()).info("Flushing
> failed", e);
> }
>
> semaphore.release();
> }
> }
>
> I can see the SemaphoreSendHandler putting out a true for the
> result.isOK() call.
>
> But I can’t see any network traffic and no message on the client side. I
> am checking the with a Chrome Extension (Simple Web Socket Client) on
> Chrome 61 and 62.
>
> Versions:
>
> Tomcat 8.5.21
> Java: Oracle JDK 1.8 151 (tested 131 too)
> OS: Raspbian Stretch
>
> I cannot see any reason why this is not working.
>
> Kind Regards,
> Christoph

Re: Fwd: Content-Type is turned to lower when passed through mod_jk - this looks to be a bug.

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 10/15/17 6:54 PM, Mark O'Donohue wrote:
> Hi
> 
> Just wanted an opinion on this before I logged a bug report against
> mod_jk.c
> 
> 
> Running our proxied request via mod_jk we are seeing the returned
> content-type being changing to all lowercase:
> 
> eg:
> 
> Content-Type: application/xxx..+*JSON*; charset=utf-8
> 
> to:
> 
> Content-Type: application/xxx..+*json*; charset=utf-8
> 
> 
> We thought this was tomcat at first, but turns out to be mod_jk.c
> that is the cause :
> 
> http://svn.apache.org/repos/asf/tomcat/jk/trunk/native/apache-2.0/mod_
jk.c
>
> 
> 
> 
> *for* *(*h *=* 0*;* h *<* num_of_headers*;* h*++)* *{*
> 
> *if* *(!*strcasecmp*(*header_names*[*h*],* "Content-type"*))* *{*
> 
> char ***tmp *=* apr_pstrdup*(*r*->*pool*,* header_values*[*h *]);*
> 
> ap_content_type_tolower*(*tmp*);*
> 
> /* It should be done like this in Apache 2.0 */
> 
> /* This way, Apache 2.0 will be able to set the output filter */
> 
> /* and it make jk useable with deflate using */
> 
> /* AddOutputFilterByType DEFLATE text/html */
> 
> ap_set_content_type*(*r*,* tmp*);*
> 
> *}*
> 
> 
> 
> Now on the validity of upper vs lower - it seems a little bit of a
> grey area:
> 
> https://www.w3.org/Protocols/rfc1341/4_Content-Type.html
> 
> 
> 
> The type, subtype, and parameter names are not case sensitive. For
> example, TEXT, Text, and TeXt are all equivalent. Parameter values
> are normally case sensitive, but certain parameters are interpreted
> to be case- insensitive, depending on the intended use. (For
> example, multipart boundaries are case-sensitive, but the "access-
> type" for message/External-body is not case-sensitive.)
> 
> 
> 
> 
> 
> But as a proxy we dont have an opinion - we just want to pass on
> what we get !
> 
> 
> Also if we run the request via mod_proxy/*mod_proxy_ajp.c* instead
> then the returned content-type header is *not *changed.
> 
> So should I open a bug against mod_jk for it?

I think the only bug here is that mod_jk is wasting time rewriting a
header that doesn't need to be modified.

But I see this strictly as a performance problem and not as a
spec-violation.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlno1p8ACgkQHPApP6U8
pFiUPw/+I4tz1k2pHGC5qW+f8e0+A3gEdfu4StL3b9Uwu5ci/eo3L0Z7oe7t2vXp
7ctifUCs8Ns8wGYj5QEwaR/8NKlgCavscG+jMzFdffsmszh+hPjzUa72q0IYKnHU
6Qc25xqj1Ru2/Iz1SV7t13T+t1ctfdE5wnB2RDC53F1ldA54/fwyLf2ActxdMW+K
XEH+9A+q203WriFIP4Ie1qD4M/x/7J57MBjp3dkbspfR2hmwGvESljXBuAKuDw8N
xpOt2bdXbnqNdHpVtOiHQxvyG9n4Vy69+/8Gd/fvpMsWoH/nJOG99xQ3IIsHieUG
ulLtn2Bb4RIgwGXCnV2cK0SCMPKoyYHMoFQ7fPQIbP3lXqhFtHsrYuGkzZ0ylk08
jqmV3e2VlB70Gd0iXUIhKZLEN1oWirUFZU8behhP75DWKWEAqZA1ThFBk9naG1RX
kLPWpVugB5Q1uLZulK34f5rRBmd85qceIYOfz30wNaT5pHfyumb7/MYoKE9l03lp
JcUg/UbG9XgfsQsC/vH/sSzCCFk89wtUgIqi9VjXQ4uomsJiutzmiyPvtVAYpcdI
v7qEFvvyVvXVuhU7xaygyAsLTQq4s/gHJ0Fx11Nx91iOCDwDEKLUkQZ3ZDcgQglI
Qjy4fcxeM4f7legRH7jhccUptzJZovbdOgMM1TCU8tiIIWFE2EQ=
=UpzH
-END PGP SIGNATURE-

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

Re: More, Re: Weird problem: browsers refusing to connect; more "fun with ciphers clauses on the connector tag"

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

James,

On 10/16/17 2:35 PM, James H. H. Lampert wrote:
> I just got finished going through 20 other customer Tomcat
> installations we administer.
> 
> First, I found that most of them were accepting the DHE ciphers
> I'd disabled on the problem installation, and SSLLabs was giving
> them bad ratings for doing so.

Just for completeness, there's nothing wrong with DHE other than that
it's slow. Your previous post showed that it was using "weak primes"
which IS a concern, but unfortunately there are very old clients that
don't support larger primes (I'm looking at YOU, Java 1.6) and so
options are limited.

> Second, I found that two of the other installations were accepting
> the ECDHE ciphers I'd disabled, and yet they were working just fine
> in Chrome 60 (one of them still on a "test" certificate that was 
> self-signed, wrong domain, and expired! -- we can encourage them to
> pick a CA, and let us help them install a signed cert, but we can't
> MAKE them do it).

You should enable ECDHE. It's the best per-CPU-cycle key-agreement
algorithm available today. EC keys (for authentication) are a little
less useful than RSA these days, but if you can support both, I would
recommend doing ahead to support both.

A thought just occurred to me: are some clients using libtcnative/APR
and others not? I believe Tomcat still prefers APR/tcnative to the
Java NIO connector is the libraries are available. For Tomcat 7, the
configuration is sensitive to the type of connector being used, so if
you "disabled a cipher suite" and it seems to be still enabled (e.g.
ECDHE) that could be an explanation.

> That one is running on an AS/400 at V7R3, with a JVM that IDs in
> Manager as "jvmap3270sr10fp1-20170215_012.6"; the other one that's
> working fine with the ECDHE certs active is an AS/400 at V7R1, with
> a JVM that IDs as "jvmap3260sr16fp15-20151029_01."

I think most of that is going to be meaningless to us, unfortunately.
The output of "java -version" is going to be more useful.

> In all cases, SSL is via JSSE, not OpenSSL (we've never even heard
> of anybody getting Tomcat running via OpenSSL on an AS/400).

Okay, that's good to know.

> Could it be that the browser is trying to use the ECDHE ciphers,
> and something in the OS or the JVM is blowing up when it tries to
> use them?

The browser tells the server what cipher suites it supports during the
initial handshake, and the server decides which algorithm to use. The
client doesn't try multiple different connections to see which one
sticks. The server either replies saying "okay, were using "suite X"
or "go away, we can't talk to each other because we don't have any
algorithms in common".

Is this just happening at a single client? Oh, maybe not, because you
said you tried to use Google Chrome yourself and it didn't work. I was
thinking "maybe some group policy disabled a whole swath of cipher
suites in the org" but that's unlikely to be the case unless your
Chrome instance was also affected.

Is it possible that the browsers within the org are contacting a
DIFFERENT server than the Tomcat itself? Perhaps a load-balancer or
reverse-proxy that was broken, and it only *appears* like Tomcat is
broken? You ran SSLLabs tool against the site and it says it supports
RSA-AES/CBC-SHA which is definitely a decent algorithm (though GCM
should be preferred over CBC mode in nearly all cases).

Honestly, your server should be supporting more than just those two
protocols, but those two should be sufficient to establish a
connection with a server that only supports those two.

Did you know that Qualys/SSLLabs also has a *client test* as well? Try
pointing your Google Chrome instance at this page and see what it says:
https://www.ssllabs.com/ssltest/viewMyClient.html

I just tried it with my Firefox 56 on Macos and these two cipher
suites are supported (as well as many other, of course):

TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)

I did the same with Chrome 60 (latest) and is says it supports a
virtually identical list of cipher suites that Firefox does. I didn't
check any old versions.

Maybe have someone from inside the client's org share their screen
with you and have them run SSLLabs test against the hostname as they
see it from within.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlno2pEACgkQHPApP6U8
pFhDGBAAk9FcFLmeNy/tScYF9S5SB557qHpGoCfcHMvMTGVy3n8eKsqv2OPT3mSq
JwYxDdil2opagLh061Pa1TiNBMfXqWOMdQi573bBeHdWgMrAllfd+hDVSUSqHpIL
3AqhTZI2NDC1Yvg8mAnoF7vbVFSDVnGVs5duyAjcbCJ+nrjBGK+oGteFAC2RiTN5
e4fZmte01Gie+9ihAWeTLc4YQlJT/cygIA1l4EJO0vwJJonwaR/1QGa8PhPxnIgj
XXL5zgg3KS6MEf9ioyhZKEJDjCACigal0OIwOGpDHHHkHjwKOHJQ2eJsUz24Ub6U
TNCKq1MJJ7yZ1PsBQJZ3QsHZNvkJ6vcXOY70M+t6mvdDGYalw8xTcnUFcdbT2RbZ
O+Q/rT0RhTQJaOkg3Jivd81KYdfxhE1+DX8Xz6E7e4Ygpblwa0hZokGk9fosttkK

Re: Need suggestion in upgrading Apache Tomcat due to security vulnerability in Apache Tomcat 7.0.61

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Naga,

On 10/17/17 2:49 AM, naga karthikeyan wrote:
> Recently we found there is security vulnerability in Apache Tomcat 
> 7.0.61. Please note that now our application runs on Apache Tomcat
> 7.0.61.
> 
> Please advice me whether I can upgrade Apache Tomcat to latest
> Tomcat 7 version(v7.0.82)?

Well... there is the Upgrade Guide. Did you read it?
https://tomcat.apache.org/migration-7.html#Upgrading_7.0.x

Theoretically, point-releases should be drop-in replacements. Take
care to test everything in advance. You can also check to see if any
default configuration values have changed using this handy tool,
conveniently located immediately following the Upgrade Guide on the
same page:

https://tomcat.apache.org/migration-7.html#Tomcat_7.0.x_configuration_fi
le_differences

> Also please let me know when it's expected End of Life for Apache
> Tomcat 7.0.x ?

There has been no announcement for Tomcat 7 EOL. We try to provide at
least 12 months of notice for EOL for any major Tomcat version.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlno3lcACgkQHPApP6U8
pFgcchAAkyvFKVS/B65pLHRh+h8IJycY/WVb7sXpnK45cRhc88VX5/SjABTMibL2
n8sP3jidNrN44nx2pEb4807BGCmdo/4wfG8q9lPO71a029FfTZx8Eke05223+5dC
yY/f0Btvypt9JbBblvEJnJyDXv7tschZ4tyUOU0EOi6RFrBAExH7PE3/OnYLxNGf
V9zUcJtHoR94oPgxIi+kXshji4WVSNfN8uGfxvE59QIJuoLrLsW9ON46ZE5QWmNk
Lz4Vh7mznU9BMRzBOLkZ+r4ChuAswSrMkqIA9kgEXKy3vUbqaCDc/05nFT1sJqfr
sb2ZzN4vTYuhvjEM9qj+zASdgNOHn8xxBChN29FnoZ7t8vFCyqwkp/tZ/9/y2X+B
rMUrxSs6kNGuTvQ20l98daGr5wf0DBKrp2lembvhWc7xdklRC7Uuj+Z3IYB1EcZ9
ncxMov0D7xo8ram2t/D53N5Y3Yjj8cT0QINoumADnTULQLLpRNguOO2sjXEzDm8J
PqqKnAftHKNZ76VOMERENvm1QBwO09CF9dQ9Zx4aSaeEDbidthhYmXZ72LUopn0/
2LcQ31FnaLeUhHkN2u4p3i3/udBgJVQj+Uhtls9OEu+3ldxRWmiut9P+fAwh67Cr
75hQrW7bJ8FLWxEwmoSV21hlOkUmzcrUOxy2ixoHaaqPnj/NI4A=
=aVCT
-END PGP SIGNATURE-

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

Re: TLS support: consider bundling native libs in JARs

[Mark Thomas]

On 19 October 2017 15:11:19 BST, Brian Clozel  wrote:
>Hi,
>
>More and more servers are choosing to make available one or more
>solutions
>to use TLS native stacks by shipping them as JARs:
>
>* Netty has quite a few options there
>http://netty.io/wiki/forked-tomcat-native.html
>* Jetty is now shipping a conscrypt support as well
>https://webtide.com/conscrypting-native-ssl-for-jetty/
>

How does shipping a native library in a JAR work? What makes it simpler than 
building from source?

(Past experience of providing binaries for OS other than Windows is that the 
number of different builds rapidly multiplies - hence source only at the 
moment.)

>I know there are other solutions for that, like changing the boot
>classpath
>or installing native libraries directly on the host operating system.
>But
>those solutions aren't always super easy to achieve in cloud
>environments;
>there are also questions on this mailing list around
>tomcat+tcnative+openssl versions compatibility.
>
>Would the Tomcat community consider shipping JARs (with classifier and
>uber
>JARs) containing the required native libraries (libtcnative + openssl +
>apr)?

In principle no reason why not but more detail on the requirements is needed.

>Bonus question: would you consider supporting boringssl or libressl?

Libressl is supported as of 1.2.13 apart from some features where we need 
functionality not available in libressl (I forget what those features were but 
I don't think they were significant)

Boringssl should be doable as well but I don't think anyone has tried it yet.

Mark


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

Re: TLS support: consider bundling native libs in JARs

[Mark Thomas]

On 19/10/17 16:56, Mark Thomas wrote:
> On 19 October 2017 15:11:19 BST, Brian Clozel  wrote:
>> Hi,
>>
>> More and more servers are choosing to make available one or more
>> solutions
>> to use TLS native stacks by shipping them as JARs:
>>
>> * Netty has quite a few options there
>> http://netty.io/wiki/forked-tomcat-native.html
>> * Jetty is now shipping a conscrypt support as well
>> https://webtide.com/conscrypting-native-ssl-for-jetty/
>>
> 
> How does shipping a native library in a JAR work? What makes it simpler than 
> building from source?

Found the answer to my own question. Netty unpacks the native library
into a temporary directory and loads it from there.

Packaging in a JAR is simply a convenience to enable end users to use
their build tool of choice to pull in the library. For Tomcat, this
would be useful for the embedded scenario. The full binary distributions
could leverage the same mechanism or they could do something different.
That would increase the number of binary builds we needed to do for a
release.

Mark

> (Past experience of providing binaries for OS other than Windows is that the 
> number of different builds rapidly multiplies - hence source only at the 
> moment.)
> 
>> I know there are other solutions for that, like changing the boot
>> classpath
>> or installing native libraries directly on the host operating system.
>> But
>> those solutions aren't always super easy to achieve in cloud
>> environments;
>> there are also questions on this mailing list around
>> tomcat+tcnative+openssl versions compatibility.
>>
>> Would the Tomcat community consider shipping JARs (with classifier and
>> uber
>> JARs) containing the required native libraries (libtcnative + openssl +
>> apr)?
> 
> In principle no reason why not but more detail on the requirements is needed.
> 
>> Bonus question: would you consider supporting boringssl or libressl?
> 
> Libressl is supported as of 1.2.13 apart from some features where we need 
> functionality not available in libressl (I forget what those features were 
> but I don't think they were significant)
> 
> Boringssl should be doable as well but I don't think anyone has tried it yet.
> 
> Mark
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


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

Re: TLS support: consider bundling native libs in JARs

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 10/19/17 1:22 PM, Mark Thomas wrote:
> On 19/10/17 16:56, Mark Thomas wrote:
>> On 19 October 2017 15:11:19 BST, Brian Clozel
>>  wrote:
>>> Hi,
>>> 
>>> More and more servers are choosing to make available one or
>>> more solutions to use TLS native stacks by shipping them as
>>> JARs:
>>> 
>>> * Netty has quite a few options there 
>>> http://netty.io/wiki/forked-tomcat-native.html * Jetty is now
>>> shipping a conscrypt support as well 
>>> https://webtide.com/conscrypting-native-ssl-for-jetty/
>>> 
>> 
>> How does shipping a native library in a JAR work? What makes it
>> simpler than building from source?
> 
> Found the answer to my own question. Netty unpacks the native
> library into a temporary directory and loads it from there.
> 
> Packaging in a JAR is simply a convenience to enable end users to
> use their build tool of choice to pull in the library.

... and completely unnecessary for users using a packaged Tomcat,
since part of the "installation process" (either .exe "installer" for
Windows, or unzip/untar for anyone else) drops any packaged binaries
in the right place already. The problem is lack of binaries.

> For Tomcat, this would be useful for the embedded scenario.

Yes. The problem with Tomcat self-extracting a native library would be
that an embedded environment could have all kinds of problems with
that. If Tomcat extracted a native library to $TMPDIR and then allowed
the JVM to load from there, wouldn't that scare the hell out of a
developer or end-user who wasn't expecting that kind of thing? If
embedded users (developers) want to package Tomcat in that way, that's
fine, but Tomcat doing it without instructions seems like a horrible
mistake.

There is room for improving support for such a thing, but having
Tomcat provide a magic JAR file is something I'm very much -1 on doing.

> The full binary distributions could leverage the same mechanism or 
> they could do something different. That would increase the number
> of binary builds we needed to do for a release.

... and therein lies the challenge. We intentionally stopped
publishing binaries because it's such a PITA. We only produce binaries
for Microsoft Windows because (a) most Windows environment don't have
access to a compiler (sadly) and (b) there are only two artifacts to
produce: amd32 and amd64 builds.

If someone wants to volunteer to build every combination of
architecture, OS, and web server out there, I'm sure we'd appreciate
the contribution. Just be aware that it is a slippery slope. Next
thing you know, James Lampert will be asking us to produce AS/400
builds. (*ducks*)

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlno4boACgkQHPApP6U8
pFh4QA//RjVkmghJ0xx3WgI/SHvN5md3ywZPKNmMrPEyeL55R4e5g2yVEx/U5UTT
RGUICEmfhK77oQDu+YnKa95i23xGzv1CTtcE//kZeMYWu/pXaNlfF79dkmTGJqZe
bUZHCD62Zo7WtvuUVNgDt5tQn0hjq26e26/wE1jgvXk/lG3hE4tCgtH0D58uOyxI
1zu76kwaw/RubOVXBLUiSFJP/HM1hRyo0ERPqH/r0BAJv1SxPZ2Ok87wKs6pDfA5
0+raXKUmmt/DJ0T+OEEs30C7epqDMrIKW8T8X3H9gBSNU3Gta/Sp2r1G3NMxucJc
NZapiDRh+ZE42Tb76OCOAAQHtLcdCN8Hz34SKs1x2tq7N6HVd/M3zgKFTwh+g5xZ
5MlW98+uYhNIbDSqyf4CMys+5N4yBUfCIxelfduKnelxppGYMDQhadQboNqbZQjE
NsxRbbYKobn1vMPBoNzy7G4j8NpnnYjk/Vnr52WTP4QKDaXCofM2AE5aHkyUxYge
7x+E6EXOKtyj4ky0uMvwhAiBGY4fUlED3I+NiWxMajI0AZVJwA833ZbW+buE0TDA
gFaE1gwajl9EyrhWeraiSh7ZljnVc7YMdoTJt9nL8WVXPXpahzEn0EWKeiEkMvtN
QrtNnmgrtnVdNLKAaqFAnlxJzqGK9B5Horh7noDldugAuZNdtqw=
=tNgg
-END PGP SIGNATURE-

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

Re: More, Re: Weird problem: browsers refusing to connect; more "fun with ciphers clauses on the connector tag"

[James H. H. Lampert]

On 10/19/17, 10:02 AM, Christopher Schultz wrote:

The browser tells the server what cipher suites it supports during the
initial handshake, and the server decides which algorithm to use. The
client doesn't try multiple different connections to see which one
sticks. The server either replies saying "okay, were using "suite X"
or "go away, we can't talk to each other because we don't have any
algorithms in common".


That actually makes a certain amount of sense, if the JVM somehow 
*thinks* it can handle certain ciphers (e.g., the ECDHE ciphers), but 
can't. And if the Midrange box JVMs are deferring cipher implementation 
to the OS, rather than implementing it internally, I can see how that 
could happen. I'll note that the ones that have ECDHE ciphers enabled, 
and aren't blowing up not only Chrome 60 but a bunch of simulated 
browser handshakes, are all on a much newer revision of the OS, one 
that, I think, supports ECDHE at the OS level, whereas the ones on which 
I had to disable ECDHE are on an OS revision that does NOT support it at 
the OS level.


Some pretty big assumptions, but if they're right, it would explain much.

--
JHHL

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

Re: Response change between 8.5.x and 8.0.x (and earlier versions) W.R.T. Line separator CRLF vs. LF

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Adam,

On 10/17/17 12:12 PM, Adam Rauch wrote:
> On 10/16/2017 1:27 PM, Net Dawg wrote:
>> Profuse apologies.  We are unable reproduce this.  However out
>> tests were failing for another reason. 8.5.23 returns 400 error
>> with header "HTTP/1.1 400" where as version 8.0.47 returns the
>> same as "HTTP/1.1 400 Bad Request".  When the tests check for the
>> legacy header they were failing.  As soon as we stopped checking
>> for "Bad Request" our tests work.  On Monday, October 16, 
>> 2017, 8:19:33 AM GMT-10, Mark Thomas  wrote: On
>> 16/10/17 18:48, Net Dawg wrote:
>>> We are finding line separator has changed on Mac OS X in
>>> tomcat 8.5.23 response relative to all previous versions of
>>> tomcat we tested (8.0.47, 7.0.72 and 7.0.82).  We see nothing
>>> in change log to understand this change. Specifically, 8.5.23
>>> is generating CRLF in response (showing up as ^M in vim), while
>>> previous versions of tomcat are just producing LF.  As a result
>>> all of our tests based on earlier versions of tomcat are 
>>> failing. Is this a bug, in which case we will wait for fix (and
>>> lets tests fail due to known issue in tomcat) or is this how
>>> tomcat will always generate response going forward - in which
>>> case we will make our tests more lenient to be backward
>>> compatible somehow.
>> Context please. Line separator where exactly?
>> 
>> Mark
>> 
>> 
> 
> As for the removal of response messages in 8.5.x, this appears to
> be an intentional change. From the 8.5.0 section of the change
> log, 
> http://tomcat.apache.org/tomcat-8.5-doc/changelog.html#Tomcat_8.5.0_(m
arkt)
>
>  "RFC 7230 states that clients should ignore reason phrases in
> HTTP/1.1 response messages. Since the reason phrase is optional,
> Tomcat no longer sends it. As a result the system property 
> org.apache.coyote.USE_CUSTOM_STATUS_MSG_IN_HEADER is no longer used
> and has been removed. (markt)"

Yep. Users upgrading between versions probably ought to read the
Migration Guide. Oddly enough, it's listed right there on the page.

http://tomcat.apache.org/migration-85.html#Migrating_from_8.0.x_to_8.5.x

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlno4pQACgkQHPApP6U8
pFh3NxAAs8l4iKFTRQjQrUKo9JKA8N30mdO7RKVGSDFsrLQE0b7PVeHz1SB9d22U
Xp9UY9jRlhXFLLSIQDhoOoNnTGT4SzCMSAJuzlcPWpq2YLNIOIgMHu1AWmvRLUCg
uxuB+WLsQnjbFYkZroY53wddOUc9Dh4JupHXVQlFy5V50/DR9VfTdQ/0/fJLXxR8
yK84ZuFRXPcoWSWOl0Vqd+5A0JjnvPfm4c+DpFEUIlpS+NT0/bbkyJVWFzHNPMXN
KFXT9ccW9kX6kGB18K/9LhvlUhhVZrzO7qejQNwG4WeYUdJkxnDuKqyGx7JANaWM
6UEgx40LfEAKQJXxhZNjCGBWKuToloFfRDeDXt1T/Zw1NmxJ1oLrok1FQhRR8Ztw
JS3WTwnBS0hujw8hrKnHOiVaIhUH12Q8xu1kSVOijwOSowCMwus0kSESDr9yhnDG
p+FQmANqCxs1yqzN7xJdLnTtkqkpO2b/ncRnlqZ/MJtXIE59sGEppfOQWp2OrFaH
qO8BSJIGKFYceaXd/FW5f5vbFQR5A4Jf/qqFK6jTeOp5nw7imzzxx7A72RXVIQfr
/I+575YrIHDXkYLvTAMW2LoV8HzDCw9fWy8BUerSsdntvjVfkpOZqadAkmxyUVgP
vgkXDYSo5dCYmDBzE48ev3a5XE32NCAPuesl7pYQiPdUPV4IsMU=
=YZqS
-END PGP SIGNATURE-

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