The Java version wasn't it. Recompiled and redeployed with 1.7.0_25
and it had no effect.
The SSL handshake problem went away when we disabled TLS 1.1/1.2 in the
JCP on the client side and clicked Restore Security Prompts in the JCP.
There was also a problem with JSESSIONID not being sent to
2014-03-06 0:30 GMT+04:00 Bill Davidson bill...@gmail.com:
The Java version wasn't it. Recompiled and redeployed with 1.7.0_25
and it had no effect.
The SSL handshake problem went away when we disabled TLS 1.1/1.2 in the
JCP on the client side and clicked Restore Security Prompts in the JCP.
On 3/5/2014 12:52 PM, Konstantin Kolinko wrote:
Session cookie is HttpOnly in Tomcat 7.
If you missed that in migration guide, it is here:
http://tomcat.apache.org/migration-7.html#Session_cookie_configuration
I added this to some code that is executed by most requests that we use to
track
2014-03-06 2:11 GMT+04:00 Bill Davidson bill...@gmail.com:
On 3/5/2014 12:52 PM, Konstantin Kolinko wrote:
Session cookie is HttpOnly in Tomcat 7.
If you missed that in migration guide, it is here:
http://tomcat.apache.org/migration-7.html#Session_cookie_configuration
I added this to some code
On 3/5/2014 2:28 PM, Konstantin Kolinko wrote:
The HttpOnly flag is used by cookies sent by server to the client.
There is no point checking it on request.getCookies(), as browsers do
not send it back (neither do they send 'path', 'secure' etc.).
Isn't that showing what the server is sending
On 3/5/2014 2:28 PM, Konstantin Kolinko wrote:
The HttpOnly flag is used by cookies sent by server to the client.
There is no point checking it on request.getCookies(), as browsers do
not send it back (neither do they send 'path', 'secure' etc.).
1. Isn't that what gets sent from the
Isn't the applet supposed to send browser cookies regardless of if
Javascript can see them?
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
We tried to upgrade a production server to Tomcat 7 yesterday and it
broke our printing applet that we use to control a printer in its native
printer language.
This seemed odd to us because it worked perfectly in testing. When we
go direct to our production servers (bypassing the Cisco load
On 3/4/2014 9:40 AM, Bill Davidson wrote:
We tried to upgrade a production server to Tomcat 7 yesterday and it
broke our printing applet that we use to control a printer in its native
printer language.
This seemed odd to us because it worked perfectly in testing. When we
go direct to our
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Bill,
On 3/4/14, 1:26 PM, Bill Davidson wrote:
On 3/4/2014 9:40 AM, Bill Davidson wrote:
We tried to upgrade a production server to Tomcat 7 yesterday and
it broke our printing applet that we use to control a printer in
its native printer
On 3/4/2014 11:01 AM, Christopher Schultz wrote:
On 3/4/14, 1:26 PM, Bill Davidson wrote:
I realized that I forgot a lot of info:
Tomcat 7.0.47 on RHEL 5.10 Apache httpd 2.2.25
It worked fine with Tomcat 6.0.37
The applet is bit-for-bit identical. It's built with Java 1.1
compatibility
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Bill,
On 3/4/14, 2:14 PM, Bill Davidson wrote:
On 3/4/2014 11:01 AM, Christopher Schultz wrote:
On 3/4/14, 1:26 PM, Bill Davidson wrote:
I realized that I forgot a lot of info:
Tomcat 7.0.47 on RHEL 5.10 Apache httpd 2.2.25
It worked fine
On 3/4/2014 11:22 AM, Christopher Schultz wrote:
Aah, sorry, I had missed that. So, the only change was Tomcat? No
upgrade to mod_jk or anything like that? OpenSSL upgrade? Upgraded
Java on the client? Everything else *absolutely* the same?
Exact same httpd, including mod_jk. Same files.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Bill,
On 3/4/14, 4:16 PM, Bill Davidson wrote:
On 3/4/2014 11:22 AM, Christopher Schultz wrote:
Aah, sorry, I had missed that. So, the only change was Tomcat?
No upgrade to mod_jk or anything like that? OpenSSL upgrade?
Upgraded Java on the
On 3/4/2014 1:24 PM, Christopher Schultz wrote:
Well... then you'd need a balancer for each balancer ;)
Can you reproduce this issue yourself on your own computer (running
the applet locally)? If so, what version of Java is running?
That's mostly what I've been doing for the last 24 hours.
On 3/4/2014 1:36 PM, Bill Davidson wrote:
On 3/4/2014 1:24 PM, Christopher Schultz wrote:
Well... then you'd need a balancer for each balancer ;)
Can you reproduce this issue yourself on your own computer (running
the applet locally)? If so, what version of Java is running?
That's mostly
On 3/4/2014 3:13 PM, Mark Eggers wrote:
Hmm, is the applet signed, and is the certificate from a trusted authority?
Oracle recently made some changes to Java which tightened down applet security.
They also made some changes in the security policy that block communication on
well-known ports
Did you try generating / regenerating your certificated.
Once done put it under your security directory within your jdk home
On Tue, Mar 4, 2014 at 11:10 PM, Bill Davidson bill...@gmail.com wrote:
We tried to upgrade a production server to Tomcat 7 yesterday and it
broke our printing applet
18 matches
Mail list logo
