Programmer | Westwood One
rn...@westwoodone.com
-Original Message-
From: Mark Thomas
Sent: Tuesday, April 2, 2024 10:05 AM
To: users@tomcat.apache.org
Subject: [EXT]Re: unable to set compression, compressionMinSize and
compressableMinemType attributes in UpgradeProtocol element
On 02/04
of its name imply it is better?
Rick Noel
Systems Programmer | Westwood One
rn...@westwoodone.com
-Original Message-
From: Mark Thomas
Sent: Tuesday, April 2, 2024 10:05 AM
To: users@tomcat.apache.org
Subject: [EXT]Re: unable to set compression, compressionMinSize and
compressableMinemType
On 02/04/2024 14:53, Rick Noel wrote:
Hello,
What am I missing here?
You haven't provided information on the Tomcat version you are using.
I'm assuming 10.1.x.
https://tomcat.apache.org/tomcat-10.1-doc/config/http2.html
Search for compressionMinSize.
I get warnings that the compression
Hello,
What am I missing here?
I get warnings that the compression related attributes of compression,
compressionMinSize and compressableMinemType are not being set.
02-Apr-2024 09:36:24.876 WARNING [main]
org.apache.tomcat.util.digester.SetPropertiesRule.begin Match
[Server/Service
On 02/10/2023 09:35, Leonard wrote:
Hi,
I am debugging a performance issue related to sending binary WebSocket messages
using Tomcat (embed/Spring Boot) 10.1.4 on Java 20 and MacOS 13.5.2.
For this I try to disable compression ("PerMessageDeflate") when sending
messages.
Th
Hi,
I am debugging a performance issue related to sending binary WebSocket messages
using Tomcat (embed/Spring Boot) 10.1.4 on Java 20 and MacOS 13.5.2.
For this I try to disable compression ("PerMessageDeflate") when sending
messages.
The solution described here https://stackov
Hello Mark,
> -Ursprüngliche Nachricht-
> Von: Mark Thomas
> Gesendet: Montag, 7. November 2022 12:43
> An: users@tomcat.apache.org
> Betreff: Re: Tomcat 10 with Http2 and compression sometimes causes pages to
> load partly in FF
>
> On 06/11/2022 19:35, Thom
On 06/11/2022 19:35, Thomas Hoffmann (Speed4Trade GmbH) wrote:
Hello Mark,
I found some time for digging into this older topic with the combination http2,
Firefox, Compression and only partly loaded pages.
I hope I or the topic doesn’t bother you.
Not at all. If there is a Tomcat bug here, I
Hello Mark,
I found some time for digging into this older topic with the combination http2,
Firefox, Compression and only partly loaded pages.
I hope I or the topic doesn’t bother you.
As apache-tomcat-10.0.0-M7 doesn’t show the problem with broken pages in FF
(jsp page only partly loads
Betreff: Re: AW: AW: AW: AW: AW: Tomcat 10 with Http2 and compression
sometimes closes connection with Firefox
On 20/09/2022 20:22, Thomas Hoffmann (Speed4Trade GmbH) wrote:
Hello Mark,
-Ursprüngliche Nachricht-
Von: Mark Thomas
Gesendet: Dienstag, 20. September 2022 20:13
An: users
t; An: users@tomcat.apache.org
> Betreff: Re: AW: AW: AW: AW: AW: Tomcat 10 with Http2 and compression
> sometimes closes connection with Firefox
>
> On 20/09/2022 20:22, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> > Hello Mark,
> >
> >> -Ursprüngliche Nachricht-
>
On 20/09/2022 20:22, Thomas Hoffmann (Speed4Trade GmbH) wrote:
Hello Mark,
-Ursprüngliche Nachricht-
Von: Mark Thomas
Gesendet: Dienstag, 20. September 2022 20:13
An: users@tomcat.apache.org
Betreff: Re: AW: AW: AW: AW: Tomcat 10 with Http2 and compression
sometimes closes connection
Hello Mark,
> -Ursprüngliche Nachricht-
> Von: Mark Thomas
> Gesendet: Dienstag, 20. September 2022 20:13
> An: users@tomcat.apache.org
> Betreff: Re: AW: AW: AW: AW: Tomcat 10 with Http2 and compression
> sometimes closes connection with Firefox
>
> On 20/09/202
and compression sometimes closes
connection with Firefox
On 19/09/2022 19:19, Thomas Hoffmann (Speed4Trade GmbH) wrote:
Hello Mark,
thanks for the update.
The commit looked promising. I tried with Tomcat 10.1 M17 but unfortunately it
didn't help.
The partly loaded website is still occuring.
Setting
information.
Thanks! Thomas
Von: Mark Thomas
Gesendet: Dienstag, 20. September 2022 09:04
An: users@tomcat.apache.org
Betreff: Re: AW: AW: AW: Tomcat 10 with Http2 and compression sometimes closes
connection with Firefox
On 19/09/2022 19:19, Thomas Hoffmann
(...) is not contained here.
Greetings, Thoas
Von: Mark Thomas
Gesendet: Montag, 19. September 2022 19:22
An: users@tomcat.apache.org
Betreff: Re: AW: AW: Tomcat 10 with Http2 and compression sometimes closes
connection with Firefox
Thomas,
Please update to the latest 10.1.x
maybe (?)
Stream.write(...) is not contained here.
Greetings, Thoas
Von: Mark Thomas
Gesendet: Montag, 19. September 2022 19:22
An: users@tomcat.apache.org
Betreff: Re: AW: AW: Tomcat 10 with Http2 and compression sometimes closes
connection with Firefox
Thomas
Hello,
I would create a ticket and sum up all the collected information about this
issue, if there are no further suggestions.
Closing a single stream in http2 causes an internal exception in
StreamProcessor which bubbles up in different ways, depending whether
http-compression is active
> An: Tomcat Users List
> Betreff: AW: AW: Tomcat 10 with Http2 and compression sometimes closes
> connection with Firefox
>
> Oh... I also discovered an additional message in the wireshark dump.
> Tomcat replied with a goaway packet with the text:
> Connection [22], Stre
4Trade GmbH)
>
> Gesendet: Mittwoch, 27. Juli 2022 20:48
> An: Tomcat Users List
> Betreff: AW: AW: Tomcat 10 with Http2 and compression sometimes closes
> connection with Firefox
>
> Hello Mark,
>
> I did some further investigations. I hope I don’t bother you with this t
nstag, 5. Juli 2022 09:59
> An: Tomcat Users List
> Betreff: AW: AW: Tomcat 10 with Http2 and compression sometimes closes
> connection with Firefox
>
> Hallo Mark,
>
> > -Ursprüngliche Nachricht-
> > Von: Mark Thomas
> > Gesendet: Montag, 4. Juli 2022 19:37
&
Hallo Mark,
> -Ursprüngliche Nachricht-
> Von: Mark Thomas
> Gesendet: Montag, 4. Juli 2022 19:37
> An: users@tomcat.apache.org
> Betreff: Re: AW: Tomcat 10 with Http2 and compression sometimes closes
> connection with Firefox
>
> On 30/06/2022 07:40, Mark Thom
On 30/06/2022 07:40, Mark Thomas wrote:
I think I'm going to need the sample app to investigate this.
I have received the sample application and can recreate the issue.
Going back to your original summary:
1) Main page was requested by Firefox from Tomcat (GET ...)
2) Tomcat sends the
related but not the cause of the issue
- The stacktrace was not logged any more with Tomcat 10.0.18 (but
problem stayed)
- The problem only occurs with HTTP2
- It also only occurs when http compression is activated
(compression="force" or "on")
- a provided debug-log of HTTP2 (l
> -Ursprüngliche Nachricht-
> Von: Mark Thomas
> Gesendet: Montag, 27. Juni 2022 22:00
> An: users@tomcat.apache.org
> Betreff: Re: Tomcat 10 with Http2 and compression sometimes closes
> connection with Firefox
>
> On 26/06/2022 15:59, Thomas Hoffmann
On 26/06/2022 15:59, Thomas Hoffmann (Speed4Trade GmbH) wrote:
Hello Mark,
few months ago we already discussed an issue with http2 and compression. The old title
was "Many IllegalStateException when using http2 protocol".
I start from scratch so nobody needs to lookup old stuff and fi
Hello Mark,
few months ago we already discussed an issue with http2 and compression. The
old title was "Many IllegalStateException when using http2 protocol".
I start from scratch so nobody needs to lookup old stuff and first I want to
summarize the old discussion and then add the ne
Hi Mark
crisb> P.S.: If a documentation update is recommended,
crisb> I would be happy to make the changes,
crisb> but I would probably need guidance for that too. ;-)
markt> Source file is here:
markt> https://github.com/apache/tomcat/blob/main/webapps/docs/config/http.xml
markt> A pull
implemented it on at least
one of our dev servers. We may roll that back in light of your suggestion
below.
markt> I'd probably look at getting IIS to compress the content instead:
markt>
https://docs.microsoft.com/en-us/iis/extensions/iis-compression/iis-compression-overview
t> IIS will be using AJP to talk to Tomcat which doesn't support
compression. You may be able to get IIS to compress the files.
Is it possible to connect IIS to TC using HTTP instead of AJP? Several "Tomcat IIS
How-To" articles all mention using AJP (not HTTP) using an ISAPI redirector.
In
t support
compression. You may be able to get IIS to compress the files.
Is it possible to connect IIS to TC using HTTP instead of AJP? Several "Tomcat
IIS How-To" articles all mention using AJP (not HTTP) using an ISAPI redirector.
--
Cris Berneburg
CACI Senio
reverse proxy module (whatever) to fix that.
Maybe there is an option to tell IIS not to uncompress the response. Or
you could add compression to IIS a well. Yes, in that case, TC
compresses, IIS uncompresses and compresses again... :(
Carsten
GMT
Keep-Alive: timeout=20
Connection: keep-alive
Weird, when going thru IIS to TC, it's not compressed:
IIS will be using AJP to talk to Tomcat which doesn't support
compression. You may be able to get IIS to compress the files.
Mark
HTTP/1.1 200 200
Content-Type: application/json;charse
Thanks Mark!
cb> 1. compressionMinSize - What are the units, bytes?
Markt> Yes.
cb> 2. compressibleMimeType - If you specify a type explicitly, [...] Are [the
defaults]
cb> over-ridden, so they need to be specified explicitly too? Or is it
cumulative?
Markt> Default is over-ridden.
OK, that
On 21/07/2021 15:06, Berneburg, Cris J. - US wrote:
Hi Folks :-)
Got some questions about turning on compression. Looking at the documentation
(I did not read the whole thing, just the portions in question), I still need
some clarification.
https://tomcat.apache.org/tomcat-8.5-doc/config
Hi Folks :-)
Got some questions about turning on compression. Looking at the documentation
(I did not read the whole thing, just the portions in question), I still need
some clarification.
https://tomcat.apache.org/tomcat-8.5-doc/config/http.html
1. compressionMinSize - What are the units
Am 2020-06-09 um 22:20 schrieb Mark Thomas:
Hi all,
An enhancement has been opened to enable response compression by default:
https://bz.apache.org/bugzilla/show_bug.cgi?id=64431
In short, the proposal is to change the default for the Connector's
compression attribute from &quo
Although I believe that buggy clients are no longer a problem today,
compression may introduce complications when Tomcat runs behind a
reverse proxy as it is often the case. If your front-end server (e.g.
Apache) needs to modify the responses (e.g. with mod_proxy_http), you'll
end up
On Tue, Jun 9, 2020 at 10:20 PM Mark Thomas wrote:
> Hi all,
>
> An enhancement has been opened to enable response compression by default:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=64431
>
> In short, the proposal is to change the default for the Connector's
> compr
isn't that compression only working when the browser request for it?
So there are buggy browsers that do request it but can't handle it?
i would say that an opt-out is then also fine..
On Wed, 10 Jun 2020 at 08:28, Martin Grigorov wrote:
> On Tue, Jun 9, 2020 at 11:26 PM Manuel Doming
On Tue, Jun 9, 2020 at 11:26 PM Manuel Dominguez Sarmiento
wrote:
> I would not change this default. GZIP (or other kinds) of response
> compression are better addressed as servlet filters. Having the Tomcat
> feature is good, but IMHO it should only be enabled by those who need it.
>
I would not change this default. GZIP (or other kinds) of response
compression are better addressed as servlet filters. Having the Tomcat
feature is good, but IMHO it should only be enabled by those who need it.
At least in our case we have our own code to deal with this, considering
proxying
Hi all,
An enhancement has been opened to enable response compression by default:
https://bz.apache.org/bugzilla/show_bug.cgi?id=64431
In short, the proposal is to change the default for the Connector's
compression attribute from "off" to "on".
This would be for To
sitive to
> network traffic usage, HTTP compression is a must.
Sounds reasonable. In any case, the server and the client should work
together, regardless of whether it's a risky configuration or not.
I was just wondering if maybe this incompatibility might be a
non-issue. But in your case, I th
and
clients should support any valid configuration.
My web application feeds its clients with large chunks of plain text data.
Clients are mobile devices which are sensitive to network traffic usage,
HTTP compression is a must.
Thank you,
Kirill
On Thu, 9 May 2019 at 01:08, Christopher Schultz
> If we open https://www.google.com in Safari (both iOS and Mac OS), we see
> that HTML and JS are received over HTTP/2 with GZIP compression. So in
> general Safari supports HTTP/2+GZIP.
> Could it be that Tomcat does some sort of HTTP/2+GZIP which conforms to all
> the specs but someho
i and native apps on iOS 11 and iOS 12 which means that Tomcat
> HTTP/2 cannot be enabled for any service with iOS clients.
>
> If we open https://www.google.com in Safari (both iOS and Mac OS),
> we see that HTML and JS are received over HTTP/2 with GZIP
> compression. So in general
are received over HTTP/2 with GZIP compression. So in
general Safari supports HTTP/2+GZIP.
Could it be that Tomcat does some sort of HTTP/2+GZIP which conforms to all
the specs but somehow is "Apple-incompatible"? Do you think some subtle
changes (including crazy ones like headers order, etc)
with HTTP/2 support. Everything works perfectly
> fine until I enable content compression.
> Google Chrome on Mac OS is OK with gzip compression. Apple Safari on Mac OS
> and iOS fail with “The operation couldn’t be completed. Protocol error”
> (NSPOSIXErrorDomain:100). iOS URLSessi
Hi,
I am trying to run Tomcat with HTTP/2 support. Everything works perfectly
fine until I enable content compression.
Google Chrome on Mac OS is OK with gzip compression. Apple Safari on Mac OS
and iOS fail with “The operation couldn’t be completed. Protocol error”
(NSPOSIXErrorDomain:100). iOS
Tomcat version in question 8.5.15 and 8.5.31 (tested
>>> on both)
>>
>> http://tomcat.apache.org/tomcat-8.5-doc/config/http.html
>>
>> Search for sendfile.
>>
>> ?
>>
>
> I thought sendfile is NIO only, this was probably the mistake.
It's for NIO/NIO
On Mon, Nov 26, 2018 at 10:27 PM Mark Thomas wrote:
> On 26/11/2018 21:19, Leon Rosenberg wrote:
> > Good time of the day,
> >
> > I am debugging bad page insights reported by google for a mobile versus
> > desktop version of our site and I'm seeing that the static resources,
> > served by the
On 26/11/2018 21:19, Leon Rosenberg wrote:
> Good time of the day,
>
> I am debugging bad page insights reported by google for a mobile versus
> desktop version of our site and I'm seeing that the static resources,
> served by the DefaultServlet (aka files) aren't compressed, versus to
> dynamic
hu, 18 Oct 2018 08:11:28 GMT Content-Type: text/css
Content-Length: 131194 Date: Mon, 26 Nov 2018 20:53:37 GMT
Are there any specific settings to the default servlet to enable it to
support compression? Both files are css, hence they should be covered by
default compression types. Are there
; On 25/07/18 23:05, Aayush Dev wrote:
>> >> With Tomcat 8.5.31, I cant enable gzip compression with HTTP2
>> protocol. If
>> >> someone has successfully enabled compression on Tomcat 8.5 with HTTP2
>> >> protocol, please help me with correct configuration.
&
Thanks Mark. Will wait for the release for our next production upgrade.
-Aayush
On Wed, Aug 1, 2018 at 5:08 PM, pc8...@gmail.com wrote:
> Hurray!
>
>
> > Mark Thomas 於 2018年8月1日 下午4:27 寫道：
> >
> >> On 25/07/18 23:05, Aayush Dev wrote:
> >> With Tomcat
Hurray!
> Mark Thomas 於 2018年8月1日 下午4:27 寫道：
>
>> On 25/07/18 23:05, Aayush Dev wrote:
>> With Tomcat 8.5.31, I cant enable gzip compression with HTTP2 protocol. If
>> someone has successfully enabled compression on Tomcat 8.5 with HTTP2
>> protocol, please help
On 25/07/18 23:05, Aayush Dev wrote:
> With Tomcat 8.5.31, I cant enable gzip compression with HTTP2 protocol. If
> someone has successfully enabled compression on Tomcat 8.5 with HTTP2
> protocol, please help me with correct configuration.
Clean Tomcat 8.5.x dev build
(should work
> see this thread in detail.
>
> https://www.mail-archive.com/users@tomcat.apache.org/msg128302.html <
> https://www.mail-archive.com/users@tomcat.apache.org/msg128302.html>
>
>
>
>
> > On Jul 25, 2018, at 6:05 PM, Aayush Dev wrote:
> >
> > With Tomcat 8.5.3
.
see this thread in detail.
https://www.mail-archive.com/users@tomcat.apache.org/msg128302.html
<https://www.mail-archive.com/users@tomcat.apache.org/msg128302.html>
> On Jul 25, 2018, at 6:05 PM, Aayush Dev wrote:
>
> With Tomcat 8.5.31, I cant enable gzip compression with
With Tomcat 8.5.31, I cant enable gzip compression with HTTP2 protocol. If
someone has successfully enabled compression on Tomcat 8.5 with HTTP2
protocol, please help me with correct configuration.
Things tried:
- tried with and without useSendfile="false" attribute under
Upgra
Fri, 19 Jan 2018 01:13:10
>> GMT status:200
>> strict-transport-security:max-age=31536000;includeSubDomains
>> x-content-type-options:nosniff x-frame-options:SAMEORIGIN
>> x-xss-protection:1; mode=block
>>
>>
>>
>>> On Jan 29, 2018, at 9:49 AM, Christopher Sc
istopherschultz.net> wrote:
>>
> Pierre,
>
> On 1/29/18 7:03 AM, Pierre Chiu wrote:
>>>> According to the change log, this is fixed in in bug 60276.
>>>> However, I cannot make it work.
>>>>
>>>> Gzip compression working fine with
rote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Pierre,
>
> On 1/29/18 7:03 AM, Pierre Chiu wrote:
>> According to the change log, this is fixed in in bug 60276.
>> However, I cannot make it work.
>>
>> Gzip compression working fine w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Pierre,
On 1/29/18 7:03 AM, Pierre Chiu wrote:
> According to the change log, this is fixed in in bug 60276.
> However, I cannot make it work.
>
> Gzip compression working fine without the UpgradeProtocol tag.
> Adding UpgradePro
According to the change log, this is fixed in in bug 60276. However, I cannot
make it work.
Gzip compression working fine without the UpgradeProtocol tag.
Adding UpgradeProtocol for http2 and gzip compression stop working
g java 8 to build
>>> 151 (x86-64), tomcat is producing illegal compressed responses
>>> - sometimes. Firefox and Chrome are complaining about content
>>> encoding errors. Firefox error message is: an invalid or
>>> unknown form of compression was used.
>>>
>>&
mpressed responses - sometimes.
>> Firefox and Chrome are complaining about content encoding errors. Firefox
>> error message is: an invalid or unknown form of compression was used.
>>
>> Tested with tomcat 7.0.56 ant tomcat 7.0.82 on debian stretch and ubuntu
>> artful. The d
is: an invalid or unknown form of compression was used.
Tested with tomcat 7.0.56 ant tomcat 7.0.82 on debian stretch and ubuntu
artful. The debian system is running on openvz kernel 2.6.32-46-pve (system
locale en_US.UTF-8). Ubuntu is running kernel 4.13.0-16 with locale de_DE.UTF-8.
Tomcat's manager
Hello,
We have a very stange problem. Since updating java 8 to build 151 (x86-64),
tomcat is producing illegal compressed responses - sometimes. Firefox and Chrome
are complaining about content encoding errors. Firefox error message is: an
invalid or unknown form of compression was used
ndle
> > files of certain mime types (or all mime-types except for an
> > exclusion list of mime types) and/or of certain sizes while
> > compression will handle files of other mime-types and/or certain
> > sizes?
>
> You could configure a second DefaultServlet that ma
ngle best thing to do
> > to make a user's experience better when accessing a single-page web
> > application, they will say "enable compression" so why it isn't turned on
> > by default was a mystery, and that it plays second fiddle to serving
> static
> > file from t
zes while
> compression will handle files of other mime-types and/or certain
> sizes?
You could configure a second DefaultServlet that matches specific
patterns. You could also configure a "named" DefaultServlet and then
use a Filter to decide if you want your CompressionDefaultServlet to
application, they will say "enable compression" so why it isn't turned on
> by default was a mystery, and that it plays second fiddle to serving static
> file from the file system in an efficient manner was a double mystery.
>
> Perhaps if my fellow tomcat users w
ill handle files of
certain mime types (or all mime-types except for an exclusion list of mime
types) and/or of certain sizes while compression will handle files of
other
mime-types and/or certain sizes?
Both settings have a minimum file size that engages their mechanism but to
set up a division of lab
point where sendFile will handle files of
>> certain mime types (or all mime-types except for an exclusion list of mime
>> types) and/or of certain sizes while compression will handle files of
>> other
>> mime-types and/or certain sizes?
>>
>> Both settings have
mime types (or all mime-types except for an exclusion list of
> mime
> > types) and/or of certain sizes while compression will handle files of
> other
> > mime-types and/or certain sizes?
>
> No.
>
> > Both settings have a minimum file size that engages their mechanism bu
On 18/04/17 15:58, Chris Gamache wrote:
> Excellent information. Thank you!
>
> Is there a way to create a split point where sendFile will handle files of
> certain mime types (or all mime-types except for an exclusion list of mime
> types) and/or of certain sizes while compress
commenting on.
On 18.04.2017 16:58, Chris Gamache wrote:
Excellent information. Thank you!
Is there a way to create a split point where sendFile will handle files of
certain mime types (or all mime-types except for an exclusion list of mime
types) and/or of certain sizes while compression will ha
Hi Cris,
> Excellent information. Thank you!
>
> Is there a way to create a split point where sendFile will handle files of
> certain mime types (or all mime-types except for an exclusion list of mime
> types) and/or of certain sizes while compression will handle files of oth
Excellent information. Thank you!
Is there a way to create a split point where sendFile will handle files of
certain mime types (or all mime-types except for an exclusion list of mime
types) and/or of certain sizes while compression will handle files of other
mime-types and/or certain sizes
On 18.04.2017 14:50, Chris Gamache wrote:
Using tomcat 8.0.43 ...
I'm grappling with GZip compression options. Historically, I've used a
custom GZip filter and that's been fine for the most part. If the file
being served is under 50K the filter would compress it in memory and send
it out
Using tomcat 8.0.43 ...
I'm grappling with GZip compression options. Historically, I've used a
custom GZip filter and that's been fine for the most part. If the file
being served is under 50K the filter would compress it in memory and send
it out. If the file is over 50K, it would connect
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Konstantin,
On 2/4/17 2:43 PM, Konstantin Kolinko wrote:
> 2017-02-04 18:55 GMT+03:00 Patrizio Munzi
> <patrizio.mu...@gmail.com>:
>> It looks like tomcat 8.5 HTTP/2 protocol does not support GZIP
>> compression. Can anyon
On 04/02/17 15:55, Patrizio Munzi wrote:
It looks like tomcat 8.5 HTTP/2 protocol does not support GZIP compression. Can
anyone confirm or give advise on how to enable it?
https://bz.apache.org/bugzilla/show_bug.cgi?id=60276
Mark
2017-02-04 18:55 GMT+03:00 Patrizio Munzi <patrizio.mu...@gmail.com>:
> It looks like tomcat 8.5 HTTP/2 protocol does not support GZIP compression.
> Can anyone confirm or give advise on how to enable it?
>
> The following does not work:
>
> connectionTimeout="2000
It looks like tomcat 8.5 HTTP/2 protocol does not support GZIP compression. Can
anyone confirm or give advise on how to enable it?
The following does not work:
Thanks
--
Patrizio Munzi
t; - Apache Tomcat Native library 1.2.7
>
>
>
> The HTTPS connector on server.xml is the shown below. All works
> properly ex= cept compression, no way to have contents compressed
> in client side. Someon= e knows what could be missing?
How are you determining that com
compression, no way to have contents compressed in client side. Someon= e
knows what could be missing?
Thanks in advance and best regards!
Raúl
, then what happen, e.g IE-11. If user tries
to open the web application from IE-11 , then what happen.
If the server does not support TLS or SPDY compression, then it
doesn't matter what problems the client has.
I'm not sure if there's a way to disable SPDY compression, since it's
built
List
Subject: Re: SSL / TLS compression | SPDY service|CVE-2012-4929
Rahul,
On 27.3.2015 14:42, Rahul Kumar Singh wrote:
So how to disable compression and / or the SPDY service in tomcat6.
If you are using JSSE connectors (BIO/NIO/NIO2), compression is already
disabled because JSSE does
of two configurations that are known to be
required for the CRIME attack:
- SSL / TLS compression is enabled.
The attack allows an attacker to reveal sensitive information that is being
passed inside an encrypted SSL tunnel. The most straightforward way to leverage
this vulnerability is to use
Rahul,
On 27.3.2015 14:42, Rahul Kumar Singh wrote:
So how to disable compression and / or the SPDY service in tomcat6.
If you are using JSSE connectors (BIO/NIO/NIO2), compression is already
disabled because JSSE does not support it, and there is no support for
SPDY protocol on those
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Ognjen,
On 3/27/15 11:04 AM, Ognjen Blagojevic wrote:
On 27.3.2015 14:42, Rahul Kumar Singh wrote:
So how to disable compression and / or the SPDY service in
tomcat6.
If you are using JSSE connectors (BIO/NIO/NIO2), compression is
already
.
From: Ognjen Blagojevic [ognjen.d.blagoje...@gmail.com]
Sent: Friday, March 27, 2015 8:34 PM
To: Tomcat Users List
Subject: Re: SSL / TLS compression | SPDY service|CVE-2012-4929
Rahul,
On 27.3.2015 14:42, Rahul Kumar Singh wrote:
So how to disable
against SSL/TLS
compression. Feel free to read online all about the CRIME
attack.
That was what I was hoping it did when I asked the original
question :)
I haven't really done any analysis of SSL compression (that is,
compression as implemented by the TLS/SSL layer) alone versus
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Martin,
On 8/8/13 8:20 PM, Martin Gainty wrote:
as earlier mentioned
chrome is the only browser that supports compression on SSL
streams
Mozilla Firefox had implemented TLS+compression for SPDY requests, and
thus was vulnerable. Since CRIME
On 09/08/2013 14:50, Christopher Schultz wrote:
It's too bad it took a researcher a year to figure out that
compression of any kind makes encryption (where the attacker can force
random probing attacks) weak. It's not like SSL+compression and
SSL-compression+compression is that different
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Mark,
On 8/9/13 9:14 AM, Mark Thomas wrote:
On 09/08/2013 14:50, Christopher Schultz wrote:
It's too bad it took a researcher a year to figure out that
compression of any kind makes encryption (where the attacker can
force random probing
On 09/08/2013 15:28, Christopher Schultz wrote:
Mark,
On 8/9/13 9:14 AM, Mark Thomas wrote:
On 09/08/2013 14:50, Christopher Schultz wrote:
It's too bad it took a researcher a year to figure out that
compression of any kind makes encryption (where the attacker can
force random probing
1 - 100 of 213 matches
Mail list logo
