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"
> >>> />
> >>>
> >>>
> >>> 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
>
Re: Initiating httpservletrequest from inside Tomcat / TomEE
This was in the spirit of one of my suggestions and probably how I would approach the problem to save them/me having to create a Tomcat request harness .. encapsulate the service in a static method and call that (cohesive). Have a super day, John On 5/8/19, Christopher Schultz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Terence and Paul, > > On 5/6/19 14:36, Terence M. Bandoian wrote: >> On 5/6/2019 10:45 AM, Paul Carter-Brown wrote: 2) Can the servlets >> you want to use be refactored so that the underlying functionality >> is exposed in a way that doesn't require any context? > > I think this is more likely to get you a satisfying solution. > > As much fun it is to watch you try to explain to John what you are > trying to do (which seems straightforward, in principle, to me), I > think you are barking up a tree which doesn't like dogs. > > Is it very important that your "work" actually be invoked via a > servlet request/response mechanism? Or can you, as Terence suggests, > call the "meat" of the service directly instead of invoking the "web > service"? > > - -chris > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlzTavcACgkQHPApP6U8 > pFifog/+O2rgZGSHOSWYXq53NOXE6aN9byqVMfG2mj+Y2Ms8wvptgW6Dt5U4Slj5 > P+mD3tzBlaQlmDyl6aaLfk8cm2lSmphNUXDv8IKi5AMxMDRBrfAVPi0t0WXIfaDC > odgE78Mnmztbb/wnCLDzeDEV+G2iDPc6Fy7n+4P1GtU82666vVBeE026Mtwi7PX/ > KwsQjwLSsNzkk0HlTXVPvC0lJeVdK4bCpk5sqhHZaDKaZvRvvR7guEXOG96ga+Xl > RhTmz4Pe5s6BUImSdXI4ycT4Q9z9P2vZhcbOBBe/oCJivYaYshYgSkjgZ5scaMby > DjP15t12SXtZiR5/K/OgCjXBFIX0ilc5Avn4bkIvBi2odf+vpaKif0z3XYujD6Ho > PIauQhKORF5Rb8zOjb3ERnWOwtgv2S5s3zx22nIRV5IpgM9666p3p3mOU4Via4lh > Eql/A+vT0nxLvoKmVXbw4eMh4c6UJKMk+e47sWbKTb9iwxLL9eyez2Co7YJLuwXr > I+WeOet8naU6y+jfJ6Z7uuJw9FAeTAuUxHj315qYcovrBdiQWDHxMCFrV5TTZVJc > oDKBkM86O82z477Ei/aSxxwF0qx9aFf8OtlzGIISkhOjIjzhY4l1ZKueMykAbEgb > IkBqN7OMrvb5ekuV0c9U61vFTZ9zcmbJiaVidOHmFvRtuMohiIQ= > =x7LQ > -END PGP SIGNATURE- > > - > 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: Initiating httpservletrequest from inside Tomcat / TomEE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Terence and Paul, On 5/6/19 14:36, Terence M. Bandoian wrote: > On 5/6/2019 10:45 AM, Paul Carter-Brown wrote: 2) Can the servlets > you want to use be refactored so that the underlying functionality > is exposed in a way that doesn't require any context? I think this is more likely to get you a satisfying solution. As much fun it is to watch you try to explain to John what you are trying to do (which seems straightforward, in principle, to me), I think you are barking up a tree which doesn't like dogs. Is it very important that your "work" actually be invoked via a servlet request/response mechanism? Or can you, as Terence suggests, call the "meat" of the service directly instead of invoking the "web service"? - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlzTavcACgkQHPApP6U8 pFifog/+O2rgZGSHOSWYXq53NOXE6aN9byqVMfG2mj+Y2Ms8wvptgW6Dt5U4Slj5 P+mD3tzBlaQlmDyl6aaLfk8cm2lSmphNUXDv8IKi5AMxMDRBrfAVPi0t0WXIfaDC odgE78Mnmztbb/wnCLDzeDEV+G2iDPc6Fy7n+4P1GtU82666vVBeE026Mtwi7PX/ KwsQjwLSsNzkk0HlTXVPvC0lJeVdK4bCpk5sqhHZaDKaZvRvvR7guEXOG96ga+Xl RhTmz4Pe5s6BUImSdXI4ycT4Q9z9P2vZhcbOBBe/oCJivYaYshYgSkjgZ5scaMby DjP15t12SXtZiR5/K/OgCjXBFIX0ilc5Avn4bkIvBi2odf+vpaKif0z3XYujD6Ho PIauQhKORF5Rb8zOjb3ERnWOwtgv2S5s3zx22nIRV5IpgM9666p3p3mOU4Via4lh Eql/A+vT0nxLvoKmVXbw4eMh4c6UJKMk+e47sWbKTb9iwxLL9eyez2Co7YJLuwXr I+WeOet8naU6y+jfJ6Z7uuJw9FAeTAuUxHj315qYcovrBdiQWDHxMCFrV5TTZVJc oDKBkM86O82z477Ei/aSxxwF0qx9aFf8OtlzGIISkhOjIjzhY4l1ZKueMykAbEgb IkBqN7OMrvb5ekuV0c9U61vFTZ9zcmbJiaVidOHmFvRtuMohiIQ= =x7LQ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
ApacheCon call for presentations, httpd content
Hi, folks. The call for presentations for ApacheCon North America closes in a little less than 6 days. The CFP is here - https://www.apachecon.com/acna19/cfp.html - and closes May 13th. Thanks! Jean-Frederic - 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
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: Fix for DBCP-518
Great, thanks a lot Mark! On Fri, May 3, 2019 at 9:42 PM Mark Thomas wrote: > On 26/04/2019 17:27, Mark Thomas wrote: > > On 24/04/2019 16:28, Lazar Kirchev wrote: > >> Hello, > >> > >> Any update on this? > > > > No specific plans but I can do an update of DBCP2, Pool2 etc for the > > next set of releases. > > I've just pushed the commits for this. It will be included in 8.5.41 > onwards. > > Mark > > > > > > Mark > > > > > >> > >> Regards, > >> Lazar > >> > >> On Tue, Apr 16, 2019 at 4:28 PM Lazar Kirchev > >> wrote: > >> > >>> Hello, > >>> > >>> Do you have any plans to get the fix for > >>> https://issues.apache.org/jira/browse/DBCP-518 in the Tomcat 8.5 > clone of > >>> the Commons DBCP? > >>> The commits with the fix are > >>> > https://github.com/apache/commons-dbcp/commit/81aea944160608838cb2d7cdfb0d9b6893a655d9 > , > >>> > >>> > https://github.com/apache/commons-dbcp/commit/3449a42bbaeed0ff5b0d07998169ff2896bf45c7 > >>> and > >>> > https://github.com/apache/commons-dbcp/commit/91f7e267e61047614751763f6c5968a1ff65f82c > >>> > >>> Regards, > >>> Lazar > >>> > >> > > > > > > - > > 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 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: Apache httpd / tomcat AJP connector(s?)
On 07/05/2019 13:37, André Warnier (tomcat) wrote:
> Hi.
>
> On 26.04.2019 18:16, Mark Thomas wrote:
>> On 24/04/2019 10:58, André Warnier (tomcat) wrote:
>>> Hi.
>>>
>>> This is somewhat of an arcane question and somewhat straddling httpd and
>>> tomcat, so if I'm on the wrong list for this, just let me know.
>>
>> Here is fine. We can always move the thread if necessary.
>>
>>> The question is : is there any particular reason why the combination
>>> mod_proxy + mod_proxy_ajp (in httpd), does not seem to follow the
>>> ProxyPreserveHost directive, when proxying something from httpd to
>>> tomcat ?
>>
>> None that I am aware of.
>>
>> I've complete a quick test with httpd 2.4.34 and Tomcat 9.0.x and I see
>> the host header is passed via AJP as expected.
>>
>> I suggest wireshark to look at what is on the wire.
>
> I haven't done a wireshark trace yet.
> But as a cheap approximation for now, I tried to use the (tomcat) Access
> Log to see what was going on, and there I hit another (but I believe
> related) issue :
>
> According to :
> http://tomcat.apache.org/tomcat-8.5-doc/config/valve.html#Access_Log_Valve
> some patterns available are :
> - %p - Local port on which this request was received.
> and
> - %{xxx}p write local (server) port (xxx==local) or remote (client) port
> (xxx=remote)
>
> So if I understand this right, "%{local}p" should print the same as
> "%p", and both should be "the local port on which this request was
> received".
When using AJP the original values as received by httpd and passed by
AJP are injected into the Tomcat request so things like redirects are
generated correctly without additional configuration.
It is one of those scenarios where things happen by "magic" which are
great when it works bur can make debugging more complicated.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Initiating httpservletrequest from inside Tomcat / TomEE
On 06/05/2019 17:47, Owen Rubel wrote:
> I didn't think that TomEE was Tomcat. Wasn't it it's own thing??? I mean
> TomEE is this separate project maintained by this up here in Seattle vs
> Tomcat which is an Apache Project.
Apache Tomcat are Apache TomEE are both Apache projects.
Apache TomEE spun out from Apache OpenEJB and is available in various
forms that each provide support for a different combination of
additional Java EE APIs.
Mark
>
> Owen Rubel
> oru...@gmail.com
>
>
> On Mon, May 6, 2019 at 9:16 AM Paul Carter-Brown
> wrote:
>
>> Hi John,
>>
>> See original request. It's pretty much a Kafka/Servlet proxy/gateway:
>>
>> I'm trying to design a Kafka consumer and producer that will run inside the
>> tomcat jvm and pick up messages off a Kafka topic and translate them into a
>> servlet request and pass it through tomcat and then when the response is
>> complete then translate it into a Kafka message and put it onto another
>> topic as a reply. This way I can reuse our existing jax-rs rest services
>> and expose them as an async api over Kafka. The idea is to make the Kafka
>> messages similar to http in that they would consist of headers and a body.
>> The body would be json.
>>
>>
>> On Mon, May 6, 2019 at 6:13 PM John Dale wrote:
>>
>>> You could try debugging the tomcat code and find out how, right after
>>> it parses the TCP request, it invokes the servlet. You can then
>>> create your own harness for tomcat code after initializing the
>>> appropriate context for the request to tomcat. I don't know off hand
>>> where in the tomcat code this cut point can be found.
>>>
>>> Is this a performance issue, or are you building a proxy?
>>>
>>> What is the problem you're trying to solve?
>>>
>>> On 5/6/19, Paul Carter-Brown wrote:
Yea, but the issue is that only works when calling in the context of a
current servlet call.
Here is the kind of problem I want to solve:
@WebServlet(name = "MyExample", urlPatterns = {"/example"},
>>> loadOnStartup =
1)
public class Example extends HttpServlet {
@PersistenceContext
private EntityManager em;
@Override
public void init(ServletConfig config) {
Thread t = new Thread(() -> {
while (true) {
try {
// Do a GET to /example/ and get the response
>> without
going out on localhost and back in
// We cant just call doGet as we want the request
>> to
flow through the servlet filters, do the entitymanager injection etc
Thread.sleep(1);
} catch (Exception e) {
}
}
});
t.start();
}
@Override
protected void doGet(HttpServletRequest req, HttpServletResponse
>>> resp)
throws ServletException, IOException {
// do stuff like use em
resp.setStatus(200);
resp.getWriter().write("Hello World");
}
}
On Mon, May 6, 2019 at 5:35 PM John Dale wrote:
> For reference, I did find this after searching "calling a servlet
> programmatically":
> https://docs.oracle.com/cd/E19146-01/819-2634/abxbn/index.html
>
> On 5/6/19, Paul Carter-Brown wrote:
>> I think we are completely missing each other. Forget sockets - that
>>> was
>> just an example. I have code running in a Tomcat App server which is
>> not
>> managed by Tomcat and is not initiated by anything within Tomcat.
>> That
> code
>> now wants to call a servlet hosted in that very same JVM. Any way to
>>> do
>> that without going out and back in on TCP?
>>
>>
>> On Mon, May 6, 2019 at 5:14 PM John Dale wrote:
>>
>>> Sockets are an implementation of TCP/UDP inherently.
>>>
>>> Perhaps a mountaintop signal fire?
>>>
>>> ;)
>>>
>>> John
>>>
>>>
>>> On 5/6/19, Paul Carter-Brown wrote:
lol on the Semaphore Telegraph,
I can't use a request dispatcher as the request is being
>> initiated
> from
code that has no context. I already have it working with HTTP
>> using
asynchttp library, but I want to avoid the overhead. E.g. lets
>> say
>>> I
>>> wrote
my own server socket listener on port 1 running in the Tomcat
JVM
and
got some request in some propriatary protocol called X. Now I
>> want
to
>>> call
a Tomcat servlet in the current JVM with some info I got over X
> without
going out on TCP and back in
On Mon, May 6, 2019 at 4:40 PM John Dale
>>> wrote:
> If you're wanting to forward control to another servlet deployed
>>> in
> the same context:
> https://www.javatpoint.com/requestdispatcher-in-servlet
>
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
