On 10/15/2018 2:15 AM, Jäkel, Guido wrote:
I have no experience with embedded tomcat, but it should be also straight
forward. Said that, I can't imagine the advantage of such an approach against
the currently used, which just start the Web Application Server (Jetty, Tomcat
or whatever) with th
Hi Chris,
On Fri, Oct 19, 2018 at 2:14 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Igor,
>
> On 10/16/18 17:03, Igor Cicimov wrote:
> > On Tue, Oct 16, 2018 at 8:56 PM Igor Cicimov
> > wrote:
> >
> >> Hi Jose,
> >>
> >> On
On 18/10/18 21:39, Phil Clay wrote:
> So my questions are:
> 1) Is there another way of delegating processing of certain url patterns to a
> separate threadpool?
No. Tomcat does not provide such a feature.
> 2) Is this a bug? i.e. should filterChains still be usable after doFilter
> returns
I published a video that shows the performance benefits of HTTP/2 vs
HTTP/1.1
To see just the demo, skip to 1:39 - https://youtu.be/jhqrRT4fvOA?t=99
To watch from the beginning where there is some more information about
the h2 protocol, visit https://youtu.be/jhqrRT4fvOA
h/t Jean-Frederic Cl
Hi,
On Tomcat 9.0.12, what is the recommended way of having HTTP requests sent to a
certain URL pattern be processed on a separate threadpool from all other
requests?
I have found that the HTTP Connectors can only be configured with one executor,
therefore all requests always get processed on
>
>
> > There is no jre at all any more also from openjdk
>
> There is little difference between a JRE and a JDK. One just comes
> with a compiler.
>
not really,
until java 10 we had also desktop integration
like java -jar assignments and jnlp association for starting a webstart
application
so f
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Mark,
On 10/18/18 09:09, Mark H. Wood wrote:
> On Thu, Oct 18, 2018 at 11:55:24AM +0100, M. Manna wrote:
>> Thanks a bunch Mark.
>>
>> "The correct fix is to ensure that the user agents are sending
>> specification compliant requests." - Do you me
Roger that, thanks
On Thu, Oct 18, 2018, 9:38 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Alex,
>
> On 10/18/18 11:08, Alex O'Ree wrote:
> > Basically. I start with the tomcat distro, apply my changes, then
> > zip it up
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Alex,
On 10/18/18 11:08, Alex O'Ree wrote:
> Basically. I start with the tomcat distro, apply my changes, then
> zip it up and distribute. I'm at a situation when patches are
> preferable over a complete reinstall of my product thus the
> inquiry.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Cris,
On 10/17/18 12:28, Berneburg, Cris J. - US wrote:
> Thanks Mark
>
> mt> The argument for a JRE vs a JDK is that the JDK includes mt> a
> compiler. The only reason Tomcat can run on a JRE and mt> still
> support JSPs (which require compilation
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Cris,
On 10/17/18 12:43, Berneburg, Cris J. - US wrote:
> Thanks Igal
>
> mt> OpenJDK is very close to the Oracle JDK these days. I regularly
> run mt> Tomcat's unit tests with the latest OpenJDK and have yet to
> find an mt> issue that is OpenJDK
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Johan,
On 10/15/18 17:04, Johan Compagner wrote:
> Op ma 15 okt. 2018 20:37 schreef Mark Thomas :
>
>>
>>
>> I'd be more concerned that Oracle are starting to charge for
>> production usage. That alone would be enough for me to switch to
>> OpenJ
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Igor,
On 10/16/18 17:03, Igor Cicimov wrote:
> On Tue, Oct 16, 2018 at 8:56 PM Igor Cicimov
> wrote:
>
>> Hi Jose,
>>
>> On Tue, Oct 16, 2018 at 5:52 PM Jose María Zaragoza
>> wrote:
>>
>>> Hi
>>>
>>> El mar., 16 oct. 2018 a las 1:49, Igor Cic
Basically. I start with the tomcat distro, apply my changes, then zip it
up and distribute. I'm at a situation when patches are preferable over a
complete reinstall of my product thus the inquiry. I can probably just
replace all the tomcat bits and be done with it.
On Thu, Oct 18, 2018, 8:52 AM
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Shawn,
On 10/16/18 00:00, Shawn Heisey wrote:
> On 10/15/2018 9:16 PM, Jerry Malcolm wrote:
>> I have several webapps that do a significant amount of recursive
>> loads of snippits of HTML utilizing XHR/http/ajax requests. These
>> apps are all debu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Guido,
On 10/15/18 04:15, Jäkel, Guido wrote:
> Dear Christopher,
>
> my 5ct on that: We're using Solr for years like (and together with)
> all other Webapps on Tomcat (and since some month on Wildfly) in a
> "classic" (non-cloud) setup without any
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hans,
On 10/15/18 03:17, Hans Schou wrote:
> On Fri, 12 Oct 2018 at 14:12, Mark Thomas
> wrote:
>
>>
>> For the HTTP connector processing proxied traffic originally
>> received over HTTPS you want: SSLEnabled="false" scheme="https"
>> secure="tr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Alex,
On 10/14/18 18:06, Alex O'Ree wrote:
> Is there perhaps a patch that can be applied or better yet, a list
> of jars that are were affected by this? (I'm just trying to find a
> simple way to patch a large volume of servers)
There is nothing o
On Thu, 18 Oct 2018 at 13:38, Mark Thomas wrote:
> On 18/10/18 12:17, Johan Compagner wrote:
> > how is the browser to blame for "
> > defaultMessageType=true&locale=en_US&action=[key:label.edit]"
> >
> > that url is not generated by a browser but by some software that uses a
> > browser...
>
> B
We already know that the parameter is the issue. Having to change all the
parameter i.e. refactoring code is always the answer.
The question was more about the recommended way of handling this issue
without exposing application to any specific vulnerability. I believe Mark
T has answered this alrea
On Thu, Oct 18, 2018 at 11:55:24AM +0100, M. Manna wrote:
> Thanks a bunch Mark.
>
> "The correct fix is to ensure that the user agents are sending
> specification compliant requests." - Do you mean at browser level ? If so,
> is there any specific browser/update we can use? We've checked a few
>
On 18/10/18 12:17, Johan Compagner wrote:
> how is the browser to blame for "
> defaultMessageType=true&locale=en_US&action=[key:label.edit]"
>
> that url is not generated by a browser but by some software that uses a
> browser...
Browsers these days try to be helpful and show the user the un-enc
I understand. We will use the connector patch for now. But thanks again for
sharing your thoughts. And the link to apache Confluence is really helpful!
Thanks,
On Thu, 18 Oct 2018 at 12:12, Mark Thomas wrote:
> On 18/10/18 11:55, M. Manna wrote:
> > Thanks a bunch Mark.
> >
> > "The correct fix
how is the browser to blame for "
defaultMessageType=true&locale=en_US&action=[key:label.edit]"
that url is not generated by a browser but by some software that uses a
browser...
On Thu, 18 Oct 2018 at 12:55, M. Manna wrote:
> Thanks a bunch Mark.
>
> "The correct fix is to ensure that the use
On 18/10/18 11:55, M. Manna wrote:
> Thanks a bunch Mark.
>
> "The correct fix is to ensure that the user agents are sending
> specification compliant requests." - Do you mean at browser level ? If so,
> is there any specific browser/update we can use? We've checked a few
> browsers so far (Firefo
Thanks a bunch Mark.
"The correct fix is to ensure that the user agents are sending
specification compliant requests." - Do you mean at browser level ? If so,
is there any specific browser/update we can use? We've checked a few
browsers so far (Firefox, Edge, Chrome) and none of them seem to have
can you share the full debug log ? what is the client for this SSL service
? browser or some other standalone programs
what version of JDK is being used?
On Thu, Oct 18, 2018 at 2:20 PM Sashidharan Ramamurthy <
sashidharan.ramamur...@ericsson.com> wrote:
> Any updates users of tomcat on this iss
On 18/10/18 09:52, M. Manna wrote:
> Hello,
>
> We received in error in our application after we have upgraded to 8.5.34
>
> INFO: Error parsing HTTP request header
> Note: further occurrences of HTTP header parsing errors will be logged at
> DEBUG level.
> java.lang.IllegalArgumentException: Inv
Hello,
We received in error in our application after we have upgraded to 8.5.34
INFO: Error parsing HTTP request header
Note: further occurrences of HTTP header parsing errors will be logged at
DEBUG level.
java.lang.IllegalArgumentException: Invalid character found in the request
target. The val
Any updates users of tomcat on this issue!!!
-Original Message-
From: Sashidharan Ramamurthy
Sent: Wednesday, October 17, 2018 4:22 PM
To: users@tomcat.apache.org
Subject: FW: Issue while configuring keystore/SSL for Tomcat 8.5.33
Hi Tomcat user group,
We have installed and deployed To
30 matches
Mail list logo
