Re: [EXT]Re: unable to set compression, compressionMinSize and compressableMinemType attributes in UpgradeProtocol element
On 02/04/2024 15:41, Rick Noel wrote: Mark you were correct. I, needed to move those attributes to the Connection element. Plus on top of that I had this misspelled attribute compressableMinemType should be compressibleMimeType In your opinion, should we use the Upgrade UpgradeProtcol protocol? It depends. h2 is more performant in some circumstances. Best to test and find out. I mean does not the semantics of its name imply it is better? I'm afraid not. It is just the name of the process (HTTP upgrade) use to transition from HTTP/1.1 to h2c. Mark 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 attributes in UpgradeProtocol element 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 related attributes of compression, compressionMinSize and compressableMinemType are not being set. I have also tried moving of compression, compressionMinSize and compressableMinemType to the Connector element with same results That seems ... unlikely. Please provide the Connector configuration and the error message. BTW, I am supposed to get improved speed by using the UpgradeProtcol Correct? It depends. YMMV. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you know the sender and you are sure the content is safe. Please report the message using the Report Message feature in your email client if you believe the email is suspicious. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [EXT]Re: unable to set compression, compressionMinSize and compressableMinemType attributes in UpgradeProtocol element
Mark you were correct. I, needed to move those attributes to the Connection element. Plus on top of that I had this misspelled attribute compressableMinemType should be compressibleMimeType In your opinion, should we use the Upgrade UpgradeProtcol protocol? I mean does not the semantics 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 attributes in UpgradeProtocol element 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 related attributes of compression, > compressionMinSize and compressableMinemType are not being set. > I have also tried moving of compression, compressionMinSize and > compressableMinemType to the Connector element with same results That seems ... unlikely. Please provide the Connector configuration and the error message. > BTW, I am supposed to get improved speed by using the UpgradeProtcol > Correct? It depends. YMMV. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you know the sender and you are sure the content is safe. Please report the message using the Report Message feature in your email client if you believe the email is suspicious. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: unable to set compression, compressionMinSize and compressableMinemType attributes in UpgradeProtocol element
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 related attributes of compression, compressionMinSize and compressableMinemType are not being set. I have also tried moving of compression, compressionMinSize and compressableMinemType to the Connector element with same results That seems ... unlikely. Please provide the Connector configuration and the error message. BTW, I am supposed to get improved speed by using the UpgradeProtcol Correct? It depends. YMMV. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
unable to set compression, compressionMinSize and compressableMinemType attributes in UpgradeProtocol element
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/Connector/UpgradeProtocol] failed to set property [compression] to [on] 02-Apr-2024 09:36:24.880 WARNING [main] org.apache.tomcat.util.digester.SetPropertiesRule.begin Match [Server/Service/Connector/UpgradeProtocol] failed to set property [compressionMinSize] to [2048] 02-Apr-2024 09:36:24.880 WARNING [main] org.apache.tomcat.util.digester.SetPropertiesRule.begin Match [Server/Service/Connector/UpgradeProtocol] failed to set property [compressableMimeType] to [text/html,text/xml,text/plain,text/css,text/javascript,application/javascript,application/json,application/xml] The warnings above came with this server.xml defined. I have also tried moving of compression, compressionMinSize and compressableMinemType to the Connector element with same results BTW, I am supposed to get improved speed by using the UpgradeProtcol Correct? Rick Noel Systems Programmer | Westwood One rn...@westwoodone.com
Re: Websocket: Disable compression/permessage-deflate
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.
The solution described here https://stackoverflow.com/a/30148633/7198739 does not work
anymore, because the option "DISABLE_BUILTIN_EXTENSIONS" was removed some
versions ago.
Is there any alternative method to disable "PerMessageDeflate" in the current
version of Tomcat? Any guidance or suggestions would be appreciated.
In order of likely simplicity:
1. Don't request PerMessageDeflate in the client.
2. Use a custom ServerEndpointConfig.Configurator, override
getNegotiatedExtensions() and return an empty / edited list.
3. Add a Filter *before* WsFilter and change / remove the HTTP header
Sec-WebSocket-Extensions
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Websocket: Disable compression/permessage-deflate
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://stackoverflow.com/a/30148633/7198739 does
not work anymore, because the option "DISABLE_BUILTIN_EXTENSIONS" was removed
some versions ago.
Is there any alternative method to disable "PerMessageDeflate" in the current
version of Tomcat? Any guidance or suggestions would be appreciated.
AW: Tomcat 10 with Http2 and compression sometimes causes pages to load partly in FF
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, 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 want to get it fixed.
>
> > As apache-tomcat-10.0.0-M7 doesn’t show the problem with broken pages
> > in FF (jsp page only partly loads) and it showed up with
> > apache-tomcat-10.0.0-
> M8, I was taking a look at the changes. This was my current approach to this
> topic.
> >
> > The change which makes the difference is in Http2UpgradeHandler:
> > int reserveWindowSize(Stream stream, int reservation, boolean block)
> > throws IOException { ...
> > if (!stream.canWrite()) {
> >
> stream.doStreamCancel(sm.getString("upgradeHandler.stream.notWritable",
> > stream.getConnectionId(),
> > stream.getIdAsString()),
> Http2Error.STREAM_CLOSED);
> > }
> >
> > The older version just threw an exception instead of calling doStreamCancel
> when the client is closing the stream:
> >
> > if (!stream.canWrite()) {
> > throw new CloseNowException(
> >
> > sm.getString("upgradeHandler.stream.notWritable",
> > stream.getConnectionId(),
> > stream.getIdentifier()));
> > }
> >
> > The method doStreamCancel is setting some properties before throwing also
> a CloseNowException:
> >
> > void doStreamCancel(String msg, Http2Error error) throws
> CloseNowException {
> > StreamException se = new StreamException(msg, error, getIdAsInt());
> > // Prevent the application making further writes
> > streamOutputBuffer.closed = true;
> > // Prevent Tomcat's error handling trying to write
> > coyoteResponse.setError();
> > coyoteResponse.setErrorReported();
> > // Trigger a reset once control returns to Tomcat
> > streamOutputBuffer.reset = se;
> > throw new CloseNowException(msg, se);
> > }
> >
> > The line "streamOutputBuffer.closed = true;" seems to be responsible for the
> partly shown pages in FF.
> > If I comment out this line, no problem shows up with FF, http2 and
> compression="force".
>
> Nice bit of detective work. Setting streamOutputBuffer.closed=true will
> prevent
> the application from writing the rest of the resource content which would
> explain the partial response seen on the client side.
>
> > This line seems to have some side effect somewhere else.
> > Unfortunately, I don’t know the code of Tomcat and http2 protocol.
> > Can you think about which side effect this line might have (in combination
> with compression / GZipOutputFilter)?
> > Maybe you have an inspiring idea about the cause or have a hint, where to
> follow the track.
>
> I think this is more symptom rather than root cause. The symptom is visible
> because of the change to call doStreamCancel() but the question for me is what
> is triggering this to be called in the first place.
>
> Digging into that a little:
>
> stream.canWrite() needs to return false.
>
> That happens when the Stream is in one of the states that does not permit
> write. Those states are:
> IDLE
> RESERVED_LOCAL
> HALF_CLOSED_LOCAL
> CLOSED_RX
> CLOSED_TX
> CLOSED_RST_RX
> CLOSED_RST_TX
>
> One thing we could do is improve the error message so it logs the current
> Stream state. That will help narrow down how the Stream got into that state.
>
> I'll get than done for the next set of releases.
>
> Mark
Thank you so much for investigating this.
As far as I saw in the Wireshark dump, the Firefox-Browser is closing one http2
stream (don’t know why FF behaves like that).
It seems FF is fetching cached resources and after fetching recognizes that it
doesn’t need it.
So the reason is that the browser is cancelling / closing the http2-stream.
The closed stream happens in version 10.0.0-M7 and 10.0.0-M8 but only causes
issues in version M8. Thus I assume that the issue is somewhere later on in the
handling.
Strangely it causes only problems in connection with the compression=on/force
setting.
Re: Tomcat 10 with Http2 and compression sometimes causes pages to load partly in FF
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 want to get it fixed.
As apache-tomcat-10.0.0-M7 doesn’t show the problem with broken pages in FF
(jsp page only partly loads) and
it showed up with apache-tomcat-10.0.0-M8, I was taking a look at the changes.
This was my current approach to this topic.
The change which makes the difference is in Http2UpgradeHandler:
int reserveWindowSize(Stream stream, int reservation, boolean block) throws
IOException {
...
if (!stream.canWrite()) {
stream.doStreamCancel(sm.getString("upgradeHandler.stream.notWritable",
stream.getConnectionId(), stream.getIdAsString()),
Http2Error.STREAM_CLOSED);
}
The older version just threw an exception instead of calling doStreamCancel
when the client is closing the stream:
if (!stream.canWrite()) {
throw new CloseNowException(
sm.getString("upgradeHandler.stream.notWritable",
stream.getConnectionId(),
stream.getIdentifier()));
}
The method doStreamCancel is setting some properties before throwing also a
CloseNowException:
void doStreamCancel(String msg, Http2Error error) throws CloseNowException
{
StreamException se = new StreamException(msg, error, getIdAsInt());
// Prevent the application making further writes
streamOutputBuffer.closed = true;
// Prevent Tomcat's error handling trying to write
coyoteResponse.setError();
coyoteResponse.setErrorReported();
// Trigger a reset once control returns to Tomcat
streamOutputBuffer.reset = se;
throw new CloseNowException(msg, se);
}
The line "streamOutputBuffer.closed = true;" seems to be responsible for the
partly shown pages in FF.
If I comment out this line, no problem shows up with FF, http2 and
compression="force".
Nice bit of detective work. Setting streamOutputBuffer.closed=true will
prevent the application from writing the rest of the resource content
which would explain the partial response seen on the client side.
This line seems to have some side effect somewhere else.
Unfortunately, I don’t know the code of Tomcat and http2 protocol.
Can you think about which side effect this line might have (in combination with
compression / GZipOutputFilter)?
Maybe you have an inspiring idea about the cause or have a hint, where to
follow the track.
I think this is more symptom rather than root cause. The symptom is
visible because of the change to call doStreamCancel() but the question
for me is what is triggering this to be called in the first place.
Digging into that a little:
stream.canWrite() needs to return false.
That happens when the Stream is in one of the states that does not
permit write. Those states are:
IDLE
RESERVED_LOCAL
HALF_CLOSED_LOCAL
CLOSED_RX
CLOSED_TX
CLOSED_RST_RX
CLOSED_RST_TX
One thing we could do is improve the error message so it logs the
current Stream state. That will help narrow down how the Stream got into
that state.
I'll get than done for the next set of releases.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 10 with Http2 and compression sometimes causes pages to load partly in FF
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) and
it showed up with apache-tomcat-10.0.0-M8, I was taking a look at the changes.
This was my current approach to this topic.
The change which makes the difference is in Http2UpgradeHandler:
int reserveWindowSize(Stream stream, int reservation, boolean block) throws
IOException {
...
if (!stream.canWrite()) {
stream.doStreamCancel(sm.getString("upgradeHandler.stream.notWritable",
stream.getConnectionId(), stream.getIdAsString()),
Http2Error.STREAM_CLOSED);
}
The older version just threw an exception instead of calling doStreamCancel
when the client is closing the stream:
if (!stream.canWrite()) {
throw new CloseNowException(
sm.getString("upgradeHandler.stream.notWritable",
stream.getConnectionId(),
stream.getIdentifier()));
}
The method doStreamCancel is setting some properties before throwing also a
CloseNowException:
void doStreamCancel(String msg, Http2Error error) throws CloseNowException {
StreamException se = new StreamException(msg, error, getIdAsInt());
// Prevent the application making further writes
streamOutputBuffer.closed = true;
// Prevent Tomcat's error handling trying to write
coyoteResponse.setError();
coyoteResponse.setErrorReported();
// Trigger a reset once control returns to Tomcat
streamOutputBuffer.reset = se;
throw new CloseNowException(msg, se);
}
The line "streamOutputBuffer.closed = true;" seems to be responsible for the
partly shown pages in FF.
If I comment out this line, no problem shows up with FF, http2 and
compression="force".
This line seems to have some side effect somewhere else.
Unfortunately, I don’t know the code of Tomcat and http2 protocol.
Can you think about which side effect this line might have (in combination with
compression / GZipOutputFilter)?
Maybe you have an inspiring idea about the cause or have a hint, where to
follow the track.
Thank you very much in advance,
Thomas
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: AW: AW: AW: AW: AW: Tomcat 10 with Http2 and compression sometimes closes connection with Firefox
On 21/09/2022 06:48, Thomas Hoffmann (Speed4Trade GmbH) wrote: Hallo Mark, thank you for the explanation. Could you guide me in this case? Shall I set all logging options in tomcat to trace (logging.properties)? Thomas, The level of logging in your most recent off-list trace was perfect. The issue was that the logging did not show the problem you described. The issue you described is that the client resets a single stream and Tomcat then incorrectly closes the entire connection. That in turns triggers stack traces in the logs as the application attempts to write to the other streams in the connection as those streams are now closed. I could not find any evidence of that in the logging you provided. Every stack trace associated with a write to a closed stream was preceded by the client sending a reset frame for that stream. You need to: - recreate the case of Tomcat closing an entire connection in response to the client resetting a single stream - capture HTTP/2 debug logs when this occurs - provide those logs Mark Thanks! Thomas -Ursprüngliche Nachricht- Von: Mark Thomas Gesendet: Dienstag, 20. September 2022 22:28 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- 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/2022 17:58, Thomas Hoffmann (Speed4Trade GmbH) wrote: Hello Mark, I will send you the log and access-log to your email address. I am not sure whether it contradicts the observation. For example: - Browser opens a TCP-connection and requests the HTML page. - Tomcat sends single packages with HTML via http2-stream no 1. - Browser requests CSS via http2-stream no 2. - Tomcat serves HTML via stream 1 and css via stream 2. - Browser closes stream 2 which triggers tomcat to close the whole TCP connection including stream 1. - Thus the html stream is also cancelled, leading to a partly visible html page. Thomas, I can find no evidence of the sequence above in the logs you provided. In all the cases I could find, the client first reset the stream sending 0x08 (cancel) as the reason. If you can provide a connection and stream id that exhibits the behaviour you are describing, I'll be happy to look at it. Mark I can record a network trace with wireshark if this helps. The last time I saw that the browser aborts one stream as you described. It shouldn’t close the whole TCP connection, just the stream. I try to get a wireshark dump on weekend. Thomas, A wireshark trace is unlikely to help. I need the Tomcat debug logs to see what is happening internally. You need to provide the debug log trace for an instance where Tomcat closes the entire connection after the client resets a single stream. In all the examples in the previous log, every time there was a stack trace for a stream, it was preceeded by the client resetting that stream - and hence was normal behaviour. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: AW: AW: AW: AW: AW: Tomcat 10 with Http2 and compression sometimes closes connection with Firefox
Hallo Mark, thank you for the explanation. Could you guide me in this case? Shall I set all logging options in tomcat to trace (logging.properties)? Thanks! Thomas > -Ursprüngliche Nachricht- > Von: Mark Thomas > Gesendet: Dienstag, 20. September 2022 22:28 > 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- > >> 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/2022 17:58, Thomas Hoffmann (Speed4Trade GmbH) wrote: > >>> Hello Mark, > >>> > >>> > >>> I will send you the log and access-log to your email address. > >>> > >>> I am not sure whether it contradicts the observation. > >>> > >>> > >>> For example: > >>> > >>> - Browser opens a TCP-connection and requests the HTML page. > >>> > >>> - Tomcat sends single packages with HTML via http2-stream no 1. > >>> > >>> - Browser requests CSS via http2-stream no 2. > >>> > >>> - Tomcat serves HTML via stream 1 and css via stream 2. > >>> > >>> - Browser closes stream 2 which triggers tomcat to close the whole > >>> TCP > >> connection including stream 1. > >>> > >>> - Thus the html stream is also cancelled, leading to a partly > >>> visible html > >> page. > >> > >> Thomas, > >> > >> I can find no evidence of the sequence above in the logs you provided. > >> In all the cases I could find, the client first reset the stream > >> sending > >> 0x08 (cancel) as the reason. > >> > >> If you can provide a connection and stream id that exhibits the > >> behaviour you are describing, I'll be happy to look at it. > >> > >> Mark > > > > I can record a network trace with wireshark if this helps. > > The last time I saw that the browser aborts one stream as you described. > > It shouldn’t close the whole TCP connection, just the stream. > > I try to get a wireshark dump on weekend. > > Thomas, > > A wireshark trace is unlikely to help. I need the Tomcat debug logs to see > what is happening internally. > > You need to provide the debug log trace for an instance where Tomcat > closes the entire connection after the client resets a single stream. > > In all the examples in the previous log, every time there was a stack trace > for > a stream, it was preceeded by the client resetting that stream > - and hence was normal behaviour. > > Mark > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org
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@tomcat.apache.org Betreff: Re: AW: AW: AW: AW: Tomcat 10 with Http2 and compression sometimes closes connection with Firefox On 20/09/2022 17:58, Thomas Hoffmann (Speed4Trade GmbH) wrote: Hello Mark, I will send you the log and access-log to your email address. I am not sure whether it contradicts the observation. For example: - Browser opens a TCP-connection and requests the HTML page. - Tomcat sends single packages with HTML via http2-stream no 1. - Browser requests CSS via http2-stream no 2. - Tomcat serves HTML via stream 1 and css via stream 2. - Browser closes stream 2 which triggers tomcat to close the whole TCP connection including stream 1. - Thus the html stream is also cancelled, leading to a partly visible html page. Thomas, I can find no evidence of the sequence above in the logs you provided. In all the cases I could find, the client first reset the stream sending 0x08 (cancel) as the reason. If you can provide a connection and stream id that exhibits the behaviour you are describing, I'll be happy to look at it. Mark I can record a network trace with wireshark if this helps. The last time I saw that the browser aborts one stream as you described. It shouldn’t close the whole TCP connection, just the stream. I try to get a wireshark dump on weekend. Thomas, A wireshark trace is unlikely to help. I need the Tomcat debug logs to see what is happening internally. You need to provide the debug log trace for an instance where Tomcat closes the entire connection after the client resets a single stream. In all the examples in the previous log, every time there was a stack trace for a stream, it was preceeded by the client resetting that stream - and hence was normal behaviour. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: AW: AW: AW: AW: Tomcat 10 with Http2 and compression sometimes closes connection with Firefox
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/2022 17:58, Thomas Hoffmann (Speed4Trade GmbH) wrote: > > Hello Mark, > > > > > > I will send you the log and access-log to your email address. > > > > I am not sure whether it contradicts the observation. > > > > > > For example: > > > > - Browser opens a TCP-connection and requests the HTML page. > > > > - Tomcat sends single packages with HTML via http2-stream no 1. > > > > - Browser requests CSS via http2-stream no 2. > > > > - Tomcat serves HTML via stream 1 and css via stream 2. > > > > - Browser closes stream 2 which triggers tomcat to close the whole TCP > connection including stream 1. > > > > - Thus the html stream is also cancelled, leading to a partly visible html > page. > > Thomas, > > I can find no evidence of the sequence above in the logs you provided. > In all the cases I could find, the client first reset the stream sending > 0x08 (cancel) as the reason. > > If you can provide a connection and stream id that exhibits the behaviour you > are describing, I'll be happy to look at it. > > Mark I can record a network trace with wireshark if this helps. The last time I saw that the browser aborts one stream as you described. It shouldn’t close the whole TCP connection, just the stream. I try to get a wireshark dump on weekend. > > > > I hope the logs will provide more 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 (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 http2 logging to fine, I can see the following stack: > > > > That looks like the client reset the stream but that doesn't match > > what you are observing which sounds like Tomcat is truncating the > response. > > > >> 19-Sep-2022 20:07:16.651 FEIN [https-openssl-nio-443-exec-9] > >> org.apache.coyote.AbstractProcessor.setErrorState Error state > >> [CLOSE_NOW] reported while processing request > >> org.apache.coyote.CloseNowException: Connection [1], Stream [23], > >> This stream is not writable > > > > That this is happening with connection 1 is good. It means it should > > be easy to reproduce. Please can you: > > - enable debug logging for HTTP/2 > > - restart Tomcat > > - trigger this problem > > - provide the full debug logs > > > > I want to trace what is happening on the HTTP/2 connection leading up > > to the truncation occurring. > > > > Thanks, > > > > Mark > > > > > >> at org.apache.coyote.http2.Stream.doStreamCancel(Stream.java:258) > >> at > >> > org.apache.coyote.http2.Http2UpgradeHandler.reserveWindowSize(Http2U > p > >> gradeHandler.java:919) at > >> > org.apache.coyote.http2.Stream$StreamOutputBuffer.flush(Stream.java:9 > >> 45) at > >> > org.apache.coyote.http2.Stream$StreamOutputBuffer.flush(Stream.java:8 > >> 91) at > >> > org.apache.coyote.http2.Stream$StreamOutputBuffer.end(Stream.java:990 > >> ) at > >> org.apache.coyote.http11.filters.GzipOutputFilter.end(GzipOutputFilte > >> r.java:128) at > >> org.apache.coyote.http2.Http2OutputBuffer.end(Http2OutputBuffer.java: > >> 71) at > >> > org.apache.coyote.http2.StreamProcessor.finishResponse(StreamProcesso > >> r.java:230) at > >> org.apache.coyote.AbstractProcessor.action(AbstractProcessor.java:391 > >> ) at org.apache.coyote.Response.action(Response.java:210) > >> at > >> org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:25 > >> 8) at > >> org.apache.catalina.connector.Response.finishResponse(Response.java:4 > >> 18) at > >> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav > &g
Re: AW: AW: AW: AW: Tomcat 10 with Http2 and compression sometimes closes connection with Firefox
On 20/09/2022 17:58, Thomas Hoffmann (Speed4Trade GmbH) wrote:
Hello Mark,
I will send you the log and access-log to your email address.
I am not sure whether it contradicts the observation.
For example:
- Browser opens a TCP-connection and requests the HTML page.
- Tomcat sends single packages with HTML via http2-stream no 1.
- Browser requests CSS via http2-stream no 2.
- Tomcat serves HTML via stream 1 and css via stream 2.
- Browser closes stream 2 which triggers tomcat to close the whole TCP
connection including stream 1.
- Thus the html stream is also cancelled, leading to a partly visible html page.
Thomas,
I can find no evidence of the sequence above in the logs you provided.
In all the cases I could find, the client first reset the stream sending
0x08 (cancel) as the reason.
If you can provide a connection and stream id that exhibits the
behaviour you are describing, I'll be happy to look at it.
Mark
I hope the logs will provide more 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 (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 http2 logging to fine, I can see the following stack:
That looks like the client reset the stream but that doesn't match what
you are observing which sounds like Tomcat is truncating the response.
19-Sep-2022 20:07:16.651 FEIN [https-openssl-nio-443-exec-9]
org.apache.coyote.AbstractProcessor.setErrorState Error state [CLOSE_NOW]
reported while processing request
org.apache.coyote.CloseNowException: Connection [1], Stream [23], This stream
is not writable
That this is happening with connection 1 is good. It means it should be
easy to reproduce. Please can you:
- enable debug logging for HTTP/2
- restart Tomcat
- trigger this problem
- provide the full debug logs
I want to trace what is happening on the HTTP/2 connection leading up to
the truncation occurring.
Thanks,
Mark
at org.apache.coyote.http2.Stream.doStreamCancel(Stream.java:258)
at
org.apache.coyote.http2.Http2UpgradeHandler.reserveWindowSize(Http2UpgradeHandler.java:919)
at org.apache.coyote.http2.Stream$StreamOutputBuffer.flush(Stream.java:945)
at org.apache.coyote.http2.Stream$StreamOutputBuffer.flush(Stream.java:891)
at org.apache.coyote.http2.Stream$StreamOutputBuffer.end(Stream.java:990)
at
org.apache.coyote.http11.filters.GzipOutputFilter.end(GzipOutputFilter.java:128)
at org.apache.coyote.http2.Http2OutputBuffer.end(Http2OutputBuffer.java:71)
at
org.apache.coyote.http2.StreamProcessor.finishResponse(StreamProcessor.java:230)
at org.apache.coyote.AbstractProcessor.action(AbstractProcessor.java:391)
at org.apache.coyote.Response.action(Response.java:210)
at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:258)
at org.apache.catalina.connector.Response.finishResponse(Response.java:418)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:388)
at org.apache.coyote.http2.StreamProcessor.service(StreamProcessor.java:426)
at
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
at org.apache.coyote.http2.StreamProcessor.process(StreamProcessor.java:87)
at org.apache.coyote.http2.StreamRunnable.run(StreamRunnable.java:35)
at
org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
at
org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: org.apache.coyote.http2.StreamException: Connection [1], Stream
[23], This stream is not writable
at org.apache.coyote.http2.Stream.doStreamCancel(Stream.java:250)
... 20 more
Looks like the Exception bubbles up from the last line of tthis method:
void doStreamCancel(String msg, Http2Error error) throws
CloseNowException {
StreamException se = new StreamException(msg, error, getIdAsInt());
// Prevent the application making further writes
streamOutputBuffer.closed = true;
// Prevent Tomcat's error handling trying to write
coyoteResponse.setError();
coyoteResponse.setErrorReported();
// Trigger a reset once control returns to Tomcat
streamOutputBuffer.reset = se;
throw new CloseNowException(msg, se);
}
The CloseNowException() bubbles up without being caught maybe (?)
Stream.write(...) is not contained here.
Greetings, Thoas
Von: Mark Thomas
Gesendet: Montag, 19. September
AW: AW: AW: AW: Tomcat 10 with Http2 and compression sometimes closes connection with Firefox
Hello Mark,
I will send you the log and access-log to your email address.
I am not sure whether it contradicts the observation.
For example:
- Browser opens a TCP-connection and requests the HTML page.
- Tomcat sends single packages with HTML via http2-stream no 1.
- Browser requests CSS via http2-stream no 2.
- Tomcat serves HTML via stream 1 and css via stream 2.
- Browser closes stream 2 which triggers tomcat to close the whole TCP
connection including stream 1.
- Thus the html stream is also cancelled, leading to a partly visible html page.
I hope the logs will provide more 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 (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 http2 logging to fine, I can see the following stack:
That looks like the client reset the stream but that doesn't match what
you are observing which sounds like Tomcat is truncating the response.
> 19-Sep-2022 20:07:16.651 FEIN [https-openssl-nio-443-exec-9]
> org.apache.coyote.AbstractProcessor.setErrorState Error state [CLOSE_NOW]
> reported while processing request
> org.apache.coyote.CloseNowException: Connection [1], Stream [23], This stream
> is not writable
That this is happening with connection 1 is good. It means it should be
easy to reproduce. Please can you:
- enable debug logging for HTTP/2
- restart Tomcat
- trigger this problem
- provide the full debug logs
I want to trace what is happening on the HTTP/2 connection leading up to
the truncation occurring.
Thanks,
Mark
> at org.apache.coyote.http2.Stream.doStreamCancel(Stream.java:258)
> at
> org.apache.coyote.http2.Http2UpgradeHandler.reserveWindowSize(Http2UpgradeHandler.java:919)
> at org.apache.coyote.http2.Stream$StreamOutputBuffer.flush(Stream.java:945)
> at org.apache.coyote.http2.Stream$StreamOutputBuffer.flush(Stream.java:891)
> at org.apache.coyote.http2.Stream$StreamOutputBuffer.end(Stream.java:990)
> at
> org.apache.coyote.http11.filters.GzipOutputFilter.end(GzipOutputFilter.java:128)
> at org.apache.coyote.http2.Http2OutputBuffer.end(Http2OutputBuffer.java:71)
> at
> org.apache.coyote.http2.StreamProcessor.finishResponse(StreamProcessor.java:230)
> at org.apache.coyote.AbstractProcessor.action(AbstractProcessor.java:391)
> at org.apache.coyote.Response.action(Response.java:210)
> at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:258)
> at org.apache.catalina.connector.Response.finishResponse(Response.java:418)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:388)
> at org.apache.coyote.http2.StreamProcessor.service(StreamProcessor.java:426)
> at
> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
> at org.apache.coyote.http2.StreamProcessor.process(StreamProcessor.java:87)
> at org.apache.coyote.http2.StreamRunnable.run(StreamRunnable.java:35)
> at
> org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
> at
> org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
> at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: org.apache.coyote.http2.StreamException: Connection [1], Stream
> [23], This stream is not writable
> at org.apache.coyote.http2.Stream.doStreamCancel(Stream.java:250)
> ... 20 more
>
>
>
> Looks like the Exception bubbles up from the last line of tthis method:
>
> void doStreamCancel(String msg, Http2Error error) throws
> CloseNowException {
> StreamException se = new StreamException(msg, error, getIdAsInt());
> // Prevent the application making further writes
> streamOutputBuffer.closed = true;
> // Prevent Tomcat's error handling trying to write
> coyoteResponse.setError();
> coyoteResponse.setErrorReported();
> // Trigger a reset once control returns to Tomcat
> streamOutputBuffer.reset = se;
> throw new CloseNowException(msg, se);
> }
>
> The CloseNowException() bubbles up without being caught 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:
Re: AW: AW: AW: Tomcat 10 with Http2 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 http2 logging to fine, I can see the following stack:
That looks like the client reset the stream but that doesn't match what
you are observing which sounds like Tomcat is truncating the response.
19-Sep-2022 20:07:16.651 FEIN [https-openssl-nio-443-exec-9]
org.apache.coyote.AbstractProcessor.setErrorState Error state [CLOSE_NOW]
reported while processing request
org.apache.coyote.CloseNowException: Connection [1], Stream [23], This stream
is not writable
That this is happening with connection 1 is good. It means it should be
easy to reproduce. Please can you:
- enable debug logging for HTTP/2
- restart Tomcat
- trigger this problem
- provide the full debug logs
I want to trace what is happening on the HTTP/2 connection leading up to
the truncation occurring.
Thanks,
Mark
at org.apache.coyote.http2.Stream.doStreamCancel(Stream.java:258)
at
org.apache.coyote.http2.Http2UpgradeHandler.reserveWindowSize(Http2UpgradeHandler.java:919)
at org.apache.coyote.http2.Stream$StreamOutputBuffer.flush(Stream.java:945)
at org.apache.coyote.http2.Stream$StreamOutputBuffer.flush(Stream.java:891)
at org.apache.coyote.http2.Stream$StreamOutputBuffer.end(Stream.java:990)
at
org.apache.coyote.http11.filters.GzipOutputFilter.end(GzipOutputFilter.java:128)
at org.apache.coyote.http2.Http2OutputBuffer.end(Http2OutputBuffer.java:71)
at
org.apache.coyote.http2.StreamProcessor.finishResponse(StreamProcessor.java:230)
at org.apache.coyote.AbstractProcessor.action(AbstractProcessor.java:391)
at org.apache.coyote.Response.action(Response.java:210)
at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:258)
at org.apache.catalina.connector.Response.finishResponse(Response.java:418)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:388)
at org.apache.coyote.http2.StreamProcessor.service(StreamProcessor.java:426)
at
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
at org.apache.coyote.http2.StreamProcessor.process(StreamProcessor.java:87)
at org.apache.coyote.http2.StreamRunnable.run(StreamRunnable.java:35)
at
org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
at
org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: org.apache.coyote.http2.StreamException: Connection [1], Stream
[23], This stream is not writable
at org.apache.coyote.http2.Stream.doStreamCancel(Stream.java:250)
... 20 more
Looks like the Exception bubbles up from the last line of tthis method:
void doStreamCancel(String msg, Http2Error error) throws CloseNowException
{
StreamException se = new StreamException(msg, error, getIdAsInt());
// Prevent the application making further writes
streamOutputBuffer.closed = true;
// Prevent Tomcat's error handling trying to write
coyoteResponse.setError();
coyoteResponse.setErrorReported();
// Trigger a reset once control returns to Tomcat
streamOutputBuffer.reset = se;
throw new CloseNowException(msg, se);
}
The CloseNowException() bubbles up without being caught 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,
Please update to the latest 10.1.x release and re-test. There is what
looks like a fix for this issue in 10.1.0-M12:
https://github.com/apache/tomcat/commit/b738fa6ee0e6789b104e652d95c982827e9753dd
Mark
On 01/08/2022 21:46, Thomas Hoffmann (Speed4Trade GmbH) wrote:
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 or not.
In the first case it leads to closing the complete TCP connection.
Thanks! Thomas
-Ursprüngliche Nachricht-
Von: Thomas Hoffmann (Speed4Trade GmbH)
Gesendet: Donnerstag, 28. Juli 2022 22:25
An: Tomcat Users List
Betreff: AW: AW: Tomcat 10 with Http2 and compression sometimes closes
connection with Firefox
Hello Mark,
I got a stack trace which also shows the involvement of the gzip filter. I set
the loglevel for the http2-StreamProcessor to get the details.
The stack trace was written when the problem with FF occurred.
FF cl
AW: AW: AW: Tomcat 10 with Http2 and compression sometimes closes connection with Firefox
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 http2 logging to fine, I can see the following stack:
19-Sep-2022 20:07:16.651 FEIN [https-openssl-nio-443-exec-9]
org.apache.coyote.AbstractProcessor.setErrorState Error state [CLOSE_NOW]
reported while processing request
org.apache.coyote.CloseNowException: Connection [1], Stream [23], This stream
is not writable
at org.apache.coyote.http2.Stream.doStreamCancel(Stream.java:258)
at
org.apache.coyote.http2.Http2UpgradeHandler.reserveWindowSize(Http2UpgradeHandler.java:919)
at org.apache.coyote.http2.Stream$StreamOutputBuffer.flush(Stream.java:945)
at org.apache.coyote.http2.Stream$StreamOutputBuffer.flush(Stream.java:891)
at org.apache.coyote.http2.Stream$StreamOutputBuffer.end(Stream.java:990)
at
org.apache.coyote.http11.filters.GzipOutputFilter.end(GzipOutputFilter.java:128)
at org.apache.coyote.http2.Http2OutputBuffer.end(Http2OutputBuffer.java:71)
at
org.apache.coyote.http2.StreamProcessor.finishResponse(StreamProcessor.java:230)
at org.apache.coyote.AbstractProcessor.action(AbstractProcessor.java:391)
at org.apache.coyote.Response.action(Response.java:210)
at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:258)
at org.apache.catalina.connector.Response.finishResponse(Response.java:418)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:388)
at org.apache.coyote.http2.StreamProcessor.service(StreamProcessor.java:426)
at
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
at org.apache.coyote.http2.StreamProcessor.process(StreamProcessor.java:87)
at org.apache.coyote.http2.StreamRunnable.run(StreamRunnable.java:35)
at
org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
at
org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: org.apache.coyote.http2.StreamException: Connection [1], Stream
[23], This stream is not writable
at org.apache.coyote.http2.Stream.doStreamCancel(Stream.java:250)
... 20 more
Looks like the Exception bubbles up from the last line of tthis method:
void doStreamCancel(String msg, Http2Error error) throws CloseNowException {
StreamException se = new StreamException(msg, error, getIdAsInt());
// Prevent the application making further writes
streamOutputBuffer.closed = true;
// Prevent Tomcat's error handling trying to write
coyoteResponse.setError();
coyoteResponse.setErrorReported();
// Trigger a reset once control returns to Tomcat
streamOutputBuffer.reset = se;
throw new CloseNowException(msg, se);
}
The CloseNowException() bubbles up without being caught 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,
Please update to the latest 10.1.x release and re-test. There is what
looks like a fix for this issue in 10.1.0-M12:
https://github.com/apache/tomcat/commit/b738fa6ee0e6789b104e652d95c982827e9753dd
Mark
On 01/08/2022 21:46, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> 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 or not.
> In the first case it leads to closing the complete TCP connection.
>
> Thanks! Thomas
>
>
>> -Ursprüngliche Nachricht-
>> Von: Thomas Hoffmann (Speed4Trade GmbH)
>>
>> Gesendet: Donnerstag, 28. Juli 2022 22:25
>> An: Tomcat Users List
>> Betreff: AW: AW: Tomcat 10 with Http2 and compression sometimes closes
>> connection with Firefox
>>
>> Hello Mark,
>>
>> I got a stack trace which also shows the involvement of the gzip filter. I
>> set
>> the loglevel for the http2-StreamProcessor to get the details.
>> The stack trace was written when the problem with FF occurred.
>> FF closed one single stream in http2 connection and tomcat seemed to have
>> closed the whole TCP connection:
>>
>> 28-Jul-2022 22:16:40.939 FEIN [https-openssl-nio-443-exec-13]
>> org.apache.coyote.http2.StreamProcessor.process Connection [0], Stream
>> [23], An error occurred during processing that was fatal to the connection
>>
AW: AW: Tomcat 10 with Http2 and compression sometimes closes connection with Firefox
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 or not. In the first case it leads to closing the complete TCP connection. Thanks! Thomas > -Ursprüngliche Nachricht- > Von: Thomas Hoffmann (Speed4Trade GmbH) > > Gesendet: Donnerstag, 28. Juli 2022 22:25 > An: Tomcat Users List > Betreff: AW: AW: Tomcat 10 with Http2 and compression sometimes closes > connection with Firefox > > Hello Mark, > > I got a stack trace which also shows the involvement of the gzip filter. I set > the loglevel for the http2-StreamProcessor to get the details. > The stack trace was written when the problem with FF occurred. > FF closed one single stream in http2 connection and tomcat seemed to have > closed the whole TCP connection: > > 28-Jul-2022 22:16:40.939 FEIN [https-openssl-nio-443-exec-13] > org.apache.coyote.http2.StreamProcessor.process Connection [0], Stream > [23], An error occurred during processing that was fatal to the connection > java.lang.IllegalStateException: Connection [0], Stream [23], > Unable > to write to stream once it has been closed >at > org.apache.coyote.http2.Stream$StreamOutputBuffer.doWrite(Stream.java: > 880) >at > org.apache.coyote.http11.filters.GzipOutputFilter$FakeOutputStream.write( > GzipOutputFilter.java:158) >at > java.base/java.util.zip.GZIPOutputStream.finish(GZIPOutputStream.java:171 > ) >at > org.apache.coyote.http11.filters.GzipOutputFilter.end(GzipOutputFilter.java > :125) >at > org.apache.coyote.http2.Http2OutputBuffer.end(Http2OutputBuffer.java:71 > ) >at > org.apache.coyote.http2.StreamProcessor.finishResponse(StreamProcessor. > java:209) >at > org.apache.coyote.AbstractProcessor.action(AbstractProcessor.java:386) >at > org.apache.coyote.http2.StreamProcessor.service(StreamProcessor.java:420 > ) >at > org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.ja > va:65) >at > org.apache.coyote.http2.StreamProcessor.process(StreamProcessor.java:73 > ) >at > org.apache.coyote.http2.StreamRunnable.run(StreamRunnable.java:35) >at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolE > xecutor.java:1136) >at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPool > Executor.java:635) >at > org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThr > ead.java:61) >at > java.base/java.lang.Thread.run(Thread.java:833) > > I hope the stack shows the problem and helps to identify the problem. > Seems like the error handling has changed a bit with Tomcat 10.0.0 M8 with > http2 and is causing the issue. > > Thanks in advance! > Thomas > > > -Ursprüngliche Nachricht- > > Von: Thomas Hoffmann (Speed4Trade GmbH) > > > > Gesendet: Mittwoch, 27. Juli 2022 20:52 > > 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], Stream [19], An error occurred during processing > > that was fatal to the connection > > > > > -Ursprüngliche Nachricht- > > > Von: Thomas Hoffmann (Speed4Trade 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 > topic. > > > > > > I was trying to narrow down the tomcat version where the problem > > > started to appear. > > > The problem with the interrupted connection started with 10.0.0-M8 > > > With Tomcat 10.0.0-M7 everything works fine. > > > > > > Comparing the sources, there are some (maybe relevant) changes in > > >
AW: AW: Tomcat 10 with Http2 and compression sometimes closes connection with Firefox
Hello Mark, I got a stack trace which also shows the involvement of the gzip filter. I set the loglevel for the http2-StreamProcessor to get the details. The stack trace was written when the problem with FF occurred. FF closed one single stream in http2 connection and tomcat seemed to have closed the whole TCP connection: 28-Jul-2022 22:16:40.939 FEIN [https-openssl-nio-443-exec-13] org.apache.coyote.http2.StreamProcessor.process Connection [0], Stream [23], An error occurred during processing that was fatal to the connection java.lang.IllegalStateException: Connection [0], Stream [23], Unable to write to stream once it has been closed at org.apache.coyote.http2.Stream$StreamOutputBuffer.doWrite(Stream.java:880) at org.apache.coyote.http11.filters.GzipOutputFilter$FakeOutputStream.write(GzipOutputFilter.java:158) at java.base/java.util.zip.GZIPOutputStream.finish(GZIPOutputStream.java:171) at org.apache.coyote.http11.filters.GzipOutputFilter.end(GzipOutputFilter.java:125) at org.apache.coyote.http2.Http2OutputBuffer.end(Http2OutputBuffer.java:71) at org.apache.coyote.http2.StreamProcessor.finishResponse(StreamProcessor.java:209) at org.apache.coyote.AbstractProcessor.action(AbstractProcessor.java:386) at org.apache.coyote.http2.StreamProcessor.service(StreamProcessor.java:420) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65) at org.apache.coyote.http2.StreamProcessor.process(StreamProcessor.java:73) at org.apache.coyote.http2.StreamRunnable.run(StreamRunnable.java:35) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.base/java.lang.Thread.run(Thread.java:833) I hope the stack shows the problem and helps to identify the problem. Seems like the error handling has changed a bit with Tomcat 10.0.0 M8 with http2 and is causing the issue. Thanks in advance! Thomas > -Ursprüngliche Nachricht- > Von: Thomas Hoffmann (Speed4Trade GmbH) > > Gesendet: Mittwoch, 27. Juli 2022 20:52 > 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], Stream [19], An error occurred during processing that was > fatal to the connection > > > -Ursprüngliche Nachricht- > > Von: Thomas Hoffmann (Speed4Trade 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 > > topic. > > > > I was trying to narrow down the tomcat version where the problem > > started to appear. > > The problem with the interrupted connection started with 10.0.0-M8 > > With Tomcat 10.0.0-M7 everything works fine. > > > > Comparing the sources, there are some (maybe relevant) changes in the > > org.apache.coyote.http2 package from M7 --> M8: > > - Http2AsynUpgradeHandler > > - Http2UpgradeHandler > > - Stream > > - StreamProcessor > > > > The observed problem was, that the browser (firefox) was sending a > > RST_Stream packet to close a single stream within the http2 protocol > > and tomcat was closing the whole connection instead of closing just > > that stream (wireshark dump would be available). > > > > In Stream.java a new method "doStreamCancel" was introduced (or an old > > method was renamed) with release M8. > > This looks related to the observed problem mentioned above. > > > > Does this information help to take a look again at this problem? > > If I should try something or can assist with testing, just let me know. > > > > Thanks! > > Thomas > > > > > > > > > > > -Ursprüngliche Nachricht- > > > Von: Thomas Hoffmann (Speed4Trade GmbH) > > > > > > Gesendet: Dienstag, 5. Juli 2022 09:59 > >
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], Stream [19], An error occurred during processing that was fatal to the connection > -Ursprüngliche Nachricht- > Von: Thomas Hoffmann (Speed4Trade 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 topic. > > I was trying to narrow down the tomcat version where the problem started > to appear. > The problem with the interrupted connection started with 10.0.0-M8 With > Tomcat 10.0.0-M7 everything works fine. > > Comparing the sources, there are some (maybe relevant) changes in the > org.apache.coyote.http2 package from M7 --> M8: > - Http2AsynUpgradeHandler > - Http2UpgradeHandler > - Stream > - StreamProcessor > > The observed problem was, that the browser (firefox) was sending a > RST_Stream packet to close a single stream within the http2 protocol and > tomcat was closing the whole connection instead of closing just that stream > (wireshark dump would be available). > > In Stream.java a new method "doStreamCancel" was introduced (or an old > method was renamed) with release M8. > This looks related to the observed problem mentioned above. > > Does this information help to take a look again at this problem? > If I should try something or can assist with testing, just let me know. > > Thanks! > Thomas > > > > > > -Ursprüngliche Nachricht- > > Von: Thomas Hoffmann (Speed4Trade GmbH) > > > > Gesendet: Dienstag, 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 > > > 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 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 first compressed chunks of data to the browser > > > 3) Firefox reads the first packages and notices, that additional > > > resources are needed (CSS, JS ...) > > > 4) While Tomcat is still sending the main page in chunks, the > > > browser is already requesting additional resources on other channels > > > 5) Firefox is sending a RST_STREAM and closes that last requested > > > stream(s) (dunno why it does request first and then closes the > > > channel) > > > 6) Tomcat is sending a GoAway message to the browser > > > 7) Tomcat stops also sending the main page (on a different channel) > > > > > > > > > I tested with 10.0.x. > > > > > > I don't see the above sequence. > > > > > > I ran the test 4 times, closing the browser between each test > > > > > > When things go wrong it appears that FireFox is re-using the main > > > page > > > (ticket.jsp) from a cache. > > > > > > I see the additional resources being requested and then cancelled. > > > > > > I do not see any GOAWAY messages from Tomcat. > > > > > > I do see a single GOAWAY message from the browser to Tomcat when I > > > close the browser window (as expected). > > > > > > I don't see anything going wrong on the Tomcat side. > > > > > > At the moment, this looks to me like an issue with Firefox rather > > > than with Tomcat. > > > > > > If you can narrow the test case to something that shows Tomcat doing > > > something wrong, then I'd be happy to look at this again. > > > > > > Mark > > > > > > > > > - > > > > Thank you very much for taking a look at it! > > > > I could also see that the browser cache is used sometimes. Sometimes > > the j
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 topic. I was trying to narrow down the tomcat version where the problem started to appear. The problem with the interrupted connection started with 10.0.0-M8 With Tomcat 10.0.0-M7 everything works fine. Comparing the sources, there are some (maybe relevant) changes in the org.apache.coyote.http2 package from M7 --> M8: - Http2AsynUpgradeHandler - Http2UpgradeHandler - Stream - StreamProcessor The observed problem was, that the browser (firefox) was sending a RST_Stream packet to close a single stream within the http2 protocol and tomcat was closing the whole connection instead of closing just that stream (wireshark dump would be available). In Stream.java a new method "doStreamCancel" was introduced (or an old method was renamed) with release M8. This looks related to the observed problem mentioned above. Does this information help to take a look again at this problem? If I should try something or can assist with testing, just let me know. Thanks! Thomas > -Ursprüngliche Nachricht- > Von: Thomas Hoffmann (Speed4Trade GmbH) > > Gesendet: Dienstag, 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 > > 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 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 first compressed chunks of data to the browser > > 3) Firefox reads the first packages and notices, that additional > > resources are needed (CSS, JS ...) > > 4) While Tomcat is still sending the main page in chunks, the browser > > is already requesting additional resources on other channels > > 5) Firefox is sending a RST_STREAM and closes that last requested > > stream(s) (dunno why it does request first and then closes the > > channel) > > 6) Tomcat is sending a GoAway message to the browser > > 7) Tomcat stops also sending the main page (on a different channel) > > > > > > I tested with 10.0.x. > > > > I don't see the above sequence. > > > > I ran the test 4 times, closing the browser between each test > > > > When things go wrong it appears that FireFox is re-using the main page > > (ticket.jsp) from a cache. > > > > I see the additional resources being requested and then cancelled. > > > > I do not see any GOAWAY messages from Tomcat. > > > > I do see a single GOAWAY message from the browser to Tomcat when I > > close the browser window (as expected). > > > > I don't see anything going wrong on the Tomcat side. > > > > At the moment, this looks to me like an issue with Firefox rather than > > with Tomcat. > > > > If you can narrow the test case to something that shows Tomcat doing > > something wrong, then I'd be happy to look at this again. > > > > Mark > > > > - > > Thank you very much for taking a look at it! > > I could also see that the browser cache is used sometimes. Sometimes the > jsp is requested from the server, sometimes not. > > I did several tests again and the behaviour is not very consistent, thus it's > hard to get a handle on the problem. > I was also thinking about the possibility of a Firefox bug but this wouldn’t > explain that: > 1) It only happens with Tomcat 10.x and doesn’t show up with Tomcat 9.x > 2) Users don’t report any problems with other internet websites (using > Firefox) > > The GoAway seems to be sent from time to time by Tomcat, but not always. > I recorded one session which matches my last description: > https://privfile.com/download.php?fid=62c3ec1170199-MTM2OTM= > I set up another PC for testing, thus the IP addresses (source/target) differ > and can be interpreted more easily. > Maybe the last Capture was not readable without the keyfile, thus I > exported it differently and it should be readable now. > > a) Is the behaviour according to the linked network trace an expected > behaviour? (sending a GoAway after a rst_stream message) > b) Have you been able to reproduce the error with Tomcat 9.x? > > If you have any hints or suggestions, how I could narrow it down, please drop > a line. > I don’t have any big or great ideas at the moment. > > Thank you very much! > Thomas > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org
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 > 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 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 first compressed chunks of data to the browser > 3) Firefox reads the first packages and notices, that additional resources are > needed (CSS, JS ...) > 4) While Tomcat is still sending the main page in chunks, the browser is > already requesting additional resources on other channels > 5) Firefox is sending a RST_STREAM and closes that last requested > stream(s) (dunno why it does request first and then closes the channel) > 6) Tomcat is sending a GoAway message to the browser > 7) Tomcat stops also sending the main page (on a different channel) > > > I tested with 10.0.x. > > I don't see the above sequence. > > I ran the test 4 times, closing the browser between each test > > When things go wrong it appears that FireFox is re-using the main page > (ticket.jsp) from a cache. > > I see the additional resources being requested and then cancelled. > > I do not see any GOAWAY messages from Tomcat. > > I do see a single GOAWAY message from the browser to Tomcat when I close > the browser window (as expected). > > I don't see anything going wrong on the Tomcat side. > > At the moment, this looks to me like an issue with Firefox rather than with > Tomcat. > > If you can narrow the test case to something that shows Tomcat doing > something wrong, then I'd be happy to look at this again. > > Mark > > - Thank you very much for taking a look at it! I could also see that the browser cache is used sometimes. Sometimes the jsp is requested from the server, sometimes not. I did several tests again and the behaviour is not very consistent, thus it's hard to get a handle on the problem. I was also thinking about the possibility of a Firefox bug but this wouldn’t explain that: 1) It only happens with Tomcat 10.x and doesn’t show up with Tomcat 9.x 2) Users don’t report any problems with other internet websites (using Firefox) The GoAway seems to be sent from time to time by Tomcat, but not always. I recorded one session which matches my last description: https://privfile.com/download.php?fid=62c3ec1170199-MTM2OTM= I set up another PC for testing, thus the IP addresses (source/target) differ and can be interpreted more easily. Maybe the last Capture was not readable without the keyfile, thus I exported it differently and it should be readable now. a) Is the behaviour according to the linked network trace an expected behaviour? (sending a GoAway after a rst_stream message) b) Have you been able to reproduce the error with Tomcat 9.x? If you have any hints or suggestions, how I could narrow it down, please drop a line. I don’t have any big or great ideas at the moment. Thank you very much! Thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: Tomcat 10 with Http2 and compression sometimes closes connection with Firefox
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 first compressed chunks of data to the browser 3) Firefox reads the first packages and notices, that additional resources are needed (CSS, JS ...) 4) While Tomcat is still sending the main page in chunks, the browser is already requesting additional resources on other channels 5) Firefox is sending a RST_STREAM and closes that last requested stream(s) (dunno why it does request first and then closes the channel) 6) Tomcat is sending a GoAway message to the browser 7) Tomcat stops also sending the main page (on a different channel) I tested with 10.0.x. I don't see the above sequence. I ran the test 4 times, closing the browser between each test When things go wrong it appears that FireFox is re-using the main page (ticket.jsp) from a cache. I see the additional resources being requested and then cancelled. I do not see any GOAWAY messages from Tomcat. I do see a single GOAWAY message from the browser to Tomcat when I close the browser window (as expected). I don't see anything going wrong on the Tomcat side. At the moment, this looks to me like an issue with Firefox rather than with Tomcat. If you can narrow the test case to something that shows Tomcat doing something wrong, then I'd be happy to look at this again. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: Tomcat 10 with Http2 and compression sometimes closes connection with Firefox
On 27/06/2022 21:49, Thomas Hoffmann (Speed4Trade GmbH) wrote: Von: Mark Thomas On 26/06/2022 15:59, Thomas Hoffmann (Speed4Trade GmbH) wrote: Problem: When opening a webpage at a new Tab, Firefox sometimes doesn't load the full page from Tomcat 10 Observation / Circumstances: - Doesn't happen with Tomcat 9 (tested up to 9.0.64) - Problem showed up after upgrading from Tomcat 9.0.56 to 10.0.16 - Tomcat 10.0.16 also showed a stacktrace in the logfile 07-Mar-2022 07:24:01.780 SCHWERWIEGEND [https-openssl-nio-443- exec-21] org.apache.catalina.core.ApplicationDispatcher.invoke Servlet.service() for servlet [jsp] threw exception java.lang.IllegalStateException: Connection [66], Stream [113], Unable to write to stream once it has been closed at org.apache.coyote.http2.Stream$StreamOutputBuffer.doWrite(Stream.java: 843) - The stack is probably 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 (loglevel FINE) didn't narrow down the issue This week I found time for digging down into the rabbit hole and also was able to create an almost static application. I did several network traces and it followed the following scheme: 1) Main page was requested by Firefox from Tomcat (GET ...) 2) Tomcat sends the first compressed chunks of data to the browser 3) Firefox reads the first packages and notices, that additional resources are needed (CSS, JS ...) 4) While Tomcat is still sending the main page in chunks, the browser is already requesting additional resources on other channels 5) Firefox is sending a RST_STREAM and closes that last requested stream(s) (dunno why it does request first and then closes the channel) 6) Tomcat is sending a GoAway message to the browser 7) Tomcat stops also sending the main page (on a different channel) Shouldn't tomcat just close the requested stream and continue serving the other stream(s)? Looks like Tomcat got upset and also closed the other stream :) Pcap-file is available at https://privfile.com/download.php?fid=62b8721f9f29a-MTM1NTk= for around 2 weeks. I could also provide an almost static app which relatively often shows this issue (after several trials). As it contains some internal CI and stuff, I could sent it to a personal address. I tested with Win10 and Win11, FF 101, Tomcat 10.0.16 I am currently working on some HTTP/2 test failures that might be relevant. Can you re-test with this additional attribute set on the Connector element: useAsyncIO="false" Hello Mark, despite this setting, the problem can still be reproduced. My connector looked like: Maybe the wireshark trace above can provide some hints or ideas. If I can test something else or if I should send you the sample app, just drop a line. I think I'm going to need the sample app to investigate this. ma...@apache.org Thanks, Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: Tomcat 10 with Http2 and compression sometimes closes connection with Firefox
> -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 (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 first I want to > summarize the old discussion and then add the new gathered information. > > > > Problem: > > When opening a webpage at a new Tab, Firefox sometimes doesn't load > > the full page from Tomcat 10 > > > > Observation / Circumstances: > > - Doesn't happen with Tomcat 9 (tested up to 9.0.64) > > - Problem showed up after upgrading from Tomcat 9.0.56 to 10.0.16 > > - Tomcat 10.0.16 also showed a stacktrace in the logfile > > 07-Mar-2022 07:24:01.780 SCHWERWIEGEND [https-openssl-nio-443- > exec-21] org.apache.catalina.core.ApplicationDispatcher.invoke > Servlet.service() for servlet [jsp] threw exception > > java.lang.IllegalStateException: Connection [66], Stream [113], > Unable to write to stream once it has been closed > > at > org.apache.coyote.http2.Stream$StreamOutputBuffer.doWrite(Stream.java: > 843) > > at > org.apache.coyote.http11.filters.GzipOutputFilter$FakeOutputStream.write( > GzipOutputFilter.java:159) > > at > java.base/java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream. > java:252) > > at > java.base/java.util.zip.DeflaterOutputStream.write(DeflaterOutputStream.ja > va:210) > > at > java.base/java.util.zip.GZIPOutputStream.write(GZIPOutputStream.java:148 > ) > > at > org.apache.coyote.http11.filters.GzipOutputFilter.doWrite(GzipOutputFilter. > java:69) > > at > org.apache.coyote.http2.Http2OutputBuffer.doWrite(Http2OutputBuffer.jav > a:59) > > at org.apache.coyote.Response.doWrite(Response.java:625) > > at > org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.ja > va:340) > > at > org.apache.catalina.connector.OutputBuffer.flushByteBuffer(OutputBuffer.j > ava:783) > > at > org.apache.catalina.connector.OutputBuffer.realWriteChars(OutputBuffer.ja > va:453) > > at > org.apache.catalina.connector.OutputBuffer.flushCharBuffer(OutputBuffer.j > ava:788) > > at > org.apache.catalina.connector.OutputBuffer.append(OutputBuffer.java:727) > > at > org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:505) > > at > org.apache.catalina.connector.CoyoteWriter.write(CoyoteWriter.java:148) > > at > org.apache.catalina.filters.ExpiresFilter$XPrintWriter.write(ExpiresFilter.java: > 850) > > at > org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:275) > > at java.base/java.io.PrintWriter.write(PrintWriter.java:506) > > at > org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:275) > > at java.base/java.io.PrintWriter.write(PrintWriter.java:506) > > at > org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:112 > ) > > at > org.apache.jasper.runtime.JspWriterImpl.flush(JspWriterImpl.java:160) > > at > org.apache.jsp.WEB_002dINF.jsp.businessrelations.ticket_005frelations_inc_ > jsp._jspService(ticket_005frelations_inc_jsp.java:702) > > ... > > - The stack is probably 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 (loglevel FINE) didn't narrow down the > > issue > > > > > > This week I found time for digging down into the rabbit hole and also was > able to create an almost static application. > > > > I did several network traces and it followed the following scheme: > > 1) Main page was requested by Firefox from Tomcat (GET ...) > > 2) Tomcat sends the first compressed chunks of data to the browser > > 3) Firefox reads the first packages and notices, that additional > > resources are needed (CSS, JS ...) > > 4) While Tomcat is still sen
Re: Tomcat 10 with Http2 and compression sometimes closes connection with Firefox
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 first I want to summarize the old discussion and then add the new gathered information. Problem: When opening a webpage at a new Tab, Firefox sometimes doesn't load the full page from Tomcat 10 Observation / Circumstances: - Doesn't happen with Tomcat 9 (tested up to 9.0.64) - Problem showed up after upgrading from Tomcat 9.0.56 to 10.0.16 - Tomcat 10.0.16 also showed a stacktrace in the logfile 07-Mar-2022 07:24:01.780 SCHWERWIEGEND [https-openssl-nio-443-exec-21] org.apache.catalina.core.ApplicationDispatcher.invoke Servlet.service() for servlet [jsp] threw exception java.lang.IllegalStateException: Connection [66], Stream [113], Unable to write to stream once it has been closed at org.apache.coyote.http2.Stream$StreamOutputBuffer.doWrite(Stream.java:843) at org.apache.coyote.http11.filters.GzipOutputFilter$FakeOutputStream.write(GzipOutputFilter.java:159) at java.base/java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream.java:252) at java.base/java.util.zip.DeflaterOutputStream.write(DeflaterOutputStream.java:210) at java.base/java.util.zip.GZIPOutputStream.write(GZIPOutputStream.java:148) at org.apache.coyote.http11.filters.GzipOutputFilter.doWrite(GzipOutputFilter.java:69) at org.apache.coyote.http2.Http2OutputBuffer.doWrite(Http2OutputBuffer.java:59) at org.apache.coyote.Response.doWrite(Response.java:625) at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:340) at org.apache.catalina.connector.OutputBuffer.flushByteBuffer(OutputBuffer.java:783) at org.apache.catalina.connector.OutputBuffer.realWriteChars(OutputBuffer.java:453) at org.apache.catalina.connector.OutputBuffer.flushCharBuffer(OutputBuffer.java:788) at org.apache.catalina.connector.OutputBuffer.append(OutputBuffer.java:727) at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:505) at org.apache.catalina.connector.CoyoteWriter.write(CoyoteWriter.java:148) at org.apache.catalina.filters.ExpiresFilter$XPrintWriter.write(ExpiresFilter.java:850) at org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:275) at java.base/java.io.PrintWriter.write(PrintWriter.java:506) at org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:275) at java.base/java.io.PrintWriter.write(PrintWriter.java:506) at org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:112) at org.apache.jasper.runtime.JspWriterImpl.flush(JspWriterImpl.java:160) at org.apache.jsp.WEB_002dINF.jsp.businessrelations.ticket_005frelations_inc_jsp._jspService(ticket_005frelations_inc_jsp.java:702) ... - The stack is probably 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 (loglevel FINE) didn't narrow down the issue This week I found time for digging down into the rabbit hole and also was able to create an almost static application. I did several network traces and it followed the following scheme: 1) Main page was requested by Firefox from Tomcat (GET ...) 2) Tomcat sends the first compressed chunks of data to the browser 3) Firefox reads the first packages and notices, that additional resources are needed (CSS, JS ...) 4) While Tomcat is still sending the main page in chunks, the browser is already requesting additional resources on other channels 5) Firefox is sending a RST_STREAM and closes that last requested stream(s) (dunno why it does request first and then closes the channel) 6) Tomcat is sending a GoAway message to the browser 7) Tomcat stops also sending the main page (on a different channel) Shouldn't tomcat just close the requested stream and continue serving the other stream(s)? Looks like Tomcat got upset and also closed the other stream :) Pcap-file is available at https://privfile.com/download.php?fid=62b8721f9f29a-MTM1NTk= for around 2 weeks. I could also provide an almost static app which relatively often shows this issue (after several trials). As it contains some internal CI and stuff, I could sent it to a personal address. I tested with Win10 and Win11, FF 101, Tomcat 10.0.16 I am current
Tomcat 10 with Http2 and compression sometimes closes connection with Firefox
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 new gathered information. Problem: When opening a webpage at a new Tab, Firefox sometimes doesn't load the full page from Tomcat 10 Observation / Circumstances: - Doesn't happen with Tomcat 9 (tested up to 9.0.64) - Problem showed up after upgrading from Tomcat 9.0.56 to 10.0.16 - Tomcat 10.0.16 also showed a stacktrace in the logfile 07-Mar-2022 07:24:01.780 SCHWERWIEGEND [https-openssl-nio-443-exec-21] org.apache.catalina.core.ApplicationDispatcher.invoke Servlet.service() for servlet [jsp] threw exception java.lang.IllegalStateException: Connection [66], Stream [113], Unable to write to stream once it has been closed at org.apache.coyote.http2.Stream$StreamOutputBuffer.doWrite(Stream.java:843) at org.apache.coyote.http11.filters.GzipOutputFilter$FakeOutputStream.write(GzipOutputFilter.java:159) at java.base/java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream.java:252) at java.base/java.util.zip.DeflaterOutputStream.write(DeflaterOutputStream.java:210) at java.base/java.util.zip.GZIPOutputStream.write(GZIPOutputStream.java:148) at org.apache.coyote.http11.filters.GzipOutputFilter.doWrite(GzipOutputFilter.java:69) at org.apache.coyote.http2.Http2OutputBuffer.doWrite(Http2OutputBuffer.java:59) at org.apache.coyote.Response.doWrite(Response.java:625) at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:340) at org.apache.catalina.connector.OutputBuffer.flushByteBuffer(OutputBuffer.java:783) at org.apache.catalina.connector.OutputBuffer.realWriteChars(OutputBuffer.java:453) at org.apache.catalina.connector.OutputBuffer.flushCharBuffer(OutputBuffer.java:788) at org.apache.catalina.connector.OutputBuffer.append(OutputBuffer.java:727) at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:505) at org.apache.catalina.connector.CoyoteWriter.write(CoyoteWriter.java:148) at org.apache.catalina.filters.ExpiresFilter$XPrintWriter.write(ExpiresFilter.java:850) at org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:275) at java.base/java.io.PrintWriter.write(PrintWriter.java:506) at org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:275) at java.base/java.io.PrintWriter.write(PrintWriter.java:506) at org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:112) at org.apache.jasper.runtime.JspWriterImpl.flush(JspWriterImpl.java:160) at org.apache.jsp.WEB_002dINF.jsp.businessrelations.ticket_005frelations_inc_jsp._jspService(ticket_005frelations_inc_jsp.java:702) ... - The stack is probably 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 (loglevel FINE) didn't narrow down the issue This week I found time for digging down into the rabbit hole and also was able to create an almost static application. I did several network traces and it followed the following scheme: 1) Main page was requested by Firefox from Tomcat (GET ...) 2) Tomcat sends the first compressed chunks of data to the browser 3) Firefox reads the first packages and notices, that additional resources are needed (CSS, JS ...) 4) While Tomcat is still sending the main page in chunks, the browser is already requesting additional resources on other channels 5) Firefox is sending a RST_STREAM and closes that last requested stream(s) (dunno why it does request first and then closes the channel) 6) Tomcat is sending a GoAway message to the browser 7) Tomcat stops also sending the main page (on a different channel) Shouldn't tomcat just close the requested stream and continue serving the other stream(s)? Looks like Tomcat got upset and also closed the other stream :) Pcap-file is available at https://privfile.com/download.php?fid=62b8721f9f29a-MTM1NTk= for around 2 weeks. I could also provide an almost static app which relatively often shows this issue (after several trials). As it contains some internal CI and stuff, I could sent it to a personal address. I tested with Win10 and Win11, FF 101, Tomcat 10.0.16 Thanks in advance! Thomas --
RE: compression?
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 request is fine. Pull request #442 created on http.xml, "clarified compressionMinSize and compressibleMimeType". -- Cris Berneburg CACI Senior Software Engineer This electronic message contains information from CACI International Inc or subsidiary companies, which may be company sensitive, proprietary, privileged or otherwise protected from disclosure. The information is intended to be used solely by the recipient(s) named above. If you are not an intended recipient, be aware that any review, disclosure, copying, distribution or use of this transmission or its contents is prohibited. If you have received this transmission in error, please notify the sender immediately.
RE: compression?
Thanks Mark :-) crisb> Is it possible to connect IIS to TC using HTTP instead of AJP? crisb> Several "Tomcat IIS How-To" articles all mention using AJP crisb> (not HTTP) using an ISAPI redirector. markt> In theory, yes. You'd need to find an HTTP reverse proxy component for IIS. markt> This looks like the sort of thing you'd need: markt> https://docs.microsoft.com/en-us/iis/extensions/url-rewrite-module/ markt> reverse-proxy-with-url-rewrite-v2-and-application-request-routing markt> The downside is that you will need to manually configure a lot of the stuff markt> AJP does "for free". Correctly configuring a reverse proxy is one of those markt> tasks where all sorts of things can catch you out. Yeah, that looks way more complicated than what I was hoping for. Talked with the sysadmin about it and he agreed, even though he 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 That looks better, much less complex and fragile. I see in the " element in applicationHost.config" that you can specify mimeType's - perfect. We'll see what the SA thinks. The other option the SA and I talked about was dropping IIS altogether. ;-) -- Cris Berneburg CACI Senior Software Engineer This electronic message contains information from CACI International Inc or subsidiary companies, which may be company sensitive, proprietary, privileged or otherwise protected from disclosure. The information is intended to be used solely by the recipient(s) named above. If you are not an intended recipient, be aware that any review, disclosure, copying, distribution or use of this transmission or its contents is prohibited. If you have received this transmission in error, please notify the sender immediately. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: compression?
On 27/07/2021 13:08, Berneburg, Cris J. - US wrote: Carsten and Mark Thanks for the info. :-) crisb> Weird, when going thru IIS to TC, it's not compressed c.klein> IIS fetches the requested resource from TC, acting as an HTTP client (or are you using AJP with IIS?). markt> 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 theory, yes. You'd need to find an HTTP reverse proxy component for IIS. This looks like the sort of thing you'd need: https://docs.microsoft.com/en-us/iis/extensions/url-rewrite-module/reverse-proxy-with-url-rewrite-v2-and-application-request-routing The downside is that you will need to manually configure a lot of the stuff AJP does "for free". Correctly configuring a reverse proxy is one of those tasks where all sorts of things can catch you out. I'd probably look at getting IIS to compress the content instead: https://docs.microsoft.com/en-us/iis/extensions/iis-compression/iis-compression-overview Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: compression?
Carsten and Mark Thanks for the info. :-) crisb> Weird, when going thru IIS to TC, it's not compressed c.klein> IIS fetches the requested resource from TC, acting as an HTTP client (or are you using AJP with IIS?). markt> 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. -- Cris Berneburg CACI Senior Software Engineer This electronic message contains information from CACI International Inc or subsidiary companies, which may be company sensitive, proprietary, privileged or otherwise protected from disclosure. The information is intended to be used solely by the recipient(s) named above. If you are not an intended recipient, be aware that any review, disclosure, copying, distribution or use of this transmission or its contents is prohibited. If you have received this transmission in error, please notify the sender immediately.
Re: compression?
Chris, Weird, when going thru IIS to TC, it's not compressed: HTTP/1.1 200 200 Content-Type: application/json;charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/10.0 Date: Fri, 23 Jul 2021 16:34:30 GMT Content-Length: 3210105 That has likely nothing to do with TC. It's an IIS or reverse proxy thing. IIS fetches the requested resource from TC, acting as an HTTP client (or are you using AJP with IIS?). It gets a compressed response. What does IIS do next? It just uncompresses the resource and sends it back as response to its client (your browser). So, it's up to IIS or its 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: compression?
On 23/07/2021 18:53, Berneburg, Cris J. - US wrote: 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 worked when connecting directly to TC: HTTP/1.1 200 vary: accept-encoding Content-Encoding: gzip Content-Type: application/json;charset=UTF-8 Content-Language: en-US Transfer-Encoding: chunked Date: Fri, 23 Jul 2021 16:37:48 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;charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/10.0 Date: Fri, 23 Jul 2021 16:34:30 GMT Content-Length: 3210105 cb> P.S.: If a documentation update is recommended, I would be happy to cb> make the changes, 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 request is fine. If you prefer to provide a patch, use "diff -u" Markt> format, create a BZ issue and attach the patch. I'll have a look at it later. Also, I'm quite a newbie with git. -- Cris Berneburg CACI Senior Software Engineer This electronic message contains information from CACI International Inc or subsidiary companies, which may be company sensitive, proprietary, privileged or otherwise protected from disclosure. The information is intended to be used solely by the recipient(s) named above. If you are not an intended recipient, be aware that any review, disclosure, copying, distribution or use of this transmission or its contents is prohibited. If you have received this transmission in error, please notify the sender immediately. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: compression?
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 worked when connecting directly to TC: HTTP/1.1 200 vary: accept-encoding Content-Encoding: gzip Content-Type: application/json;charset=UTF-8 Content-Language: en-US Transfer-Encoding: chunked Date: Fri, 23 Jul 2021 16:37:48 GMT Keep-Alive: timeout=20 Connection: keep-alive Weird, when going thru IIS to TC, it's not compressed: HTTP/1.1 200 200 Content-Type: application/json;charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/10.0 Date: Fri, 23 Jul 2021 16:34:30 GMT Content-Length: 3210105 cb> P.S.: If a documentation update is recommended, I would be happy to cb> make the changes, 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 request is fine. If you prefer to provide a patch, use "diff -u" Markt> format, create a BZ issue and attach the patch. I'll have a look at it later. Also, I'm quite a newbie with git. -- Cris Berneburg CACI Senior Software Engineer This electronic message contains information from CACI International Inc or subsidiary companies, which may be company sensitive, proprietary, privileged or otherwise protected from disclosure. The information is intended to be used solely by the recipient(s) named above. If you are not an intended recipient, be aware that any review, disclosure, copying, distribution or use of this transmission or its contents is prohibited. If you have received this transmission in error, please notify the sender immediately.
Re: compression?
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/http.html 1. compressionMinSize - What are the units, bytes? Yes. 2. compressibleMimeType - If you specify a type explicitly, like "application/json", what does it do with the defaults, like "text/html"? Are they over-ridden, so they need to be specified explicitly too? Or is it cumulative? Default is over-ridden. Thanks for your time. P.S.: If a documentation update is recommended, I would be happy to make the changes, but I would probably need guidance for that too. ;-) Source file is here: https://github.com/apache/tomcat/blob/main/webapps/docs/config/http.xml A pull request is fine. If you prefer to provide a patch, use "diff -u" format, create a BZ issue and attach the patch. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
compression?
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, bytes? 2. compressibleMimeType - If you specify a type explicitly, like "application/json", what does it do with the defaults, like "text/html"? Are they over-ridden, so they need to be specified explicitly too? Or is it cumulative? Thanks for your time. P.S.: If a documentation update is recommended, I would be happy to make the changes, but I would probably need guidance for that too. ;-) -- Cris Berneburg CACI Senior Software Engineer This electronic message contains information from CACI International Inc or subsidiary companies, which may be company sensitive, proprietary, privileged or otherwise protected from disclosure. The information is intended to be used solely by the recipient(s) named above. If you are not an intended recipient, be aware that any review, disclosure, copying, distribution or use of this transmission or its contents is prohibited. If you have received this transmission in error, please notify the sender immediately. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Should Tomcat 10 enable response compression by default?
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 "off" to "on". This would be for Tomcat 10 onwards only. The following would be unchanged: - compressibleMimeType - compressionMinSize - noCompressionStrongETag Shouldn't this be gone in 10? It would be helpful to know what the range of views of the user community are on this proposal. So, thoughts? Don't enable by default. Carsten Klein brought up a few good points. Another is when used in corporate networks, where clients and servers are close, I see no benefit for compression here. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Should Tomcat 10 enable response compression by default?
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 with a quite expensive compress -> decompress -> compress processing chain on the back end. That is obviously no good idea from a performance and resource consumption point of view. So, I'm actually with Rémy. Leave it off by default and point out that there is an "on" available by explicitly writing compression="off" to the connector. Carsten 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 compression attribute from "off" to "on". This would be for Tomcat 10 onwards only. The following would be unchanged: - compressibleMimeType - compressionMinSize - noCompressionStrongETag It would be helpful to know what the range of views of the user community are on this proposal. So, thoughts? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Should Tomcat 10 enable response compression by default?
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 > compression attribute from "off" to "on". > > This would be for Tomcat 10 onwards only. > > The following would be unchanged: > - compressibleMimeType > - compressionMinSize > - noCompressionStrongETag > > It would be helpful to know what the range of views of the user > community are on this proposal. > > So, thoughts? > I would prefer to leave it as it is now, but if you want to publicize it more, maybe compression="off" could be added to the default server.xml so that people know it's there. Rémy
Re: Should Tomcat 10 enable response compression by default?
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 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. > > > > At least in our case we have our own code to deal with this, considering > > proxying, CDN, buggy browsers, etc. > > > > I think the same - it should be opt-in feature. > > My 2c. > > Martin > > > > > > *Manuel Dominguez Sarmiento* > > > > On 09/06/2020 17:20, 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 > > > compression attribute from "off" to "on". > > > > > > This would be for Tomcat 10 onwards only. > > > > > > The following would be unchanged: > > > - compressibleMimeType > > > - compressionMinSize > > > - noCompressionStrongETag > > > > > > It would be helpful to know what the range of views of the user > > > community are on this proposal. > > > > > > So, thoughts? > > > > > > Mark > > > > > > - > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > > > -- Johan Compagner Servoy
Re: Should Tomcat 10 enable response compression by default?
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. > > At least in our case we have our own code to deal with this, considering > proxying, CDN, buggy browsers, etc. > I think the same - it should be opt-in feature. My 2c. Martin > > *Manuel Dominguez Sarmiento* > > On 09/06/2020 17:20, 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 > > compression attribute from "off" to "on". > > > > This would be for Tomcat 10 onwards only. > > > > The following would be unchanged: > > - compressibleMimeType > > - compressionMinSize > > - noCompressionStrongETag > > > > It would be helpful to know what the range of views of the user > > community are on this proposal. > > > > So, thoughts? > > > > Mark > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > >
Re: Should Tomcat 10 enable response compression by default?
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, CDN, buggy browsers, etc. *Manuel Dominguez Sarmiento* On 09/06/2020 17:20, 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 compression attribute from "off" to "on". This would be for Tomcat 10 onwards only. The following would be unchanged: - compressibleMimeType - compressionMinSize - noCompressionStrongETag It would be helpful to know what the range of views of the user community are on this proposal. So, thoughts? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Should Tomcat 10 enable response compression by default?
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 Tomcat 10 onwards only. The following would be unchanged: - compressibleMimeType - compressionMinSize - noCompressionStrongETag It would be helpful to know what the range of views of the user community are on this proposal. So, thoughts? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] HTTP2 gzip compression and Safari browser
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Kirill, On 5/8/19 23:20, Kirill Ilyukhin wrote: > This might be a bad idea, but I have exactly the same issue with > static content (simple index.html file). Also BREACH vulnerability > implies three conditions, a webapp developer may decide to use > TLS+gzip because one of them is not satisfied for a particular > service. I suppose servers 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. 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 think it is. - -chris > On Thu, 9 May 2019 at 01:08, Christopher Schultz < > ch...@christopherschultz.net> wrote: > > Kirill, > > Is it a good idea to use TLS+gzip for dynamic services? > > http://breachattack.com/ > > ? > > -chris > > On 5/8/19 08:27, Kirill Ilyukhin wrote: >>>> Mark, >>>> >>>> Could you please take a closer look to the issue? This >>>> happens with Safari 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 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) might fix the >>>> issue? >>>> >>>> Thank you, Kirill >>>> >>>> On Wed, 8 May 2019 at 17:08, Mark Thomas >>>> wrote: >>>> >>>>> Although I find it hard to believe, this looks like a >>>>> browser bug. There is a similar issue with FireFox: >>>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=63354 >>>>> >>>>> I suggest opening an issue with Apple. >>>>> >>>>> Mark >>>>> >>>>> >>>>> >>>>> On 08/05/2019 05:23, Kirill Ilyukhin wrote: >>>>>> 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 URLSession >>>>>> also does not work. Is it something wrong with my >>>>>> configuration or code? Please see below server setup, >>>>>> connector configuration and servlet code. >>>>>> >>>>>> Server version: Apache Tomcat/8.5.39 Server built: Mar >>>>>> 14 2019 11:24:26 UTC Server number: 8.5.39.0 OS Name: >>>>>> Mac OS X OS Version: 10.13.6 Architecture: x86_64 >>>>>> JVM Version:9.0.1+11 JVM Vendor: Oracle >>>>>> Corporation Loaded APR based Apache Tomcat Native library >>>>>> [1.2.21] using APR version [1.6.5]. APR capabilities: >>>>>> IPv6 [true], sendfile [true], accept filters [false], >>>>>> random [true]. APR/OpenSSL configuration: useAprConnector >>>>>> [false], useOpenSSL [true] OpenSSL successfully >>>>>> initialized [OpenSSL 1.0.2r 26 Feb 2019] The >>>>>> ["https-openssl-nio-8080"] connector has been configured >>>>>> to support negotiation to [h2] via ALPN >>>>>> >>>>>> >>>>>> >>>>> protocol="org.apache.coyote.http11.Http11NioProtocol" >>>>>> asyncTimeout="2" URIEncoding="utf-8" >>>>>> acceptorThreadCount="1" >>>>>> >>>>>> >>>>> compressibleMimeType="text/html,text/xml,text/plain,text/x-json,ap pli > >>>>> cation/javascript,appl
Re: [OT] HTTP2 gzip compression and Safari browser
Christopher, This might be a bad idea, but I have exactly the same issue with static content (simple index.html file). Also BREACH vulnerability implies three conditions, a webapp developer may decide to use TLS+gzip because one of them is not satisfied for a particular service. I suppose servers 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 < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Kirill, > > Is it a good idea to use TLS+gzip for dynamic services? > > http://breachattack.com/ > > ? > > - -chris > > On 5/8/19 08:27, Kirill Ilyukhin wrote: > > Mark, > > > > Could you please take a closer look to the issue? This happens with > > Safari 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 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) might > > fix the issue? > > > > Thank you, Kirill > > > > On Wed, 8 May 2019 at 17:08, Mark Thomas wrote: > > > >> Although I find it hard to believe, this looks like a browser > >> bug. There is a similar issue with FireFox: > >> https://bz.apache.org/bugzilla/show_bug.cgi?id=63354 > >> > >> I suggest opening an issue with Apple. > >> > >> Mark > >> > >> > >> > >> On 08/05/2019 05:23, Kirill Ilyukhin wrote: > >>> 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 URLSession also > >>> does not work. Is it something wrong with my configuration or > >>> code? Please see below server setup, connector configuration > >>> and servlet code. > >>> > >>> Server version: Apache Tomcat/8.5.39 Server built: Mar 14 > >>> 2019 11:24:26 UTC Server number: 8.5.39.0 OS Name:Mac > >>> OS X OS Version: 10.13.6 Architecture: x86_64 JVM > >>> Version:9.0.1+11 JVM Vendor: Oracle Corporation Loaded > >>> APR based Apache Tomcat Native library [1.2.21] using APR > >>> version [1.6.5]. APR capabilities: IPv6 [true], sendfile > >>> [true], accept filters [false], random [true]. APR/OpenSSL > >>> configuration: useAprConnector [false], useOpenSSL [true] > >>> OpenSSL successfully initialized [OpenSSL 1.0.2r 26 Feb 2019] > >>> The ["https-openssl-nio-8080"] connector has been configured to > >>> support negotiation to [h2] via ALPN > >>> > >>> > >>> >>> protocol="org.apache.coyote.http11.Http11NioProtocol" > >>> asyncTimeout="2" URIEncoding="utf-8" > >>> acceptorThreadCount="1" > >>> > >>> > >> compressibleMimeType="text/html,text/xml,text/plain,text/x-json,appli > cation/javascript,application/json,text/css" > >>> > >> > compression="force" > >>> connectionTimeout="2" minSpareThreads="2" > >>> maxThreads="1024" processorCache="512" useSendfile="true" > >>> SSLEnabled="true" secure="true" > >>> className="org.apache.coyote.http2.Http2Protocol" > >>> > >>> > >> compressibleMimeType="text/html,text/xml,text/plain,text/x-json,appli > cation/javascript,application/json,text/css" > >>> > >> > compression="force" /> > >>> >>> certificateFile="yyy" certificateChainFile="zzz" type="RSA" > >>> /&
Re: HTTP2 gzip compression and Safari browser
On 08/05/2019 13:27, Kirill Ilyukhin wrote:
> Mark,
>
> Could you please take a closer look to the issue? This happens with Safari
> and native apps on iOS 11 and iOS 12 which means that Tomcat HTTP/2 cannot
> be enabled for any service with iOS clients.
I've done all I can. The data passed back by Tomcat is valid as far as I
can tell.
This needs to be followed up with the browser vendor(s) affected.
If someone can point to something Tomcat is doing incorrectly I'll
happily take a look but - after looking at the data sent back - it all
looks valid to me.
Mark
>
> 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 somehow is "Apple-incompatible"? Do you think some subtle
> changes (including crazy ones like headers order, etc) might fix the issue?
>
> Thank you,
> Kirill
>
> On Wed, 8 May 2019 at 17:08, Mark Thomas wrote:
>
>> Although I find it hard to believe, this looks like a browser bug. There
>> is a similar issue with FireFox:
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=63354
>>
>> I suggest opening an issue with Apple.
>>
>> Mark
>>
>>
>>
>> On 08/05/2019 05:23, Kirill Ilyukhin wrote:
>>> 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 URLSession also does not work.
>>> Is it something wrong with my configuration or code?
>>> Please see below server setup, connector configuration and servlet code.
>>>
>>> Server version: Apache Tomcat/8.5.39
>>> Server built: Mar 14 2019 11:24:26 UTC
>>> Server number: 8.5.39.0
>>> OS Name:Mac OS X
>>> OS Version: 10.13.6
>>> Architecture: x86_64
>>> JVM Version:9.0.1+11
>>> JVM Vendor: Oracle Corporation
>>> Loaded APR based Apache Tomcat Native library [1.2.21] using APR version
>>> [1.6.5].
>>> APR capabilities: IPv6 [true], sendfile [true], accept filters [false],
>>> random [true].
>>> APR/OpenSSL configuration: useAprConnector [false], useOpenSSL [true]
>>> OpenSSL successfully initialized [OpenSSL 1.0.2r 26 Feb 2019]
>>> The ["https-openssl-nio-8080"] connector has been configured to support
>>> negotiation to [h2] via ALPN
>>>
>>>
>>> >> protocol="org.apache.coyote.http11.Http11NioProtocol"
>>>asyncTimeout="2"
>>>URIEncoding="utf-8"
>>>acceptorThreadCount="1"
>>>
>>>
>> compressibleMimeType="text/html,text/xml,text/plain,text/x-json,application/javascript,application/json,text/css"
>>>compression="force"
>>>connectionTimeout="2"
>>>minSpareThreads="2"
>>>maxThreads="1024"
>>>processorCache="512"
>>>useSendfile="true"
>>>SSLEnabled="true"
>>>secure="true" >
>>> >>
>>>
>> compressibleMimeType="text/html,text/xml,text/plain,text/x-json,application/javascript,application/json,text/css"
>>> compression="force" />
>>> >> certificateFile="yyy" certificateChainFile="zzz" type="RSA"
>>> />
>>>
>>>
>>>
>>> public class TestServlet extends javax.servlet.http.HttpServlet {
>>> protected void doGet(javax.servlet.http.HttpServletRequest request,
>>> javax.servlet.http.HttpServletResponse response) throws
>>> javax.servlet.ServletException, java.io.IOException {
>>> response.setContentType("text/plain");
>>> response.setCharacterEncoding("utf-8");
>>> response.getWriter().write("Lorem ipsum dolor sit amet");
>>> }
>>> }
>>>
>>>
>>> Thank you,
>>> Kirill
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re:[OT] HTTP2 gzip compression and Safari browser
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Kirill,
Is it a good idea to use TLS+gzip for dynamic services?
http://breachattack.com/
?
- -chris
On 5/8/19 08:27, Kirill Ilyukhin wrote:
> Mark,
>
> Could you please take a closer look to the issue? This happens with
> Safari 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 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) might
> fix the issue?
>
> Thank you, Kirill
>
> On Wed, 8 May 2019 at 17:08, Mark Thomas wrote:
>
>> Although I find it hard to believe, this looks like a browser
>> bug. There is a similar issue with FireFox:
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=63354
>>
>> I suggest opening an issue with Apple.
>>
>> Mark
>>
>>
>>
>> On 08/05/2019 05:23, Kirill Ilyukhin wrote:
>>> 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 URLSession also
>>> does not work. Is it something wrong with my configuration or
>>> code? Please see below server setup, connector configuration
>>> and servlet code.
>>>
>>> Server version: Apache Tomcat/8.5.39 Server built: Mar 14
>>> 2019 11:24:26 UTC Server number: 8.5.39.0 OS Name:Mac
>>> OS X OS Version: 10.13.6 Architecture: x86_64 JVM
>>> Version:9.0.1+11 JVM Vendor: Oracle Corporation Loaded
>>> APR based Apache Tomcat Native library [1.2.21] using APR
>>> version [1.6.5]. APR capabilities: IPv6 [true], sendfile
>>> [true], accept filters [false], random [true]. APR/OpenSSL
>>> configuration: useAprConnector [false], useOpenSSL [true]
>>> OpenSSL successfully initialized [OpenSSL 1.0.2r 26 Feb 2019]
>>> The ["https-openssl-nio-8080"] connector has been configured to
>>> support negotiation to [h2] via ALPN
>>>
>>>
>>> >> protocol="org.apache.coyote.http11.Http11NioProtocol"
>>> asyncTimeout="2" URIEncoding="utf-8"
>>> acceptorThreadCount="1"
>>>
>>>
>> compressibleMimeType="text/html,text/xml,text/plain,text/x-json,appli
cation/javascript,application/json,text/css"
>>>
>>
compression="force"
>>> connectionTimeout="2" minSpareThreads="2"
>>> maxThreads="1024" processorCache="512" useSendfile="true"
>>> SSLEnabled="true" secure="true" > >> className="org.apache.coyote.http2.Http2Protocol"
>>>
>>>
>> compressibleMimeType="text/html,text/xml,text/plain,text/x-json,appli
cation/javascript,application/json,text/css"
>>>
>>
compression="force" />
>>> >> certificateFile="yyy" certificateChainFile="zzz" type="RSA"
>>> />
>>>
>>>
>>> public class TestServlet extends javax.servlet.http.HttpServlet
>>> { protected void doGet(javax.servlet.http.HttpServletRequest
>>> request, javax.servlet.http.HttpServletResponse response)
>>> throws javax.servlet.ServletException, java.io.IOException {
>>> response.setContentType("text/plain");
>>> response.setCharacterEncoding("utf-8");
>>> response.getWriter().write("Lorem ipsum dolor sit amet"); } }
>>>
>>>
>>> Thank you, Kirill
>>>
>>
>>
>> -
>>
>>
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlzS/v4ACgkQHPApP6U8
pFiy+A/9H0nCzh6M26+BZgWkdEIsQHqRV9nmdsO/durBFKZdLQ0spexkf16JEltS
cUdAwxu8ObIgBTIitXnr4Nh2hJVJCCUVpV33ZyuKuIeTfXJo4VSEP2pkIaveaKRz
bXbo003Tt1jn6278EGEhAccad7y9IVg2Et7aOMbeuUShzsJPJNnZ7xOu1VWvXjuK
if3sz2+IwD5ch9vNqICpwOAnXbC4hUVy5M5oeAPP96OhCSp8iv4Th+X4ir3f3Mbl
s7c5m9vxfwHe/zIBBfksrWCRgm0iznrTsOzgXsqYuuxQujkcIOnslJehMhQ0vuYV
gcbJW/CxQbxSsQZmBoyBI/DECdKr5uXKkUboVOz8YpISXJyyN6BLjy2h9jjUDNRQ
HO8AaqrltGvFsD6A7vQPZDWEa8mXUUQsU8x4TDVcdNIhqg+OhbeabGDBf83RRHKs
1U4MDyqo+tBNd6GV/7vciBENgL5NxmQ8csfWISijyM2+MvG4ucgaRXCfZfDNX0Kr
BRfoBeDKb7p+0XutxmpyjVh5VtBPD8Cy6xmJFu1Z6Q3OsLPnWZAk/fWQMUnIqBcX
egrsOjsk/A1klxVsQ/EzIbNzRB6NpoT8n0hrWpX9IIo4kyplqAn+C9VKT5pi9j6G
j0Pw6b9tKQKKTyXUkizELkbVbqngrp8wIY1QSopFEx5uS397KwE=
=Ww2J
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HTTP2 gzip compression and Safari browser
Mark,
Could you please take a closer look to the issue? This happens with Safari
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 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) might fix the issue?
Thank you,
Kirill
On Wed, 8 May 2019 at 17:08, Mark Thomas wrote:
> Although I find it hard to believe, this looks like a browser bug. There
> is a similar issue with FireFox:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=63354
>
> I suggest opening an issue with Apple.
>
> Mark
>
>
>
> On 08/05/2019 05:23, Kirill Ilyukhin wrote:
> > 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 URLSession also does not work.
> > Is it something wrong with my configuration or code?
> > Please see below server setup, connector configuration and servlet code.
> >
> > Server version: Apache Tomcat/8.5.39
> > Server built: Mar 14 2019 11:24:26 UTC
> > Server number: 8.5.39.0
> > OS Name:Mac OS X
> > OS Version: 10.13.6
> > Architecture: x86_64
> > JVM Version:9.0.1+11
> > JVM Vendor: Oracle Corporation
> > Loaded APR based Apache Tomcat Native library [1.2.21] using APR version
> > [1.6.5].
> > APR capabilities: IPv6 [true], sendfile [true], accept filters [false],
> > random [true].
> > APR/OpenSSL configuration: useAprConnector [false], useOpenSSL [true]
> > OpenSSL successfully initialized [OpenSSL 1.0.2r 26 Feb 2019]
> > The ["https-openssl-nio-8080"] connector has been configured to support
> > negotiation to [h2] via ALPN
> >
> >
> > > protocol="org.apache.coyote.http11.Http11NioProtocol"
> >asyncTimeout="2"
> >URIEncoding="utf-8"
> >acceptorThreadCount="1"
> >
> >
> compressibleMimeType="text/html,text/xml,text/plain,text/x-json,application/javascript,application/json,text/css"
> >compression="force"
> >connectionTimeout="2"
> > minSpareThreads="2"
> >maxThreads="1024"
> >processorCache="512"
> >useSendfile="true"
> >SSLEnabled="true"
> >secure="true" >
> > >
> >
> compressibleMimeType="text/html,text/xml,text/plain,text/x-json,application/javascript,application/json,text/css"
> > compression="force" />
> > > certificateFile="yyy" certificateChainFile="zzz" type="RSA"
> > />
> >
> >
> >
> > public class TestServlet extends javax.servlet.http.HttpServlet {
> > protected void doGet(javax.servlet.http.HttpServletRequest request,
> > javax.servlet.http.HttpServletResponse response) throws
> > javax.servlet.ServletException, java.io.IOException {
> > response.setContentType("text/plain");
> > response.setCharacterEncoding("utf-8");
> > response.getWriter().write("Lorem ipsum dolor sit amet");
> > }
> > }
> >
> >
> > Thank you,
> > Kirill
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Re: HTTP2 gzip compression and Safari browser
Although I find it hard to believe, this looks like a browser bug. There
is a similar issue with FireFox:
https://bz.apache.org/bugzilla/show_bug.cgi?id=63354
I suggest opening an issue with Apple.
Mark
On 08/05/2019 05:23, Kirill Ilyukhin wrote:
> 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 URLSession also does not work.
> Is it something wrong with my configuration or code?
> Please see below server setup, connector configuration and servlet code.
>
> Server version: Apache Tomcat/8.5.39
> Server built: Mar 14 2019 11:24:26 UTC
> Server number: 8.5.39.0
> OS Name:Mac OS X
> OS Version: 10.13.6
> Architecture: x86_64
> JVM Version:9.0.1+11
> JVM Vendor: Oracle Corporation
> Loaded APR based Apache Tomcat Native library [1.2.21] using APR version
> [1.6.5].
> APR capabilities: IPv6 [true], sendfile [true], accept filters [false],
> random [true].
> APR/OpenSSL configuration: useAprConnector [false], useOpenSSL [true]
> OpenSSL successfully initialized [OpenSSL 1.0.2r 26 Feb 2019]
> The ["https-openssl-nio-8080"] connector has been configured to support
> negotiation to [h2] via ALPN
>
>
> protocol="org.apache.coyote.http11.Http11NioProtocol"
>asyncTimeout="2"
>URIEncoding="utf-8"
>acceptorThreadCount="1"
>
>
> compressibleMimeType="text/html,text/xml,text/plain,text/x-json,application/javascript,application/json,text/css"
>compression="force"
>connectionTimeout="2"
>minSpareThreads="2"
>maxThreads="1024"
>processorCache="512"
> useSendfile="true"
>SSLEnabled="true"
>secure="true" >
>
> compressibleMimeType="text/html,text/xml,text/plain,text/x-json,application/javascript,application/json,text/css"
> compression="force" />
> certificateFile="yyy" certificateChainFile="zzz" type="RSA"
> />
>
>
>
> public class TestServlet extends javax.servlet.http.HttpServlet {
> protected void doGet(javax.servlet.http.HttpServletRequest request,
> javax.servlet.http.HttpServletResponse response) throws
> javax.servlet.ServletException, java.io.IOException {
> response.setContentType("text/plain");
> response.setCharacterEncoding("utf-8");
> response.getWriter().write("Lorem ipsum dolor sit amet");
> }
> }
>
>
> Thank you,
> Kirill
>
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
HTTP2 gzip compression and Safari browser
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 URLSession also does not work.
Is it something wrong with my configuration or code?
Please see below server setup, connector configuration and servlet code.
Server version: Apache Tomcat/8.5.39
Server built: Mar 14 2019 11:24:26 UTC
Server number: 8.5.39.0
OS Name:Mac OS X
OS Version: 10.13.6
Architecture: x86_64
JVM Version:9.0.1+11
JVM Vendor: Oracle Corporation
Loaded APR based Apache Tomcat Native library [1.2.21] using APR version
[1.6.5].
APR capabilities: IPv6 [true], sendfile [true], accept filters [false],
random [true].
APR/OpenSSL configuration: useAprConnector [false], useOpenSSL [true]
OpenSSL successfully initialized [OpenSSL 1.0.2r 26 Feb 2019]
The ["https-openssl-nio-8080"] connector has been configured to support
negotiation to [h2] via ALPN
public class TestServlet extends javax.servlet.http.HttpServlet {
protected void doGet(javax.servlet.http.HttpServletRequest request,
javax.servlet.http.HttpServletResponse response) throws
javax.servlet.ServletException, java.io.IOException {
response.setContentType("text/plain");
response.setCharacterEncoding("utf-8");
response.getWriter().write("Lorem ipsum dolor sit amet");
}
}
Thank you,
Kirill
Re: Compression for Resources served through DefaultServlet
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Leon, On 11/26/18 18:53, Leon Rosenberg wrote: > 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 DefaultServlet (aka files) >>> aren't compressed, versus to dynamic resources served by a >>> servlet. 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/NIO2 and APR, and on by default. Those are the only connectors available these days, so by default sendFile=true and therefore compression=false. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlv8lZsACgkQHPApP6U8 pFg7GhAAnYAlwdMTkpe1i995Q1mFKfOV5GTU8IpqFXFadnaiNov/mpWX64IVSGQB 3B2m0CwHgQE1Nv0lh/3AHleqC54S5i8Hiuhw3YiYBQ6xfKVbctrG2m+97WtgXSzG lwV2pUw1nsJlJ/Wlnc+/Pf1DUN6p5r8IMSIP4NnuhM0KSYwJi60bN2w10ZJsMpDR 6DFkLMT+g3LQ7lvsRsol99AQkpbkeEpUypRr1y5/duvkqz/8A/8WX4kZ7+Ix5oah y+hLmd31nqjE03wAnacLfiMQ4ziUzh0MNKfjJUnccOvK5eXLSpE6uvAtA6nsMuAK 3HxsGsDTc6wdeF6oEU3MY16AdnG6mGOhfASCv5tMqkDYrzKLnznN7dmYCpzikgjR S3SzYGoXm+YE5n0ciA/aKat+701YJZX9N9LJak60A9+eJ9Xr0gG81t/4H6FW8uo2 0M5ukNhBy08M5yqFbz3rQmDEZdOsCOCO9Mb+2ABusnjupnadBCfonUSD+JVNezXm 7im0PiiNuXGigrmURS85xAtE3VJIt9mTCylbLxMDMJw3LdZUrMpd0AK/VuBPK5/0 zjn1JvqB6qosdCqnKvERk85EKY4c4mfqVVVDl0Ok0pJcH5x3rgnmyaysjDaUy0sX ap3plQplGRpJI6J+b9QLrviYEq/4uFYabQIoEJ7p1Lm+Jq8JjhI= =eiE1 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Compression for Resources served through DefaultServlet
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 DefaultServlet (aka files) aren't compressed, versus to > > dynamic resources served by a servlet. > > 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. Thank you. Leon > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Compression for Resources served through DefaultServlet
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 resources served by a servlet. > 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. ? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Compression for Resources served through DefaultServlet
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 resources served by a servlet. Tomcat version in question 8.5.15 and 8.5.31 (tested on both) Connector setting: There is a loadbalancer in front of the connector, but its transparent, doesn't change anything. Now when I request a resource like this: https://www.mysite.com/rd/V-2.0.0-SNAPSHOT_2018-11-22T13:39:22,000/static-ext/bootstrap.css (where rd is mapping to a servlet) the result is shown in inspect tab of chrome as 18.K (obviously compressed) and the response headers indicate that the file is gziped: HTTP/1.1 200 Last-Modified: Tue, 31 Jul 02018 11:42:50 GMT Expires: Tue, 26 Nov 02019 21:15:04 GMT Content-Type: text/css Transfer-Encoding: chunked Content-Encoding: gzip Vary: Accept-Encoding Date: Mon, 26 Nov 2018 21:15:04 GMT If I make a request to a static file the file is not gziped: https://www.mysite.com/static-ext/css/bootstrap.css HTTP/1.1 200 Accept-Ranges: bytes ETag: W/"131194-1539850288000" Last-Modified: Thu, 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 any other settings to try? regards Leon
Re: HTTP2 compression on Tomcat 8.5.31
Just want to point out there is no useSendfile attribute for Upgrade Protocol in documentation for Tomcat 8.5 ( https://tomcat.apache.org/tomcat-8.5-doc/config/http2.html). It is present in Tomcat 9 (https://tomcat.apache.org/tomcat-9.0-doc/config/http2.html). On Wed, Aug 1, 2018 at 6:24 PM, Aayush Dev wrote: > 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 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 with any release from 8.5.27 onwards) >> > >> > Java 9 (just so I don't have to configure the native library) >> > >> > Configure HTTP/2 and confirm, via start-up logs it is working. >> > - Uncomment the NIO HTTPS connector >> > - Add the UpgradeProtocol (copied from the APT HTTPS connector) >> > ... The ["https-jsse-nio-8443"] connector has been configured to support >> > negotiation to [h2] via ALPN >> > >> > Request /tomcat.css (a compressible resource) >> > >> > 5581 bytes >> > >> > Uncompressed. As expected. >> > >> > Edit server.xml and add attribute compression="on" to UpgradeProtocol >> > (making sure it is added to the element nested in the NIO HTTPS >> Connector) >> > >> > Restart Tomcat >> > >> > Request /tomcat.css >> > >> > Hmm. Still not compressed... >> > >> > Double check config. Looks OK... >> > >> > Time to fire up remote debugging in the IDE. >> > >> > Find bug. Fix bug. Retest. >> > >> > 1712 bytes. That is more like it. >> > >> > The fix will be in the next release. As we are at the start of the month >> > I'm hoping to start the next 9.0.x and 8.5.x releases in the next few >> days. >> > >> > Mark >> > >> > - >> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> > For additional commands, e-mail: users-h...@tomcat.apache.org >> > >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >
Re: HTTP2 compression on Tomcat 8.5.31
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 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 with any release from 8.5.27 onwards) > > > > Java 9 (just so I don't have to configure the native library) > > > > Configure HTTP/2 and confirm, via start-up logs it is working. > > - Uncomment the NIO HTTPS connector > > - Add the UpgradeProtocol (copied from the APT HTTPS connector) > > ... The ["https-jsse-nio-8443"] connector has been configured to support > > negotiation to [h2] via ALPN > > > > Request /tomcat.css (a compressible resource) > > > > 5581 bytes > > > > Uncompressed. As expected. > > > > Edit server.xml and add attribute compression="on" to UpgradeProtocol > > (making sure it is added to the element nested in the NIO HTTPS > Connector) > > > > Restart Tomcat > > > > Request /tomcat.css > > > > Hmm. Still not compressed... > > > > Double check config. Looks OK... > > > > Time to fire up remote debugging in the IDE. > > > > Find bug. Fix bug. Retest. > > > > 1712 bytes. That is more like it. > > > > The fix will be in the next release. As we are at the start of the month > > I'm hoping to start the next 9.0.x and 8.5.x releases in the next few > days. > > > > Mark > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: HTTP2 compression on Tomcat 8.5.31
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 me with correct configuration. > > Clean Tomcat 8.5.x dev build > (should work with any release from 8.5.27 onwards) > > Java 9 (just so I don't have to configure the native library) > > Configure HTTP/2 and confirm, via start-up logs it is working. > - Uncomment the NIO HTTPS connector > - Add the UpgradeProtocol (copied from the APT HTTPS connector) > ... The ["https-jsse-nio-8443"] connector has been configured to support > negotiation to [h2] via ALPN > > Request /tomcat.css (a compressible resource) > > 5581 bytes > > Uncompressed. As expected. > > Edit server.xml and add attribute compression="on" to UpgradeProtocol > (making sure it is added to the element nested in the NIO HTTPS Connector) > > Restart Tomcat > > Request /tomcat.css > > Hmm. Still not compressed... > > Double check config. Looks OK... > > Time to fire up remote debugging in the IDE. > > Find bug. Fix bug. Retest. > > 1712 bytes. That is more like it. > > The fix will be in the next release. As we are at the start of the month > I'm hoping to start the next 9.0.x and 8.5.x releases in the next few days. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HTTP2 compression on Tomcat 8.5.31
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 with any release from 8.5.27 onwards) Java 9 (just so I don't have to configure the native library) Configure HTTP/2 and confirm, via start-up logs it is working. - Uncomment the NIO HTTPS connector - Add the UpgradeProtocol (copied from the APT HTTPS connector) ... The ["https-jsse-nio-8443"] connector has been configured to support negotiation to [h2] via ALPN Request /tomcat.css (a compressible resource) 5581 bytes Uncompressed. As expected. Edit server.xml and add attribute compression="on" to UpgradeProtocol (making sure it is added to the element nested in the NIO HTTPS Connector) Restart Tomcat Request /tomcat.css Hmm. Still not compressed... Double check config. Looks OK... Time to fire up remote debugging in the IDE. Find bug. Fix bug. Retest. 1712 bytes. That is more like it. The fix will be in the next release. As we are at the start of the month I'm hoping to start the next 9.0.x and 8.5.x releases in the next few days. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HTTP2 compression on Tomcat 8.5.31
Hi Pierre, I am testing on windows. Tomcat 9.0.5 + HTTP2 + GZIP works with OpenJDK 10.0.1 (not with Java 1.8). I am still trying to get Tomcat 8.5.31 + HTTP2 + GZIP working with OpenJDK 10.0.1. On Wed, Jul 25, 2018 at 6:23 PM, Pierre Chiu wrote: > Hi Aayush, > > Are you saying this combo, Tomcat 9.0.5, Oracle Java 1.8.0_144, gzip works > with HTTP2? Is it windows or linux? That is good to know. > > Regarding tomcat 8.5.31, I don't think config file is the issue. > Unfortunately, I don't have the skill to help the developer to debug the > problem. > > 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 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 > > UpgradeProtocol. > > - turned off "useSendfile" by adding "sendfileSize=-1" init-param for > > default servlet under conf/web.xml > > - tried APR (with OpenSSL) connector too instead of NIO > > - compression is not working with Chrome and Firefox (latest ver.) > > - testing with default ROOT webapp to avoid any other conflicting setting > > - gzip compression works with same setting on Tomcat 9.0.5 > > - using openjdk 10.0.1 (and tried with Oracle Java 1.8.0_144) > > > > Using the following connector: > > > > > protocol="org.apache.coyote.http11.Http11NioProtocol" > > > > port="8443" > > > > URIEncoding="UTF-8" > > > > maxPostSize="4096" > > > > maxHttpHeaderSize="1024000" > > > > maxThreads="2500" > > > > enableLookups="false" > > > > SSLEnabled="true" > > > > scheme="https" > > > > secure="true" > > > > compression="on" > > > > noCompressionUserAgents="gozilla,traviata" > > > > compressableMimeType= > > "text/html,text/json,application/json,text/xml,text/plain,application/ > javascript,text/css,text/javascript,text/js" > > > > useSendfile="false" > > > > compressionMinSize="500"> > > > > > > > className="org.apache.coyote.http2.Http2Protocol" > > > > compression="on" > > > > compressionMinSize="500" > > > > keepAliveTimeout="6" > > > > maxConcurrentStreamExecution="200" > > > > maxConcurrentStreams="200" > > > > maxHeaderSize="1024000" > > > > noCompressionUserAgents="gozilla,traviata" > > > > useSendfile="false" /> > > > > > > > honorCipherOrder="true" protocols="TLSv1.1,TLSv1.2" > > > > ciphers= > > "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_ > AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA" > >> > > > > > > > certificateKeystoreFile="conf/KeystoreFile.jks" > > > > certificateKeystorePassword="xx" > > > > certificateKeystoreType="JKS" /> > > > > > > > > > > > > Request headers (from Chrome): > > :authority: localhost:8443 > > :method: GET > > :path: /tomcat.css > > :scheme: https > > accept: text/css,*/*;q=0.1 > > accept-encoding: gzip, deflate, br > > accept-language: en-US,en;q=0.9 > > cache-control: no-cache > > pragma: no-cache > > referer: https://localhost:8443/ > > user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 > > (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36 > > > > Response headers (from Chrome): > > accept-ranges: bytes > > content-type: text/css > > date: Wed, 25 Jul 2018 21:48:16 GMT > > etag: W/"5931-1524878698000" > > last-modified: Sat, 28 Apr 2018 01:24:58 GMT > > status: 200 > > > > > > Thanks in advance. > >
Re: HTTP2 compression on Tomcat 8.5.31
Hi Aayush, Are you saying this combo, Tomcat 9.0.5, Oracle Java 1.8.0_144, gzip works with HTTP2? Is it windows or linux? That is good to know. Regarding tomcat 8.5.31, I don't think config file is the issue. Unfortunately, I don't have the skill to help the developer to debug the problem. 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 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 > UpgradeProtocol. > - turned off "useSendfile" by adding "sendfileSize=-1" init-param for > default servlet under conf/web.xml > - tried APR (with OpenSSL) connector too instead of NIO > - compression is not working with Chrome and Firefox (latest ver.) > - testing with default ROOT webapp to avoid any other conflicting setting > - gzip compression works with same setting on Tomcat 9.0.5 > - using openjdk 10.0.1 (and tried with Oracle Java 1.8.0_144) > > Using the following connector: > > protocol="org.apache.coyote.http11.Http11NioProtocol" > > port="8443" > > URIEncoding="UTF-8" > > maxPostSize="4096" > > maxHttpHeaderSize="1024000" > > maxThreads="2500" > > enableLookups="false" > > SSLEnabled="true" > > scheme="https" > > secure="true" > > compression="on" > > noCompressionUserAgents="gozilla,traviata" > > compressableMimeType= > "text/html,text/json,application/json,text/xml,text/plain,application/javascript,text/css,text/javascript,text/js" > > useSendfile="false" > > compressionMinSize="500"> > > > className="org.apache.coyote.http2.Http2Protocol" > > compression="on" > > compressionMinSize="500" > > keepAliveTimeout="6" > > maxConcurrentStreamExecution="200" > > maxConcurrentStreams="200" > > maxHeaderSize="1024000" > > noCompressionUserAgents="gozilla,traviata" > > useSendfile="false" /> > > > honorCipherOrder="true" protocols="TLSv1.1,TLSv1.2" > > ciphers= > "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA" >> > > > certificateKeystoreFile="conf/KeystoreFile.jks" > > certificateKeystorePassword="xx" > > certificateKeystoreType="JKS" /> > > > > > > Request headers (from Chrome): > :authority: localhost:8443 > :method: GET > :path: /tomcat.css > :scheme: https > accept: text/css,*/*;q=0.1 > accept-encoding: gzip, deflate, br > accept-language: en-US,en;q=0.9 > cache-control: no-cache > pragma: no-cache > referer: https://localhost:8443/ > user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 > (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36 > > Response headers (from Chrome): > accept-ranges: bytes > content-type: text/css > date: Wed, 25 Jul 2018 21:48:16 GMT > etag: W/"5931-1524878698000" > last-modified: Sat, 28 Apr 2018 01:24:58 GMT > status: 200 > > > Thanks in advance.
HTTP2 compression on Tomcat 8.5.31
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 UpgradeProtocol. - turned off "useSendfile" by adding "sendfileSize=-1" init-param for default servlet under conf/web.xml - tried APR (with OpenSSL) connector too instead of NIO - compression is not working with Chrome and Firefox (latest ver.) - testing with default ROOT webapp to avoid any other conflicting setting - gzip compression works with same setting on Tomcat 9.0.5 - using openjdk 10.0.1 (and tried with Oracle Java 1.8.0_144) Using the following connector: Request headers (from Chrome): :authority: localhost:8443 :method: GET :path: /tomcat.css :scheme: https accept: text/css,*/*;q=0.1 accept-encoding: gzip, deflate, br accept-language: en-US,en;q=0.9 cache-control: no-cache pragma: no-cache referer: https://localhost:8443/ user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36 Response headers (from Chrome): accept-ranges: bytes content-type: text/css date: Wed, 25 Jul 2018 21:48:16 GMT etag: W/"5931-1524878698000" last-modified: Sat, 28 Apr 2018 01:24:58 GMT status: 200 Thanks in advance.
Re: Tomcat 8.5.27 HTTP/2 connector not supporting GZIP compression
> On Jan 29, 2018, at 1:27 PM, Christopher Schultz > wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Pierre, > > On 1/29/18 1:07 PM, Pierre Chiu wrote: >> Here is the request/response header. You can tell >> Content-Encoding:gzip is missing when http2 is enabled. >> >> >> >> General (same with/without http2) Request >> URL:https://x.ca/tomcat.css Request Method:GET Status >> Code:200 Remote Address:198.163.180.42:443 Referrer >> Policy:no-referrer-when-downgrade >> >> >> Request Headers (same with/without http2) >> Accept:text/css,*/*;q=0.1 Accept-Encoding:gzip, deflate, br >> Accept-Language:en-US,en;q=0.9,zh-TW;q=0.8,zh;q=0.7 >> Cache-Control:no-cache Connection:keep-alive >> Cookie:_ga=GA1.2.1536574675.1508533871; __utmc=29525935; >> __utmz=29525935.1508478784.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd= > (none); >> __utma=29525935.990581674.1508478784.1516634493.1516996006.24 >> DNT:1 Host:x.ca Pragma:no-cache >> Referer:https://x.ca/index.jsp User-Agent:Mozilla/5.0 >> (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like >> Gecko) Chrome/63.0.3239.132 Safari/537.36 >> >> >> Response Headers (without http2) Accept-Ranges:bytes >> Content-Encoding:gzip Content-Type:text/css Date:Mon, 29 Jan 2018 >> 17:55:59 GMT ETag:W/"5931-151632439" Last-Modified:Fri, 19 Jan >> 2018 01:13:10 GMT >> Strict-Transport-Security:max-age=31536000;includeSubDomains >> Transfer-Encoding:chunked Vary:Accept-Encoding >> X-Content-Type-Options:nosniff X-Frame-Options:SAMEORIGIN >> X-XSS-Protection:1; mode=block >> >> >> Response Headers (with http2) accept-ranges:bytes >> content-type:text/css date:Mon, 29 Jan 2018 18:03:06 GMT >> etag:W/"5931-151632439" last-modified: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 Schultz >>> 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 without the UpgradeProtocol >>>>> tag. Adding UpgradeProtocol for http2 and gzip compression >>>>> stop working. >>>>> >>>>> >>>>> >>>> protocol="org.apache.coyote.http11.Http11AprProtocol" >>>>> SSLEnabled="true" scheme="https" secure="true" >>>>> maxHttpHeaderSize="32767" maxThreads="150" >>>>> URIEncoding="UTF-8" compression="on" useSendfile="off" >>>>> defaultSSLHostConfigName="*. .ca" >>>>> >>>>> >>>> className="org.apache.coyote.http2.Http2Protocol" >>>>> compression="on" >>>>> compressibleMimeType="text/html,text/xml,text/plain,text/css,text/j > ava >> >>>>> > script,application/javascript,application/json,application/xml" >>>>> >>>>> >> compressionMinSize="0" >>>>> /> > > Are you making requests directly to Tomcat, or is there a reverse > proxy in between? > > Is is possible that a servlet other than the DefaultServlet is > handling the request? > > - -chris > Hi Chris, There is no proxy. I have tried again on the same box using localhost and then result is still the same, when http2 is enabled, gzip not working. I have no other Servlet, but I have enabled HSTS in web.xml all the time (with or without http2). httpHeaderSecurity org.apache.catalina.filters.HttpHeaderSecurityFilter true antiClickJackingOption SAMEORIGIN hstsMaxAgeSeconds 31536000 hstsIncludeSubDomains true httpHeaderSecurity /* REQUEST - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.5.27 HTTP/2 connector not supporting GZIP compression
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Pierre, On 1/29/18 1:07 PM, Pierre Chiu wrote: > Here is the request/response header. You can tell > Content-Encoding:gzip is missing when http2 is enabled. > > > > General (same with/without http2) Request > URL:https://x.ca/tomcat.css Request Method:GET Status > Code:200 Remote Address:198.163.180.42:443 Referrer > Policy:no-referrer-when-downgrade > > > Request Headers (same with/without http2) > Accept:text/css,*/*;q=0.1 Accept-Encoding:gzip, deflate, br > Accept-Language:en-US,en;q=0.9,zh-TW;q=0.8,zh;q=0.7 > Cache-Control:no-cache Connection:keep-alive > Cookie:_ga=GA1.2.1536574675.1508533871; __utmc=29525935; > __utmz=29525935.1508478784.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd= (none); > __utma=29525935.990581674.1508478784.1516634493.1516996006.24 > DNT:1 Host:x.ca Pragma:no-cache > Referer:https://x.ca/index.jsp User-Agent:Mozilla/5.0 > (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like > Gecko) Chrome/63.0.3239.132 Safari/537.36 > > > Response Headers (without http2) Accept-Ranges:bytes > Content-Encoding:gzip Content-Type:text/css Date:Mon, 29 Jan 2018 > 17:55:59 GMT ETag:W/"5931-151632439" Last-Modified:Fri, 19 Jan > 2018 01:13:10 GMT > Strict-Transport-Security:max-age=31536000;includeSubDomains > Transfer-Encoding:chunked Vary:Accept-Encoding > X-Content-Type-Options:nosniff X-Frame-Options:SAMEORIGIN > X-XSS-Protection:1; mode=block > > > Response Headers (with http2) accept-ranges:bytes > content-type:text/css date:Mon, 29 Jan 2018 18:03:06 GMT > etag:W/"5931-151632439" last-modified: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 Schultz >> 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 without the UpgradeProtocol >>>> tag. Adding UpgradeProtocol for http2 and gzip compression >>>> stop working. >>>> >>>> >>>> >>> protocol="org.apache.coyote.http11.Http11AprProtocol" >>>> SSLEnabled="true" scheme="https" secure="true" >>>> maxHttpHeaderSize="32767" maxThreads="150" >>>> URIEncoding="UTF-8" compression="on" useSendfile="off" >>>> defaultSSLHostConfigName="*. .ca" >>>> >>>> >>> className="org.apache.coyote.http2.Http2Protocol" >>>> compression="on" >>>> compressibleMimeType="text/html,text/xml,text/plain,text/css,text/j ava > >>>> script,application/javascript,application/json,application/xml" >>>> >>>> > compressionMinSize="0" >>>> /> Are you making requests directly to Tomcat, or is there a reverse proxy in between? Is is possible that a servlet other than the DefaultServlet is handling the request? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlpvZ5cdHGNocmlzQGNo cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFjEPw//RpcMamGqoMW2Z5P0 x3cgjvriPpSIDfeG0iS8g+sQqbv4okrPGvftlzBd/7pjF4cGM2iUTNryyTXaLNmy I61t8l0IMT8oCJpPhcRFar47F4+ftgN1GhfSm6yecFEVS8sZoDi5pK/CGZDsAu0s JrObk2Rtsq4QiiFtL+X3kzixXaEdUBTPet2CukFR3fTIWlXDwaNzD2BO2bF87amg 2jTwiBGuRMAhwThiY0hdVMX1tjE+7poIlNntags3OCs0yOYq6/GAOQWL6AJwIm71 45cTmZ7IvzKNQG8YmUyXbYyMugCMZ41nbeXks0bEIvdf93AxBTEFaB8K1vOfKJ/R zD4puW3p43wCc4m7IfhzM6P+ETqLLPHjJ37ygBNEvV9/q/sOk6adzVJ1MGkHBPps HprBejOmBXWZggKZ5m/5uyhzHB46ucN59BbQdqeWRwjiY65PNB/KxT0JpHyQcSxZ kKfmaFwdpq/4JI/HQ9wAbteEaEsiVqNlTzUjRmId4opsq1kZlYKOuNfl5uH3k9CW ntfMMvQ7L5TBhWmO7yZTwMY0phZEvx51o9cwhV2RgAstUHKGANKA6SvwSezu9dex Fp6+9MxsBBkG8Vfq0ceYtxPzT69Dlw+JlzaUb/g4aoc9eDvDnEbEi3iQ0sFkujy/ f2GJAq7dM/56dIxzhp9k+0fQYFo= =hN1Q -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.5.27 HTTP/2 connector not supporting GZIP compression
Hi Christopher,
Here is the request/response header. You can tell Content-Encoding:gzip is
missing when http2 is enabled.
General (same with/without http2)
Request URL:https://x.ca/tomcat.css
Request Method:GET
Status Code:200
Remote Address:198.163.180.42:443
Referrer Policy:no-referrer-when-downgrade
Request Headers (same with/without http2)
Accept:text/css,*/*;q=0.1
Accept-Encoding:gzip, deflate, br
Accept-Language:en-US,en;q=0.9,zh-TW;q=0.8,zh;q=0.7
Cache-Control:no-cache
Connection:keep-alive
Cookie:_ga=GA1.2.1536574675.1508533871; __utmc=29525935;
__utmz=29525935.1508478784.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none);
__utma=29525935.990581674.1508478784.1516634493.1516996006.24
DNT:1
Host:x.ca
Pragma:no-cache
Referer:https://x.ca/index.jsp
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36
Response Headers (without http2)
Accept-Ranges:bytes
Content-Encoding:gzip
Content-Type:text/css
Date:Mon, 29 Jan 2018 17:55:59 GMT
ETag:W/"5931-151632439"
Last-Modified:Fri, 19 Jan 2018 01:13:10 GMT
Strict-Transport-Security:max-age=31536000;includeSubDomains
Transfer-Encoding:chunked
Vary:Accept-Encoding
X-Content-Type-Options:nosniff
X-Frame-Options:SAMEORIGIN
X-XSS-Protection:1; mode=block
Response Headers (with http2)
accept-ranges:bytes
content-type:text/css
date:Mon, 29 Jan 2018 18:03:06 GMT
etag:W/"5931-151632439"
last-modified: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 Schultz
> wrote:
>
> -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 UpgradeProtocol for http2 and gzip compression stop
>> working.
>>
>>
>> > protocol="org.apache.coyote.http11.Http11AprProtocol"
>> SSLEnabled="true" scheme="https" secure="true"
>> maxHttpHeaderSize="32767" maxThreads="150" URIEncoding="UTF-8"
>> compression="on" useSendfile="off" defaultSSLHostConfigName="*.
>> .ca"
>>
>> > compression="on"
>> compressibleMimeType="text/html,text/xml,text/plain,text/css,text/java
> script,application/javascript,application/json,application/xml"
>>
>>
> compressionMinSize="0"
>> />
>>
>> > disableSessionTickets="true"
>> ciphers="TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
>> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
>> TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,
>> TLS_DHE_DSS_WITH_AES_256_GCM_SHA384,
>> TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,
>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
>> TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,
>> TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,
>> TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,
>> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
>> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,
>> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,
>> TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,
>> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
>> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,
>> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,
>> TLS_DHE_DSS_WITH_AES_256_CBC_SHA,
>> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
>> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,
>> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,
>> TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,
>> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
>> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,
>> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,
>> TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,
>> TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA,
>> TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,
>> TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,
>> TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,
>> TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,
>> TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_128_GCM_SHA256,
>> TLS_EMPTY_RENEGOTIATION_INFO_SCSVF"
>>>
>> > CertificateChainFile="${catalina.home}\conf\ssl\gd_bundle-g2-g1.crt"
>>
>>
> type="RSA" />
>>
>
>
Re: Tomcat 8.5.27 HTTP/2 connector not supporting GZIP compression
-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 UpgradeProtocol for http2 and gzip compression stop
> working.
>
>
> protocol="org.apache.coyote.http11.Http11AprProtocol"
> SSLEnabled="true" scheme="https" secure="true"
> maxHttpHeaderSize="32767" maxThreads="150" URIEncoding="UTF-8"
> compression="on" useSendfile="off" defaultSSLHostConfigName="*.
> .ca"
>
> compression="on"
> compressibleMimeType="text/html,text/xml,text/plain,text/css,text/java
script,application/javascript,application/json,application/xml"
>
>
compressionMinSize="0"
> />
>
> disableSessionTickets="true"
> ciphers="TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
> TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,
> TLS_DHE_DSS_WITH_AES_256_GCM_SHA384,
> TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,
> TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,
> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,
> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,
> TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,
> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,
> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,
> TLS_DHE_DSS_WITH_AES_256_CBC_SHA,
> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,
> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,
> TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,
> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,
> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,
> TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,
> TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA,
> TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,
> TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,
> TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,
> TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,
> TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_128_GCM_SHA256,
> TLS_EMPTY_RENEGOTIATION_INFO_SCSVF"
>>
> CertificateChainFile="${catalina.home}\conf\ssl\gd_bundle-g2-g1.crt"
>
>
type="RSA" />
>
What does your request look like? Complete headers are important. What
does the response look like? Only the headers are important.
- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlpvNJQdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFiI3g/+L0hTRObxnmFWwrHV
ryUbfH0EhuyGnUWWf/ZLiCjY3c8jwIqg6YMqgSsId4dMIU+ivhJDMVczJ2ymzGeg
loPBRsrOKwhIEFwvKKCEtVi6t6LCiv9NzMAv68wg/8BaTDJBYLXfl2VJ28onDbaG
7s43F0fqnxtv8tOhL9MT3YVRtosJoY8UeSp18Sl6DuYXVtWbK/Qmi3TMFE6uhEZY
yHAkhu1fsWjfIns/PiVeWf6MK4rqXceW3gcsPC3JM0WA4QGttUfL2il0JD/ZXHtT
4oXvv+lajmFwAVLNOVxOmNBPlPzKh+hBMJMtcjHFHpsET+7aY8kYycVaVlNqLm1t
+mXmzwXbFnuZlyrk3vk+2DWi3LE8Fh2Eej8vUhFWkxbxJcg2CcksMkc6CNahhyn5
wOQWV7jKcfH0PlHALlS589TLMd0RAK1yy8atAQnoGHqH/YEZEE+CKj9O4o19laSE
rueZ8F09GZkz6bMlVqVbZRb9oMEedm28IGjhc4mZurxADr+Uug8zPL60Sxc4EMiL
RRfLi1MMLH206A9/R3qNUZXmN86hyHu3TArpvaonoGQqO98ZPKWIc1VYKxJD3OZb
TYeWHfIRWQGn/wVNgxUhAQw+RYvsif0tSlvCaXpC8NpuSCzhO+VxVplJ5l9vyXTj
eY1BiUNphjOdRtsBTbhSk18NtnQ=
=sxAm
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 8.5.27 HTTP/2 connector not supporting GZIP compression
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. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.0: compression="on" or compression="force" running on Java 1.8.0_151 causes content encoding errors in browsers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/26/17 10:30 AM, Johan Compagner wrote: > They (oracle) first introduced this in Java9.. Its something that > they don't expect that certain things are reused/cached i believe > > Now they backported that same bug also to java 8, i think they > already fixed it for the next java8 version: > > https://bugs.openjdk.java.net/browse/JDK-8189789 Thanks to both Jörg and Johan for bring this to everyone's attention. I was just getting ready to update to 8.latest in production and this may have saved me a serious headache. Thanks, - -chri > On 26 October 2017 at 16:19, Jörg Schubert > wrote: > >> Am 26.10.2017 um 15:36 schrieb Jörg Schubert: >> >>> >>> 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. >>> >>> 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,docs and demo pages are working. A lot of >>> pages of Psi-Probe <https://github.com/psi-probe/psi-probe> >>> (Version 2.3.0 and current HEAD) are failing. Also failing is a >>> webservice result redirected over >>> org.apache.camel.component.servlet.CamelHttpTransportServlet >>> from apache camel 2.20. >>> >>> Going back to oracle jdk 1.8.0_144 or openjdk 1.8.0_141 >>> resolves that issue. >>> >>> A tcpdump of a failed Psi-Probe page is attached. My knowledge >>> about HTTP ist limited. Could anyone take a look at it? >>> >>> >>> Thank You and with best regards, >>> >>> Joerg >>> >>> >>> -- * Jörg Schubert cebacus >>> Ingenieurgesellschaft mbH Friedgartenstr. 50-52 32429 Minden, >>> Germany >>> >>> Phone: +49-(0571)-9561953 Fax: +49-(0571)-9561929 >>> e-mail:jschub...@cebacus.de * >>> >>> >>> - - >>> >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >>> >> >> Some additional information: >> >> - No problems with Tomcat 8.5.23 using standard connector with >> compression="on". >> >> - Problem occurs on Tomcat7 with standard connector, ssl >> connector and http11nio >> >> >> > > -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAln3OCUACgkQHPApP6U8 pFhE5hAAkrQuqhvbL0Z8MjYOT9l9WKFoyVLrcu3NmvhboqBojdyfruwWB0eJLD0y xeSDSyab5HNS26N1cFvQ1T0U7slNuDp/wAsuIYV8eSSISUvIz3FQD/on+/wyjVTL 247tSJdCfdSu0nxIZ1SXrenptrMRzak3oT9IYCHc4v7bkAonwQYNo3mlcHa5MZ4v goIkN0O5I0ss+g1Vuy18Vt3Ixn+D4gem7sC0oFA1dAGcgmG5lsR91OGikYTlYwos D8Pbwvbbmsz+lChKgF1qGJLQ4QSezkK19uL2Y20/0FKSd97zvFxsG0/1CJBBFYtl PrbQnJjb84D7WkJo9djigS74AgBC885mAz+YAVYn02c5z0xma1zonZalhUeVhdzY 3JHZ+WXC61fF+sVj16ZcWGaOkWdFbkWJEa4AnUsRbGmvGjWUFOmYXCNdQOdE3/C6 SlV5Dd+L9IhrPmqr0fCcyScUHWyWSsfAhmAKgLH/5Cb0qioprtxFTx+J2SC7s3Yp SV+CFo4rQIvBQ+LK0178x4EI9cFJJb+m5ia5Wim4jGyk6GQBGxPFNQxhZuHUxEob 6iWjMRIZc+D3zmD9DVmdFs8kK7L1Jn0TcUy3DjnOegEvRHHWGQM3fntqbVtG67ct vpSbKXdoamAu8hv5hPxQc2sWAZOuupYdtXIYPV1NH7lqBTPihKo= =ZrWj -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.0: compression="on" or compression="force" running on Java 1.8.0_151 causes content encoding errors in browsers
They (oracle) first introduced this in Java9.. Its something that they don't expect that certain things are reused/cached i believe Now they backported that same bug also to java 8, i think they already fixed it for the next java8 version: https://bugs.openjdk.java.net/browse/JDK-8189789 On 26 October 2017 at 16:19, Jörg Schubert wrote: > Am 26.10.2017 um 15:36 schrieb Jörg Schubert: > >> >> 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. >> >> 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,docs and demo pages are working. >> A lot of pages of Psi-Probe <https://github.com/psi-probe/psi-probe> >> (Version 2.3.0 and current HEAD) are failing. >> Also failing is a webservice result redirected over >> org.apache.camel.component.servlet.CamelHttpTransportServlet from apache >> camel 2.20. >> >> Going back to oracle jdk 1.8.0_144 or openjdk 1.8.0_141 resolves that >> issue. >> >> A tcpdump of a failed Psi-Probe page is attached. My knowledge about HTTP >> ist limited. Could anyone take a look at it? >> >> >> Thank You and with best regards, >> >> Joerg >> >> >> -- >> * >> Jörg Schubert >> cebacus Ingenieurgesellschaft mbH >> Friedgartenstr. 50-52 >> 32429 Minden, Germany >> >> Phone: +49-(0571)-9561953 >> Fax: +49-(0571)-9561929 >> e-mail:jschub...@cebacus.de >> * >> >> >> ----- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> > > Some additional information: > > - No problems with Tomcat 8.5.23 using standard connector with > compression="on". > > - Problem occurs on Tomcat7 with standard connector, ssl connector and > http11nio > > > -- Johan Compagner Servoy
Re: Tomcat 7.0: compression="on" or compression="force" running on Java 1.8.0_151 causes content encoding errors in browsers
Am 26.10.2017 um 15:36 schrieb Jörg Schubert: 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. 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,docs and demo pages are working. A lot of pages of Psi-Probe <https://github.com/psi-probe/psi-probe> (Version 2.3.0 and current HEAD) are failing. Also failing is a webservice result redirected over org.apache.camel.component.servlet.CamelHttpTransportServlet from apache camel 2.20. Going back to oracle jdk 1.8.0_144 or openjdk 1.8.0_141 resolves that issue. A tcpdump of a failed Psi-Probe page is attached. My knowledge about HTTP ist limited. Could anyone take a look at it? Thank You and with best regards, Joerg -- * Jörg Schubert cebacus Ingenieurgesellschaft mbH Friedgartenstr. 50-52 32429 Minden, Germany Phone: +49-(0571)-9561953 Fax: +49-(0571)-9561929 e-mail:jschub...@cebacus.de * - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Some additional information: - No problems with Tomcat 8.5.23 using standard connector with compression="on". - Problem occurs on Tomcat7 with standard connector, ssl connector and http11nio
Tomcat 7.0: compression="on" or compression="force" running on Java 1.8.0_151 causes content encoding errors in browsers
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. 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,docs and demo pages are working. A lot of pages of Psi-Probe <https://github.com/psi-probe/psi-probe> (Version 2.3.0 and current HEAD) are failing. Also failing is a webservice result redirected over org.apache.camel.component.servlet.CamelHttpTransportServlet from apache camel 2.20. Going back to oracle jdk 1.8.0_144 or openjdk 1.8.0_141 resolves that issue. A tcpdump of a failed Psi-Probe page is attached. My knowledge about HTTP ist limited. Could anyone take a look at it? Thank You and with best regards, Joerg -- * Jörg Schubert cebacus Ingenieurgesellschaft mbH Friedgartenstr. 50-52 32429 Minden, Germany Phone: +49-(0571)-9561953 Fax: +49-(0571)-9561929 e-mail:jschub...@cebacus.de * - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: sendFiles vs. compression
On Wed, Apr 19, 2017 at 9:26 AM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Chris, > > On 4/18/17 10:58 AM, Chris Gamache wrote: > > 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? > > 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 > handle your output versus your (likely "default") SendfileDefaultServlet > . > Excellent suggestion. It's similar to the rewrite filter suggestion, but it keeps web.xml simple which is one of my goals. > > > Both settings have a minimum file size that engages their mechanism > > but to set up a division of labor I would think we would need all > > of include/exclude and max/min for both sendfile() and compression. > > Again, I could be missing something obvious by staring at the > > problem too long. > > You could also pre-compress your static files. > I like that idea. It is a good way to take care of it in a targeted and sane way. > > > @André and the rest of the listserv, In your opinions-- thinking > > about the web site consumer's experience, and having to choose > > either send sendfile() or compression-- is the juice worth the > > squeeze so-to-speak keeping sendfile() and sending uncompressed > > files, or is the better choice to enable compression at the expense > > of direct static file access and save bandwidth? > > It really depends upon your use-case. If you have a lot of free CPU > cycles, then using them instead of sendFile="true" will improve your > overall throughput to the client. > If you have a very CPU-intensive application (which most are NOT... > most apps are just waiting around for a disk, database, etc. to > respond) then maybe you want to be as CPU-efficient as possible and > use sendFile="true". > > If you have a very data-heavy application (tons of bytes need to be > sent back and forth to the client) or you have clients with very thin > pipes (e.g. mobile), then compression might outweigh "efficiency" on > the application server. > That pretty much sums it up, yea? ;) I think the group consensus is to monitor the server CPU and use that as the main factor in deciding whether to use compression or not. I really appreciate your thoughts and the thoughts of the other responders. I have a clear plan of attack now. > - -chris > > > On Tue, Apr 18, 2017 at 9:08 AM, André Warnier (tomcat) > > wrote: > > > >> 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. If the file is over 50K, > >>> it would connect the OutputStream to a GZipOutputStream rather > >>> than compressing the whole thing in memory and then sending it > >>> out from there. When that happens it doesn't send a > >>> Content-Length header. This is fine for most browsers. Safari > >>> has a problem with this and will decline to receive the file. > >>> In looking at the GZip filter I've been using, it's kind-of > >>> naive-- there must be a more intelligent compression option > >>> built into tomcat by now, right? > >>> > >>> To enable compression, I set `compression="on"` in my > >>> element in my server.xml file. There is on > >>> sticking point-- if sendFile is available (asynchronous > >>> file-sending by the DefaultServlet using NIO) it will trump > >>> compression by default. I can turn off sendFile, and browsers > >>> report that they are receiving compressed files. So it seems > >>> like an all-or-nothing situation where compression and sendFile > >>> are mutually exclusive. There are minimum file size settings > >>> for both options, but no max file size settings so I can't say > >>> "use sendFile for files under 50K and compression for files > >>> above 50K" because sendFile will alw
Re: sendFiles vs. compression
On Wed, Apr 19, 2017 at 9:05 AM, Mark H. Wood wrote: > On Tue, Apr 18, 2017 at 02:03:19PM -0400, Chris Gamache wrote: > > I had any frame of reference to base a decision on, I wouldn't have asked > > the question. Ask any front-end engineer what the single 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 the file system in an efficient manner was a double mystery. > > > > Perhaps if my fellow tomcat users would share their thought processes in > > their particular situations for selecting one method over the other, that > > might help me look at my own situation and make a good decision. > > Well, why does one want to use sendfile()? Why does one want to use > compression? > > sendfile() can be more efficient on the server end, by reducing the > number of context switches when sending large files: one switch into > kernel mode is all that is needed to get the file sent. So if you > have a lot of concurrent users and fairly large files, this economy > might dominate the user experience. > > Gotcha. More files can be sent at once (and more efficiently). We have only a few large files to transfer per client, and the rest is client/server data chatter. > OTOH compression can make more efficient use of lower-bandwidth links, > because it sends fewer bits in fewer packets to accomplish the same > task. So if you have a lot of users on slow links then this economy > might dominate the user experience. Note that compression uses more > CPU at both ends, so a server already running flat-out or a large > community of low-powered clients may eat up any savings, and then > some. > > Got it. CPU on both client and server to consider. We're not CPU bound ATM on our servers using our current naive GZipFilter, so this is a consideration I will put into the hat. We're going for shorter app load time, and bandwidth is our chief consideration. Radio time is more power/dollar intensive than (de)compression for mobile clients, and non-mobile clients won't probably blink at decompressing 500kb of javascript and a few images and fonts. > How to know which is most important? Measure! The simplest approach > would be to try it each way and ask users how they experienced the > result. If you have a lot of information about the distribution of > bandwidth and CPU power across your user community, the amount of > data to be sent per request, and the shape of traffic over time, you > can make some shrewd guesses, but in the end the best solution is the > one that does the job best, and the only way to know that is to test > and see. > Yes. Excellent advice. Thank you for your thoughtful response! > > -- > Mark H. Wood > Lead Technology Analyst > > University Library > Indiana University - Purdue University Indianapolis > 755 W. Michigan Street > Indianapolis, IN 46202 > 317-274-0749 > www.ulib.iupui.edu >
Re: sendFiles vs. compression
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chris, On 4/18/17 10:58 AM, Chris Gamache wrote: > 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? 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 handle your output versus your (likely "default") SendfileDefaultServlet . > Both settings have a minimum file size that engages their mechanism > but to set up a division of labor I would think we would need all > of include/exclude and max/min for both sendfile() and compression. > Again, I could be missing something obvious by staring at the > problem too long. You could also pre-compress your static files. > @André and the rest of the listserv, In your opinions-- thinking > about the web site consumer's experience, and having to choose > either send sendfile() or compression-- is the juice worth the > squeeze so-to-speak keeping sendfile() and sending uncompressed > files, or is the better choice to enable compression at the expense > of direct static file access and save bandwidth? It really depends upon your use-case. If you have a lot of free CPU cycles, then using them instead of sendFile="true" will improve your overall throughput to the client. If you have a very CPU-intensive application (which most are NOT... most apps are just waiting around for a disk, database, etc. to respond) then maybe you want to be as CPU-efficient as possible and use sendFile="true". If you have a very data-heavy application (tons of bytes need to be sent back and forth to the client) or you have clients with very thin pipes (e.g. mobile), then compression might outweigh "efficiency" on the application server. - -chris > On Tue, Apr 18, 2017 at 9:08 AM, André Warnier (tomcat) > wrote: > >> 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. If the file is over 50K, >>> it would connect the OutputStream to a GZipOutputStream rather >>> than compressing the whole thing in memory and then sending it >>> out from there. When that happens it doesn't send a >>> Content-Length header. This is fine for most browsers. Safari >>> has a problem with this and will decline to receive the file. >>> In looking at the GZip filter I've been using, it's kind-of >>> naive-- there must be a more intelligent compression option >>> built into tomcat by now, right? >>> >>> To enable compression, I set `compression="on"` in my >>> element in my server.xml file. There is on >>> sticking point-- if sendFile is available (asynchronous >>> file-sending by the DefaultServlet using NIO) it will trump >>> compression by default. I can turn off sendFile, and browsers >>> report that they are receiving compressed files. So it seems >>> like an all-or-nothing situation where compression and sendFile >>> are mutually exclusive. There are minimum file size settings >>> for both options, but no max file size settings so I can't say >>> "use sendFile for files under 50K and compression for files >>> above 50K" because sendFile will always trump compression. >>> >>> I think the idea of sending out static files asynchronously is >>> fantastic. I also want my pages to load faster by sending less >>> data. >>> >>> I figure the smart people who work on tomcat know a whole lot >>> more about this stuff than I do. They must have had a reason to >>> prioritize sendFile over compression, or the expert tomcat >>> administrators have figured out a way to balance the two. >>> >>> Maybe I've been staring at the problem too long, but I can't >>> figure it out. >>> >>> So, is it advisable turn of sendFile to engage compression? Or, >>> is there a combination of settings that will let me best use >>> them both? >>> >>> >> For what it's worth : sendfile() is a way by which the (web) >> application can just point the OS to a static fi
Re: sendFiles vs. compression
On Tue, Apr 18, 2017 at 02:03:19PM -0400, Chris Gamache wrote: > I had any frame of reference to base a decision on, I wouldn't have asked > the question. Ask any front-end engineer what the single 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 the file system in an efficient manner was a double mystery. > > Perhaps if my fellow tomcat users would share their thought processes in > their particular situations for selecting one method over the other, that > might help me look at my own situation and make a good decision. Well, why does one want to use sendfile()? Why does one want to use compression? sendfile() can be more efficient on the server end, by reducing the number of context switches when sending large files: one switch into kernel mode is all that is needed to get the file sent. So if you have a lot of concurrent users and fairly large files, this economy might dominate the user experience. OTOH compression can make more efficient use of lower-bandwidth links, because it sends fewer bits in fewer packets to accomplish the same task. So if you have a lot of users on slow links then this economy might dominate the user experience. Note that compression uses more CPU at both ends, so a server already running flat-out or a large community of low-powered clients may eat up any savings, and then some. How to know which is most important? Measure! The simplest approach would be to try it each way and ask users how they experienced the result. If you have a lot of information about the distribution of bandwidth and CPU power across your user community, the amount of data to be sent per request, and the shape of traffic over time, you can make some shrewd guesses, but in the end the best solution is the one that does the job best, and the only way to know that is to test and see. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu signature.asc Description: PGP signature
Re: sendFiles vs. compression
On 18.04.2017 20:03, Chris Gamache wrote: On Tue, Apr 18, 2017 at 11:24 AM, André Warnier (tomcat) wrote: Hi again. On this list, it is customary (and requested) to respond in-line and not "top post". See : http://tomcat.apache.org/lists.html#tomcat-users, item #6. It makes it easier to follow the conversation, as opposed to having to scroll back and forth to find out what you are commenting on. Noted. Apologies. 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 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 labor I would think we would need all of include/exclude and max/min for both sendfile() and compression. Again, I could be missing something obvious by staring at the problem too long. As you have probably already found out from the extensive and exquisitely written on-line tomcat documentation, there do not seem to exist such fine-tuned parameters available in the standard tomcat Connectors. Props. We could do better explaining the "why's" along with all the "what's". When I figure it out, I'll send a patch. ;) For now, I have to rely on my fine colleagues here in the list for some of the more intricate interpretations. If you want this type of control, /and/ you can more or less determine the kind of response you want to send by examining the request URL, I would have a look at a servlet filter such as URLRewrite ( http://tuckey.org/urlrewrite/), which could examine the request and determine to which specific response-generating servlet it should dispatch the call. In that servlet you can then decide yourself to compress or not the output, and/or to use sendfile. So by rewriting the URL, the request gets re-evaluated such that a different would be engaged? I still have the dilemma of determining which ladle I use to serve the data with. @André and the rest of the listserv, In your opinions-- thinking about the web site consumer's experience, and having to choose either send sendfile() or compression-- is the juice worth the squeeze so-to-speak keeping sendfile() and sending uncompressed files, or is the better choice to enable compression at the expense of direct static file access and save bandwidth? I think that this is a question to which you are the only one who can provide the right answer, because "it depends" on a lot of factors that are specific to your application, your mix of documents, your bandwidth availability and cost, the requirements of your clients etc.. With all respect, and I do thank you for your willingness to respond-- if I had any frame of reference to base a decision on, I wouldn't have asked the question. Ask any front-end engineer what the single 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 the file system in an efficient manner was a double mystery. Your any front-end engineer either is a crook, or he wants to get rid of you quickly. There is no such "one size fits all" answer, for such a vague question. Perhaps if my fellow tomcat users would share their thought processes in their particular situations for selecting one method over the other, that might help me look at my own situation and make a good decision. You already got a glimpse of our thought processes in the matter : We would start by trying out one configuration, in our own complex circumstances, and look at the results. And if we identify one particular problem area and can then ask a more precise and focused question based on some collected facts, and we cannot answer it ourselves, we might post it to the tomcat user's list. Alternatively, one of us might propose a dedicated paid consultancy, to inspect your application and your server and its connectivity and your user's usage pattern, and recommend a "best" solution based on collected facts, on his own experience in the matter, and on your budget. On Tue, Apr 18, 2017 at 9:08 AM, André Warnier (tomcat) wrote: 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. If the file is over 50K, it would connect the OutputStream to a GZipOutputStream rather than compressing the whole thing in memory and then
Re: sendFiles vs. compression
On Tue, Apr 18, 2017 at 11:24 AM, André Warnier (tomcat) wrote: > Hi again. > On this list, it is customary (and requested) to respond in-line and not > "top post". > See : http://tomcat.apache.org/lists.html#tomcat-users, item #6. > It makes it easier to follow the conversation, as opposed to having to > scroll back and forth to find out what you are commenting on. > > Noted. Apologies. > 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 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 labor I would think we would need all of >> include/exclude and max/min for both sendfile() and compression. Again, I >> could be missing something obvious by staring at the problem too long. >> > > As you have probably already found out from the extensive and exquisitely > written on-line tomcat documentation, there do not seem to exist such > fine-tuned parameters available in the standard tomcat Connectors. > Props. We could do better explaining the "why's" along with all the "what's". When I figure it out, I'll send a patch. ;) For now, I have to rely on my fine colleagues here in the list for some of the more intricate interpretations. > > If you want this type of control, /and/ you can more or less determine the > kind of response you want to send by examining the request URL, I would > have a look at a servlet filter such as URLRewrite ( > http://tuckey.org/urlrewrite/), which could examine the request and > determine to which specific response-generating servlet it should dispatch > the call. In that servlet you can then decide yourself to compress or not > the output, and/or to use sendfile. > > So by rewriting the URL, the request gets re-evaluated such that a different would be engaged? I still have the dilemma of determining which ladle I use to serve the data with. > >> @André and the rest of the listserv, In your opinions-- thinking about the >> web site consumer's experience, and having to choose either send >> sendfile() >> or compression-- is the juice worth the squeeze so-to-speak keeping >> sendfile() and sending uncompressed files, or is the better choice to >> enable compression at the expense of direct static file access and save >> bandwidth? >> > > I think that this is a question to which you are the only one who can > provide the right answer, because "it depends" on a lot of factors that are > specific to your application, your mix of documents, your bandwidth > availability and cost, the requirements of your clients etc.. > > With all respect, and I do thank you for your willingness to respond-- if I had any frame of reference to base a decision on, I wouldn't have asked the question. Ask any front-end engineer what the single 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 the file system in an efficient manner was a double mystery. Perhaps if my fellow tomcat users would share their thought processes in their particular situations for selecting one method over the other, that might help me look at my own situation and make a good decision. > > >> >> >> >> On Tue, Apr 18, 2017 at 9:08 AM, André Warnier (tomcat) >> wrote: >> >> 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. If the file is over 50K, it would connect the OutputStream to a >>>> GZipOutputStream rather than compressing the whole thing in memory and >>>> then >>>> sending it out from there. When that happens it doesn't send a >>>> Content-Length header. This is fine for most browsers. Safari has a >>>> problem >>>> with this and will decline to receive the file. In looking at the GZip >>>> filter I've been using, it's kind-of naive-- there m
Re: sendFiles vs. compression
On Tue, Apr 18, 2017 at 11:29 AM, Mark Thomas wrote: > 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 compression will handle files of > other > > mime-types and/or certain sizes? > > No. > > > Both settings have a minimum file size that engages their mechanism but > to > > set up a division of labor I would think we would need all of > > include/exclude and max/min for both sendfile() and compression. Again, I > > could be missing something obvious by staring at the problem too long. > > > > @André and the rest of the listserv, In your opinions-- thinking about > the > > web site consumer's experience, and having to choose either send > sendfile() > > or compression-- is the juice worth the squeeze so-to-speak keeping > > sendfile() and sending uncompressed files, or is the better choice to > > enable compression at the expense of direct static file access and save > > bandwidth? > > It will depend on your site and the typical traffic mix. You'd have to > test it. > > Or... > > You can have the best of both worlds if you pre-compress your static > resources. You need to be using 8.5.x or later. Look for precompressed > on http://tomcat.apache.org/tomcat-8.5-doc/default-servlet.html > > That's wicked. Something to look forward to when we are at the point of jumping to 8.5 or beyond. > Mark > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: sendFiles vs. compression
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 compression will handle files of other > mime-types and/or certain sizes? No. > Both settings have a minimum file size that engages their mechanism but to > set up a division of labor I would think we would need all of > include/exclude and max/min for both sendfile() and compression. Again, I > could be missing something obvious by staring at the problem too long. > > @André and the rest of the listserv, In your opinions-- thinking about the > web site consumer's experience, and having to choose either send sendfile() > or compression-- is the juice worth the squeeze so-to-speak keeping > sendfile() and sending uncompressed files, or is the better choice to > enable compression at the expense of direct static file access and save > bandwidth? It will depend on your site and the typical traffic mix. You'd have to test it. Or... You can have the best of both worlds if you pre-compress your static resources. You need to be using 8.5.x or later. Look for precompressed on http://tomcat.apache.org/tomcat-8.5-doc/default-servlet.html Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: sendFiles vs. compression
Hi again. On this list, it is customary (and requested) to respond in-line and not "top post". See : http://tomcat.apache.org/lists.html#tomcat-users, item #6. It makes it easier to follow the conversation, as opposed to having to scroll back and forth to find out what you are 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 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 labor I would think we would need all of include/exclude and max/min for both sendfile() and compression. Again, I could be missing something obvious by staring at the problem too long. As you have probably already found out from the extensive and exquisitely written on-line tomcat documentation, there do not seem to exist such fine-tuned parameters available in the standard tomcat Connectors. If you want this type of control, /and/ you can more or less determine the kind of response you want to send by examining the request URL, I would have a look at a servlet filter such as URLRewrite (http://tuckey.org/urlrewrite/), which could examine the request and determine to which specific response-generating servlet it should dispatch the call. In that servlet you can then decide yourself to compress or not the output, and/or to use sendfile. @André and the rest of the listserv, In your opinions-- thinking about the web site consumer's experience, and having to choose either send sendfile() or compression-- is the juice worth the squeeze so-to-speak keeping sendfile() and sending uncompressed files, or is the better choice to enable compression at the expense of direct static file access and save bandwidth? I think that this is a question to which you are the only one who can provide the right answer, because "it depends" on a lot of factors that are specific to your application, your mix of documents, your bandwidth availability and cost, the requirements of your clients etc.. On Tue, Apr 18, 2017 at 9:08 AM, André Warnier (tomcat) wrote: 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. If the file is over 50K, it would connect the OutputStream to a GZipOutputStream rather than compressing the whole thing in memory and then sending it out from there. When that happens it doesn't send a Content-Length header. This is fine for most browsers. Safari has a problem with this and will decline to receive the file. In looking at the GZip filter I've been using, it's kind-of naive-- there must be a more intelligent compression option built into tomcat by now, right? To enable compression, I set `compression="on"` in my element in my server.xml file. There is on sticking point-- if sendFile is available (asynchronous file-sending by the DefaultServlet using NIO) it will trump compression by default. I can turn off sendFile, and browsers report that they are receiving compressed files. So it seems like an all-or-nothing situation where compression and sendFile are mutually exclusive. There are minimum file size settings for both options, but no max file size settings so I can't say "use sendFile for files under 50K and compression for files above 50K" because sendFile will always trump compression. I think the idea of sending out static files asynchronously is fantastic.. I also want my pages to load faster by sending less data. I figure the smart people who work on tomcat know a whole lot more about this stuff than I do. They must have had a reason to prioritize sendFile over compression, or the expert tomcat administrators have figured out a way to balance the two. Maybe I've been staring at the problem too long, but I can't figure it out. So, is it advisable turn of sendFile to engage compression? Or, is there a combination of settings that will let me best use them both? For what it's worth : sendfile() is a way by which the (web) application can just point the OS to a static file on disk, and say "send this". And the sendfile logic in the OS takes care of the rest, in the most efficient way possible for that OS, and the call returns ok to your application right away, even possibly before the sendfile() action has completed. The sticky point here is "a static file on disk". So if you want to send back a gzipped file, then the only solution is to first create that gzipped version as a file on disk, and th
AW: sendFiles vs. compression
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 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 labor I would think we would need all of > include/exclude and max/min for both sendfile() and compression. Again, I > could be missing something obvious by staring at the problem too long. > > @André and the rest of the listserv, In your opinions-- thinking about the > web site consumer's experience, and having to choose either send sendfile() > or compression-- is the juice worth the squeeze so-to-speak keeping > sendfile() and sending uncompressed files, or is the better choice to > enable compression at the expense of direct static file access and save > bandwidth? > There may be a different aspect! Are you servicing the file on an SSL and login protected website? Then you should be aware of the BREACH attack http://breachattack.com/ and restrict the compressed resources wisely. Basically the authors say: do not use compression. Best regards Peter > > > > On Tue, Apr 18, 2017 at 9:08 AM, André Warnier (tomcat) > wrote: > > > 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. If the file is over 50K, it would connect the OutputStream to a > >> GZipOutputStream rather than compressing the whole thing in memory and > >> then > >> sending it out from there. When that happens it doesn't send a > >> Content-Length header. This is fine for most browsers. Safari has a > >> problem > >> with this and will decline to receive the file. In looking at the GZip > >> filter I've been using, it's kind-of naive-- there must be a more > >> intelligent compression option built into tomcat by now, right? > >> > >> To enable compression, I set `compression="on"` in my element > >> in my server.xml file. There is on sticking point-- if sendFile is > >> available (asynchronous file-sending by the DefaultServlet using NIO) it > >> will trump compression by default. I can turn off sendFile, and browsers > >> report that they are receiving compressed files. So it seems like an > >> all-or-nothing situation where compression and sendFile are mutually > >> exclusive. There are minimum file size settings for both options, but no > >> max file size settings so I can't say "use sendFile for files under 50K > >> and > >> compression for files above 50K" because sendFile will always trump > >> compression. > >> > >> I think the idea of sending out static files asynchronously is fantastic. > >> I > >> also want my pages to load faster by sending less data. > >> > >> I figure the smart people who work on tomcat know a whole lot more about > >> this stuff than I do. They must have had a reason to prioritize sendFile > >> over compression, or the expert tomcat administrators have figured out a > >> way to balance the two. > >> > >> Maybe I've been staring at the problem too long, but I can't figure it > >> out. > >> > >> So, is it advisable turn of sendFile to engage compression? Or, is there a > >> combination of settings that will let me best use them both? > >> > >> > > For what it's worth : > > sendfile() is a way by which the (web) application can just point the OS > > to a static file on disk, and say "send this". And the sendfile logic in > > the OS takes care of the rest, in the most efficient way possible for that > > OS, and the call returns ok to your application right away, even possibly > > before the sendfile() action has completed. > > The sticky point here is "a static file on disk". > > So if you want to send back a gzipped file, then the only solution is to > > first create that gzipped version as a file on disk, and then use > > sendfile() on that gzipped version. > > And then, presumably, you'd want to "clean up" these gzipped versions at > > some point. > > Which cannot happen right after you have called sendfile(), because you do > > not really know when it will be done actually sending the file. > > So it is not really a "priority" issue, it is that these are different > > things, and that sendfile() really only works on a file, not on dynamic > > output from a webapp. > > > > > > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > >
Re: sendFiles vs. compression
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? Both settings have a minimum file size that engages their mechanism but to set up a division of labor I would think we would need all of include/exclude and max/min for both sendfile() and compression. Again, I could be missing something obvious by staring at the problem too long. @André and the rest of the listserv, In your opinions-- thinking about the web site consumer's experience, and having to choose either send sendfile() or compression-- is the juice worth the squeeze so-to-speak keeping sendfile() and sending uncompressed files, or is the better choice to enable compression at the expense of direct static file access and save bandwidth? On Tue, Apr 18, 2017 at 9:08 AM, André Warnier (tomcat) wrote: > 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. If the file is over 50K, it would connect the OutputStream to a >> GZipOutputStream rather than compressing the whole thing in memory and >> then >> sending it out from there. When that happens it doesn't send a >> Content-Length header. This is fine for most browsers. Safari has a >> problem >> with this and will decline to receive the file. In looking at the GZip >> filter I've been using, it's kind-of naive-- there must be a more >> intelligent compression option built into tomcat by now, right? >> >> To enable compression, I set `compression="on"` in my element >> in my server.xml file. There is on sticking point-- if sendFile is >> available (asynchronous file-sending by the DefaultServlet using NIO) it >> will trump compression by default. I can turn off sendFile, and browsers >> report that they are receiving compressed files. So it seems like an >> all-or-nothing situation where compression and sendFile are mutually >> exclusive. There are minimum file size settings for both options, but no >> max file size settings so I can't say "use sendFile for files under 50K >> and >> compression for files above 50K" because sendFile will always trump >> compression. >> >> I think the idea of sending out static files asynchronously is fantastic. >> I >> also want my pages to load faster by sending less data. >> >> I figure the smart people who work on tomcat know a whole lot more about >> this stuff than I do. They must have had a reason to prioritize sendFile >> over compression, or the expert tomcat administrators have figured out a >> way to balance the two. >> >> Maybe I've been staring at the problem too long, but I can't figure it >> out. >> >> So, is it advisable turn of sendFile to engage compression? Or, is there a >> combination of settings that will let me best use them both? >> >> > For what it's worth : > sendfile() is a way by which the (web) application can just point the OS > to a static file on disk, and say "send this". And the sendfile logic in > the OS takes care of the rest, in the most efficient way possible for that > OS, and the call returns ok to your application right away, even possibly > before the sendfile() action has completed. > The sticky point here is "a static file on disk". > So if you want to send back a gzipped file, then the only solution is to > first create that gzipped version as a file on disk, and then use > sendfile() on that gzipped version. > And then, presumably, you'd want to "clean up" these gzipped versions at > some point. > Which cannot happen right after you have called sendfile(), because you do > not really know when it will be done actually sending the file. > So it is not really a "priority" issue, it is that these are different > things, and that sendfile() really only works on a file, not on dynamic > output from a webapp. > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: sendFiles vs. compression
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. If the file is over 50K, it would connect the OutputStream to a GZipOutputStream rather than compressing the whole thing in memory and then sending it out from there. When that happens it doesn't send a Content-Length header. This is fine for most browsers. Safari has a problem with this and will decline to receive the file. In looking at the GZip filter I've been using, it's kind-of naive-- there must be a more intelligent compression option built into tomcat by now, right? To enable compression, I set `compression="on"` in my element in my server.xml file. There is on sticking point-- if sendFile is available (asynchronous file-sending by the DefaultServlet using NIO) it will trump compression by default. I can turn off sendFile, and browsers report that they are receiving compressed files. So it seems like an all-or-nothing situation where compression and sendFile are mutually exclusive. There are minimum file size settings for both options, but no max file size settings so I can't say "use sendFile for files under 50K and compression for files above 50K" because sendFile will always trump compression. I think the idea of sending out static files asynchronously is fantastic. I also want my pages to load faster by sending less data. I figure the smart people who work on tomcat know a whole lot more about this stuff than I do. They must have had a reason to prioritize sendFile over compression, or the expert tomcat administrators have figured out a way to balance the two. Maybe I've been staring at the problem too long, but I can't figure it out. So, is it advisable turn of sendFile to engage compression? Or, is there a combination of settings that will let me best use them both? For what it's worth : sendfile() is a way by which the (web) application can just point the OS to a static file on disk, and say "send this". And the sendfile logic in the OS takes care of the rest, in the most efficient way possible for that OS, and the call returns ok to your application right away, even possibly before the sendfile() action has completed. The sticky point here is "a static file on disk". So if you want to send back a gzipped file, then the only solution is to first create that gzipped version as a file on disk, and then use sendfile() on that gzipped version. And then, presumably, you'd want to "clean up" these gzipped versions at some point. Which cannot happen right after you have called sendfile(), because you do not really know when it will be done actually sending the file. So it is not really a "priority" issue, it is that these are different things, and that sendfile() really only works on a file, not on dynamic output from a webapp. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
sendFiles vs. compression
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 the OutputStream to a GZipOutputStream rather than compressing the whole thing in memory and then sending it out from there. When that happens it doesn't send a Content-Length header. This is fine for most browsers. Safari has a problem with this and will decline to receive the file. In looking at the GZip filter I've been using, it's kind-of naive-- there must be a more intelligent compression option built into tomcat by now, right? To enable compression, I set `compression="on"` in my element in my server.xml file. There is on sticking point-- if sendFile is available (asynchronous file-sending by the DefaultServlet using NIO) it will trump compression by default. I can turn off sendFile, and browsers report that they are receiving compressed files. So it seems like an all-or-nothing situation where compression and sendFile are mutually exclusive. There are minimum file size settings for both options, but no max file size settings so I can't say "use sendFile for files under 50K and compression for files above 50K" because sendFile will always trump compression. I think the idea of sending out static files asynchronously is fantastic. I also want my pages to load faster by sending less data. I figure the smart people who work on tomcat know a whole lot more about this stuff than I do. They must have had a reason to prioritize sendFile over compression, or the expert tomcat administrators have figured out a way to balance the two. Maybe I've been staring at the problem too long, but I can't figure it out. So, is it advisable turn of sendFile to engage compression? Or, is there a combination of settings that will let me best use them both?
Re: Tomcat 8.5 HTTP/2 connector not supporting GZIP compression
-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
> :
>> 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:
>>
>> > port="8443" connectionTimeout="2" executor="main"
>> SSLEnabled="true" scheme="https" secure="true"
>> URIEncoding="UTF-8" maxHttpHeaderSize="10240" compression="force"
>> SSLCertificateKeyFile="${tomcat.conf.dir}/key.pem"
>> SSLCertificateFile="${tomcat.conf.dir}/cert.pem"
>> SSLPassword="changeit"> > className="org.apache.coyote.http2.Http2Protocol" />
>>
>
> When you ask about compression of dynamic content, I think that
> you should read about the following well-known issues first,
> especially the latter one:
>
> https://en.wikipedia.org/wiki/CRIME_(security_exploit)
> https://en.wikipedia.org/wiki/BREACH_(security_exploit)
It's BREACH that's worse. CRIME seems to be focused on using
known-plaintext to pick-away at the TLS encryption wrapper. While also
a known-plaintext attack, BREACH uses HTTP compression (where the
headers are not compressed before being encrypted for transfer) and
the compressed content is buried more deeply and is thus (slightly)
more difficult to pull off an attack.
There are also some mitigations, the first of which is to ensure that
your application doesn't have any XSS vulnerabilities (which is
usually a big job). The second is to play games with enabling
compression only under certain circumstances, but I suspect those
circumstances are quite difficult to truly get right, and their
validity will diminish over time.
- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJYmItEAAoJEBzwKT+lPKRYwq4P/jl57G3sUQDPNE3z3/61mf+r
WCdh8+nUmDxfdjuBrV9eJj/7rvM7wElOudT+XvtQ2oNRSO2aPUVkcLuqkDHwg5H5
XCxVqCoj+kLZFxv12WtCWaDpMc54sXDsLF0Mg0jVbnQmuFjA+G0/YCfC7Il4n4nc
VoYG69t9rkduDksDc/KDid9qb2WT/fxYXP3XmuVwIjT52QRpaqO+e9UqZBx/nPnR
zWqr1IcNJYwMZXI/5LHK9WeItlDGhVK47ziXDQ4JNAk2WistMn6k8kZEVogS63VI
8DxrAN3Ob1u5Z3/1ttEUqH8KdAFvHWNn/2S2zB2hKOfhj0PURd1sxZDjORAwVtXR
LjdKsaD/LYQ6Oej58bG+33GT6uGcq6iPXZzOqX186N5kR+D4GK515TKO98GA49Me
QClN7YU6iys+Ymf4xSva8/gNdIRYGSuK5hwhqACThGiKB0kc0pgNfeZq7N/OO5Eh
jsEIkkjy3kAEhFvBikwwUiMgMCEbbsPxmpnEnkBrID6Or94TInKHeZkHEny/ILQu
2TnMiChNnR2W0sJlPOokEyIwKepxNO5Ue4Wt9lqqoDGvKTqK3K+aZSZJqyPYATEv
Tfibkf27qTVT2vvy29B/BUyFomSIk4WfNA/fZrzyw3zatrLddla+5n3yhxK990QL
xIJtAtI8pbeeKwCJEKTU
=gP7O
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.5 HTTP/2 connector not supporting GZIP compression
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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.5 HTTP/2 connector not supporting GZIP compression
2017-02-04 18:55 GMT+03:00 Patrizio Munzi :
> 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="2" executor="main" SSLEnabled="true" scheme="https"
> secure="true" URIEncoding="UTF-8" maxHttpHeaderSize="10240"
> compression="force" SSLCertificateKeyFile="${tomcat.conf.dir}/key.pem"
> SSLCertificateFile="${tomcat.conf.dir}/cert.pem" SSLPassword="changeit">
>
>
When you ask about compression of dynamic content, I think that you
should read about the following well-known issues first, especially
the latter one:
https://en.wikipedia.org/wiki/CRIME_(security_exploit)
https://en.wikipedia.org/wiki/BREACH_(security_exploit)
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 8.5 HTTP/2 connector not supporting GZIP compression
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
Re: Compression with APR connector and SSL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Raul, On 7/28/16 2:25 PM, Martinez Maestre, Raul (CIT-IOEP) wrote: > Hi, > > > > I have configured APR with the following versions for components > > -APR version 1.5.2 > > - Open SSL version openssl-1.0.2h > > - 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 compression is not being used? I'm confused. You seem to be enabling compression at a number of places: > compression=3D"on" This should enable gzip compression of the message bodies. > compressionMinSize="2048" > compressableMimeType="text/html,text/xml,text/plain,text/css,te= > xt/javascript,text/json,application/x-javascript,application/javascrip t,app= > > lication/json" This further configures HTTP-compression. > /> h2 enables compression by default. > I think OpenSSL disabled compression by default to mitigate the CRIME attack. Their changelog[1] indicates that happened between 1.0.1h and 1.1.0, and I can't seem to find a similar change that directly affects your version. Try re-building OpenSSL with zlib support included (use either the "zlib" or "zlib-dynamic" build options). You may also be at the mercy of your OS's OpenSSL package maintainers. If you don't have zlib built-in, then you can't use compression even if you want to. If you DO have zlib built-in, you can configure the library to allow compression, but there is no direct-support for enabling this option from Tomcat. Given the CRIME vulnerability, I don't think you want to enable compression for TLS. Also, the default value for "useSendfile" is "true", and when sendfile is in use, HTTP compression is disabled. So, which compression were you trying to enable? TLS compression is a bad idea, so you should try setting useSendfile="false" and trying again . Hope that helps, - -chris [1] https://www.openssl.org/news/changelog.html (search for CRIME) -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAled8WsACgkQ9CaO5/Lv0PCadACdHhS5/k3gqVis5VeX6nha5W+Y lhoAoKYIjAC0lVOLCfJ47/HM9toFixXk =9GCe -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Compression with APR connector and SSL
Hi, I have configured APR with the following versions for components -APR version 1.5.2 - Open SSL version openssl-1.0.2h - 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? Thanks in advance and best regards! Raúl
Re: SSL / TLS compression | SPDY service|CVE-2012-4929
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rahul, On 3/27/15 10:42 PM, Rahul Kumar Singh wrote: > Ok I understand, Is it mentioned somewhere in tomcat spec. That it > is not being used in JSSE connector. > > Based on the above answer my next question: If any browser is > affected with this CVE , 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-into the SPDY protocol. - -chris > 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 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 connectors. > > If you are using APR/Native connector, if you didn't explicitly > enabled it, SPDY is disabled by default. You may disable TLS > compression using APR/Native connector parameter > SSLDisableCompression="true". > > -Ognjen > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > DISCLAIMER: > -- - - > > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. It shall not attach any > liability on the originator or NEC or its affiliates. Any views or > opinions presented in this email are solely those of the author and > may not necessarily reflect the opinions of NEC or its affiliates. > Any form of reproduction, dissemination, copying, disclosure, > modification, distribution and / or publication of this message > without the prior written consent of the author of this e-mail is > strictly prohibited. If you have received this email in error > please delete it and notify the sender immediately. . > -- - - > > > - > > 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 iQIcBAEBCAAGBQJVFqWfAAoJEBzwKT+lPKRYj/AP+QHr0m5jgXin9ronjz4vYVTW SrjNMmIfa5wB5CZJzumUd4w2f0iRxgfPT02r/bVCXICo9xKouCGrnmga+EACZaWO n/d06kn2tGAOHqL7uXd4h4bJBtXfwa6Hxj9zXqnEwMpQ7sz73lOi/l0Y0rHp39vO Htt69ymNhzJvoQ2Gbgk0a/pmcnv7SIF8i8UA8xWV3c6XAa0vg7gFrH8m7EwdXCqe jfqOHw8olx35V88rREnbGVjiwJJTf3lzAqgxXCRT15WxYyiPb2sdtn9f/oj773aa xtGKXbCekJSOAt4ukHfWiKe1K9JiXGmKtd1mVcMNYvGkjIvns/e2IiBhNsM+R2Rc t4m/ueWLeLHRpYi7khYSipIa55ghrijfHxGKFdNYGWioEgvtEP2dBS+P9KIeEvjY qKdPGyhZch0QuJBKcRdyIhfCHb8ZcLjAFJK8VX4D7uiWaaWI8Nao5oEcA+45owkX scPUKe7BOvgkGqdoOqpClzWa430SycGZPdJWwK5yjosgTIUPx2tb99cizu9jX/7b YtImcQ7lOg6Qh3BtAwyftvmw2mwGVruoa/LL0no4cR5BmN3RnuyahbIuZ/dL3d0y NEsRbny5pRjDyI7TnO3DsX9MjxICRFOImSDpUJNLv5PGlFm+rz7z8NU5HHfxRGbU zU2RT/2M2hfUy3HUkW50 =NejE -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSL / TLS compression | SPDY service|CVE-2012-4929
Rahul Kumar Singh wrote: Ok I understand, Is it mentioned somewhere in tomcat spec. That it is not being used in JSSE connector. Based on the above answer my next question: If any browser is affected with this CVE , then what happen, e.g IE-11. If user tries to open the web application from IE-11 , then what happen. Why don't you try it yourself, and report here if there is a problem that you believe may affect the Tomcat community ? 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 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 connectors. If you are using APR/Native connector, if you didn't explicitly enabled it, SPDY is disabled by default. You may disable TLS compression using APR/Native connector parameter SSLDisableCompression="true". -Ognjen - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org DISCLAIMER: --- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or NEC or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of NEC or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. . --- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: SSL / TLS compression | SPDY service|CVE-2012-4929
Ok I understand, Is it mentioned somewhere in tomcat spec. That it is not being used in JSSE connector. Based on the above answer my next question: If any browser is affected with this CVE , then what happen, e.g IE-11. If user tries to open the web application from IE-11 , then what happen. 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 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 connectors. If you are using APR/Native connector, if you didn't explicitly enabled it, SPDY is disabled by default. You may disable TLS compression using APR/Native connector parameter SSLDisableCompression="true". -Ognjen - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org DISCLAIMER: --- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or NEC or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of NEC or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. . --- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSL / TLS compression | SPDY service|CVE-2012-4929
-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 disabled because JSSE does not support it, and there is no > support for SPDY protocol on those connectors. > > If you are using APR/Native connector, if you didn't explicitly > enabled it, SPDY is disabled by default. You may disable TLS > compression using APR/Native connector parameter > SSLDisableCompression="true". +1 The Tomcat 6 documentation is a little less readable than the Tomcat 7 documentation. In Tomcat 7, the "HTTP Connector" page documents the SSLDisableCompression configuration attribute, but in Tomcat 6, you have to read the APR page: http://tomcat.apache.org/tomcat-6.0-doc/apr.html - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVFXMgAAoJEBzwKT+lPKRYZswQAINjhC7fBtfYx0I92ZblEsKF wGLT+SeEmMdH19rozRgpLRykbV8ozbJ0LI2eLbfZLIzkvl6e/xL5AJOdiAiaDurA +WDat8tGOo9O4ElQV50iBJEHTL2n6opd9YN9ub3q0qkh7VhfHQoTKpdItinpgCfh 0oLmwd9smDNCucGIz/Q9DMqoVo2TDVH223hYgllxkVdxwXwQa2YM+ZLdc7R0DZ9s bQmS24CBBzge6CfEPrYgPEkwAIHkbXvxY9T20sepA9GCE0TzQVFvoEPB8a2kqrsR lrRmkl+o3cj2Fdl5XCPD+6SF/w4GFUK5qdKt0fMPxB95MTWh2zyEk6lz8YPFq16t N37wdsvVUs1roMGyl3lVq5GNYHRH+d+jxQxP2pmx8wjOzQczTK1z4Z2nZ7bewJxt T9VB+/9Y8HDTNF8/JPafEZ9N152DnL7TZCoObMOIOQgYAgK3L0HENM6HZ8TbKmT4 uPRxGQQDTGTAkhFmHFkCh3ECWop+J5qQ+PCZciAsFOwqLt16cV9GYgB3xkKwIIol 8q5FdWoQUt3eNMlGhTbLYaJ2yuCRiA++3IkbExlWg4o4YaWsDI0kCZBxa4JuRVjv 1BcJ9+as8gP+jNZV+2WAgcfMQeptlh3B/HDi5Xl77VqDkVI2ZVMdnx7RhthPW6W1 O1jWJM5mMlheaY7zIAos =C3Tb -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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 not support it, and there is no support for SPDY protocol on those connectors. If you are using APR/Native connector, if you didn't explicitly enabled it, SPDY is disabled by default. You may disable TLS compression using APR/Native connector parameter SSLDisableCompression="true". -Ognjen - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
SSL / TLS compression | SPDY service|CVE-2012-4929
Hello Tomcat support team, Thanks for your continuous support. Problem : Security issue | CVE-2012-4929 Overview: The TLS protocol 1.2 and earlier, as used in Mozilla Firefox, Google Chrome, Qt, and other products, can encrypt compressed data without properly obfuscating the length of the unencrypted data, which allows man-in-the-middle attackers to obtain plaintext HTTP headers by observing length differences during a series of guesses in which a string in an HTTP request potentially matches an unknown string in an HTTP header, aka a "CRIME" attack. The remote service has one 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 it to retrieve cookies being passed by an application and use them to login to the application as the victim The TLS protocol encrypts compressed data without properly obfuscating the length of the unencrypted data. Successful exploitation may result in a remote attacker conducting man-in-the-middle attacks. According to our analysis seems: (No SSL compression in IE, Firefox has disabled it from V15.0 in 2012 and already disbaled in latest version of chrome).- TLS advertises the SPDY protocol earlier than version 4. Solution: Disable compression and / or the SPDY service. So how to disable compression and / or the SPDY service in tomcat6. Regards, Rahul Kumar Singh DISCLAIMER: --- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or NEC or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of NEC or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. . ---
Re: Tomcat config question: 'compression' versus 'SSLDisableCompression'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 8/9/13 12:17 PM, Mark Eggers wrote: > On 8/9/2013 8:10 AM, Mark Thomas wrote: >> 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 attacks) weak. It's not >>>>> like SSL+compression and SSL-compression+compression is >>>>> that different. >>> >>>> It didn't. The original CRIME presentation covered this >>>> topic. I fail to understand why such a fuss is being made of >>>> this re-hashing. >>> >>> I wouldn't say this constitutes a "fuss". >> >> "fuss" was a reference to how some folks are reacting to this >> "new" attack, "BREACH". First it isn't new, second it isn't (in >> my view) practical. >> >>>> The original CRIME presentation also (correctly) pointed out >>>> that any attack based on this is entirely theoretical and not >>>> currently at all practical. >>> >>> Coffee shop + XSS? Perhaps a stretch. >> >> To succeed, the attacker requires: >> >> a) The victim is using a site that uses HTTP-level compression >> on responses b) The site echoes user input in HTTP response >> bodies c) The response bodies contain a constant secret (eg. CSRF >> token) >> >> So far, not too hard. c) is a little unusual. Session IDs are >> normally in cookie headers, CSRF tokens should change on every >> request. That said, there are plenty of sites that meet a) to >> c). >> >> d) The attacker has the ability to view the victim's encrypted >> traffic. e) The attacker has the ability to cause the victim to >> send HTTP requests to the vulnerable web server. >> >> e) is where I think this attack becomes impractical. This may >> change over time but at the moment the coffee shop scenario would >> require social engineering the victim or subverting the router if >> the site mixed HTTP and HTTPS. A malicious ISP / $work sysadmin >> is another option with mixed HTTP/HTTPS. > > I was reading about the pineapple wifi mark iv the other day. It > looks to be a particularly powerful piece of pen testing equipment. > This tool in a coffee shop would probably be all you need to have a > good chance at e). > > In short, don't do banking (or other sensitive work) at a coffee > shop when the pages are a mix of HTTP and HTTPS. Lots of people will stupidly connect to any unencrypted WiFi when they are out and about. I'd say this is a fairly plausible attack vector. Note that unencrypted + encrypted traffic is not necessary. You can just look over someone's shoulder to see what bank they're using. These days in the US most people use one of only like 5 banks. (It's kind of sad.) Once you know the site that is being used, just browse there yourself and attempt to login: you can probably see what kind of authentication / session tracking is being used without tricking the target into revealing that kind of information to you via HTTP (i.e. without HTTPS). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSBRr1AAoJEBzwKT+lPKRYxHwP/2WZmt7P+gtsiZ2Qx/S+idmr xN+k/XHS4kaxWOBdo8sK3lzZYE9mB5ROtsuVYQQZ1WRJaQS0Vb09/VCJ4GnpOSFf SR9aThyAXCxnnxF2vviTZUL93Dwh0LM/HwbRGpjYy5Tns0+qXATwm1IBNK3jzarF Mvx2SOrMAGqiTEet9CqW/7yYQV31kFpLaZGiDsdJT6FM+mBG8OrVcYstBr0b6qXF LC2IILQshvHvcAUmAEDDPO8NRfgxCY+4uzY9M028DromKeliAQ7PO0KD4E3nErZZ xL5ysEgSKSahd+0a1QJRXvLccb4XRLL9GCcSP9/TvUzqbOahWUDrIHgLGJWZYAfS ql4nO2QLtVDfTdtgBUyuNQsn+AlJZHR96g/N7lHuxZU8fap5Auir8xFijWDRWrdn LfykGonHPZ75UDlOFQmMUPM/8H6AFbymw9R8ZhpbCMwEPAU/SqVARbCLAThIVQWN zrroWjVqMLdUTbdqvT3Xi9EnmXkPuszHGjqQRtVgt60MRRZ63bkM8+F2hnJGlSId VpUFi6RrK0wM4TFd2viGlW7SbSbl/vSHAPruAYzwAJvkI+g2QduW8HVV4lESyZ+T C9vVnz59BJwsokc5H3ykNCcnurkaWCBwEm70LTc9MQKlS8ICyOtKX31TugZvzPKv EiJZhuKGsOZR/+lf3ser =98t0 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat config question: 'compression' versus 'SSLDisableCompression'
On 8/9/2013 8:10 AM, Mark Thomas wrote: 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 attacks) weak. It's not like SSL+compression and SSL-compression+compression is that different. It didn't. The original CRIME presentation covered this topic. I fail to understand why such a fuss is being made of this re-hashing. I wouldn't say this constitutes a "fuss". "fuss" was a reference to how some folks are reacting to this "new" attack, "BREACH". First it isn't new, second it isn't (in my view) practical. The original CRIME presentation also (correctly) pointed out that any attack based on this is entirely theoretical and not currently at all practical. Coffee shop + XSS? Perhaps a stretch. To succeed, the attacker requires: a) The victim is using a site that uses HTTP-level compression on responses b) The site echoes user input in HTTP response bodies c) The response bodies contain a constant secret (eg. CSRF token) So far, not too hard. c) is a little unusual. Session IDs are normally in cookie headers, CSRF tokens should change on every request. That said, there are plenty of sites that meet a) to c). d) The attacker has the ability to view the victim's encrypted traffic. e) The attacker has the ability to cause the victim to send HTTP requests to the vulnerable web server. e) is where I think this attack becomes impractical. This may change over time but at the moment the coffee shop scenario would require social engineering the victim or subverting the router if the site mixed HTTP and HTTPS. A malicious ISP / $work sysadmin is another option with mixed HTTP/HTTPS. I was reading about the pineapple wifi mark iv the other day. It looks to be a particularly powerful piece of pen testing equipment. This tool in a coffee shop would probably be all you need to have a good chance at e). In short, don't do banking (or other sensitive work) at a coffee shop when the pages are a mix of HTTP and HTTPS. The point is that folks are starting to chip-away at certain aspects of TLS. Just like they did with hashing algorithms. MD5 was great when it came out. So was SSL. There's nothing wrong with looking toward the future, even if the current crop of problems aren't exactly catastrophic. Indeed. If only everyone was approaching this with the same sense of perspective. I agree the attacks will only get better / easier / more practical but right now there are some big obstacles and I don't see any obvious roots to getting over them. Mark I'm not a security person, nor do I play one online. . . . . just my two cents /mde/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat config question: 'compression' versus 'SSLDisableCompression'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 8/9/13 11:10 AM, Mark Thomas wrote: > 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 attacks) weak. It's not like >>>> SSL+compression and SSL-compression+compression is that >>>> different. >> >>> It didn't. The original CRIME presentation covered this topic. >>> I fail to understand why such a fuss is being made of this >>> re-hashing. >> >> I wouldn't say this constitutes a "fuss". > > "fuss" was a reference to how some folks are reacting to this > "new" attack, "BREACH". First it isn't new, second it isn't (in my > view) practical. Fair enough. >>> The original CRIME presentation also (correctly) pointed out >>> that any attack based on this is entirely theoretical and not >>> currently at all practical. >> >> Coffee shop + XSS? Perhaps a stretch. > > To succeed, the attacker requires: > > a) The victim is using a site that uses HTTP-level compression on > responses b) The site echoes user input in HTTP response bodies c) > The response bodies contain a constant secret (eg. CSRF token) > > So far, not too hard. c) is a little unusual. Session IDs are > normally in cookie headers, CSRF tokens should change on every > request. That said, there are plenty of sites that meet a) to c). > > d) The attacker has the ability to view the victim's encrypted > traffic. e) The attacker has the ability to cause the victim to > send HTTP requests to the vulnerable web server. > > e) is where I think this attack becomes impractical. This may > change over time but at the moment the coffee shop scenario would > require social engineering the victim or subverting the router if > the site mixed HTTP and HTTPS. A malicious ISP / $work sysadmin is > another option with mixed HTTP/HTTPS. I tend to agree: being able to both remotely monitor the victim's traffic *and* remotely-control the browser means that you already have quite a bit of control over the situation. Perhaps decrypting the SSL stream isn't the worst thing an attacker in such a position can accomplish. >> The point is that folks are starting to chip-away at certain >> aspects of TLS. Just like they did with hashing algorithms. MD5 >> was great when it came out. So was SSL. There's nothing wrong >> with looking toward the future, even if the current crop of >> problems aren't exactly catastrophic. > > Indeed. If only everyone was approaching this with the same sense > of perspective. I agree the attacks will only get better / easier / > more practical but right now there are some big obstacles and I > don't see any obvious roots to getting over them. Agreed. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSBRAUAAoJEBzwKT+lPKRYKMsP/3ye2X1m8oZGMxDfjhOxLr+B xRS1SycborjXnEhAXnGAx+U1jFDzKPWQ0AdDMd2o4NKPqS6jWJTQ37CBeXN+25y2 0+FxZKP9FwrY94qY/dCNHK70nuUda6hpcGcpWRc78swh+hUnBzB0ue52WaaWjTJH DfTPcRu1zvIeXj1zylIG4GebqKOH1+5P+NgL37+hnzoIwGmsgJ2FeVpAXELrrtZJ wOcYguKLv0NrqkAx7CvZDmtr6a4ZpZvmyXpVGJlaoi/ejmQzDvtZDOFlsBaYOMwc 4HsweP4mEi7Ms3QYBzn9naVFXr1x+saaoO75F0jnRGE9yLJXbkhGgmpLM/+arnhO /laV3ZMqHLXZYu+cmZvD/JsdL2liAaMPcwEB3c1ebFuTI8ro7+/7qlVx+H2inGew 2DIvWePjAXyKuudL8GqqHTcsbe6nrbpB41fqRyWCBSxtZwLbUfxgfjfXRQOfkX5e 88f2FmL7/BHq7YgO368rreZWx+RVze2SVv7nGm20M7LzEP6Dd2k7etca+K+KdS9L ndNs4yHAtK8328dPsCsIYwcI767Y/5qTV3UIV0Bz8YDfjSYZvDQYVlCQRHs1VA/A xisZptwRA1jZro3WrTlgzjdHfTOcxIYDaL65eZUXcjGgXB2T9YeIAfguf7PFK5wC I6LlkxLa23oMvDL7Z2+c =RJjz -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat config question: 'compression' versus 'SSLDisableCompression'
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 attacks) weak. It's not like SSL+compression >>> and SSL-compression+compression is that different. > >> It didn't. The original CRIME presentation covered this topic. I >> fail to understand why such a fuss is being made of this >> re-hashing. > > I wouldn't say this constitutes a "fuss". "fuss" was a reference to how some folks are reacting to this "new" attack, "BREACH". First it isn't new, second it isn't (in my view) practical. >> The original CRIME presentation also (correctly) pointed out that >> any attack based on this is entirely theoretical and not currently >> at all practical. > > Coffee shop + XSS? Perhaps a stretch. To succeed, the attacker requires: a) The victim is using a site that uses HTTP-level compression on responses b) The site echoes user input in HTTP response bodies c) The response bodies contain a constant secret (eg. CSRF token) So far, not too hard. c) is a little unusual. Session IDs are normally in cookie headers, CSRF tokens should change on every request. That said, there are plenty of sites that meet a) to c). d) The attacker has the ability to view the victim's encrypted traffic. e) The attacker has the ability to cause the victim to send HTTP requests to the vulnerable web server. e) is where I think this attack becomes impractical. This may change over time but at the moment the coffee shop scenario would require social engineering the victim or subverting the router if the site mixed HTTP and HTTPS. A malicious ISP / $work sysadmin is another option with mixed HTTP/HTTPS. > The point is that folks are starting to chip-away at certain aspects > of TLS. Just like they did with hashing algorithms. MD5 was great when > it came out. So was SSL. There's nothing wrong with looking toward the > future, even if the current crop of problems aren't exactly catastrophic. Indeed. If only everyone was approaching this with the same sense of perspective. I agree the attacks will only get better / easier / more practical but right now there are some big obstacles and I don't see any obvious roots to getting over them. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat config question: 'compression' versus 'SSLDisableCompression'
-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 attacks) weak. It's not like SSL+compression >> and SSL-compression+compression is that different. > > It didn't. The original CRIME presentation covered this topic. I > fail to understand why such a fuss is being made of this > re-hashing. I wouldn't say this constitutes a "fuss". > The original CRIME presentation also (correctly) pointed out that > any attack based on this is entirely theoretical and not currently > at all practical. Coffee shop + XSS? Perhaps a stretch. The point is that folks are starting to chip-away at certain aspects of TLS. Just like they did with hashing algorithms. MD5 was great when it came out. So was SSL. There's nothing wrong with looking toward the future, even if the current crop of problems aren't exactly catastrophic. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSBO5wAAoJEBzwKT+lPKRYxakP/2PXSoCBrzgvVjkKrmvOh2Ag 5IVuP5eoIVpTT/ud6d8/uYDnSVSA/OI64lFZqZDwuiu11XnMC/uxDc/O4cfbCxA4 AYu0BgY/NDPUCAyPIcjujP22oBZibvYVr9RFrTFHdtmAaVT7KiLglCUaJzxuZtt7 6/A1+y4Q5X+g40fukNtIbwW7Of3hA2KNPeWt5s6aivYaUdQDfdYfMYh+kED+JMhS HKpmaEBoj0KwOAv5iKbWaVphe+ZuFuqnLJq82GbJqWsiwQ3uykK0x/gAI9tmWe4D SwpSszi5jwyv8SAoewyNLQr0ojNlzwkftVOrBEFyijfCAhu86xPHGDn1QghFQEpg ALXn0oMQkeP7zVfxv4f2ID/u5iOtkT2O8G/jeq3jA08Ide7qi1+kNsWZyrvGS9r7 qkCoE9GayRgGKIEAS+mJLMhJ28ttJ4wvugSpsaSSNOu6CTWIY5mnlovbpPir18GN uZCKMofeIn/fHAROFiHyFudP00z/uxX8r//gCCo0rcwcXRMUS/lxHZJNjYDL+ACA QFiSWvgAlm8JWEpgF2DjckIND5ZoFvBS5KztkLlbZCeqzw9iSA/FY4r7EqfbQ0Rj Nr9yvDGONDzgUp2BwHJIcYKIB5QQnSD1JfshVn//hv7Cm7v1GoA0b71Kkb2V+3s+ wZQf5DcDObBEck5VG2qE =xEbv -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
