[Bug 64762] CoyoteInputStream getInputStream() read (wait after premature end and the rest comes)
https://bz.apache.org/bugzilla/show_bug.cgi?id=64762
--- Comment #11 from Ralf Hauser ---
The problem still persists, albeit we were able to almost make it disappear
We no longer wait a limited amount of sleep iterations, but "forever" (provided
the browser declares "content-length").
Reasoning: we are on a quick fiber network and most of the affected users
normally are on arbitrary (slow) home-office networks and only experience it
intermittently.
So if we don't wait forever, they will see an error, so we better wait until
their browser-timeout anyway and hopefully get the last expected packets before
that happens.
Another strange, but also locally reproduceable phenomenon is that normally
HttpsServletRequest request.getAttribute("javax.servlet.forward.request_uri")
is not null, but under certain circumstances it is null.
In this case request.getRequestURI() which eventually gets to
org.apache.coyote.Request.requestURI() still has the value sought.
Further analysis show that if HttpsServletRequest is instantiated by
org.apache.catalina.core.ApplicationHttpRequest the attribute has a value but
if it is rg.apache.catalina.connector.Request (inside
org.apache.catalina.connector.RequestFacade), all its source of attributes are
empty (specialAttributes, attributes, coyoteRequest.getAttribute()) i.e. null
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
feature request: reload SSL certificate automatically after X days (configuration option)
Hi guys, *Shortly*: Tomcat should have either Connector or SSLHostConfig option to automatically reload certificate from the same file after X days, i.e. reloadAfterDays=10 to force Tomcat to reload the certificate automatically after 10 days. *Long*: SSL certificates have a period of expiration and in the case of Letsencrypt, it's set to 3 months as they think everyone should have the renewal mechanism automatically. As the Letsencrypt is the most popular SSL issuing authority (source: https://trends.builtwith.com/ssl/LetsEncrypt ), I think Tomcat should have an integration with Letsencrypt working flawlessly. We are currently using the script to renew the certificate (I can share our integration details with whoever is interested, please email me if you are interested), but it's restarting Tomcat. As Tomcat shall not be restarted ever (ideally), I think Tomcat should have an option to reload certificate, without a dependency to Tomcat source code and "hacks" like some available on StackOverflow: https://stackoverflow.com/questions/5816239/how-do-i-force-tomcat-to-reload-trusted-certificates). Those hacks are no good as: 1) code to reload certificate should not run inside Java code, as letsencrypt is invoked through Linux 2) each application uses that Stackoverflow hack have additional compile and run dependency set to Tomcat (which is very bad). I have a proposal on how this should be fixed: Tomcat should have a server.xml options something like certificateReloadAfterDays or reloadAfterDays I see this is moved to SSLHostConfig, we are still using old params. Do you agree on this feature? If so... I'm not lazy to try to do it myself, but as I haven't ever written Tomcat code neither know procedures (I have been coding professionally since 2006, but I never committed to Maven or Git project before, lol), is there someone else who is keen on doing this feature?
Re: feature request: reload SSL certificate automatically after X days (configuration option)
Mladen, On 12/19/20 05:12, Mladen Adamović wrote: Hi guys, *Shortly*: Tomcat should have either Connector or SSLHostConfig option to automatically reload certificate from the same file after X days, i.e. reloadAfterDays=10 to force Tomcat to reload the certificate automatically after 10 days. Why not use cron? You can do this with a single "curl" command and the Manager+JMXProxyServlet. *Long*: SSL certificates have a period of expiration and in the case of Letsencrypt, it's set to 3 months as they think everyone should have the renewal mechanism automatically. As the Letsencrypt is the most popular SSL issuing authority (source: https://trends.builtwith.com/ssl/LetsEncrypt ), I think Tomcat should have an integration with Letsencrypt working flawlessly. We are currently using the script to renew the certificate (I can share our integration details with whoever is interested, please email me if you are interested), but it's restarting Tomcat. As Tomcat shall not be restarted ever (ideally), I think Tomcat should have an option to reload certificate, without a dependency to Tomcat source code and "hacks" like some available on StackOverflow: https://stackoverflow.com/questions/5816239/how-do-i-force-tomcat-to-reload-trusted-certificates). Those hacks are no good as: 1) code to reload certificate should not run inside Java code, as letsencrypt is invoked through Linux 2) each application uses that Stackoverflow hack have additional compile and run dependency set to Tomcat (which is very bad). I have a proposal on how this should be fixed: Tomcat should have a server.xml options something like certificateReloadAfterDays or reloadAfterDays I see this is moved to SSLHostConfig, we are still using old params. Do you agree on this feature? If so... I'm not lazy to try to do it myself, but as I haven't ever written Tomcat code neither know procedures (I have been coding professionally since 2006, but I never committed to Maven or Git project before, lol), is there someone else who is keen on doing this feature? Have a look at this: http://tomcat.apache.org/presentations.html#latest-lets-encrypt -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: feature request: reload SSL certificate automatically after X days (configuration option)
On Sat, Dec 19, 2020 at 2:29 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:
> Why not use cron? You can do this with a single "curl" command and the
> Manager+JMXProxyServlet.
>
We are not using Tomcat manager app.
Why someone should be forced to use Manager, to read/setup the
documentation regarding JMXProxyServlet, create an additional
servlet (where does it have dependency on?) only to reload automatically
certificates?
I'm proposing a solution with the simple SSLHostConfig parameter. It's a
user friendly. Simple, intuitive.
No need for using manager, no need to create a specific servlet somewhere
in your code. Just a single server.xml argument.
Also, *another idea*, I'm contributing this code (see below) we are using
for Letsencrypt ACME challenge.
Tomcat could also have an option, i.e. in web.xml to automatically support
Letsencrypt ACME challenge.
Idea for web.xml
Letsencrypt-acme
org.apache.catalina.servlets.LetsencryptAcmeChallenge
etc.
We are using
@WebServlet(name = "LetsencryptAcmeChallenge", urlPatterns =
{"/.well-known/acme-challenge/*"})
public class LetsencryptAcmeChallenge extends HttpServlet {
/**
* Processes requests for both HTTP GET and
POST methods.
*
* @param request servlet request
* @param response servlet response
* @throws ServletException if a servlet-specific error occurs
* @throws IOException if an I/O error occurs
*/
protected void processRequest(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
String requestUrl = request.getRequestURL().toString();
if (requestUrl.contains(".well-known/acme-challenge/")) {
int indexFilename = requestUrl.lastIndexOf("/") + 1;
boolean wasError = true;
if (indexFilename > 0 && indexFilename < requestUrl.length()) {
String filename = requestUrl.substring(indexFilename);
File existingFile = new
File("/tmp/letsencrypt/public_html/.well-known/acme-challenge/" +
filename);
if (existingFile.exists()) {
response.setContentType("text/plain");
OutputStream out = response.getOutputStream();
FileInputStream in = new FileInputStream(existingFile);
FilesOperations.inputStreamToOutputStream(in, out);
wasError = false;
}
}
if (wasError) {
throw new ServletException("invalid requestUrl " + requestUrl);
}
}
from FilesOperations:
public static void inputStreamToOutputStream(InputStream in,
OutputStream out) throws IOException {
try {
byte[ ] buf = new byte[32 * 1024]; // 32K buffer
int bytesRead;
while ((bytesRead = in.read(buf)) != -1) {
out.write(buf, 0, bytesRead);
}
} finally {
if (in != null) {
in.close();
out.close();
}
}
}
> > *Long*:
> > SSL certificates have a period of expiration and in the case of
> > Letsencrypt, it's set to 3 months as they think everyone should have the
> > renewal mechanism automatically.
> >
> > As the Letsencrypt is the most popular SSL issuing authority (source:
> > https://trends.builtwith.com/ssl/LetsEncrypt ), I think Tomcat should
> have
> > an integration with Letsencrypt working flawlessly.
> >
> > We are currently using the script to renew the certificate (I can share
> our
> > integration details with whoever is interested, please email me if you
> are
> > interested), but it's restarting Tomcat.
> >
> > As Tomcat shall not be restarted ever (ideally), I think Tomcat should
> have
> > an option to reload certificate, without a dependency to Tomcat source
> code
> > and "hacks" like some available on StackOverflow:
> >
> https://stackoverflow.com/questions/5816239/how-do-i-force-tomcat-to-reload-trusted-certificates
> ).
> > Those hacks are no good as:
> > 1) code to reload certificate should not run inside Java code, as
> > letsencrypt is invoked through Linux
> > 2) each application uses that Stackoverflow hack have additional compile
> > and run dependency set to Tomcat (which is very bad).
> >
> > I have a proposal on how this should be fixed: Tomcat should have a
> > server.xml options something like certificateReloadAfterDays or
> > reloadAfterDays
> >
> > I see this is moved to SSLHostConfig, we are still using old params.
> >
> > Do you agree on this feature?
> >
> > If so... I'm not lazy to try to do it myself, but as I haven't ever
> written
> > Tomcat code neither know procedures (I have been coding professionally
> > since 2006, but I never committed to Maven or Git project before, lol),
> is
> > there someone else who is keen on doing this feature?
>
> Have a look at this:
> http://tomcat.apache.org/presentations.html#latest-lets-encrypt
>
> -chris
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional
Re: feature request: reload SSL certificate automatically after X days (configuration option)
https://github.com/apache/openwebbeans-meecrowave/tree/master/meecrowave-letsencrypt/src/main/java/org/apache/meecrowave/letencrypt
should be reusable just dropping the few references to meeceowave and
replacing it by valve or listener config in server.xml.
It sounds saner than a random reload N days since it can reload when the
cert changes.
Le sam. 19 déc. 2020 à 15:24, Mladen Adamović a
écrit :
> On Sat, Dec 19, 2020 at 2:29 PM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
> > Why not use cron? You can do this with a single "curl" command and the
> > Manager+JMXProxyServlet.
> >
>
> We are not using Tomcat manager app.
>
> Why someone should be forced to use Manager, to read/setup the
> documentation regarding JMXProxyServlet, create an additional
> servlet (where does it have dependency on?) only to reload automatically
> certificates?
>
> I'm proposing a solution with the simple SSLHostConfig parameter. It's a
> user friendly. Simple, intuitive.
> No need for using manager, no need to create a specific servlet somewhere
> in your code. Just a single server.xml argument.
>
> Also, *another idea*, I'm contributing this code (see below) we are using
> for Letsencrypt ACME challenge.
> Tomcat could also have an option, i.e. in web.xml to automatically support
> Letsencrypt ACME challenge.
> Idea for web.xml
>
> Letsencrypt-acme
>
>
> org.apache.catalina.servlets.LetsencryptAcmeChallenge
>
> etc.
>
>
>
> We are using
> @WebServlet(name = "LetsencryptAcmeChallenge", urlPatterns =
> {"/.well-known/acme-challenge/*"})
> public class LetsencryptAcmeChallenge extends HttpServlet {
>
> /**
>* Processes requests for both HTTP GET and
> POST methods.
>*
>* @param request servlet request
>* @param response servlet response
>* @throws ServletException if a servlet-specific error occurs
>* @throws IOException if an I/O error occurs
>*/
> protected void processRequest(HttpServletRequest request,
> HttpServletResponse response)
> throws ServletException, IOException {
> String requestUrl = request.getRequestURL().toString();
> if (requestUrl.contains(".well-known/acme-challenge/")) {
> int indexFilename = requestUrl.lastIndexOf("/") + 1;
> boolean wasError = true;
> if (indexFilename > 0 && indexFilename < requestUrl.length()) {
> String filename = requestUrl.substring(indexFilename);
> File existingFile = new
> File("/tmp/letsencrypt/public_html/.well-known/acme-challenge/" +
> filename);
> if (existingFile.exists()) {
> response.setContentType("text/plain");
> OutputStream out = response.getOutputStream();
> FileInputStream in = new FileInputStream(existingFile);
> FilesOperations.inputStreamToOutputStream(in, out);
> wasError = false;
> }
> }
> if (wasError) {
> throw new ServletException("invalid requestUrl " + requestUrl);
> }
> }
>
> from FilesOperations:
> public static void inputStreamToOutputStream(InputStream in,
> OutputStream out) throws IOException {
> try {
> byte[ ] buf = new byte[32 * 1024]; // 32K buffer
> int bytesRead;
> while ((bytesRead = in.read(buf)) != -1) {
> out.write(buf, 0, bytesRead);
> }
> } finally {
> if (in != null) {
> in.close();
> out.close();
> }
> }
> }
>
>
>
>
>
>
>
>
> > > *Long*:
> > > SSL certificates have a period of expiration and in the case of
> > > Letsencrypt, it's set to 3 months as they think everyone should have
> the
> > > renewal mechanism automatically.
> > >
> > > As the Letsencrypt is the most popular SSL issuing authority (source:
> > > https://trends.builtwith.com/ssl/LetsEncrypt ), I think Tomcat should
> > have
> > > an integration with Letsencrypt working flawlessly.
> > >
> > > We are currently using the script to renew the certificate (I can share
> > our
> > > integration details with whoever is interested, please email me if you
> > are
> > > interested), but it's restarting Tomcat.
> > >
> > > As Tomcat shall not be restarted ever (ideally), I think Tomcat should
> > have
> > > an option to reload certificate, without a dependency to Tomcat source
> > code
> > > and "hacks" like some available on StackOverflow:
> > >
> >
> https://stackoverflow.com/questions/5816239/how-do-i-force-tomcat-to-reload-trusted-certificates
> > ).
> > > Those hacks are no good as:
> > > 1) code to reload certificate should not run inside Java code, as
> > > letsencrypt is invoked through Linux
> > > 2) each application uses that Stackoverflow hack have additional
> compile
> > > and run dependency set to Tomcat (which is very bad).
> > >
> > > I have a proposal on how this should be fixed: Tomcat should have a
> > > server.xml options something like certificateReloadAfterDays or
> > > reloadAfterDays
> > >
> > > I se
Re: feature request: reload SSL certificate automatically after X days (configuration option)
On Sat, Dec 19, 2020 at 4:25 PM Romain Manni-Bucau
wrote:
> It sounds saner than a random reload N days since it can reload when the
> cert changes.
>
Hi Romain,
BTW, Letsencrypt always creates a new file:
i.e.
lrwxrwxrwx 1 root root 35 Dec 1 01:05 cert.pem -> ../../archive/
numbeo.com/cert53.pem
so random reloads should be fine AFAIK.
However, if it's possible to have even more nature and easier integration
with Letsencrypt that would be even nicer.
I did go briefly through your code, there are many places I currently don't
understand.
Ideally, users want Tomcat listed here: https://certbot.eff.org/ as a fully
supported server.
>
> Le sam. 19 déc. 2020 à 15:24, Mladen Adamović
> a
> écrit :
>
> > On Sat, Dec 19, 2020 at 2:29 PM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > > Why not use cron? You can do this with a single "curl" command and the
> > > Manager+JMXProxyServlet.
> > >
> >
> > We are not using Tomcat manager app.
> >
> > Why someone should be forced to use Manager, to read/setup the
> > documentation regarding JMXProxyServlet, create an additional
> > servlet (where does it have dependency on?) only to reload automatically
> > certificates?
> >
> > I'm proposing a solution with the simple SSLHostConfig parameter. It's a
> > user friendly. Simple, intuitive.
> > No need for using manager, no need to create a specific servlet somewhere
> > in your code. Just a single server.xml argument.
> >
> > Also, *another idea*, I'm contributing this code (see below) we are using
> > for Letsencrypt ACME challenge.
> > Tomcat could also have an option, i.e. in web.xml to automatically
> support
> > Letsencrypt ACME challenge.
> > Idea for web.xml
> >
> > Letsencrypt-acme
> >
> >
> >
> org.apache.catalina.servlets.LetsencryptAcmeChallenge
> >
> > etc.
> >
> >
> >
> > We are using
> > @WebServlet(name = "LetsencryptAcmeChallenge", urlPatterns =
> > {"/.well-known/acme-challenge/*"})
> > public class LetsencryptAcmeChallenge extends HttpServlet {
> >
> > /**
> >* Processes requests for both HTTP GET and
> > POST methods.
> >*
> >* @param request servlet request
> >* @param response servlet response
> >* @throws ServletException if a servlet-specific error occurs
> >* @throws IOException if an I/O error occurs
> >*/
> > protected void processRequest(HttpServletRequest request,
> > HttpServletResponse response)
> > throws ServletException, IOException {
> > String requestUrl = request.getRequestURL().toString();
> > if (requestUrl.contains(".well-known/acme-challenge/")) {
> > int indexFilename = requestUrl.lastIndexOf("/") + 1;
> > boolean wasError = true;
> > if (indexFilename > 0 && indexFilename < requestUrl.length()) {
> > String filename = requestUrl.substring(indexFilename);
> > File existingFile = new
> > File("/tmp/letsencrypt/public_html/.well-known/acme-challenge/" +
> > filename);
> > if (existingFile.exists()) {
> > response.setContentType("text/plain");
> > OutputStream out = response.getOutputStream();
> > FileInputStream in = new FileInputStream(existingFile);
> > FilesOperations.inputStreamToOutputStream(in, out);
> > wasError = false;
> > }
> > }
> > if (wasError) {
> > throw new ServletException("invalid requestUrl " + requestUrl);
> > }
> > }
> >
> > from FilesOperations:
> > public static void inputStreamToOutputStream(InputStream in,
> > OutputStream out) throws IOException {
> > try {
> > byte[ ] buf = new byte[32 * 1024]; // 32K buffer
> > int bytesRead;
> > while ((bytesRead = in.read(buf)) != -1) {
> > out.write(buf, 0, bytesRead);
> > }
> > } finally {
> > if (in != null) {
> > in.close();
> > out.close();
> > }
> > }
> > }
> >
> >
> >
> >
> >
> >
> >
> >
> > > > *Long*:
> > > > SSL certificates have a period of expiration and in the case of
> > > > Letsencrypt, it's set to 3 months as they think everyone should have
> > the
> > > > renewal mechanism automatically.
> > > >
> > > > As the Letsencrypt is the most popular SSL issuing authority (source:
> > > > https://trends.builtwith.com/ssl/LetsEncrypt ), I think Tomcat
> should
> > > have
> > > > an integration with Letsencrypt working flawlessly.
> > > >
> > > > We are currently using the script to renew the certificate (I can
> share
> > > our
> > > > integration details with whoever is interested, please email me if
> you
> > > are
> > > > interested), but it's restarting Tomcat.
> > > >
> > > > As Tomcat shall not be restarted ever (ideally), I think Tomcat
> should
> > > have
> > > > an option to reload certificate, without a dependency to Tomcat
> source
> > > code
> > > > and "hacks" like some available on StackOverflow:
> > > >
> > >
> >
> https://st
Re: feature request: reload SSL certificate automatically after X days (configuration option)
Le sam. 19 déc. 2020 à 16:43, Mladen Adamović a
écrit :
> On Sat, Dec 19, 2020 at 4:25 PM Romain Manni-Bucau
> wrote:
>
> > It sounds saner than a random reload N days since it can reload when the
> > cert changes.
> >
>
> Hi Romain,
> BTW, Letsencrypt always creates a new file:
> i.e.
> lrwxrwxrwx 1 root root 35 Dec 1 01:05 cert.pem -> ../../archive/
> numbeo.com/cert53.pem
> so random reloads should be fine AFAIK.
>
If rotation is long enough yes otherwise no so depends the letzencrypt and
cron setup.
In several cases you can end up having an expired cert for some time.
> However, if it's possible to have even more nature and easier integration
> with Letsencrypt that would be even nicer.
> I did go briefly through your code, there are many places I currently don't
> understand.
>
Code can likely be simplified but high level it is just about enabling
letsencrypt http dance thanks a valve and reloading the cert on update.
Note that acme client is easy to recode to avoid any licensing work so it
vould be a tomcat-letsencrypt module easily IMHO.
> Ideally, users want Tomcat listed here: https://certbot.eff.org/ as a
> fully
> supported server.
>
>
>
>
>
>
> >
> > Le sam. 19 déc. 2020 à 15:24, Mladen Adamović >
> > a
> > écrit :
> >
> > > On Sat, Dec 19, 2020 at 2:29 PM Christopher Schultz <
> > > ch...@christopherschultz.net> wrote:
> > >
> > > > Why not use cron? You can do this with a single "curl" command and
> the
> > > > Manager+JMXProxyServlet.
> > > >
> > >
> > > We are not using Tomcat manager app.
> > >
> > > Why someone should be forced to use Manager, to read/setup the
> > > documentation regarding JMXProxyServlet, create an additional
> > > servlet (where does it have dependency on?) only to reload
> automatically
> > > certificates?
> > >
> > > I'm proposing a solution with the simple SSLHostConfig parameter. It's
> a
> > > user friendly. Simple, intuitive.
> > > No need for using manager, no need to create a specific servlet
> somewhere
> > > in your code. Just a single server.xml argument.
> > >
> > > Also, *another idea*, I'm contributing this code (see below) we are
> using
> > > for Letsencrypt ACME challenge.
> > > Tomcat could also have an option, i.e. in web.xml to automatically
> > support
> > > Letsencrypt ACME challenge.
> > > Idea for web.xml
> > >
> > > Letsencrypt-acme
> > >
> > >
> > >
> >
> org.apache.catalina.servlets.LetsencryptAcmeChallenge
> > >
> > > etc.
> > >
> > >
> > >
> > > We are using
> > > @WebServlet(name = "LetsencryptAcmeChallenge", urlPatterns =
> > > {"/.well-known/acme-challenge/*"})
> > > public class LetsencryptAcmeChallenge extends HttpServlet {
> > >
> > > /**
> > >* Processes requests for both HTTP GET and
> > > POST methods.
> > >*
> > >* @param request servlet request
> > >* @param response servlet response
> > >* @throws ServletException if a servlet-specific error occurs
> > >* @throws IOException if an I/O error occurs
> > >*/
> > > protected void processRequest(HttpServletRequest request,
> > > HttpServletResponse response)
> > > throws ServletException, IOException {
> > > String requestUrl = request.getRequestURL().toString();
> > > if (requestUrl.contains(".well-known/acme-challenge/")) {
> > > int indexFilename = requestUrl.lastIndexOf("/") + 1;
> > > boolean wasError = true;
> > > if (indexFilename > 0 && indexFilename < requestUrl.length()) {
> > > String filename = requestUrl.substring(indexFilename);
> > > File existingFile = new
> > > File("/tmp/letsencrypt/public_html/.well-known/acme-challenge/" +
> > > filename);
> > > if (existingFile.exists()) {
> > > response.setContentType("text/plain");
> > > OutputStream out = response.getOutputStream();
> > > FileInputStream in = new FileInputStream(existingFile);
> > > FilesOperations.inputStreamToOutputStream(in, out);
> > > wasError = false;
> > > }
> > > }
> > > if (wasError) {
> > > throw new ServletException("invalid requestUrl " + requestUrl);
> > > }
> > > }
> > >
> > > from FilesOperations:
> > > public static void inputStreamToOutputStream(InputStream in,
> > > OutputStream out) throws IOException {
> > > try {
> > > byte[ ] buf = new byte[32 * 1024]; // 32K buffer
> > > int bytesRead;
> > > while ((bytesRead = in.read(buf)) != -1) {
> > > out.write(buf, 0, bytesRead);
> > > }
> > > } finally {
> > > if (in != null) {
> > > in.close();
> > > out.close();
> > > }
> > > }
> > > }
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > > > *Long*:
> > > > > SSL certificates have a period of expiration and in the case of
> > > > > Letsencrypt, it's set to 3 months as they think everyone should
> have
> > > the
> > > > > renewal mechanism aut
Re: feature request: reload SSL certificate automatically after X days (configuration option)
On Sat, Dec 19, 2020 at 5:06 PM Romain Manni-Bucau
wrote:
> Code can likely be simplified but high level it is just about enabling
> letsencrypt http dance thanks a valve and reloading the cert on update.
>
> Note that acme client is easy to recode to avoid any licensing work so it
> vould be a tomcat-letsencrypt module easily IMHO.
>
Thinking more about this problem... instead of this reload SSL
configuration feature, we need fully integrated support for Letsencrypt.
On a side note, Tomcat might be lacking a command line manager utility,
having manager running on a port sounds... like we are people who avoid a
command line, no?
Although I managed my own way of integration, and wrote my own ACME client,
I don't know yet what Tomcat needs to do to be fully Letsencrypt
integrated.
Are there someone currently working on easy letsencrypt integration?
If not, Romain (or others who are reading this thread), are there existing
devs who want to do it?
I'm ready to join, if someone wants the assistance, but it would probably
be helpful not to duplicate efforts.
The question to project maintainers: would be interested in reviewing that
code for inclusion in the codebase?
(I'm not sure yet how it goes, I'm new here. Certainly, the fact that I
never contributed code to the open-source project which wasn't started by
me doesn't help).
>
>
> > Ideally, users want Tomcat listed here: https://certbot.eff.org/ as a
> > fully
> > supported server.
> >
> >
> >
> >
> >
> >
> > >
> > > Le sam. 19 déc. 2020 à 15:24, Mladen Adamović <
> mladen.adamo...@gmail.com
> > >
> > > a
> > > écrit :
> > >
> > > > On Sat, Dec 19, 2020 at 2:29 PM Christopher Schultz <
> > > > ch...@christopherschultz.net> wrote:
> > > >
> > > > > Why not use cron? You can do this with a single "curl" command and
> > the
> > > > > Manager+JMXProxyServlet.
> > > > >
> > > >
> > > > We are not using Tomcat manager app.
> > > >
> > > > Why someone should be forced to use Manager, to read/setup the
> > > > documentation regarding JMXProxyServlet, create an additional
> > > > servlet (where does it have dependency on?) only to reload
> > automatically
> > > > certificates?
> > > >
> > > > I'm proposing a solution with the simple SSLHostConfig parameter.
> It's
> > a
> > > > user friendly. Simple, intuitive.
> > > > No need for using manager, no need to create a specific servlet
> > somewhere
> > > > in your code. Just a single server.xml argument.
> > > >
> > > > Also, *another idea*, I'm contributing this code (see below) we are
> > using
> > > > for Letsencrypt ACME challenge.
> > > > Tomcat could also have an option, i.e. in web.xml to automatically
> > > support
> > > > Letsencrypt ACME challenge.
> > > > Idea for web.xml
> > > >
> > > > Letsencrypt-acme
> > > >
> > > >
> > > >
> > >
> >
> org.apache.catalina.servlets.LetsencryptAcmeChallenge
> > > >
> > > > etc.
> > > >
> > > >
> > > >
> > > > We are using
> > > > @WebServlet(name = "LetsencryptAcmeChallenge", urlPatterns =
> > > > {"/.well-known/acme-challenge/*"})
> > > > public class LetsencryptAcmeChallenge extends HttpServlet {
> > > >
> > > > /**
> > > >* Processes requests for both HTTP GET and
> > > > POST methods.
> > > >*
> > > >* @param request servlet request
> > > >* @param response servlet response
> > > >* @throws ServletException if a servlet-specific error occurs
> > > >* @throws IOException if an I/O error occurs
> > > >*/
> > > > protected void processRequest(HttpServletRequest request,
> > > > HttpServletResponse response)
> > > > throws ServletException, IOException {
> > > > String requestUrl = request.getRequestURL().toString();
> > > > if (requestUrl.contains(".well-known/acme-challenge/")) {
> > > > int indexFilename = requestUrl.lastIndexOf("/") + 1;
> > > > boolean wasError = true;
> > > > if (indexFilename > 0 && indexFilename < requestUrl.length()) {
> > > > String filename = requestUrl.substring(indexFilename);
> > > > File existingFile = new
> > > > File("/tmp/letsencrypt/public_html/.well-known/acme-challenge/" +
> > > > filename);
> > > > if (existingFile.exists()) {
> > > > response.setContentType("text/plain");
> > > > OutputStream out = response.getOutputStream();
> > > > FileInputStream in = new FileInputStream(existingFile);
> > > > FilesOperations.inputStreamToOutputStream(in, out);
> > > > wasError = false;
> > > > }
> > > > }
> > > > if (wasError) {
> > > > throw new ServletException("invalid requestUrl " +
> requestUrl);
> > > > }
> > > > }
> > > >
> > > > from FilesOperations:
> > > > public static void inputStreamToOutputStream(InputStream in,
> > > > OutputStream out) throws IOException {
> > > > try {
> > > > byte[ ] buf = new byte[32 * 1024]; // 32K buffer
> > > > int bytesRead;
> > > > while ((bytesRead =
Re: feature request: reload SSL certificate automatically after X days (configuration option)
Le sam. 19 déc. 2020 à 17:34, Mladen Adamović a
écrit :
> On Sat, Dec 19, 2020 at 5:06 PM Romain Manni-Bucau
> wrote:
>
> > Code can likely be simplified but high level it is just about enabling
> > letsencrypt http dance thanks a valve and reloading the cert on update.
> >
> > Note that acme client is easy to recode to avoid any licensing work so it
> > vould be a tomcat-letsencrypt module easily IMHO.
> >
>
>
> Thinking more about this problem... instead of this reload SSL
> configuration feature, we need fully integrated support for Letsencrypt.
>
+1
>
> On a side note, Tomcat might be lacking a command line manager utility,
> having manager running on a port sounds... like we are people who avoid a
> command line, no?
>
It moves the problem elsewhere, how would the CLI communicate with tomcat?
JMX, HTTP uses a port, a file based communication would be probably worse
because of perms and other admin issues (and just not working in k8s).
Personally I think today it is not really an issue because typically it is
either automatic or it is not due to the deployers/schedulers we use today
(k8s the first one);
>
> Although I managed my own way of integration, and wrote my own ACME client,
> I don't know yet what Tomcat needs to do to be fully Letsencrypt
> integrated.
>
Think what is in meecrowave is more or less what is needed - except the
config which is not "tomcat spirit". Main issue is: will known folder be
publicly available or hidden behind a proxy preventing the integration to
work?
But I guess a default integration module can assume it is available.
>
> Are there someone currently working on easy letsencrypt integration?
> If not, Romain (or others who are reading this thread), are there existing
> devs who want to do it?
> I'm ready to join, if someone wants the assistance, but it would probably
> be helpful not to duplicate efforts.
>
Not active but happy to help if needed. In particular to get a HTTP lets
encrypt client not using acme client (plain java 11 client or even http url
connection if java 8 is required for this module).
>
> The question to project maintainers: would be interested in reviewing that
> code for inclusion in the codebase?
> (I'm not sure yet how it goes, I'm new here. Certainly, the fact that I
> never contributed code to the open-source project which wasn't started by
> me doesn't help).
>
Side note: worse case it could fit meecrowave module. Just means making an
abstract class and 2 subclasses with configuration 1. tomcat style 2.
meecrowave style. Just an idea but can be a home for that module if tomcat
is not.
>
>
>
>
>
>
> >
> >
> > > Ideally, users want Tomcat listed here: https://certbot.eff.org/ as a
> > > fully
> > > supported server.
> > >
> > >
> > >
> > >
> > >
> > >
> > > >
> > > > Le sam. 19 déc. 2020 à 15:24, Mladen Adamović <
> > mladen.adamo...@gmail.com
> > > >
> > > > a
> > > > écrit :
> > > >
> > > > > On Sat, Dec 19, 2020 at 2:29 PM Christopher Schultz <
> > > > > ch...@christopherschultz.net> wrote:
> > > > >
> > > > > > Why not use cron? You can do this with a single "curl" command
> and
> > > the
> > > > > > Manager+JMXProxyServlet.
> > > > > >
> > > > >
> > > > > We are not using Tomcat manager app.
> > > > >
> > > > > Why someone should be forced to use Manager, to read/setup the
> > > > > documentation regarding JMXProxyServlet, create an additional
> > > > > servlet (where does it have dependency on?) only to reload
> > > automatically
> > > > > certificates?
> > > > >
> > > > > I'm proposing a solution with the simple SSLHostConfig parameter.
> > It's
> > > a
> > > > > user friendly. Simple, intuitive.
> > > > > No need for using manager, no need to create a specific servlet
> > > somewhere
> > > > > in your code. Just a single server.xml argument.
> > > > >
> > > > > Also, *another idea*, I'm contributing this code (see below) we are
> > > using
> > > > > for Letsencrypt ACME challenge.
> > > > > Tomcat could also have an option, i.e. in web.xml to automatically
> > > > support
> > > > > Letsencrypt ACME challenge.
> > > > > Idea for web.xml
> > > > >
> > > > > Letsencrypt-acme
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.catalina.servlets.LetsencryptAcmeChallenge
> > > > >
> > > > > etc.
> > > > >
> > > > >
> > > > >
> > > > > We are using
> > > > > @WebServlet(name = "LetsencryptAcmeChallenge", urlPatterns =
> > > > > {"/.well-known/acme-challenge/*"})
> > > > > public class LetsencryptAcmeChallenge extends HttpServlet {
> > > > >
> > > > > /**
> > > > >* Processes requests for both HTTP GET and
> > > > > POST methods.
> > > > >*
> > > > >* @param request servlet request
> > > > >* @param response servlet response
> > > > >* @throws ServletException if a servlet-specific error occurs
> > > > >* @throws IOException if an I/O error occurs
> > > > >*/
> > > > > protected void processRequest(HttpServletRequest request,
> > > > > HttpServletResponse response)
>
Re: [OT] feature request: reload SSL certificate automatically after X days (configuration option)
Mladen, On 12/19/20 11:33, Mladen Adamović wrote: On Sat, Dec 19, 2020 at 5:06 PM Romain Manni-Bucau wrote: On a side note, Tomcat might be lacking a command line manager utility, having manager running on a port sounds... like we are people who avoid a command line, no? There is a command-line manager: it's called curl and you use it with the Manager web application. You said you didn't want to use that, so ... I guess you are out of luck. Anything other than curl + JMXProxyServlet will be not sane. JMX can do pretty much anything; developing another protocol for another command-line interface is not a good use of anyone's time. -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: feature request: reload SSL certificate automatically after X days (configuration option)
On Sat, Dec 19, 2020 at 6:30 PM Romain Manni-Bucau
wrote:
> It moves the problem elsewhere, how would the CLI communicate with tomcat?
> JMX, HTTP uses a port, a file based communication would be probably worse
> because of perms and other admin issues (and just not working in k8s).
>
I don't see other sane ways actually. So it seems a web-based manager with
curl is there to stay (for the time being at least).
To Chris: It's somewhat weird that the user needs a web manager just for
curl-ing certification renewal.
To everyone:
I have a suggestion on improving Documentation regarding SSL.
https://tomcat.apache.org/tomcat-10.0-doc/ssl-howto.html
Currently, it states
Configuration
Prepare the Certificate Keystore
Tomcat currently operates only on JKS, PKCS11 or PKCS12 format keystores.
...
I think it should start with
Configuration
Option 1) Use Tomcat Native
which would showcase a path to something like:
Option 2) Without Tomcat Native
...
I don't know what is the formal process for improving the documentation
here?
> > >
> > > >
> > > >
> > > > >
> > > > > Le sam. 19 déc. 2020 à 15:24, Mladen Adamović <
> > > mladen.adamo...@gmail.com
> > > > >
> > > > > a
> > > > > écrit :
> > > > >
> > > > > > On Sat, Dec 19, 2020 at 2:29 PM Christopher Schultz <
> > > > > > ch...@christopherschultz.net> wrote:
> > > > > >
> > > > > > > Why not use cron? You can do this with a single "curl" command
> > and
> > > > the
> > > > > > > Manager+JMXProxyServlet.
> > > > > > >
> > > > > >
> > > > > > We are not using Tomcat manager app.
> > > > > >
> > > > > > Why someone should be forced to use Manager, to read/setup the
> > > > > > documentation regarding JMXProxyServlet, create an additional
> > > > > > servlet (where does it have dependency on?) only to reload
> > > > automatically
> > > > > > certificates?
> > > > > >
> > > > > > I'm proposing a solution with the simple SSLHostConfig parameter.
> > > It's
> > > > a
> > > > > > user friendly. Simple, intuitive.
> > > > > > No need for using manager, no need to create a specific servlet
> > > > somewhere
> > > > > > in your code. Just a single server.xml argument.
> > > > > >
> > > > > > Also, *another idea*, I'm contributing this code (see below) we
> are
> > > > using
> > > > > > for Letsencrypt ACME challenge.
> > > > > > Tomcat could also have an option, i.e. in web.xml to
> automatically
> > > > > support
> > > > > > Letsencrypt ACME challenge.
> > > > > > Idea for web.xml
> > > > > >
> > > > > > Letsencrypt-acme
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> org.apache.catalina.servlets.LetsencryptAcmeChallenge
> > > > > >
> > > > > > etc.
> > > > > >
> > > > > >
> > > > > >
> > > > > > We are using
> > > > > > @WebServlet(name = "LetsencryptAcmeChallenge", urlPatterns =
> > > > > > {"/.well-known/acme-challenge/*"})
> > > > > > public class LetsencryptAcmeChallenge extends HttpServlet {
> > > > > >
> > > > > > /**
> > > > > >* Processes requests for both HTTP GET and
> > > > > > POST methods.
> > > > > >*
> > > > > >* @param request servlet request
> > > > > >* @param response servlet response
> > > > > >* @throws ServletException if a servlet-specific error occurs
> > > > > >* @throws IOException if an I/O error occurs
> > > > > >*/
> > > > > > protected void processRequest(HttpServletRequest request,
> > > > > > HttpServletResponse response)
> > > > > > throws ServletException, IOException {
> > > > > > String requestUrl = request.getRequestURL().toString();
> > > > > > if (requestUrl.contains(".well-known/acme-challenge/")) {
> > > > > > int indexFilename = requestUrl.lastIndexOf("/") + 1;
> > > > > > boolean wasError = true;
> > > > > > if (indexFilename > 0 && indexFilename <
> > requestUrl.length()) {
> > > > > > String filename = requestUrl.substring(indexFilename);
> > > > > > File existingFile = new
> > > > > > File("/tmp/letsencrypt/public_html/.well-known/acme-challenge/" +
> > > > > > filename);
> > > > > > if (existingFile.exists()) {
> > > > > > response.setContentType("text/plain");
> > > > > > OutputStream out = response.getOutputStream();
> > > > > > FileInputStream in = new FileInputStream(existingFile);
> > > > > > FilesOperations.inputStreamToOutputStream(in, out);
> > > > > > wasError = false;
> > > > > > }
> > > > > > }
> > > > > > if (wasError) {
> > > > > > throw new ServletException("invalid requestUrl " +
> > > requestUrl);
> > > > > > }
> > > > > > }
> > > > > >
> > > > > > from FilesOperations:
> > > > > > public static void inputStreamToOutputStream(InputStream in,
> > > > > > OutputStream out) throws IOException {
> > > > > > try {
> > > > > > byte[ ] buf = new byte[32 * 1024]; // 32K buffer
> > > > > > int bytesRead;
> > > > > > while ((bytesRea
Bug report for Tomcat 7 [2020/12/20]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major | | | | MIN=Minor NOR=NormalENH=Enhancement TRV=Trivial | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | |50944|Ver|Blk|2011-03-18|JSF: java.lang.NullPointerException at com.sun.fac| |55470|New|Enh|2013-08-23|Help users for ClassNotFoundExceptions during star| |55477|New|Enh|2013-08-23|Add a solution to map a realm name to a security r| |56148|New|Enh|2014-02-17|support (multiple) ocsp stapling | |56300|New|Enh|2014-03-22|[Tribes] No useful examples, lack of documentation| |56438|New|Enh|2014-04-21|If jar scan does not find context config or TLD co| |56614|New|Enh|2014-06-12|Add a switch to ignore annotations detection on ta| |56787|New|Enh|2014-07-29|Simplified jndi name parsing | |57367|New|Enh|2014-12-18|If JAR scan experiences a stack overflow, give the| |57827|New|Enh|2015-04-17|Enable adding/removing of members via jmx in a sta| |57872|New|Enh|2015-04-29|Do not auto-switch session cookie to version=1 due| |60597|New|Enh|2017-01-17|Add ability to set cipher suites for websocket cli| |63167|New|Enh|2019-02-12|Network Requirements To Resolve No Members Active | +-+---+---+--+--+ | Total 13 bugs | +---+ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Bug report for Tomcat 8 [2020/12/20]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major | | | | MIN=Minor NOR=NormalENH=Enhancement TRV=Trivial | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | |55243|New|Enh|2013-07-11|Add special search string for nested roles| |55383|New|Enh|2013-08-07|Improve markup and design of Tomcat's HTML pages | |55675|New|Enh|2013-10-18|Checking and handling invalid configuration option| |55788|New|Enh|2013-11-16|TagPlugins should key on tag QName rather than imp| |56166|New|Enh|2014-02-20|Suggestions for exception handling (avoid potentia| |56398|New|Enh|2014-04-11|Support Arquillian-based unit testing | |56402|New|Enh|2014-04-11|Add support for HTTP Upgrade to AJP components| |56448|New|Enh|2014-04-23|Implement a robust solution for client initiated S| |56522|Opn|Enh|2014-05-14|jasper-el 8 does not comply to EL Spec 3.0 regardi| |56546|New|Enh|2014-05-19|Improve thread trace logging in WebappClassLoader.| |56713|New|Enh|2014-07-12|Limit time that incoming request waits while webap| |57130|New|Enh|2014-10-22|Allow digest.sh to accept password from a file or | |57421|New|Enh|2015-01-07|Farming default directories | |57486|New|Enh|2015-01-23|Improve reuse of ProtectedFunctionMapper instances| |57701|New|Enh|2015-03-13|Implement "[Redeploy]" button for a web applicatio| |57830|New|Enh|2015-04-18|Add support for ProxyProtocol | |58052|Opn|Enh|2015-06-19|RewriteValve: Implement additional RewriteRule dir| |58072|New|Enh|2015-06-23|ECDH curve selection | |58837|New|Enh|2016-01-12|support "X-Content-Security-Policy" a.k.a as "CSP"| |58935|Opn|Enh|2016-01-29|Re-deploy from war without deleting context | |59232|New|Enh|2016-03-24|Make the context name of an app available via JNDI| |59758|New|Enh|2016-06-27|Add http proxy username-password credentials suppo| |60281|Ver|Nor|2016-10-20|Pathname of uploaded WAR file should not be contai| |60721|Ver|Nor|2017-02-10|Unable to find key spec if more applications use b| |60849|New|Enh|2017-03-13|Tomcat NIO Connector not able to handle SSL renego| |61668|Ver|Min|2017-10-26|Possible NullPointerException in org.apache.coyote| |61877|New|Enh|2017-12-08|use web.xml from CATALINA_HOME by default | |61917|New|Enh|2017-12-19|AddDefaultCharsetFilter only supports text/* respo| |62150|New|Enh|2018-03-01|Behavior of relative paths with RequestDispatcher | |62214|New|Enh|2018-03-22|The "userSubtree=true" and "roleSubtree=true" in J| |62245|New|Enh|2018-04-02|[Documentation] Mention contextXsltFile in Default| |63080|New|Enh|2019-01-16|Support rfc7239 Forwarded header | |63195|Inf|Enh|2019-02-21|Add easy way to test RemoteIpValve works properly | |65007|New|Nor|2020-12-18|Misleading instructions on import an SSL certifica| +-+---+---+--+--+ | Total 34 bugs | +---+ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Bug report for Taglibs [2020/12/20]
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) |
| | +-+
| | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major |
| | | MIN=Minor NOR=NormalENH=Enhancement TRV=Trivial |
| | | +-+
| | | | Date Posted |
| | | | +--+
| | | | | Description |
| | | | | |
|38193|Ass|Enh|2006-01-09|[RDC] BuiltIn Grammar support for Field |
|38600|Ass|Enh|2006-02-10|[RDC] Enable RDCs to be used in X+V markup (X+RDC)|
|42413|New|Enh|2007-05-14|[PATCH] Log Taglib enhancements |
|46052|New|Nor|2008-10-21|SetLocaleSupport is slow to initialize when many l|
|48333|New|Enh|2009-12-02|TLD generator |
|57548|New|Min|2015-02-08|Auto-generate the value for org.apache.taglibs.sta|
|57684|New|Min|2015-03-10|Version info should be taken from project version |
|59359|New|Enh|2016-04-20|(Task) Extend validity period for signing KEY - be|
|59668|New|Nor|2016-06-06|x:forEach retains the incorrect scope when used in|
|61875|New|Nor|2017-12-08|Investigate whether Xalan can be removed |
|64649|New|Nor|2020-08-06|XSLT transformation - document('') doesn't return |
+-+---+---+--+--+
| Total 11 bugs |
+---+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Bug report for Tomcat Connectors [2020/12/20]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major | | | | MIN=Minor NOR=NormalENH=Enhancement TRV=Trivial | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | |46767|New|Enh|2009-02-25|mod_jk to send DECLINED in case no fail-over tomca| |47327|New|Enh|2009-06-07|Return tomcat authenticated user back to mod_jk (A| |47750|New|Maj|2009-08-27|ISAPI: Loss of worker settings when changing via j| |48830|New|Nor|2010-03-01|IIS shutdown blocked in endpoint service when serv| |49822|New|Enh|2010-08-25|Add hash lb worker method | |49903|New|Enh|2010-09-09|Make workers file reloadable | |52483|New|Enh|2012-01-18|Print JkOptions's options in log file and jkstatus| |54621|New|Enh|2013-02-28|[PATCH] custom mod_jk availability checks | |56489|New|Enh|2014-05-05|Include a directory for configuration files | |56576|New|Enh|2014-05-29|Websocket support | |57402|New|Enh|2014-12-30|Provide correlation ID between mod_jk log and acce| |57403|New|Enh|2014-12-30|Persist configuration changes made via status work| |57407|New|Enh|2014-12-31|Make session_cookie, session_path and session_cook| |57790|New|Enh|2015-04-03|Check worker names for typos | |61476|New|Enh|2017-09-01|Allow reset of an individual worker stat value| |61621|New|Enh|2017-10-15|Content-Type is forced to lowercase when it goes t| |62093|New|Enh|2018-02-09|Allow use_server_errors to apply to specific statu| |63808|Opn|Enh|2019-10-05|the fact that JkMount makes other directives ineff| |64775|New|Nor|2020-09-28|mod_jk is sending both Content-Length and Transfer| |64878|New|Nor|2020-11-06|Can not determine the proper size for pid_t / pthr| +-+---+---+--+--+ | Total 20 bugs | +---+ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Bug report for Tomcat Native [2020/12/20]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major | | | | MIN=Minor NOR=NormalENH=Enhancement TRV=Trivial | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | |62911|New|Enh|2018-11-15|Add support for proxying ocsp requests via ProxyH| |64826|New|Maj|2020-10-19|libtcnative prompts for private key password in so| |64862|New|Enh|2020-10-30|Improve LibreSSL support | +-+---+---+--+--+ | Total3 bugs | +---+ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Bug report for Tomcat 9 [2020/12/20]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major | | | | MIN=Minor NOR=NormalENH=Enhancement TRV=Trivial | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | |57505|New|Enh|2015-01-27|Add integration tests for JspC| |58530|New|Enh|2015-10-23|Proposal for new Manager HTML GUI | |58548|Inf|Enh|2015-10-26|support certifcate transparency | |58859|New|Enh|2016-01-14|Allow to limit charsets / encodings supported by T| |59344|Ver|Enh|2016-04-18|PEM file support for JSSE | |59750|New|Enh|2016-06-24|Amend "authenticate" method with context by means | |60997|New|Enh|2017-04-17|Enhance SemaphoreValve to support denied status an| |61971|New|Enh|2018-01-06|documentation for using tomcat with systemd | |62048|New|Enh|2018-01-25|Missing logout function in Manager and Host-Manage| |62072|New|Enh|2018-02-01|Add support for request compression | |62312|New|Enh|2018-04-18|Add Proxy Authentication support to websocket clie| |62405|New|Enh|2018-05-23|Add Rereadable Request Filter | |62488|New|Enh|2018-06-25|Obtain dependencies from Maven Central where possi| |62611|Inf|Enh|2018-08-09|Compress log files after rotation | |62723|New|Enh|2018-09-14|Clarify "channelSendOptions" value in cluster docu| |62773|New|Enh|2018-09-28|Change DeltaManager to handle session deserializat| |62814|New|Enh|2018-10-10|Use readable names for cluster channel/map options| |62843|New|Enh|2018-10-22|Tomcat Russian localization | |62964|Inf|Enh|2018-11-29|Add RFC7807 conformant Problem Details for HTTP st| |63023|New|Enh|2018-12-20|Provide a way to load SecurityProviders into the s| |63049|New|Enh|2018-12-31|Add support in system properties override from com| |63237|New|Enh|2019-03-06|Consider processing mbeans-descriptors.xml at comp| |63389|New|Enh|2019-04-27|Enable Servlet Warmup for Containerization| |63493|New|Enh|2019-06-10|enhancement - add JMX counters to monitor authenti| |63505|New|Enh|2019-06-14|enhancement - support of stored procedures for Dat| |63545|New|Enh|2019-07-06|enhancement - add a new pattern attribute for logg| |63943|Opn|Enh|2019-11-20|Add possibility to overwrite remote port with info| |63983|Ver|Cri|2019-12-03|Jasper builds-up open files until garbage collecti| |64144|New|Enh|2020-02-14|Add an option for rejecting requests that have bot| |64230|New|Enh|2020-03-15|Allow to configure session manager to skip expirin| |64395|New|Enh|2020-04-30|Windows Installer should offer an option to select| |64762|Inf|Reg|2020-09-23|CoyoteInputStream getInputStream() read (wait afte| |64771|Inf|Maj|2020-09-26|Windows CPU processor always running by a thread r| |64830|Opn|Reg|2020-10-20|HTTP2 : GOAWAY sent with Protocol Error and Frame | |64938|Inf|Nor|2020-11-27|response.setCharacterEncoding(null) should clear p| |65001|New|Nor|2020-12-17|HTTPNIO non-blocking IO servlet 3.1 API may fail t| +-+---+---+--+--+ | Total 36 bugs | +---+ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Bug report for Tomcat Modules [2020/12/20]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major | | | | MIN=Minor NOR=NormalENH=Enhancement TRV=Trivial | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | |50571|Inf|Nor|2011-01-11|Tomcat 7 JDBC connection pool exception enhancemen| |51595|Inf|Nor|2011-08-01|org.apache.tomcat.jdbc.pool.jmx.ConnectionPool sho| |51879|Inf|Enh|2011-09-22|Improve access to Native Connection Methods | |52024|Inf|Enh|2011-10-13|Custom interceptor to support automatic failover o| |53199|Inf|Enh|2012-05-07|Refactor ConnectionPool to use ScheduledExecutorSe| |54437|New|Enh|2013-01-16|Update PoolProperties javadoc for ConnectState int| |54929|Inf|Nor|2013-05-05|jdbc-pool cannot be used with Java 1.5, "java.lang| |55078|New|Nor|2013-06-07|Configuring a DataSource Resource with dataSourceJ| |55662|New|Enh|2013-10-17|Add a way to set an instance of java.sql.Driver di| |56046|New|Enh|2014-01-21|org.apache.tomcat.jdbc.pool.XADataSource InitSQL p| |56088|New|Maj|2014-01-29|AbstractQueryReport$StatementProxy throws exceptio| |56310|Inf|Maj|2014-03-25|PooledConnection and XAConnection not handled corr| |56586|New|Nor|2014-06-02|initSQL should be committed if defaultAutoCommit =| |56775|New|Nor|2014-07-28|PoolCleanerTime schedule issue| |56779|New|Nor|2014-07-28|Allow multiple connection initialization statement| |56790|New|Nor|2014-07-29|Resizing pool.maxActive to a higher value at runti| |56798|New|Nor|2014-07-31|Idle eviction strategy could perform better (and i| |56804|New|Nor|2014-08-02|Use a default validationQueryTimeout other than "f| |56805|New|Nor|2014-08-02|datasource.getConnection() may be unnecessarily bl| |56837|New|Nor|2014-08-11|if validationQuery have error with timeBetweenEvic| |56970|New|Nor|2014-09-11|MaxActive vs. MaxTotal for commons-dbcp and tomcat| |57460|New|Nor|2015-01-19|[DB2]Connection broken after few hours but not rem| |57729|New|Enh|2015-03-20|Add QueryExecutionReportInterceptor to log query e| |58489|Opn|Maj|2015-10-08|QueryStatsComparator throws IllegalArgumentExcepti| |59077|New|Nor|2016-02-26|DataSourceFactory creates a neutered data source | |59569|New|Nor|2016-05-18|isWrapperFor/unwrap implementations incorrect | |59879|New|Nor|2016-07-18|StatementCache interceptor returns ResultSet objec| |60195|New|Nor|2016-10-02|No javadoc in Maven Central | |60522|New|Nor|2016-12-27|An option for setting if the transaction should be| |60524|Inf|Nor|2016-12-28|NPE in SlowQueryReport in tomcat-jdbc-7.0.68 | |60645|New|Nor|2017-01-25|StatementFinalizer is not thread-safe | |61032|New|Nor|2017-04-24|min pool size is not being respected | |61103|New|Nor|2017-05-18|StatementCache potentially caching non-functional | |61302|New|Enh|2017-07-15|Refactoring of DataSourceProxy| |61303|New|Enh|2017-07-15|Refactoring of ConnectionPool | |62432|New|Nor|2018-06-06|Memory Leak in Statement Finalizer? | |62598|New|Enh|2018-08-04|support pool with multiple JDBC data sources | |62910|Inf|Nor|2018-11-15|tomcat-jdbc global pool transaction problem | |63612|Inf|Cri|2019-07-26|PooledConnection#connectUsingDriver, Thread.curren| |63705|New|Nor|2019-08-29|The tomcat pool doesn't register all connection th| |64083|New|Nor|2020-01-17|JDBC pool keeps closed connection as available| |64107|New|Maj|2020-01-30|PreparedStatements correctly closed are not return| |64231|New|Nor|2020-03-16|Tomcat jdbc pool behaviour| |64570|New|Nor|2020-07-01|Transaction not rollbacked if autocommit is false | |64809|New|Nor|2020-10-13|Connection properties not reset to defaults when C| +-+---+---+--+--+ | Total 45 bugs | +---+ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
