Re: KrbException: Do not have keys of types listed in default_tkt_enctypes available
On 15/05/2015 08:34, Ravindhar Konka wrote:
Hi All
I am trying to use SSO functionality for my app
apache-tomcat-7.0.61
windows server 2008 R2
java 1.8.0_25
active directory machine ( DOMAIN-ad)
tomcat instance machine (windows-sso-demo)
username (ss0ad...@domain.com)
password (XX)
krb5.ini
[libdefaults]
default_realm = DOMAIN.COM
default_keytab_name = FILE:c:\apache-tomcat-7.0.61\conf\test.keytab
default_tkt_enctypes = AES256-CTS AES128-CTS RC4-HMAC DES3-CBC-SHA1
DES-CBC-MD5 DES-CBC-CRC
default_tgs_enctypes = AES256-CTS AES128-CTS RC4-HMAC DES3-CBC-SHA1
DES-CBC-MD5 DES-CBC-CRC
permitted_enctypes = AES256-CTS AES128-CTS RC4-HMAC DES3-CBC-SHA1
DES-CBC-MD5 DES-CBC-CRC
forwardable=true
[realms]
DOMAIN.COM= {
kdc = DOMAIN-ad:88
default_domain = DOMAIN.com
}
[domain_realm]
domain.com=DOMAIN.COM
.domain.com= DOMAIN.COM
[appdefaults]
autologin = true
forward = true
forwardable = true
encrypt = true
test.keytab
C:\Users\Administratorktpass -princ HTTP/windows-sso-demo.domain.com@DOMAIN
.COM -mapuser ssoadmin -pass P@ssw0rd -crypto all -kvno 0 -ptype
KRB5_NT_PRINCIP
AL -out test.keytab
C:\Users\ssoadminkinit ssoadmin
Password for ssoad...@domain.com:
New ticket is stored in cache file C:\Users\ssoadmin\krb5cc_ssoadmin
C:\Users\ssoadminkinit -k -t test.keytab
Exception: krb_error 0 Do not have keys of types listed in
default_tkt_enctypes
available; only have keys of following type: No error
KrbException: Do not have keys of types listed in default_tkt_enctypes
available
; only have keys of following type:
at sun.security.krb5.internal.crypto.EType.getDefaults(EType.java:280)
at sun.security.krb5.KrbAsReqBuilder.build(KrbAsReqBuilder.java:261)
at sun.security.krb5.KrbAsReqBuilder.send(KrbAsReqBuilder.java:315)
at sun.security.krb5.KrbAsReqBuilder.action(KrbAsReqBuilder.java:361)
at sun.security.krb5.internal.tools.Kinit.init(Kinit.java:219)
at sun.security.krb5.internal.tools.Kinit.main(Kinit.java:113)
CAN YOU PLEASE HELP ME
http://tomcat.apache.org/tomcat-7.0-doc/windows-auth-howto.html
Follow those steps *exactly* and you will have a working configuration.
Note there is a known issue with SPNEGO and Java 8u40 onwards. Stick to
an earlier Java version until we have a workaround in place.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: KrbException: Do not have keys of types listed in default_tkt_enctypes available
Hey Mark
thanks for quick reply ,I followed same doc. Which you provided
-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Friday, May 15, 2015 1:14 PM
To: Tomcat Users List
Subject: Re: KrbException: Do not have keys of types listed in
default_tkt_enctypes available
On 15/05/2015 08:34, Ravindhar Konka wrote:
Hi All
I am trying to use SSO functionality for my app
apache-tomcat-7.0.61
windows server 2008 R2
java 1.8.0_25
active directory machine ( DOMAIN-ad)
tomcat instance machine (windows-sso-demo) username
(ss0ad...@domain.com) password (XX)
krb5.ini
[libdefaults]
default_realm = DOMAIN.COM
default_keytab_name = FILE:c:\apache-tomcat-7.0.61\conf\test.keytab
default_tkt_enctypes = AES256-CTS AES128-CTS RC4-HMAC DES3-CBC-SHA1
DES-CBC-MD5 DES-CBC-CRC default_tgs_enctypes = AES256-CTS AES128-CTS
RC4-HMAC DES3-CBC-SHA1 DES-CBC-MD5 DES-CBC-CRC permitted_enctypes =
AES256-CTS AES128-CTS RC4-HMAC DES3-CBC-SHA1 DES-CBC-MD5 DES-CBC-CRC
forwardable=true
[realms]
DOMAIN.COM= {
kdc = DOMAIN-ad:88
default_domain = DOMAIN.com }
[domain_realm]
domain.com=DOMAIN.COM
.domain.com= DOMAIN.COM
[appdefaults]
autologin = true
forward = true
forwardable = true
encrypt = true
test.keytab
C:\Users\Administratorktpass -princ
HTTP/windows-sso-demo.domain.com@DOMAIN
.COM -mapuser ssoadmin -pass P@ssw0rd -crypto all -kvno 0 -ptype
KRB5_NT_PRINCIP AL -out test.keytab
C:\Users\ssoadminkinit ssoadmin
Password for ssoad...@domain.com:
New ticket is stored in cache file C:\Users\ssoadmin\krb5cc_ssoadmin
C:\Users\ssoadminkinit -k -t test.keytab
Exception: krb_error 0 Do not have keys of types listed in
default_tkt_enctypes available; only have keys of following type: No
error
KrbException: Do not have keys of types listed in default_tkt_enctypes
available ; only have keys of following type:
at sun.security.krb5.internal.crypto.EType.getDefaults(EType.java:280)
at sun.security.krb5.KrbAsReqBuilder.build(KrbAsReqBuilder.java:261)
at sun.security.krb5.KrbAsReqBuilder.send(KrbAsReqBuilder.java:315)
at sun.security.krb5.KrbAsReqBuilder.action(KrbAsReqBuilder.java:361)
at sun.security.krb5.internal.tools.Kinit.init(Kinit.java:219)
at sun.security.krb5.internal.tools.Kinit.main(Kinit.java:113)
CAN YOU PLEASE HELP ME
http://tomcat.apache.org/tomcat-7.0-doc/windows-auth-howto.html
Follow those steps *exactly* and you will have a working configuration.
Note there is a known issue with SPNEGO and Java 8u40 onwards. Stick to an
earlier Java version until we have a workaround in place.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the
property of Persistent Systems Ltd. It is intended only for the use of the
individual or entity to which it is addressed. If you are not the intended
recipient, you are not authorized to read, retain, copy, print, distribute or
use this message. If you have received this communication in error, please
notify the sender and delete all copies of this message. Persistent Systems
Ltd. does not accept any liability for virus infected mails.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Http 2 support in Tomcat
On 15/05/2015 08:55, anjan bacchu wrote: wondering what the plans are for supporting HTTP 2 support in tomcat ? When is it planned ? Which version(s) are likely to get support ? Work is in progress now. http://tomcat.markmail.org/thread/twqufoz53txetagh I hope to have basic support working in the next couple of weeks (it is probably only a couple of days work but I have other stuff I need to do first). Complete support will need to wait until the Servlet EG decides what the API is going to look like. Until then I'll probably implement whatever the latest thinking is in the Servlet EG. It will be included in Tomcat 9 (it will be required by Servlet 4.0). We may back-port support to earlier versions but that would require significant refactoring of the I/O code to do so. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Http 2 support in Tomcat
wondering what the plans are for supporting HTTP 2 support in tomcat ? When is it planned ? Which version(s) are likely to get support ?
KrbException: Do not have keys of types listed in default_tkt_enctypes available
Hi All
I am trying to use SSO functionality for my app
apache-tomcat-7.0.61
windows server 2008 R2
java 1.8.0_25
active directory machine ( DOMAIN-ad)
tomcat instance machine (windows-sso-demo)
username (ss0ad...@domain.com)
password (XX)
krb5.ini
[libdefaults]
default_realm = DOMAIN.COM
default_keytab_name = FILE:c:\apache-tomcat-7.0.61\conf\test.keytab
default_tkt_enctypes = AES256-CTS AES128-CTS RC4-HMAC DES3-CBC-SHA1 DES-CBC-MD5
DES-CBC-CRC
default_tgs_enctypes = AES256-CTS AES128-CTS RC4-HMAC DES3-CBC-SHA1 DES-CBC-MD5
DES-CBC-CRC
permitted_enctypes = AES256-CTS AES128-CTS RC4-HMAC DES3-CBC-SHA1 DES-CBC-MD5
DES-CBC-CRC
forwardable=true
[realms]
DOMAIN.COM= {
kdc = DOMAIN-ad:88
default_domain = DOMAIN.com
}
[domain_realm]
domain.com=DOMAIN.COM
.domain.com= DOMAIN.COM
[appdefaults]
autologin = true
forward = true
forwardable = true
encrypt = true
test.keytab
C:\Users\Administratorktpass -princ HTTP/windows-sso-demo.domain.com@DOMAIN
.COM -mapuser ssoadmin -pass P@ssw0rd -crypto all -kvno 0 -ptype KRB5_NT_PRINCIP
AL -out test.keytab
C:\Users\ssoadminkinit ssoadmin
Password for ssoad...@domain.com:
New ticket is stored in cache file C:\Users\ssoadmin\krb5cc_ssoadmin
C:\Users\ssoadminkinit -k -t test.keytab
Exception: krb_error 0 Do not have keys of types listed in default_tkt_enctypes
available; only have keys of following type: No error
KrbException: Do not have keys of types listed in default_tkt_enctypes available
; only have keys of following type:
at sun.security.krb5.internal.crypto.EType.getDefaults(EType.java:280)
at sun.security.krb5.KrbAsReqBuilder.build(KrbAsReqBuilder.java:261)
at sun.security.krb5.KrbAsReqBuilder.send(KrbAsReqBuilder.java:315)
at sun.security.krb5.KrbAsReqBuilder.action(KrbAsReqBuilder.java:361)
at sun.security.krb5.internal.tools.Kinit.init(Kinit.java:219)
at sun.security.krb5.internal.tools.Kinit.main(Kinit.java:113)
CAN YOU PLEASE HELP ME
DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the
property of Persistent Systems Ltd. It is intended only for the use of the
individual or entity to which it is addressed. If you are not the intended
recipient, you are not authorized to read, retain, copy, print, distribute or
use this message. If you have received this communication in error, please
notify the sender and delete all copies of this message. Persistent Systems
Ltd. does not accept any liability for virus infected mails.
RE: KrbException: Do not have keys of types listed in default_tkt_enctypes available
[libdefaults]
default_realm = DOMAIN.COM
default_keytab_name = FILE:c:\apache-tomcat-7.0.61\conf\test.keytab
default_tkt_enctypes = rc4-hmac,aes256-cts-hmac-sha1-96,aes128-cts-hmac-sha1-96
default_tgs_enctypes = rc4-hmac,aes256-cts-hmac-sha1-96,aes128-cts-hmac-sha1-96
forwardable=true
[realms]
DOMAIN.COM= {
kdc = domain-ad.DOMAIN.com:88
default_domain = DOMAIN.com
}
[domain_realm]
domain.com=DOMAIN.COM
.domain.com= DOMAIN.COM
[appdefaults]
autologin = true
forward = true
forwardable = true
encrypt = true
C:\Users\Administratorktpass /out c:\test.keytab /mapuser ssoad...@domain.com
/princ HTTP/windows-sso-demo.domain@domain.com /pass P@ssw0rd /kvno 0
C:\Users\ssoadminkinit -k -t test.keytab
Exception: krb_error 0 Do not have keys of types listed in default_tkt_enctypes
available; only have keys of following type: No error
KrbException: Do not have keys of types listed in default_tkt_enctypes available
; only have keys of following type:
at sun.security.krb5.internal.crypto.EType.getDefaults(EType.java:280)
at sun.security.krb5.KrbAsReqBuilder.build(KrbAsReqBuilder.java:261)
at sun.security.krb5.KrbAsReqBuilder.send(KrbAsReqBuilder.java:315)
at sun.security.krb5.KrbAsReqBuilder.action(KrbAsReqBuilder.java:361)
at sun.security.krb5.internal.tools.Kinit.init(Kinit.java:219)
at sun.security.krb5.internal.tools.Kinit.main(Kinit.java:113)
C:\Users\ssoadmin
-Original Message-
From: Ravindhar Konka [mailto:ravindhar_ko...@persistent.com]
Sent: Friday, May 15, 2015 1:38 PM
To: Tomcat Users List
Subject: RE: KrbException: Do not have keys of types listed in
default_tkt_enctypes available
Hey Mark
thanks for quick reply ,I followed same doc. Which you provided
-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Friday, May 15, 2015 1:14 PM
To: Tomcat Users List
Subject: Re: KrbException: Do not have keys of types listed in
default_tkt_enctypes available
On 15/05/2015 08:34, Ravindhar Konka wrote:
Hi All
I am trying to use SSO functionality for my app
apache-tomcat-7.0.61
windows server 2008 R2
java 1.8.0_25
active directory machine ( DOMAIN-ad)
tomcat instance machine (windows-sso-demo) username
(ss0ad...@domain.com) password (XX)
krb5.ini
[libdefaults]
default_realm = DOMAIN.COM
default_keytab_name = FILE:c:\apache-tomcat-7.0.61\conf\test.keytab
default_tkt_enctypes = AES256-CTS AES128-CTS RC4-HMAC DES3-CBC-SHA1
DES-CBC-MD5 DES-CBC-CRC default_tgs_enctypes = AES256-CTS AES128-CTS
RC4-HMAC DES3-CBC-SHA1 DES-CBC-MD5 DES-CBC-CRC permitted_enctypes =
AES256-CTS AES128-CTS RC4-HMAC DES3-CBC-SHA1 DES-CBC-MD5 DES-CBC-CRC
forwardable=true
[realms]
DOMAIN.COM= {
kdc = DOMAIN-ad:88
default_domain = DOMAIN.com }
[domain_realm]
domain.com=DOMAIN.COM
.domain.com= DOMAIN.COM
[appdefaults]
autologin = true
forward = true
forwardable = true
encrypt = true
test.keytab
C:\Users\Administratorktpass -princ
HTTP/windows-sso-demo.domain.com@DOMAIN
.COM -mapuser ssoadmin -pass P@ssw0rd -crypto all -kvno 0 -ptype
KRB5_NT_PRINCIP AL -out test.keytab
C:\Users\ssoadminkinit ssoadmin
Password for ssoad...@domain.com:
New ticket is stored in cache file C:\Users\ssoadmin\krb5cc_ssoadmin
C:\Users\ssoadminkinit -k -t test.keytab
Exception: krb_error 0 Do not have keys of types listed in
default_tkt_enctypes available; only have keys of following type: No
error
KrbException: Do not have keys of types listed in default_tkt_enctypes
available ; only have keys of following type:
at sun.security.krb5.internal.crypto.EType.getDefaults(EType.java:280)
at sun.security.krb5.KrbAsReqBuilder.build(KrbAsReqBuilder.java:261)
at sun.security.krb5.KrbAsReqBuilder.send(KrbAsReqBuilder.java:315)
at sun.security.krb5.KrbAsReqBuilder.action(KrbAsReqBuilder.java:361)
at sun.security.krb5.internal.tools.Kinit.init(Kinit.java:219)
at sun.security.krb5.internal.tools.Kinit.main(Kinit.java:113)
CAN YOU PLEASE HELP ME
http://tomcat.apache.org/tomcat-7.0-doc/windows-auth-howto.html
Follow those steps *exactly* and you will have a working configuration.
Note there is a known issue with SPNEGO and Java 8u40 onwards. Stick to an
earlier Java version until we have a workaround in place.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the
property of Persistent Systems Ltd. It is intended only for the use of the
individual or entity to which it is addressed. If you are not the intended
recipient, you are not authorized to read, retain, copy, print, distribute or
use this message. If you have received this communication in error, please
notify the
Tomcat connector: mod_jk 1.2.40 in 32 bit for OS - Linux 2.6.39-400.21.1.el6uek.x86_64
Hi, I am looking for mod_jk 1.2.40 source/binary on 32 bit, for Linux OS to be used with Oracle Http Server build on Apache 2.2 I could not find the details anywhere on your site. Also the link for the connector which is made available on your website is on 64 bit. Hence, request you to please direct me to the link from where I can download the appropriate module. Thanks. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJP config questions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jeffrey, On 5/14/15 6:38 PM, Jeffrey Janner wrote: (Hopefully, this isn't a duplicate post, but I sent the original a half-hour ago and I haven't seen it come back yet.) Guys, it's been a long time since I did any work with AJP, but it looks like something I'll be implementing soon. I have a couple of basic questions, mostly related to ProxyPassReverse, but also one related to SSL. I know to turn on mod_proxy and mod_proxy_ajp and a simple ProxyPass where the source and dest paths match, i.e. both are /foo. The question is if they differ. The httpd docs give this example: Rewriting Proxied Path ProxyPass /apps/foo ajp://backend.example.com:8009/foo ProxyPassReverse /apps/foo http://www.example.com/foo but don't mention if you need to turn on the RewriteEngine. Also, the second line doesn't look correct. Shouldn't it be http://www.example.com/app/foo? Or maybe ajp://backend.example.com:8009/foo? Trying to re-name the context path during proxying is a road that ends in tears. ProxyPassReverse only re-writes headers like SetCookie and Location. If you have links within your pages, you'll need to use something like mod_html to re-write all of them as the page is streamed back to the client. Best practice is to re-name the application to apps#foo.war if that's really the URL path you want to use. (The above configuration does not use mod_rewrite, hence the absence of RewriteEngine On.) BTW: we don't seem to be able to get the example to work. ProxyPass /myapp ajp://localhost:8009/myapp works, but ProxyPass /app ajp://localhost:8009/myapp does not work, and we've tried various iterations of ProxyPassReverse with it. When you say doesn't work, what do you really mean? What's the best way to handle ROOT.war, assuming there are other webapps to deploy as well? This is tough. I would recommend that you put all web applications in distinct paths, and not use ROOT at all. It makes proxying a little more sane IMHO. You can definitely still do it (just do all your ProxyPasses for the non-ROOT webapps *first* in httpd.conf, and then have one that does something like ProxyPass / [endpoint] last to handle the ROOT webapp. What if I don't want ROOT.war, but want to send / to a specific webapp? Put index.html into ROOT/index.html and do a redirect (or something roughly equivalent, like using RedirectMatch ^/$ /webapp/). SSL Question: Since our web.xml is configured to redirect all requests to SSL in the security-constraints area, how does that effect the options that need to be supplied in the connector? Right now, we just have the basic config as it comes in the initial conf.xml. When using mod_proxy_ajp, the SSL information should be passed-over from httpd to Tomcat just like when you are using mod_jk, so I don't think you'll get a redirect storm. mod_jk sends-over some extra stuff by default that mod_proxy_ajp I think does not, but I can't remember off the top of my head what those things are. Sorry for being a newbie on this, but the last time I messed with Apache proxy was 4.0 and then I used JK. You can still certainly use mod_jk, but you'll find the same issues with path-rewriting. I've been using mod_jk forever and I have no plans to abandon it. mod_jk is alive and well if you'd prefer to use something with which you have previous experience. But you do have to build it separately, since it doesn't come bundled with httpd (which is definitely a bummer). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVVeBnAAoJEBzwKT+lPKRYsAwP/086jW4zeX/5BZxJyMsEbjLp fEJCj8tJguyKoXRkgVIqeVW9aHK86elY3JYaAx/00GmrZACZbk2J963XB58E3YyV C3bd3K1BkHGYsWCoYwqEcNUIygnaJEuWrydXalcJrvrsk5vprkkFKQE/yu2Wu7gg vdNcbLe+LwySbYAJdzrBWYiyTFqarA/ShFkyMcpsEz+TWpbcDZptfpLLs2M30lPz /53OaJvfVs4yle/nXaqvG7R61RXc1/JkEOVApXMhn+lCnP2XBwNhVtpqsAjwIRMv ArdZClXH5wEpB+8rwWZVwMVQhJZJqGZXjBX8k9r1zNoXzomN6TWnB6zcnjOBpMVC RaErv9KQmSDsRWwmz5wyhdHWNPOVo48g0oCZhg22cF4tCXd879x25P4HIEyR5hT/ oJppa8kT7nSSaRQbq3s0n1LrBUMa7FqF+544zID6HnATSlNVADP5DOMUFrrEU+yH sAtsKsdjeuvO01FsI7f246vtwZ4VbXu8UfFswgFanHFFLGV0oLOOHbYyNEQF5tVU VeAsAMAg4dkNplW70XL4CGXho7WVEauCoivWVYxIvgQXyBA8q1NO89ZwGHO2wE5L lODTZ/16d/pI3VTxZJB10ENpVFQrpoXZz4Qaq24UCI6cli4OVGlBuelsCzgocga3 0T/nQcypPZ7IMQB4B0wy =ZtFn -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: CVE-2015-0204 - FREAK vulnerability on tomcat 7.
We would love to help but without the bare minimum description we are unable to do so. Sorry! On Fri, May 15, 2015 at 2:10 PM, Penubothu, Srinivasa M srinivasa.penubo...@bankofamerica.com wrote: Hello, I am looking for help with fixing FREAK vulnerability on tomcat 7. I am unable to find a solution for tomcat. Any help would be much appreciated. Regards Srinivasa(Vasu) Penubothu -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.
RE: CVE-2015-0204 - FREAK vulnerability on tomcat 7.
From: Penubothu, Srinivasa M [mailto:srinivasa.penubo...@bankofamerica.com] Subject: RE: CVE-2015-0204 - FREAK vulnerability on tomcat 7. Title: SSL/TLS Server Accepts RSA_EXPORT Cipher Suites (FREAK) CVE ID: CVE-2015-0204 That particular CVE number is only for the OpenSSL client side of the problem. Whether or not your server accepts RSA export keys is controlled by configuration, and is not officially a CVE item. Diagnosis: The remote SSL/TLS server accepts RSA_EXPORT cipher suites which is vulnerable to session downgrade vulnerability. Result: Exploitation allows an attacker to bypass security restrictions on the targeted host. Recommended Solution: Disable RSA_EXPORT cipher suites. Trying to find how to apply this fix in Tomcat 7. Appreciate your help! Read this mailing list thread: http://marc.info/?l=tomcat-userm=142911397006702w=2 - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SPNEGO test configuration with Manager webapp
On 14/05/2015 22:29, Mark Thomas wrote: On 14/05/2015 21:11, Mark Thomas wrote: On 29/03/2015 23:13, André Warnier wrote: David Marsh wrote: I've tested all the following public JDKs jdk-7u45-windows-i586.exe jdk-7u65-windows-i586.exe jdk-7u75-windows-i586.exe jdk-8-windows-i586.exe jdk-8u5-windows-i586.exe jdk-8u11-windows-i586.exe jdk-8u20-windows-i586.exe jdk-8u25-windows-i586.exe jdk-8u31-windows-i586.exe jdk-8u40-windows-i586.exe -- Only this one fails SPNEGO / Bad GSS Token Seems a recent fix must broken it. That is really great info. Thanks. As promised I have found some time to look into this. It appears that this fix in 8u40 onwards broke SPNEGO. https://bugs.openjdk.java.net/browse/JDK-8048194 The fix that was applied wasn't the one suggested in the bug report. I've spent some time looking at the code but I haven't found a way around this yet. Good news (sort of). I have an *extremely* dirty hack that fixes this on my test instance by moving some of the data about in the token that the client sends. It works with 8u20 and 8u45. At the moment the hack is extremely fragile. I need to make it more robust and make it optional. I should be able to get that done tomorrow and have it included in the next Tomcat 8 release. Fix applied to trunk (for 9.0.x), 8.0.x (for 8.0.23 onwards) and 7.0.x (for 7.0.63 onwards). Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
CVE-2015-0204 - FREAK vulnerability on tomcat 7.
Hello, I am looking for help with fixing FREAK vulnerability on tomcat 7. I am unable to find a solution for tomcat. Any help would be much appreciated. Regards Srinivasa(Vasu) Penubothu -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.
RE: CVE-2015-0204 - FREAK vulnerability on tomcat 7.
Here are the details of the vulnerability. Title: SSL/TLS Server Accepts RSA_EXPORT Cipher Suites (FREAK) CVE ID: CVE-2015-0204 Diagnosis: The remote SSL/TLS server accepts RSA_EXPORT cipher suites which is vulnerable to session downgrade vulnerability. Result: Exploitation allows an attacker to bypass security restrictions on the targeted host. Recommended Solution: Disable RSA_EXPORT cipher suites. Trying to find how to apply this fix in Tomcat 7. Appreciate your help! Regards Srinivasa(Vasu) Penubothu Mortgage Build Deployment Team • MTGBDT SharePoint Site • MTGBDT Nexus Engagement Link Division: Mortgage Technology Phones: 469-201-8855(Work) 214-250-8424(Mobile) Email: srinivasa.penubo...@bankofamerica.com -Original Message- From: Neill Lima [mailto:neill.l...@visual-meta.com] Sent: Friday, May 15, 2015 7:15 AM To: Tomcat Users List Subject: Re: CVE-2015-0204 - FREAK vulnerability on tomcat 7. We would love to help but without the bare minimum description we are unable to do so. Sorry! On Fri, May 15, 2015 at 2:10 PM, Penubothu, Srinivasa M srinivasa.penubo...@bankofamerica.commailto:srinivasa.penubo...@bankofamerica.com wrote: Hello, I am looking for help with fixing FREAK vulnerability on tomcat 7. I am unable to find a solution for tomcat. Any help would be much appreciated. Regards Srinivasa(Vasu) Penubothu -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.
Re: Issues with Tomcat 7.0.57 not loading ActionServlets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Raj, On 5/13/15 10:29 PM, Raj wrote: Hi Chris, Thanks for your response. Sorry for the late response as I was out of town. I verified struts-config.xml the files and have this plug-in className=org.apache.struts.validator.ValidatorPlugIn set-property property=pathnames value=/org/apache/struts/validator/validator-rules.xml, /WEB-INF/validator-rules.xml / /plug-in There is some changes in Tomcat 5.x and Tomcat 7.x as to how the classes are loaded, I have a feeling that is what is the issue. I changed the context.xml for my app so that loader delegate=true/ so the class loader should behave the same way but the issue is still present. Can you give some more pointers? Sure. First, don't change the load order of your class loader. If you really typed the above, then you haven't changed anything because loader is not valid. It would need to be Loader (case matters). First, I would double-check to see if you have any newline characters in your value above. It probably won't matter, but I don't have any in mine, and mine works just fine under Tomcat versions 4 through 9. Where is your file validator-rules.xml? In a WAR? If so, where is the WAR file? On the disk? If so, where on the disk. What is your CATALINA_HOME? CATALINA_BASE? What is the appBase for your Host? Nothing has changed in Tomcat's resource-loading that should cause a problem unless you have some kind of very fragile setup. What you have presented so far looks perfectly normal, and Tomcat should not interfere with loading that file, just as it's always been able to do. Thanks, - -chris On Thu, May 7, 2015 at 6:56 AM, Christopher Schultz ch...@christopherschultz.net wrote: Raj, On 5/6/15 8:55 PM, Raj wrote: I upgraded my application from tomcat 5.5.15, JDK 1.5, Struts 1.1 on Debian 2.6.32 to tomcat 7.0.57, JDK 1.6, struts 1.1 on ubuntu14.04 and Action Servlets are not loading. I am thinking of this is something to do with version conflict. Please let me know what I am missing. I assure you that Struts 1.1 works on Tomcat 7.0.57 and Java 1.6. What you describe is my production environment, which works quite well. Below is the error Apr 24, 2015 9:00:20 PM org.apache.catalina.core.ApplicationContext log INFO: org.apache.webapp.balancer.BalancerFilter: init(): ruleChain: [org.apache.webapp.balancer.RuleChain: RoundRobinRule@643fd34a] Apr 24, 2015 9:00:20 PM org.apache.catalina.core.ApplicationContext log INFO: Marking servlet action as unavailable Apr 24, 2015 9:00:20 PM org.apache.catalina.core.StandardContext loadOnStartup SEVERE: Servlet threw load() exception javax.servlet.UnavailableException: Cannot load a validator resource from '/WEB-INF/validator-rules.xml' Evidently, you are missing validator-rules.xml from your /WEB-INF/ directory. The Struts validator plug-in uses struts-config.xml to locate the validator-rules.xml file. Look at your web.xml to find out what file Struts is using to load its configuration. You are looking for the config init-param for the org.apache.struts.action.ActionServlet servlet. There may be more than one file listed under config; you'll have to check them all. Look in each of those config files. Look for the string org.apache.struts.validator.ValidatorPlugIn, which will define a plug-in. The pathnames property for the plug-in will list the files that the validator plug-in is going to try to load. All of those files need to be available on the classpath or filesystem. You probably have something like this: plug-in className=org.apache.struts.validator.ValidatorPlugIn set-property property=pathnames value=/org/apache/struts/validator/validator-rules.xml, /WEB-INF/validator-rules.xml / set-property property=stopOnFirstError value=false / /plug-in Check to see that all of those paths point to actual resources that can be loaded from your web application. Note that the first value (/org/apache/struts/validator/validator-rules.xml) is loaded from one of the Struts JAR files. BTW Struts 1-based applications also work just fine on Tomcat 8 and Java 8. Since you are upgrading, you should probably go all the way up. Hope that helps, -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVVd3vAAoJEBzwKT+lPKRYdSsP+QHQBtwAO3MTPxivSCezLaal ephor9Qlp0rUzxrhnpm42c1Ip9TU8xjN3qmVFRNsO0TeEHheseNIrLjxQi/u+7b6 K831TR8FVaS9RcbEFTG6EhTH0tyUpcNiJYFfdtVuBQXjrrHu1PEBAa3DbZ1fWsG6 BPDKYhpPvzqvzd12AywRVysX0wmDds1EXCiURIqh4fW6/a81OBYmt0rGdVlOAG86 uJIi7wdXa374oYXoroblIQc4QhG6ir4EIdldP2bfFV8Kx3wNYvMim7ZPtG/+3fEL QZO+mjHBCiPynWSgEVn9VhrOZOABdTj7yl3Ymq4y3hH+99FdDyyHLEUnsne458PN
Re: Tomcat connector: mod_jk 1.2.40 in 32 bit for OS - Linux 2.6.39-400.21.1.el6uek.x86_64
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Prarthana, On 5/15/15 6:09 AM, Prarthana Agwania wrote: I am looking for mod_jk 1.2.40 source/binary on 32 bit, for Linux OS to be used with Oracle Http Server build on Apache 2.2 I could not find the details anywhere on your site. Also the link for the connector which is made available on your website is on 64 bit. Hence, request you to please direct me to the link from where I can download the appropriate module. http://tomcat.apache.org/download-connectors.cgi The ASF does not publish binaries except under very special circumstance s. The above link will take you to the source-download page. Download the source, configure for your platform, and compile. See the README.txt file in the source download for instructions for building. Compiling on Linux should not be a problem at all, though you will likely need to install the httpd-dev or apache2-dev package for your distribution as a prerequisite. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVVeGOAAoJEBzwKT+lPKRYzHwP/16YFdBf2LPZJk0gyl7yisq1 wYuBmvq4Id7oaE3OIDT0GqedwPvU7jXWQCS5uGGzj/NwJUdmsYJIT2OF/71APcDv vHYz/CBPq63bQrc4wUTjmUTMSX3m+zrFH+m3CY18dA3FPcNJBRUJB0zjIzHgM9Es pAWZrWfBy/9gYKKXYv+iZEwLdNV/kpwnzR6MuGoKGOXt5VNYOf13topEcYbj/nKv 6b2vhMGPCIf0DpVR1zl4lavZCuX857wEe1oPlfCpI0jYITPaqUEqQxHLNLGgin2b XlEE+AmJXJKg+ug8XpXTwlWop2FIQbWVCOq/HkjsHkwDWu7D0OSVKMx/GSz1azlG +wSZkj40IO7Uz/o31kqRNZCyvH8MWt+Hd3RYsVUsM34BdXaU0ZG0aEzt+w36gyEg /7rHqbH/jLRzBnnPnpJSBzogEhWNxkV77eUadSUuUBaIMDgbar+Fc1B8a6z1FvkN wdlHM+HBOyqN5vcb085Ny3+4QAhgSdRCQx6CiHeVMnsmg0qtUlCzoyMogF9Z3uGM aJN3kgZZiwk9rp+ZgUh2Xb07vFQ7oSGlmvqsbbhXWj+Jy+BYyNcw7cQVhiTpF8qa imfHvLqEnbn/SfB2oPPGe0B23BurDvlzeG27nVjAERdNnu6oJw18yaJqrMpqj7U6 l0kISkhYLc9W9N7LWvE5 =t5K/ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
tomcat7 PID file and status check
I trying to find a service script (init.d) that I can use to start, stop, and check status of my tomcat7 instances. We run multiple instances of tomcat of a single server. I have found scripts out that where the status call checks the ps table to get the pid to determine the status. I thought that tomcat wrote out a .pid file into the file system, but I do not see it in my tomcat instance folder structure. What is the proper way to manage the pid ... do I get it from the process table via ps or do I write it out to the file system? Thanks, Eric
Re: CVE-2015-0204 - FREAK vulnerability on tomcat 7.
On 5/15/2015 8:23 AM, Penubothu, Srinivasa M wrote: Here are the details of the vulnerability. Title: SSL/TLS Server Accepts RSA_EXPORT Cipher Suites (FREAK) CVE ID: CVE-2015-0204 Diagnosis: The remote SSL/TLS server accepts RSA_EXPORT cipher suites which is vulnerable to session downgrade vulnerability. Result: Exploitation allows an attacker to bypass security restrictions on the targeted host. Recommended Solution: Disable RSA_EXPORT cipher suites. Trying to find how to apply this fix in Tomcat 7. Appreciate your help! Update to the latest JRE and TC versions. Regards Srinivasa(Vasu) Penubothu Mortgage Build Deployment Team • MTGBDT SharePoint Site • MTGBDT Nexus Engagement Link Division: Mortgage Technology Phones: 469-201-8855(Work) 214-250-8424(Mobile) Email: srinivasa.penubo...@bankofamerica.com -Original Message- From: Neill Lima [mailto:neill.l...@visual-meta.com] Sent: Friday, May 15, 2015 7:15 AM To: Tomcat Users List Subject: Re: CVE-2015-0204 - FREAK vulnerability on tomcat 7. We would love to help but without the bare minimum description we are unable to do so. Sorry! On Fri, May 15, 2015 at 2:10 PM, Penubothu, Srinivasa M srinivasa.penubo...@bankofamerica.commailto:srinivasa.penubo...@bankofamerica.com wrote: Hello, I am looking for help with fixing FREAK vulnerability on tomcat 7. I am unable to find a solution for tomcat. Any help would be much appreciated. Regards Srinivasa(Vasu) Penubothu -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Http 2 support in Tomcat
Good news thanks for the update. It may be some time before servlet 4 support is released but good to know Tomcat will be ready then.But does APR support http/2? I know other web servers now do. Also, I think Tomcat supports websockets which has the important capabilities that http/2 has and has been available longer. Depending upon your strategy you might want to go with that or wait a couple of years for http/2. Remember the firewalls, proxies and other network systems have to support http/2 before it can reach Tomcat. So it may be by the time http/3 is approved. Regards,-Tony From: Mark Thomas ma...@apache.org To: Tomcat Users List users@tomcat.apache.org Sent: Friday, May 15, 2015 2:00 AM Subject: Re: Http 2 support in Tomcat On 15/05/2015 08:55, anjan bacchu wrote: wondering what the plans are for supporting HTTP 2 support in tomcat ? When is it planned ? Which version(s) are likely to get support ? Work is in progress now. http://tomcat.markmail.org/thread/twqufoz53txetagh I hope to have basic support working in the next couple of weeks (it is probably only a couple of days work but I have other stuff I need to do first). Complete support will need to wait until the Servlet EG decides what the API is going to look like. Until then I'll probably implement whatever the latest thinking is in the Servlet EG. It will be included in Tomcat 9 (it will be required by Servlet 4.0). We may back-port support to earlier versions but that would require significant refactoring of the I/O code to do so. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Http 2 support in Tomcat
Hi Chris, I do not want to start a war but I am using Wildfly 9.0.0 CR1. The initial reason I looked it was due to Undertow. Then I found out they had a HTTP/2 implementation and when I tried that for half of my requests headers went from 3xx bytes down to 3x bytes. The response times were a millisecond but I expected that and they have put into place a measurement down to nanoseconds since internally I am seeing less than microsecond sometimes from my cache system. I plan to move away from Wildfly and use just Undertow if I can to have a lighter container but it was advised to start with Wildfly to use Undertow. For me I feel servlets are getting old and need to be replaced by something else. Way to many layers to get to your application code. I also believe with all the advancements in CPU and memory size that limiting to a single thread when using stateless requests is a waste of capability. Incremental increases in capability is a safe way to go but fun to try something leading edge even if I have to create it myself. Sorry about the rambling. I am still trying to get the servlet 4 implementation release date. Best Regards to Apache,-Tony From: Christopher Schultz ch...@christopherschultz.net To: Tomcat Users List users@tomcat.apache.org Sent: Friday, May 15, 2015 2:49 PM Subject: Re: Http 2 support in Tomcat -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Tony, On 5/15/15 2:43 PM, PerfGuru wrote: Thanks Mark Chris this is a very informative. I am using a httpd that supports http/2 and wow is it impressive. Sorry, I had to stop using Apache/Tomcat to use it but the performance and bandwidth gains are so nice it is addicting and my users have noticed. How does it compare to, say, HTTP/1.1 + Content-Encoding: gzip? I realize that HTTP/1.1 never compresses the message headers and that H/2 uses tokens and Huffman Coding to further compress the headers, but I'd like to see some real-world data if you have it. What server are you using? I will look into jre/jdk 9 and ask Oracle if servlet 4 is in the EA's. I would like to stay with http/2 rather than go to websockets but I am an early adopter and if it is stable and has servlet 4 with http/2 I will give it a try and let you know the results. When Tomcat 9 goes Stable, HTTP/2 will definitely work. I'm sure there will be some edge cases that will need to be fixed as time goes on, but the spec will require H/2 and Tomcat will implement faithfully. We don't want to merely say oh, yeah, H/2 kinda works and, well, we HAD to do it, so YMMV. We want to say you can rely on Tomcat to serve H/2 as well as H/1. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVVlvjAAoJEBzwKT+lPKRY3bwP/1wqb41Eu1fqN80MbrcUUdrJ qnrWD4o9EsvpPo5Abe0mkGXwiP+F2blDKFRYSXolpuADbmMpsd2gLPjrEGiy6H/J M6HFbjWPTAt4cIzscSZjAAUrpe05v0M39ZuV7z+nHXjT5UTyZQgmiNn3uvHPbVwQ DnfwTReswgyi0E5O5Q3qRz32lP49OpZyLgvAEl4N2cd64a+7ScX1eMHpq/NuVuQ8 N+E/GdgsC+UFOO6DYKHNsn8/kOZ1B7oP4e9fmudnBDCXOFTfqB5lsgGRTkvdXQR8 6dJEq8PkkTxPt0tqdd0UAT6FcLU0Axsm/CzNtej5pj5mIUrt9e5PpRPLH8uk1h2/ waq88NyOxJoYKycngubgK/rL1IET7kJ/Nu4f4j4hFDhMxox1w3K9HrMdKogpPYCY Uh7mdCphpjQxZirkwDnDlwOtbq+t66mNM/DJkeumQ3zfC3fe2wLevnDd7cNOEEx/ fj/r2GbB5p+EtOm67ysAyMc5STdobbueZO/ggBleD2tIiMxOcWE+sXbaXHNzydw4 y9phbm75Q2P8w8EslITnyqyTtbUdyAYJUAhy6nosHXujwwAp+wK+J1yfSzlu4a2w fLjgp92QsYP5fcA7yyNv0zI0tIREKJwONyL+vd2DD1IGibdxKGssjCtUr0QkhpfT BXvYpY5JXNoF0YDIEchy =QGzZ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat7 PID file and status check
On Fri, May 15, 2015 at 6:56 AM, Eric Wood eric.w...@irondata.com wrote: I trying to find a service script (init.d) that I can use to start, stop, and check status of my tomcat7 instances. We run multiple instances of tomcat of a single server. I have found scripts out that where the status call checks the ps table to get the pid to determine the status. I thought that tomcat wrote out a .pid file into the file system, but I do not see it in my tomcat instance folder structure. What is the proper way to manage the pid ... do I get it from the process table via ps or do I write it out to the file system? Look at the output of `cd $CATALINA_HOME/bin grep pid *.sh` :-) -- Hassan Schroeder hassan.schroe...@gmail.com http://about.me/hassanschroeder twitter: @hassan Consulting Availability : Silicon Valley or remote - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Issue in setting up SHA2 certificate with tomcat6
Hi, I am trying to configure SHA2 algorithm certificates with tomcat6 in centos 6. I have created a keystore of format JKS using keytool and imported the certificate and intermediates to the keystore. When i restart the tomcat, logs do not show any kind of errors it starts up normally but when i try to connect to host from a browser it shows the following error my system configuration OS : centos tomcat 6 java1.7.x In chrome Version 39.0.2171.71 (64-bit) SSL connection error Hide detailsUnable to make a secure connection to the server. This may be a problem with the server, or it may be requiring a client authentication certificate that you don't have. Error code: ERR_SSL_PROTOCOL_ERROR In firefox it shows Cannot communicate securely with peer: no common encryption algorithm(s). (Error code: ssl_error_no_cypher_overlap) tomcat configuration for the certificate in server.xml Connector port=8443 maxHttpHeaderSize=8192 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false disableUploadTimeout=true acceptCount=100 scheme=https secure=true SSLEnabled=true keystoreFile=/etc/tomcat6/x.jks keystorePass=xx clientAuth=false sslEnabledProtocols=TLSv1, TLSv1.1, TLSv1.2 / When i change the tomcat keystore with another certificates of SHA1 algorithm everything works fine. Thanks Pavan
Issue in setting up SHA2 certificate with tomcat6
Hi, I am trying to configure SHA2 algorithm certificates with tomcat6 in centos 6. I have created a keystore of format JKS using keytool and imported the certificate and intermediates to the keystore. When i restart the tomcat, logs do not show any kind of errors it starts up normally but when i try to connect to host from a browser it shows the following error my system configuration OS : centos tomcat 6 java1.7.x In chrome Version 39.0.2171.71 (64-bit) SSL connection error Hide detailsUnable to make a secure connection to the server. This may be a problem with the server, or it may be requiring a client authentication certificate that you don't have. Error code: ERR_SSL_PROTOCOL_ERROR In firefox it shows Cannot communicate securely with peer: no common encryption algorithm(s). (Error code: ssl_error_no_cypher_overlap) tomcat configuration for the certificate in server.xml Connector port=8443 maxHttpHeaderSize=8192 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false disableUploadTimeout=true acceptCount=100 scheme=https secure=true SSLEnabled=true keystoreFile=/etc/tomcat6/x.jks keystorePass=xx clientAuth=false sslEnabledProtocols=TLSv1, TLSv1.1, TLSv1.2 / When i change the tomcat keystore with another certificates of SHA1 algorithm everything works fine. Thanks Pavan
Re: Http 2 support in Tomcat
Am 15.05.2015 um 20:23 schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 5/15/15 12:59 PM, Mark Thomas wrote: On 15/05/2015 17:49, Christopher Schultz wrote: Tony, On 5/15/15 12:06 PM, PerfGuru wrote: Good news thanks for the update. It may be some time before servlet 4 support is released but good to know Tomcat will be ready then. But does APR support http/2? I know other web servers now do. Mark's initial work on the HTTP/2 connector has been using APR. Note that APR doesn't handle the HTTP protocol, it just helps manage sockets, pools, etc. The protocol needs to be built on top of those building blocks. Please see the dev list (archives) for details. Just search for HTTP/2 subjects. Correct. This is primarily because ALPN support is not there in JSSE yet and wont be until Java 9. That said, one of the reasons for the huge amount of connector refactoring that I did before starting on HTTP/2 was so that the connector implementation specific code was kept to a minimum (so far just ALPN). HTTP/2 will work just fine with NIO and NIO2 just as soon as JSSE support ALPN and we plumb it in. Is this something that's workable with the current pre-release builds of Java 9? Presumably, Servlet 4 will require Java 8. Does that mean that HTTP/2 with the NIO connectors will only be available with a higher JRE version? h2c support (HTTP/2 over a cleartext channel via HTTP upgrade rather than TLS) is also on the TODO list. It shouldn't be much work to add (less than a day) and it wil be available for all connectors. Also, I think Tomcat supports websockets which has the important capabilities that http/2 has and has been available longer. Tomcat supports Websocket since Tomcat 7, as long as you are running on Java 7 or higher. Depending upon your strategy you might want to go with that or wait a couple of years for http/2. Remember the firewalls, proxies and other network systems have to support http/2 before it can reach Tomcat. So it may be by the time http/3 is approved. Tomcat has no choice (application developers do). Servlet 4.0 will require HTTP/2 so Tomcat has to support it. Correct. Using Websocket through certain proxies (e.g. httpd) is even still sometimes tricky. Yeah. We should touch base with jimjag and discuss this. I think the httpd thinking around WebSockets and the Java world thinking about WebSockets aren't quite lined up. +1 Perhaps there isn't much use for Websockets in the Perl or PHP world, where a lot of httpd installations are being used. Jim Riggs's (reprise, I believe) presentation at ApacheCon about how mod_php needs to die (paraphrasing) advocates more extensive use of mod_proxy_* to physically separate the web tier from the application tier, in a way that more closely resembles how Java webapps are deployed. Perhaps if the world starts listening to the Jim Riggses of the world, the shortcomings of mod_proxy_websocket and friends will become more apparent. Do you see any problems using a HTTP/2 enabled proxy in front of Tomcat HTTP or AJP connectors? Combining httpd with mod_h2 and mod_jk should give us enough time for Servlet 4.0 - assuming that the critical slow bandwith, high latency path between the client and the proxy benefits most of the new procotol. - Stefan -- Mayr Stefan Hausen - Gassenaecker 10 82269 Geltendorf Tel.: 08193 - 9979469 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Issues with Tomcat 7.0.57 not loading ActionServlets
Thanks Chris for the quick response, for class loader it is Loader but as your saying not make that change so will not. Validator-rules. Xml file is under Catalina_Home/webapps/app-name/WEB-INF/ and the app is in exploded format. This is working fine on tomcat 5.x and we just copied the files from their to tomcat 7.x. Yes, this looks normal as other functionalities are working except when we call struts it doesn't work. Thanks Raj Sent from my iPhone On May 15, 2015, at 6:52 AM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Raj, On 5/13/15 10:29 PM, Raj wrote: Hi Chris, Thanks for your response. Sorry for the late response as I was out of town. I verified struts-config.xml the files and have this plug-in className=org.apache.struts.validator.ValidatorPlugIn set-property property=pathnames value=/org/apache/struts/validator/validator-rules.xml, /WEB-INF/validator-rules.xml / /plug-in There is some changes in Tomcat 5.x and Tomcat 7.x as to how the classes are loaded, I have a feeling that is what is the issue. I changed the context.xml for my app so that loader delegate=true/ so the class loader should behave the same way but the issue is still present. Can you give some more pointers? Sure. First, don't change the load order of your class loader. If you really typed the above, then you haven't changed anything because loader is not valid. It would need to be Loader (case matters). First, I would double-check to see if you have any newline characters in your value above. It probably won't matter, but I don't have any in mine, and mine works just fine under Tomcat versions 4 through 9. Where is your file validator-rules.xml? In a WAR? If so, where is the WAR file? On the disk? If so, where on the disk. What is your CATALINA_HOME? CATALINA_BASE? What is the appBase for your Host? Nothing has changed in Tomcat's resource-loading that should cause a problem unless you have some kind of very fragile setup. What you have presented so far looks perfectly normal, and Tomcat should not interfere with loading that file, just as it's always been able to do. Thanks, - -chris On Thu, May 7, 2015 at 6:56 AM, Christopher Schultz ch...@christopherschultz.net wrote: Raj, On 5/6/15 8:55 PM, Raj wrote: I upgraded my application from tomcat 5.5.15, JDK 1.5, Struts 1.1 on Debian 2.6.32 to tomcat 7.0.57, JDK 1.6, struts 1.1 on ubuntu14.04 and Action Servlets are not loading. I am thinking of this is something to do with version conflict. Please let me know what I am missing. I assure you that Struts 1.1 works on Tomcat 7.0.57 and Java 1.6. What you describe is my production environment, which works quite well. Below is the error Apr 24, 2015 9:00:20 PM org.apache.catalina.core.ApplicationContext log INFO: org.apache.webapp.balancer.BalancerFilter: init(): ruleChain: [org.apache.webapp.balancer.RuleChain: RoundRobinRule@643fd34a] Apr 24, 2015 9:00:20 PM org.apache.catalina.core.ApplicationContext log INFO: Marking servlet action as unavailable Apr 24, 2015 9:00:20 PM org.apache.catalina.core.StandardContext loadOnStartup SEVERE: Servlet threw load() exception javax.servlet.UnavailableException: Cannot load a validator resource from '/WEB-INF/validator-rules.xml' Evidently, you are missing validator-rules.xml from your /WEB-INF/ directory. The Struts validator plug-in uses struts-config.xml to locate the validator-rules.xml file. Look at your web.xml to find out what file Struts is using to load its configuration. You are looking for the config init-param for the org.apache.struts.action.ActionServlet servlet. There may be more than one file listed under config; you'll have to check them all. Look in each of those config files. Look for the string org.apache.struts.validator.ValidatorPlugIn, which will define a plug-in. The pathnames property for the plug-in will list the files that the validator plug-in is going to try to load. All of those files need to be available on the classpath or filesystem. You probably have something like this: plug-in className=org.apache.struts.validator.ValidatorPlugIn set-property property=pathnames value=/org/apache/struts/validator/validator-rules.xml, /WEB-INF/validator-rules.xml / set-property property=stopOnFirstError value=false / /plug-in Check to see that all of those paths point to actual resources that can be loaded from your web application. Note that the first value (/org/apache/struts/validator/validator-rules.xml) is loaded from one of the Struts JAR files. BTW Struts 1-based applications also work just fine on Tomcat 8 and Java 8. Since you are upgrading, you should probably go all the way up. Hope that helps, -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
Re: Http 2 support in Tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 5/15/15 12:59 PM, Mark Thomas wrote: On 15/05/2015 17:49, Christopher Schultz wrote: Tony, On 5/15/15 12:06 PM, PerfGuru wrote: Good news thanks for the update. It may be some time before servlet 4 support is released but good to know Tomcat will be ready then. But does APR support http/2? I know other web servers now do. Mark's initial work on the HTTP/2 connector has been using APR. Note that APR doesn't handle the HTTP protocol, it just helps manage sockets, pools, etc. The protocol needs to be built on top of those building blocks. Please see the dev list (archives) for details. Just search for HTTP/2 subjects. Correct. This is primarily because ALPN support is not there in JSSE yet and wont be until Java 9. That said, one of the reasons for the huge amount of connector refactoring that I did before starting on HTTP/2 was so that the connector implementation specific code was kept to a minimum (so far just ALPN). HTTP/2 will work just fine with NIO and NIO2 just as soon as JSSE support ALPN and we plumb it in. Is this something that's workable with the current pre-release builds of Java 9? Presumably, Servlet 4 will require Java 8. Does that mean that HTTP/2 with the NIO connectors will only be available with a higher JRE version? h2c support (HTTP/2 over a cleartext channel via HTTP upgrade rather than TLS) is also on the TODO list. It shouldn't be much work to add (less than a day) and it wil be available for all connectors. Also, I think Tomcat supports websockets which has the important capabilities that http/2 has and has been available longer. Tomcat supports Websocket since Tomcat 7, as long as you are running on Java 7 or higher. Depending upon your strategy you might want to go with that or wait a couple of years for http/2. Remember the firewalls, proxies and other network systems have to support http/2 before it can reach Tomcat. So it may be by the time http/3 is approved. Tomcat has no choice (application developers do). Servlet 4.0 will require HTTP/2 so Tomcat has to support it. Correct. Using Websocket through certain proxies (e.g. httpd) is even still sometimes tricky. Yeah. We should touch base with jimjag and discuss this. I think the httpd thinking around WebSockets and the Java world thinking about WebSockets aren't quite lined up. +1 Perhaps there isn't much use for Websockets in the Perl or PHP world, where a lot of httpd installations are being used. Jim Riggs's (reprise, I believe) presentation at ApacheCon about how mod_php needs to die (paraphrasing) advocates more extensive use of mod_proxy_* to physically separate the web tier from the application tier, in a way that more closely resembles how Java webapps are deployed. Perhaps if the world starts listening to the Jim Riggses of the world, the shortcomings of mod_proxy_websocket and friends will become more apparent. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVVjm/AAoJEBzwKT+lPKRY6ZAQAK5BSg+ilfOs6T9hNtX91h/x /aZm6dSzncJMyP7gZ1FX2J9wlq+P99lx8FZEkO4gJOVpi/uGqP+nYvZoKydTQ8sb WbMVLMZBjrR+cP0gnX1sMELKQD7Llq8InYblfY9sE3s+wf8BKX4W2NXYei51vQv9 2k9tdgp7k/ibMu4jbSTnuqrFy67eTYLOJEwqXH6F0zsItwCqGX2njFH/ra4i9oU3 SMyIPNYngC3SYKurTve1cxZpU4J3FuWx/KcLIEIePMNUKU/Ner77tizqNi/xil7b Dw7VPgPVnD9tavznCd7Fz9HMhi/giG+X1rK9UJ7tnkP8kpdC+RgM0JPTB6nqEgvW uMJfXWagVcU+Rtmt8smWOpV1VlEMsorqJ8I4OS5DTACt0aFVRsjSXNKRaeLBUUje JPqRFmHKESksIWwJAnWY7BderGPegWTreDreeAQcvy+6ZkkWxxL925iPd+2aDBhP hU/p65YnqqPp8qc+HYwtV5aC1UE1CcKXh8VepFnb9z3H7wUe8hSu1PcxqHUhwJXl OMDjfCGrGs5egdWXqZgQSQKfE9nnhCZqOsKSY+Q5NhBs2P6TKhwv+i0VzdzNKyW8 jKjaoiE3CQEeb1YcPhT7JywChCdL9HKU1xlpY4LfTdIsmz/YngMi4DyWvaAL7dPX qY7fh/2rVnqrZXm52SzO =bawW -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Listeners' requestDestoyed() method not called in exception cases
We recently ran into an issue where the requestDestroyed() method of listeners were not being called when exceptions were propagated out of our application. Looking into the code, it seems related to this[1]. Is this the expected behavior for listeners and we can’t rely on the requestDestroyed() method always being called for a request? One option we have considered is migrating to exclusively using filters and handling the exceptional use case explicitly there. Is there a recommended approach for this use case? -Simon [1] http://grepcode.com/file/repo1.maven.org/maven2/org.apache.tomcat.embed/tomcat-embed-core/7.0.59/org/apache/catalina/core/ApplicationDispatcher.java#486
Re: Issues with Tomcat 7.0.57 not loading ActionServlets
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Raj,
On 5/15/15 12:49 PM, RAJ wrote:
Thanks Chris for the quick response, for class loader it is
Loader but as your saying not make that change so will not.
Validator-rules. Xml file is under
Catalina_Home/webapps/app-name/WEB-INF/ and the app is in
exploded format. This is working fine on tomcat 5.x and we just
copied the files from their to tomcat 7.x.
Yes, this looks normal as other functionalities are working except
when we call struts it doesn't work.
- From earlier:
javax.servlet.UnavailableException: Cannot load a validator
resource from '/WEB-INF/validator-rules.xml'
at
org.apache.struts.validator.ValidatorPlugIn.init(ValidatorPlugIn.java:
174)
at org.apache.struts.action.ActionServlet.initModulePlugIns(
ActionServlet.java:839)
I checked the code for ValidatorPlugIn.init and it looks like this
code stupidly swallows the original exception:
try { this.initResources();
servlet.getServletContext().setAttribute(VALIDATOR_KEY +
config.getPrefix(), resources);
servlet.getServletContext().setAttribute(STOP_ON_ERROR_KEY + '.' +
config.getPrefix(), (this.stopOnFirstError ? Boolean.TRUE :
Boolean.FALSE)); } catch (Exception e) { log.error(e.getMessage(),
e); throw new UnavailableException( Cannot load a validator
resource from ' + pathnames + '); }
But! It *does* log it at the ERROR level. Check your other log files
to see what the actual error (and stack trace!) is.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVVjqsAAoJEBzwKT+lPKRYJCgP/0sGsjg8Dn+7l0TAXJEPUNTk
v00h/2MShxWET0olsScyhwLdBIBQi3yjfuVEIq7A5s0StU2JGsN69VncMtaT9OcF
kSIJMQhDxpWI0VaD+2oqQzTfMW6SHB/yrFgxWRlxeVztczrQYuIfWuv5JX/lLOIO
LalZMlRn+7maRcyyvSktriOgbNVWuzuQWw3lOBcWR7Se72T1uFxTIyIhWFX/ieG6
HnYNr/oghMAsb0ief7t0/FRpuOAs2R7cTPyfezPDCk8ba74euq8SUYh8g0fG3Bw0
ihN8myamrPJO/H4nBO9RD2A+VaGGR+Pkr4iNnsRklxwtssanuEI5ppLrvRSO1l5D
Da4Hg+8q+4tepCBaZ/qx+eCJhHTVTezmOr5qIbWBPnRKbkK05dySYGaJV7hNS4ks
TQmszvXe3mfMRMMJXofX+hgqhcKa9ZR6YpJxnc+0GLuAmt1Z+Zbz47fEj1Y8dorZ
bMluz5fwIxavnokIA6a+xQGnhxyAmSJovCZWSlBUNnOTsbiJZ8t1gjk8bLZO4RQ+
osCL6+tyVLEVDKXO6Ax2BjvShjywMJan+c+ulTY8CXF/0iIPvxaVy9j9C2N1Vfcc
WAlocKne//iDIm0tWU7b72XZcwA6xoXMLM2LaFHVg9NuIPzhRfAJ2LsMs+BD4bgz
pG9gSXQMqM93v5lzi2fi
=hjYO
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Http 2 support in Tomcat
On 15/05/2015 19:23, Christopher Schultz wrote: Mark, On 5/15/15 12:59 PM, Mark Thomas wrote: On 15/05/2015 17:49, Christopher Schultz wrote: Tony, On 5/15/15 12:06 PM, PerfGuru wrote: Good news thanks for the update. It may be some time before servlet 4 support is released but good to know Tomcat will be ready then. But does APR support http/2? I know other web servers now do. Mark's initial work on the HTTP/2 connector has been using APR. Note that APR doesn't handle the HTTP protocol, it just helps manage sockets, pools, etc. The protocol needs to be built on top of those building blocks. Please see the dev list (archives) for details. Just search for HTTP/2 subjects. Correct. This is primarily because ALPN support is not there in JSSE yet and wont be until Java 9. That said, one of the reasons for the huge amount of connector refactoring that I did before starting on HTTP/2 was so that the connector implementation specific code was kept to a minimum (so far just ALPN). HTTP/2 will work just fine with NIO and NIO2 just as soon as JSSE support ALPN and we plumb it in. Is this something that's workable with the current pre-release builds of Java 9? I have no idea. I haven't had time to look at it. If you fancy playing with it ..; ;) Presumably, Servlet 4 will require Java 8. Does that mean that HTTP/2 with the NIO connectors will only be available with a higher JRE version? The good folks over at Jetty have an ugly hack (involves replacing part of the JRE) that back-ports the feature to Java 8 so it will be available that way. There are other options too. h2c support (HTTP/2 over a cleartext channel via HTTP upgrade rather than TLS) is also on the TODO list. It shouldn't be much work to add (less than a day) and it wil be available for all connectors. Also, I think Tomcat supports websockets which has the important capabilities that http/2 has and has been available longer. Tomcat supports Websocket since Tomcat 7, as long as you are running on Java 7 or higher. Depending upon your strategy you might want to go with that or wait a couple of years for http/2. Remember the firewalls, proxies and other network systems have to support http/2 before it can reach Tomcat. So it may be by the time http/3 is approved. Tomcat has no choice (application developers do). Servlet 4.0 will require HTTP/2 so Tomcat has to support it. Correct. Using Websocket through certain proxies (e.g. httpd) is even still sometimes tricky. Yeah. We should touch base with jimjag and discuss this. I think the httpd thinking around WebSockets and the Java world thinking about WebSockets aren't quite lined up. +1 Perhaps there isn't much use for Websockets in the Perl or PHP world, where a lot of httpd installations are being used. Jim Riggs's (reprise, I believe) presentation at ApacheCon about how mod_php needs to die (paraphrasing) advocates more extensive use of mod_proxy_* to physically separate the web tier from the application tier, in a way that more closely resembles how Java webapps are deployed. Perhaps if the world starts listening to the Jim Riggses of the world, the shortcomings of mod_proxy_websocket and friends will become more apparent. +1. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Http 2 support in Tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Tony, On 5/15/15 12:06 PM, PerfGuru wrote: Good news thanks for the update. It may be some time before servlet 4 support is released but good to know Tomcat will be ready then. But does APR support http/2? I know other web servers now do. Mark's initial work on the HTTP/2 connector has been using APR. Note that APR doesn't handle the HTTP protocol, it just helps manage sockets, pools, etc. The protocol needs to be built on top of those building blocks. Please see the dev list (archives) for details. Just search for HTTP/2 subjects. Also, I think Tomcat supports websockets which has the important capabilities that http/2 has and has been available longer. Tomcat supports Websocket since Tomcat 7, as long as you are running on Java 7 or higher. Depending upon your strategy you might want to go with that or wait a couple of years for http/2. Remember the firewalls, proxies and other network systems have to support http/2 before it can reach Tomcat. So it may be by the time http/3 is approved. Correct. Using Websocket through certain proxies (e.g. httpd) is even still sometimes tricky. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVViOkAAoJEBzwKT+lPKRYr30P/10riJrlBEM4jYSvAfnO/DXP kGf1y5bX6TIgMk1USIrCRMayKNWH/YDRpbOIWA5/dg3tN2Uq1XBANa1hUxmN89KX +ESKe/jyxZoGayCK3q9V3pTgwixSzGzpSzMsQ37KXQw/yhcYS48sZqbCfMjQ0ajx 8AKWw2tPXbTPen5XXvxWB2SaCfmpVOPuXTxXIqJwOThStOkfMj8ko5yn9A+lNUJp EDZq4Tk3sLxOpTq9oDKeyweYUxUurj2F0+TZ3Z+lV5BN3/G4WWUcvStS8Zwa5r1f rQ+mn6Dj3X/pGGS2YmtotlibYB0zFybXKli7zNeXgir0+xprNgF6nm0pu6iZdogx hBU4ulKi9R66HPPVSBIMpqz5bo4Sg2p7yockIqrMmRP/Wv9VLL53pBOuxFvCvVgd gYdaVBe71cJDmVNfZpBGMfH0wNd7EZ4WJsCcVZupc6kLWeD/BjIOfGVvRvmKBhuX DvPFz6WqQpSU5Cs1dZSZ9+uD4dRljToqOXA9TBRSLENaS31PKdVVJW6Fl1sqwK90 7Gr84CIcVS9RyYpnFoR93fDaxgTkus9AxIUa3YfHUde3C6ISwvdw0ioCTfYfli9D D4HuGou/vB6SniwL6gs1wemq6SBaT0I1CO7fRlOQRb+RI4HkH5YOAzt5FM18OPR6 kzRHzg3egOnSFVF0LiFz =7HLo -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Http 2 support in Tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Tony, On 5/15/15 2:43 PM, PerfGuru wrote: Thanks Mark Chris this is a very informative. I am using a httpd that supports http/2 and wow is it impressive. Sorry, I had to stop using Apache/Tomcat to use it but the performance and bandwidth gains are so nice it is addicting and my users have noticed. How does it compare to, say, HTTP/1.1 + Content-Encoding: gzip? I realize that HTTP/1.1 never compresses the message headers and that H/2 uses tokens and Huffman Coding to further compress the headers, but I'd like to see some real-world data if you have it. What server are you using? I will look into jre/jdk 9 and ask Oracle if servlet 4 is in the EA's. I would like to stay with http/2 rather than go to websockets but I am an early adopter and if it is stable and has servlet 4 with http/2 I will give it a try and let you know the results. When Tomcat 9 goes Stable, HTTP/2 will definitely work. I'm sure there will be some edge cases that will need to be fixed as time goes on, but the spec will require H/2 and Tomcat will implement faithfully. We don't want to merely say oh, yeah, H/2 kinda works and, well, we HAD to do it, so YMMV. We want to say you can rely on Tomcat to serve H/2 as well as H/1. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVVlvjAAoJEBzwKT+lPKRY3bwP/1wqb41Eu1fqN80MbrcUUdrJ qnrWD4o9EsvpPo5Abe0mkGXwiP+F2blDKFRYSXolpuADbmMpsd2gLPjrEGiy6H/J M6HFbjWPTAt4cIzscSZjAAUrpe05v0M39ZuV7z+nHXjT5UTyZQgmiNn3uvHPbVwQ DnfwTReswgyi0E5O5Q3qRz32lP49OpZyLgvAEl4N2cd64a+7ScX1eMHpq/NuVuQ8 N+E/GdgsC+UFOO6DYKHNsn8/kOZ1B7oP4e9fmudnBDCXOFTfqB5lsgGRTkvdXQR8 6dJEq8PkkTxPt0tqdd0UAT6FcLU0Axsm/CzNtej5pj5mIUrt9e5PpRPLH8uk1h2/ waq88NyOxJoYKycngubgK/rL1IET7kJ/Nu4f4j4hFDhMxox1w3K9HrMdKogpPYCY Uh7mdCphpjQxZirkwDnDlwOtbq+t66mNM/DJkeumQ3zfC3fe2wLevnDd7cNOEEx/ fj/r2GbB5p+EtOm67ysAyMc5STdobbueZO/ggBleD2tIiMxOcWE+sXbaXHNzydw4 y9phbm75Q2P8w8EslITnyqyTtbUdyAYJUAhy6nosHXujwwAp+wK+J1yfSzlu4a2w fLjgp92QsYP5fcA7yyNv0zI0tIREKJwONyL+vd2DD1IGibdxKGssjCtUr0QkhpfT BXvYpY5JXNoF0YDIEchy =QGzZ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Listeners' requestDestoyed() method not called in exception cases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Simon, On 5/15/15 2:26 PM, Pilkington, Simon wrote: We recently ran into an issue where the requestDestroyed() method of listeners were not being called when exceptions were propagated out of our application. Looking into the code, it seems related to this[1]. Is this the expected behavior for listeners and we can’t rely on the requestDestroyed() method always being called for a request? Hmm. Looking at the spec, I don't see any requirement that the container *must* invoke those event listeners, so I think Tomcat is in-spec, here. That being said, I think a reasonable person would expect that the listener would fire even in the case of an exception condition. This is something I might want to file with the Servlet EG. At the very least, they might be able to make a statement about the intent of the EG, and provide a clarification with the next release of the Specification. Would you be willing to do that? The Servlet EG's JIRA instance is dog-slow, but usable. One option we have considered is migrating to exclusively using filters and handling the exceptional use case explicitly there. Is there a recommended approach for this use case? That all depends upon your use case. The Filter interface certainly allows you to use your own try/catch blocks to make sure you intercept exceptions that propagate up the stack. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVVjxiAAoJEBzwKT+lPKRYVpIQAJUg37n/jybTxhhKYK/j53dL nKDK4C/PJDlwewvmeljtSHD9ghqGXR1WMgnfkXDcECVARJqgoEhOhTT+aY8W7b0M /BDvB48LiCYkaE6/z6gEqDkrz+JWo2y1p2m/3XgwOaYdhvqzlC0Le88tB+scmDdo LgaJFTrgVyTDdH1cZs3d0TAFCy+5kQR7Zt8UxxRL7xaxohwj5NB8KMVD4TZZysY8 Q3PBAsjI43bJYgLlVFX9lp3aDWKd4Ug549z2BMrFDeRivP6tkwNaCRICuluHClrx opEpQj7kvpQOUivQfmYxRTHqavoj0rgaOtocvtN/+4TRboTff6fpxSTZJtSVc/gc OIRGe7t6wr7jqLXvTw7eAV49zMsA23GwSUb1fa62kaLdmW2ohxLGpQud45yUgYSr gM01UP6gIWuckO1mMAT8kEsujUGC3eCxAUJCV9F8ZNnw4zT5SS2DIPbzvj6I5qIR q7GGmskfeijKDOHyt111McQbQFYl9liMiKBOORd1wDk9lGP/QzPqpGSvZhwDA0wa NlBABocrAgsWPjk81jjvaDdpVMVsv3269FTiQhh4D06372tai6E0/cV+uKHrPGOU BV4R6gS9FuQTc7VRiSmenusvuw5ILD1/YhnU3eU/0V+ovq5Nn0PLTq0Xr1lPnrnZ 3oLXMtc/GwZ0PNOXDDVB =fFyO -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Http 2 support in Tomcat
Thanks Mark Chris this is a very informative. I am using a httpd that supports http/2 and wow is it impressive. Sorry, I had to stop using Apache/Tomcat to use it but the performance and bandwidth gains are so nice it is addicting and my users have noticed. I will look into jre/jdk 9 and ask Oracle if servlet 4 is in the EA's. I would like to stay with http/2 rather than go to websockets but I am an early adaptor and if it is stable and has servlet 4 with http/2 I will give it a try and let you know the results. Best Regards,-Tony From: Mark Thomas ma...@apache.org To: Tomcat Users List users@tomcat.apache.org Sent: Friday, May 15, 2015 12:28 PM Subject: Re: Http 2 support in Tomcat On 15/05/2015 19:23, Christopher Schultz wrote: Mark, On 5/15/15 12:59 PM, Mark Thomas wrote: On 15/05/2015 17:49, Christopher Schultz wrote: Tony, On 5/15/15 12:06 PM, PerfGuru wrote: Good news thanks for the update. It may be some time before servlet 4 support is released but good to know Tomcat will be ready then. But does APR support http/2? I know other web servers now do. Mark's initial work on the HTTP/2 connector has been using APR. Note that APR doesn't handle the HTTP protocol, it just helps manage sockets, pools, etc. The protocol needs to be built on top of those building blocks. Please see the dev list (archives) for details. Just search for HTTP/2 subjects. Correct. This is primarily because ALPN support is not there in JSSE yet and wont be until Java 9. That said, one of the reasons for the huge amount of connector refactoring that I did before starting on HTTP/2 was so that the connector implementation specific code was kept to a minimum (so far just ALPN). HTTP/2 will work just fine with NIO and NIO2 just as soon as JSSE support ALPN and we plumb it in. Is this something that's workable with the current pre-release builds of Java 9? I have no idea. I haven't had time to look at it. If you fancy playing with it ..; ;) Presumably, Servlet 4 will require Java 8. Does that mean that HTTP/2 with the NIO connectors will only be available with a higher JRE version? The good folks over at Jetty have an ugly hack (involves replacing part of the JRE) that back-ports the feature to Java 8 so it will be available that way. There are other options too. h2c support (HTTP/2 over a cleartext channel via HTTP upgrade rather than TLS) is also on the TODO list. It shouldn't be much work to add (less than a day) and it wil be available for all connectors. Also, I think Tomcat supports websockets which has the important capabilities that http/2 has and has been available longer. Tomcat supports Websocket since Tomcat 7, as long as you are running on Java 7 or higher. Depending upon your strategy you might want to go with that or wait a couple of years for http/2. Remember the firewalls, proxies and other network systems have to support http/2 before it can reach Tomcat. So it may be by the time http/3 is approved. Tomcat has no choice (application developers do). Servlet 4.0 will require HTTP/2 so Tomcat has to support it. Correct. Using Websocket through certain proxies (e.g. httpd) is even still sometimes tricky. Yeah. We should touch base with jimjag and discuss this. I think the httpd thinking around WebSockets and the Java world thinking about WebSockets aren't quite lined up. +1 Perhaps there isn't much use for Websockets in the Perl or PHP world, where a lot of httpd installations are being used. Jim Riggs's (reprise, I believe) presentation at ApacheCon about how mod_php needs to die (paraphrasing) advocates more extensive use of mod_proxy_* to physically separate the web tier from the application tier, in a way that more closely resembles how Java webapps are deployed. Perhaps if the world starts listening to the Jim Riggses of the world, the shortcomings of mod_proxy_websocket and friends will become more apparent. +1. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Http 2 support in Tomcat
On 15/05/2015 17:49, Christopher Schultz wrote: Tony, On 5/15/15 12:06 PM, PerfGuru wrote: Good news thanks for the update. It may be some time before servlet 4 support is released but good to know Tomcat will be ready then. But does APR support http/2? I know other web servers now do. Mark's initial work on the HTTP/2 connector has been using APR. Note that APR doesn't handle the HTTP protocol, it just helps manage sockets, pools, etc. The protocol needs to be built on top of those building blocks. Please see the dev list (archives) for details. Just search for HTTP/2 subjects. Correct. This is primarily because ALPN support is not there in JSSE yet and wont be until Java 9. That said, one of the reasons for the huge amount of connector refactoring that I did before starting on HTTP/2 was so that the connector implementation specific code was kept to a minimum (so far just ALPN). HTTP/2 will work just fine with NIO and NIO2 just as soon as JSSE support ALPN and we plumb it in. h2c support (HTTP/2 over a cleartext channel via HTTP upgrade rather than TLS) is also on the TODO list. It shouldn't be much work to add (less than a day) and it wil be available for all connectors. Also, I think Tomcat supports websockets which has the important capabilities that http/2 has and has been available longer. Tomcat supports Websocket since Tomcat 7, as long as you are running on Java 7 or higher. Depending upon your strategy you might want to go with that or wait a couple of years for http/2. Remember the firewalls, proxies and other network systems have to support http/2 before it can reach Tomcat. So it may be by the time http/3 is approved. Tomcat has no choice (application developers do). Servlet 4.0 will require HTTP/2 so Tomcat has to support it. Correct. Using Websocket through certain proxies (e.g. httpd) is even still sometimes tricky. Yeah. We should touch base with jimjag and dicuss this. I think the httpd thinking around WebSockets and the Java world thinking about WebSockets aren't quite lined up. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Http 2 support in Tomcat
Am 15.05.2015 um 20:43 schrieb PerfGuru: Thanks Mark Chris this is a very informative. I am using a httpd that supports http/2 and wow is it impressive. Sorry, I had to stop using Apache/Tomcat to use it but the performance and bandwidth gains are so nice it is addicting and my users have noticed. I will look into jre/jdk 9 and ask Oracle if servlet 4 is in the EA's. I would like to stay with http/2 rather than go to websockets but I am an early adaptor and if it is stable and has servlet 4 with http/2 I will give it a try and let you know the results. Best Regards,-Tony Note that web socket and HTTP/2 serve very different purposes. Web sockets provide you basically with a socket you can use for setting up your own protocol and get rid of request/response semantics. Web socket allow to set up asynchoneous communication. HTTP/2 more or less has the same request/response semantics as HTTP. It is onyl a more efficient implementation of that by combining multiple request/response streams into one TCP connection, using header compression etc. etc. HTTP/2 is still synchroneous. Yes, there is a notion of server push, but push in HTTP/2 is very different from what one would name a push in the web socket world. I think it would be better to clearly keep the two terms web socket and HTTP/2 separated. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
