Re: (tomcat) branch main updated: Add support for shallow copies when using WebDAV
вт, 21 мая 2024 г. в 14:55, :
>
> The following commit(s) were added to refs/heads/main by this push:
> new 4176706761 Add support for shallow copies when using WebDAV
> 4176706761 is described below
>
> commit 4176706761242851b14be303daf2a00ef385ee49
> Author: Mark Thomas
> AuthorDate: Tue May 21 12:54:40 2024 +0100
>
> Add support for shallow copies when using WebDAV
> ---
> .../apache/catalina/servlets/WebdavServlet.java| 31
> +-
> webapps/docs/changelog.xml | 7 +
> 2 files changed, 31 insertions(+), 7 deletions(-)
>
> diff --git a/java/org/apache/catalina/servlets/WebdavServlet.java
> b/java/org/apache/catalina/servlets/WebdavServlet.java
> index a489eb0e51..b1b67030af 100644
> --- a/java/org/apache/catalina/servlets/WebdavServlet.java
> +++ b/java/org/apache/catalina/servlets/WebdavServlet.java
> @@ -1519,7 +1519,20 @@ public class WebdavServlet extends DefaultServlet
> implements PeriodicEventListen
>
> Map errorList = new HashMap<>();
>
> -boolean result = copyResource(errorList, path, destinationPath);
> +boolean infiniteCopy = true;
> +String depthHeader = req.getHeader("Depth");
> +if (depthHeader != null) {
> +if (depthHeader.equals("infinity")) {
> +// NO-OP - this is the default
> +} else if (depthHeader.equals("0")) {
> +infiniteCopy = false;
> +} else {
> +resp.sendError(WebdavStatus.SC_BAD_REQUEST);
> +return false;
> +}
> +}
> +
> +boolean result = copyResource(errorList, path, destinationPath,
> infiniteCopy);
>
> if ((!result) || (!errorList.isEmpty())) {
> if (errorList.size() == 1) {
> @@ -1548,16 +1561,18 @@ public class WebdavServlet extends DefaultServlet
> implements PeriodicEventListen
> /**
> * Copy a collection.
> *
> - * @param errorList Map containing the list of errors which occurred
> during the copy operation
> - * @param sourcePath of the resource to be copied
> - * @param dest Destination path
> + * @param errorListMap containing the list of errors which occurred
> during the copy operation
> + * @param source Path of the resource to be copied
> + * @param dest Destination path
> + * @param infiniteCopy {@code true} if this copy is to be an infinite
> copy, otherwise {@code false} for a shallow
> + * copy
> *
> * @return true if the copy was successful
> */
> -private boolean copyResource(Map errorList, String
> source, String dest) {
> +private boolean copyResource(Map errorList, String
> source, String dest, boolean infiniteCopy) {
>
> if (debug > 1) {
> -log("Copy: " + source + " To: " + dest);
> +log("Copy: " + source + " To: " + dest + " Infinite: " +
> infiniteCopy);
> }
>
> WebResource sourceResource = resources.getResource(source);
> @@ -1583,7 +1598,9 @@ public class WebdavServlet extends DefaultServlet
> implements PeriodicEventListen
> childSrc += "/";
> }
> childSrc += entry;
> -copyResource(errorList, childSrc, childDest);
> +if (infiniteCopy) {
> +copyResource(errorList, childSrc, childDest, true);
> +}
> }
I think that the "if (infiniteCopy)" block here is too narrow.
The whole loop over children (starting with "String[] entries =
resources.list(source)") here is useless when the infiniteCopy option
is false.
> } else if (sourceResource.isFile()) {
> WebResource destResource = resources.getResource(dest);
> diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Some remarks on panama libssl loading
чт, 18 апр. 2024 г. в 00:46, Rainer Jung :
>
> Hi Konstantin,
>
> Am 17.04.24 um 21:44 schrieb Konstantin Kolinko:
> > ср, 17 апр. 2024 г. в 17:21, Rainer Jung :
> >>
> >> Am 17.04.24 um 15:34 schrieb Michael Osipov:
> >>> Rainer, I do not fully understand the problem here. We use libtool to
> >>> solve exactly this problem with versioned SONAMEs. It will create
> >>> symlinks to the SONAME.
> >>> Do you expect anyone even with dlopen() to load libfoo.o.{SOVERSION}
> >>> unless it is strictly needed?
> >>>
> >>> E.g.:
> >>> lrwxr-xr-x 1 root wheel26 2024-03-22 10:20
> >>> /usr/lib/libcrypto.so@ -> ../../lib/libcrypto.so.111
> >>> lrwxr-xr-x 1 root wheel 13 2024-03-22 10:20 /usr/lib/libssl.so@
> >>> -> libssl.so.111
> >>> -r--r--r-- 1 root wheel 608008 2024-03-22 10:20 /usr/lib/libssl.so.111
> >>> and so on...
> >>
> >> Yes, I expect that! anyone is the JVM :(
> >>
> >> The problem is, that the Java API does not care about these well thought
> >> native traditions. You can not open libssl.so.3 using
> >> System.loadlibrary(String name), because whatever you give it as "name"
> >> parameter it will always try to open libname.so. It always prepends
> >> "lib" to name and always suffixes it with plain ".so".
> >>
> >> Yes, it might exist as the first in your list of symlinks, but on most
> >> linux distributions this link is not installed by default, because it is
> >> only needed when doing compilations. So it is only installed when you
> >> install development packages for libs.
> >
> > There are two methods,
> > System.loadLibrary(libname)
> > System.load(filename)
> > or the same methods in Runtime.
> >
> > The second method accepts an absolute path and apparently does no
> > manipulation on the name.
> >
> > There is also System.mapLibraryName().
> >
> > Note that o.a.t.jni.Library constructor uses all those three methods.
> > A code that was added several years ago uses mapLibraryName() and
> > load() to load a library from "catalina.home/bin". It then falls back
> > to the old algorithm that uses loadLibrary().
> >
> >
> > https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/System.html
> > https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/Runtime.html
>
> thanks for your valuable input as always. I am referring to
> java/org/apache/tomcat/util/openssl/openssl_h.java, which only contains
> which on Mac does
>
> System.loadLibrary("ssl");
> SYMBOL_LOOKUP =
> SymbolLookup.loaderLookup().or(Linker.nativeLinker().defaultLookup());
>
> and else
>
> SYMBOL_LOOKUP = SymbolLookup.libraryLookup(System.mapLibraryName("ssl"),
> LIBRARY_ARENA)
> .or(SymbolLookup.loaderLookup())
> .or(Linker.nativeLinker().defaultLookup());
>
> I *think* both attempts do not allow to use a versioned SONAME.
>
> I have not experimented with System.load(filename) and how to combine it
> with SymbolLookup. o.a.t.jni.Library does not use SymbolLookup. But it
> seems SymbolLookup is not restricted to the development library names.
> So there's hope we can improve!
>
> https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/foreign/SymbolLookup.html
Thank you for the references.
Those lines of code are not generated, but are written by Remy.
A comment referencing "https://github.com/sergot/openssl/issues/81; was a clue.
See the changes in February 2024 (starting with 2024-02-08).
SymbolLookup has two methods, just like the pair of methods in System/Runtime:
libraryLookup(String, Arena)
libraryLookup(Path, Arena).
The second method accepts a full path to a library file.
Interesting is that this new API allows unloading the library - that
is what the Arena argument is for.
As we do not plan to unload the library, I think it makes sense to use
the "good old" System.load() / loadLibrary() methods to load the
library, and use the SymbolLookup loaderLookup() factory method.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Some remarks on panama libssl loading
ср, 17 апр. 2024 г. в 17:21, Rainer Jung :
>
> Am 17.04.24 um 15:34 schrieb Michael Osipov:
> > Rainer, I do not fully understand the problem here. We use libtool to solve
> > exactly this problem with versioned SONAMEs. It will create symlinks to the
> > SONAME.
> > Do you expect anyone even with dlopen() to load libfoo.o.{SOVERSION} unless
> > it is strictly needed?
> >
> > E.g.:
> > lrwxr-xr-x 1 root wheel26 2024-03-22 10:20 /usr/lib/libcrypto.so@
> > -> ../../lib/libcrypto.so.111
> > lrwxr-xr-x 1 root wheel 13 2024-03-22 10:20 /usr/lib/libssl.so@ ->
> > libssl.so.111
> > -r--r--r-- 1 root wheel 608008 2024-03-22 10:20 /usr/lib/libssl.so.111
> > and so on...
>
> Yes, I expect that! anyone is the JVM :(
>
> The problem is, that the Java API does not care about these well thought
> native traditions. You can not open libssl.so.3 using
> System.loadlibrary(String name), because whatever you give it as "name"
> parameter it will always try to open libname.so. It always prepends
> "lib" to name and always suffixes it with plain ".so".
>
> Yes, it might exist as the first in your list of symlinks, but on most
> linux distributions this link is not installed by default, because it is
> only needed when doing compilations. So it is only installed when you
> install development packages for libs.
There are two methods,
System.loadLibrary(libname)
System.load(filename)
or the same methods in Runtime.
The second method accepts an absolute path and apparently does no
manipulation on the name.
There is also System.mapLibraryName().
Note that o.a.t.jni.Library constructor uses all those three methods.
A code that was added several years ago uses mapLibraryName() and
load() to load a library from "catalina.home/bin". It then falls back
to the old algorithm that uses loadLibrary().
https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/System.html
https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/Runtime.html
HTH
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: (tomcat) branch main updated: Further locking harmonizations for main components
чт, 4 апр. 2024 г. в 15:45, :
>
> This is an automated email from the ASF dual-hosted git repository.
>
> remm pushed a commit to branch main
> in repository https://gitbox.apache.org/repos/asf/tomcat.git
>
>
> The following commit(s) were added to refs/heads/main by this push:
> new fba89a Further locking harmonizations for main components
> fba89a is described below
>
> commit fba89a6f05223768e7d7026cd886d7f8356d
> Author: remm
> AuthorDate: Thu Apr 4 14:43:02 2024 +0200
>
> Further locking harmonizations for main components
>
> Also for lifecycle operations.
> ---
> java/org/apache/catalina/core/ContainerBase.java | 86
> +-
> java/org/apache/catalina/core/StandardService.java | 22 +++---
> webapps/docs/changelog.xml | 5 +-
> 3 files changed, 66 insertions(+), 47 deletions(-)
>
> diff --git a/java/org/apache/catalina/core/ContainerBase.java
> b/java/org/apache/catalina/core/ContainerBase.java
> index 4edd4edf9d..846f4e27d8 100644
> --- a/java/org/apache/catalina/core/ContainerBase.java
> +++ b/java/org/apache/catalina/core/ContainerBase.java
> @@ -129,6 +129,7 @@ public abstract class ContainerBase extends
> LifecycleMBeanBase implements Contai
> * The child Containers belonging to this Container, keyed by name.
> */
> protected final HashMap children = new HashMap<>();
> +private final ReadWriteLock childrenLock = new ReentrantReadWriteLock();
It is useless to have the above "children" field as protected.
Nobody will be able to access it in a safe manner, because they have
no access to childrenLock.
> @@ -632,26 +633,30 @@ public abstract class ContainerBase extends
> LifecycleMBeanBase implements Contai
> log.debug(sm.getString("containerBase.child.add", child, this));
> }
>
> -synchronized (children) {
> +childrenLock.writeLock().lock();
> +try {
> if (children.get(child.getName()) != null) {
> throw new
> IllegalArgumentException(sm.getString("containerBase.child.notUnique",
> child.getName()));
> }
> child.setParent(this); // May throw IAE
> children.put(child.getName(), child);
> -}
Change of behaviour!
The old sync block ended with the "}" above.
> -fireContainerEvent(ADD_CHILD_EVENT, child);
> +fireContainerEvent(ADD_CHILD_EVENT, child);
>
> -// Start child
> -// Don't do this inside sync block - start can be a slow process and
> -// locking the children object can cause problems elsewhere
> -try {
> -if ((getState().isAvailable() ||
> LifecycleState.STARTING_PREP.equals(getState())) && startChildren) {
> -child.start();
> +// Start child
> +// Don't do this inside sync block - start can be a slow process
> and
The above says "Don't do this inside sync block",
but your change puts it into a sync block.
(And I see similar changes of behaviour further in this commit.)
The lock was intended to protect changes of the "children" hash table,
but now it starts to protect
a) state changes of those children (start/stop/destroy)
b) notifications.
I think that the state changes (in LifecycleBase) already have their
own protection.
While stating/stopping/destroying is in progress,
that child still remains ours and findChildren() etc. should be
allowed to be called by other threads.
A write lock prevents other threads from reading the value.
https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/locks/ReentrantReadWriteLock.html
Thus I am -1.
I think it is easier to revert and work on a new patch rather than try
to amend this one.
> +// locking the children object can cause problems elsewhere
> +try {
> +if ((getState().isAvailable() ||
> LifecycleState.STARTING_PREP.equals(getState())) && startChildren) {
> +child.start();
> +}
> +} catch (LifecycleException e) {
> +throw new
> IllegalStateException(sm.getString("containerBase.child.start"), e);
> }
> -} catch (LifecycleException e) {
> -throw new
> IllegalStateException(sm.getString("containerBase.child.start"), e);
> +} finally {
> +childrenLock.writeLock().unlock();
> }
> +
> }
>
>
> @@ -688,8 +693,11 @@ public abstract class ContainerBase extends
> LifecycleMBeanBase implements Contai
> if (name == null) {
> return null;
> }
> -synchronized (children) {
> +childrenLock.readLock().lock();
> +try {
> return children.get(name);
> +} finally {
> +childrenLock.readLock().unlock();
> }
> }
>
> @@ -700,8 +708,11 @@ public abstract class ContainerBase extends
> LifecycleMBeanBase implements Contai
> */
> @Override
> public
Re: (tomcat) branch main updated: Performance tweaks for filter chain
> diff --git a/java/org/apache/tomcat/util/descriptor/web/FilterDef.java
> b/java/org/apache/tomcat/util/descriptor/web/FilterDef.java
> index 3a208964e0..b742d5c19c 100644
> --- a/java/org/apache/tomcat/util/descriptor/web/FilterDef.java
> +++ b/java/org/apache/tomcat/util/descriptor/web/FilterDef.java
> @@ -162,8 +162,14 @@ public class FilterDef implements Serializable {
>
> public void setAsyncSupported(String asyncSupported) {
> this.asyncSupported = asyncSupported;
> +asyncSupportedBoolean = !("false".equalsIgnoreCase(asyncSupported));
> }
>
> +private boolean asyncSupportedBoolean = true;
Why "true" by default?
Looking into Java Servlet 4.0 specification,
---
servlet-4_0_FINAL.pdf
2.3.3.3 Asynchronous processing says:
"The @WebServlet and @WebFilter annotations described in Chapter 8 have an
attribute - asyncSupported that is a boolean with a default value of false."
"14.3 Deployment Descriptor" says:
7. filter Element
...
The optional async-supported element, when specified, indicates
that the filter supports asynchronous request processing.
10. servlet Element
...
The optional async-
supported element, when specified, indicates that the Servlet can support
asynchronous request processing.
---
I read it so that an omission means "false".
I see that the old code uses "false".equalsIgnoreCase(), but I wonder why.
Also I wonder whether FilterDef and ServletDef classes handling of
asyncSupported could be aligned.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: (tomcat) branch main updated: Add support for JSON responses to request header example.
Chris,
Please compare the iteration logic in renderHTML vs renderJSON.
Your code misses the changes added by
https://github.com/apache/tomcat/commit/c88e75305e198f500ffd626a5b1275dc3ad46553
пн, 12 февр. 2024 г. в 23:19, :
>
> This is an automated email from the ASF dual-hosted git repository.
>
> schultz pushed a commit to branch main
> in repository https://gitbox.apache.org/repos/asf/tomcat.git
>
>
> The following commit(s) were added to refs/heads/main by this push:
> new 861b593d7b Add support for JSON responses to request header example.
> 861b593d7b is described below
>
> commit 861b593d7b2a236fbdf9c8a9fe6ef1c8edc39a38
> Author: Christopher Schultz
> AuthorDate: Mon Feb 12 15:18:22 2024 -0500
>
> Add support for JSON responses to request header example.
> ---
> webapps/docs/changelog.xml | 8 +++
> .../WEB-INF/classes/RequestHeaderExample.java | 77
> +-
> 2 files changed, 84 insertions(+), 1 deletion(-)
>
> diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
> index 1d8f6317a8..e4ddfbd30c 100644
> --- a/webapps/docs/changelog.xml
> +++ b/webapps/docs/changelog.xml
> @@ -206,6 +206,14 @@
>
>
>
> +
> +
> +
> +Add support for responses in JSON format from the examples
> application
> +RequestHeaderExample. (schultz)
> +
> +
> +
>
>
>
> diff --git a/webapps/examples/WEB-INF/classes/RequestHeaderExample.java
> b/webapps/examples/WEB-INF/classes/RequestHeaderExample.java
> index 180525dd14..451a7a1ad1 100644
> --- a/webapps/examples/WEB-INF/classes/RequestHeaderExample.java
> +++ b/webapps/examples/WEB-INF/classes/RequestHeaderExample.java
> @@ -27,6 +27,8 @@ import jakarta.servlet.http.HttpServletRequest;
> import jakarta.servlet.http.HttpServletResponse;
> import jakarta.servlet.http.HttpSession;
>
> +import org.apache.tomcat.util.json.JSONFilter;
> +
> import util.CookieFilter;
> import util.HTMLFilter;
>
> @@ -35,7 +37,6 @@ import util.HTMLFilter;
> *
> * @author James Duncan Davidson dun...@eng.sun.com>
> */
> -
> public class RequestHeaderExample extends HttpServlet {
>
> private static final long serialVersionUID = 1L;
> @@ -44,6 +45,51 @@ public class RequestHeaderExample extends HttpServlet {
> public void doGet(HttpServletRequest request,
>HttpServletResponse response)
> throws IOException, ServletException
> +{
> +if (prefersJSON(request.getHeader("Accept"))) {
> +renderJSON(request, response);
> +} else {
> +renderHTML(request, response);
> +}
> +}
> +
> +/**
> + * Returns true if the client appears to prefer a JSON response,
> + * false otherwise.
> + *
> + * Note that this method is not very pedantic and uses only a very lazy
> + * algorithm for checking whether JSON is "preferred".
> + *
> + * @param acceptHeader The value of the HTTP "Accept" header from the
> client.
> + *
> + * @return true if the client appears to prefer a JSON response,
> + * false otherwise.
> + */
> +protected boolean prefersJSON(String acceptHeader) {
> +if (null == acceptHeader) {
> +return false;
> +}
> +// mime/type, mime/type;q=n, ...
> +
> +// Don't bother with the q-factor.
> +// This is not expected to be 100% accurate or spec-compliant
> +String[] accepts = acceptHeader.split(",");
> +for (String accept : accepts) {
> +if (accept.contains("application/json")) {
> +return true;
> +}
> +
> +// text/html, application/html, etc.
> +if (accept.contains("html")) {
> +return false;
> +}
> +}
> +return false;
> +}
> +
> +protected void renderHTML(HttpServletRequest request,
> + HttpServletResponse response)
> +throws IOException, ServletException
> {
> ResourceBundle rb =
> ResourceBundle.getBundle("LocalStrings",request.getLocale());
>
> @@ -97,6 +143,35 @@ public class RequestHeaderExample extends HttpServlet {
> out.println("");
> }
>
> +protected void renderJSON(HttpServletRequest request,
> HttpServletResponse response)
> +throws IOException, ServletException
> +{
> +response.setContentType("application/json");
> +response.setCharacterEncoding("UTF-8");
> +
> +PrintWriter out = response.getWriter();
> +
> +out.append('[');
> +Enumeration e = request.getHeaderNames();
> +while (e.hasMoreElements()) {
> +String headerName = e.nextElement();
> +String headerValue = request.getHeader(headerName);
> +
> +out.append("{\"")
> +.append(JSONFilter.escape(headerName))
> +.append("\":\"")
> +
Re: (tomcat-native) 03/03: Consistent formatting. Add missing entries. Add version to title.
пн, 5 февр. 2024 г. в 11:45, : > > This is an automated email from the ASF dual-hosted git repository. > > markt pushed a commit to branch 1.2.x > in repository https://gitbox.apache.org/repos/asf/tomcat-native.git > > commit 34a274f39b836c9d9766e1707018b3b8b61c5506 > Author: Mark Thomas > AuthorDate: Mon Feb 5 08:27:04 2024 + > > Consistent formatting. Add missing entries. Add version to title. > --- > xdocs/miscellaneous/project.xml | 51 > + > xdocs/news/project.xml | 10 > xdocs/project.xml | 8 --- > 3 files changed, 36 insertions(+), 33 deletions(-) > > diff --git a/xdocs/miscellaneous/project.xml b/xdocs/miscellaneous/project.xml > index 1153ee1ea..31248d42e 100644 > --- a/xdocs/miscellaneous/project.xml > +++ b/xdocs/miscellaneous/project.xml > @@ -16,41 +16,42 @@ >limitations under the License. > --> > -href="http://tomcat.apache.org/;> > +href="http://tomcat.apache.org/;> Just spotting: The three 'project.xml" files changed by this commit still use "http:" instead of "https:" in the tag above... I tested, http://tomcat.apache.org/ responds with a 301 redirect to https://tomcat.apache.org/ Those values are used to generate links from the logo image, useful if anybody is viewing the documentation locally. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Buildbot failure in on tomcat-8.5.x
Running "release" target fails due to a typo in Javadoc. Double ">>". [javadoc] Building tree for all the packages and classes... [javadoc] /home/buildslave/slave/tomcat-8.5.x/build/output/dist/src/java/org/apache/catalina/filters/CsrfPreventionFilter.java:232: error: bad use of '>' [javadoc] * >null if the pattern is null or blank. [javadoc] ^ ... [javadoc] 1 error [javadoc] 100 warnings BUILD FAILED /home/buildslave/slave/tomcat-8.5.x/build/build.xml:2052: Javadoc returned 1 чт, 1 февр. 2024 г. в 21:08, : > > Build status: BUILD FAILED: failed compile (failure) > Worker used: bb_worker2_ubuntu > URL: https://ci2.apache.org/#builders/36/builds/728 > Blamelist: Christopher Schultz , remm > > Build Text: failed compile (failure) > Status Detected: new failure > Build Source Stamp: [branch 8.5.x] 63ced512958556c7b6d7bfc60740648cecd0020d > > > Steps: > > worker_preparation: 0 > > git: 0 > > shell: 0 > > shell_1: 0 > > shell_2: 0 > > shell_3: 0 > > shell_4: 0 > > shell_5: 0 > > compile: 2 > > > -- ASF Buildbot > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: (tomcat) branch main updated: Fix logic bug spotted by Coverity Scan
пн, 15 янв. 2024 г. в 13:16, :
>
> This is an automated email from the ASF dual-hosted git repository.
>
> markt pushed a commit to branch main
> in repository https://gitbox.apache.org/repos/asf/tomcat.git
>
>
> The following commit(s) were added to refs/heads/main by this push:
> new bee714eb1d Fix logic bug spotted by Coverity Scan
> bee714eb1d is described below
>
> commit bee714eb1dabfcc07bf410e1145f6c580f14539d
> Author: Mark Thomas
> AuthorDate: Mon Jan 15 10:11:59 2024 +
>
> Fix logic bug spotted by Coverity Scan
> ---
> .../apache/tomcat/util/digester/ServiceBindingPropertySource.java| 2 +-
> webapps/docs/changelog.xml | 5
> +
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git
> a/java/org/apache/tomcat/util/digester/ServiceBindingPropertySource.java
> b/java/org/apache/tomcat/util/digester/ServiceBindingPropertySource.java
> index 89617c9cfb..bd06630f01 100644
> --- a/java/org/apache/tomcat/util/digester/ServiceBindingPropertySource.java
> +++ b/java/org/apache/tomcat/util/digester/ServiceBindingPropertySource.java
> @@ -116,7 +116,7 @@ public class ServiceBindingPropertySource implements
> IntrospectionUtils.Property
> int length = bytes.length;
>
> if (chomp) {
> -if(length > 1 && bytes[length - 2] == '\r' && bytes[length -
> 2] == '\n') {
> +if(length > 1 && bytes[length - 2] == '\r' && bytes[length -
> 1] == '\n') {
> length -= 2;
> } else if (length > 0) {
> byte c = bytes[length - 1];
> diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
> index 6e9ffb917c..aa7fce0034 100644
> --- a/webapps/docs/changelog.xml
> +++ b/webapps/docs/changelog.xml
> @@ -120,6 +120,11 @@
> that is no longer included in the JAR. Based on pull request
> 684 by Jendrik Johannes. (markt)
>
> +
> +Fix ServiceBindingPropertySource so that trailing \r\n
> +sequences are correctly removed from files containing property values
> +when configured to do so. Bug identified by Coverity Scan. (markt)
> +
>
>
>
Reviewing the code of ServiceBindingPropertySource,
1. It removes only the last end-of-line sequence (one or two characters).
It could be rewritten with a loop to remove any \n \r characters that
are found at the end.
2. The code later uses "return new String(bytes, 0, length);"
to create a String, without specifying any encoding.
I guess that the Platform default encoding nowadays is UTF-8.
Or maybe it makes sense to use the default encoding, as people edit
those files, using whatever default encoding they prefer.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 11.0.0-M14
сб, 11 нояб. 2023 г. в 03:09, Konstantin Kolinko : > > чт, 9 нояб. 2023 г. в 22:58, Mark Thomas : > > > > The proposed Apache Tomcat 11.0.0-M14 release is now available for > > voting. > > > > It can be obtained from: > > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-11/v11.0.0-M14/ > > > > The Maven staging repo is: > > https://repository.apache.org/content/repositories/orgapachetomcat-1464 > > > > The tag is: > > https://github.com/apache/tomcat/tree/11.0.0-M14 > > 9108a1f6776f7211f5cd27e80b7b5a6e98116b01 > > > > > > The proposed 11.0.0-M14 release is: > > [ ] -1 Broken - do not release > > [ ] +1 Alpha - go ahead and release as 11.0.0-M14 > > Mark, > > Looking at > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-11/v11.0.0-M14/ > > *.asc files are missing for > apache-tomcat-11.0.0-M14-windows-x64.zip > apache-tomcat-11.0.0-M14.tar.gz > apache-tomcat-11.0.0-M14.zip > > I think that missing files can be downloaded from Maven staging repository. I uploaded the missing files, using the ones from Maven. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 11.0.0-M14
чт, 9 нояб. 2023 г. в 22:58, Mark Thomas : > > The proposed Apache Tomcat 11.0.0-M14 release is now available for > voting. > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-11/v11.0.0-M14/ > > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1464 > > The tag is: > https://github.com/apache/tomcat/tree/11.0.0-M14 > 9108a1f6776f7211f5cd27e80b7b5a6e98116b01 > > > The proposed 11.0.0-M14 release is: > [ ] -1 Broken - do not release > [ ] +1 Alpha - go ahead and release as 11.0.0-M14 Mark, Looking at https://dist.apache.org/repos/dist/dev/tomcat/tomcat-11/v11.0.0-M14/ *.asc files are missing for apache-tomcat-11.0.0-M14-windows-x64.zip apache-tomcat-11.0.0-M14.tar.gz apache-tomcat-11.0.0-M14.zip I think that missing files can be downloaded from Maven staging repository. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Which release artifact should we expect to be reproducible?
ср, 18 окт. 2023 г. в 14:55, Mark Thomas : > > On 17/10/2023 16:36, Mark Thomas wrote: > > > It looks like Javadoc generation is different between Linux and Windows > > with Java 21. That is still causing issues for the full-docs package for > > Tomcat 11. I'm still looking into options for fixing that. Other than > > that, I'm not seeing any reproducibility issues for those files. > > I've got as far as figuring out what is causing the problem. > > This commit > > https://github.com/openjdk/jdk/commit/e9f3e325c274f19b0f6eceea2367708e3be689e9 > > causes the files from $JAVA_HOME/legal/jdk.javadoc to be added to the > legal directory in the created javadoc. In Linux, some of those files > are symlinks so the entire file gets copied whereas in Windows some of > those files are text files that reference the symlink target. > > I am currently leaning towards writing an Ant task that will replace > those "link" files on Windows with the target of the link. It will need > to run after the Javadoc. Maybe this will be fixed in JDK itself? Essentially their fix for "8259530" (the commit that you referenced) is incomplete on Windows, and that is a legal issue. BTW, Reviewing that commit, I see that there exists a command-line option, "--legal-notices" that can be set to "none". BTW, the files can be seen in apache-tomcat-11.0.0-M13-fulldocs.tar.gz e.g. \tomcat-11.0-doc\api\legal\LICENSE is the following one nonsense line: Please see ..\java.base\LICENSE Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat 11, Java 21 and Windows 32-bit support
чт, 15 июн. 2023 г. в 12:32, Mark Thomas : > > [...] > > Given the above, I think we can safely: > > - plan to stop providing 32-bit Windows builds after 2025-10-14 > > - remove 32-bit Windows builds from Tomcat 11 > > Given that the only remaining supported 32-bit Windows operating system > is a consumer one (the last Windows server OS to support 32-bit was > Sever 2008) do we want to drop 32-bit support from any other products > and/or versions? I'm thinking about Tomcat Native, Connectors (mod_jk & > ISAPI redirector), and the earlier Tomcat versions. > > Personally, I'm leaning towards not making any further changes until > after 2025-10-14 but what does everyone else think? > > Thoughts? Regarding 32-bit Java on Windows, my experience is 1. I still have Java 7 (32-bit) installed, and I use it to test Tomcat 8.5. I do not know about any 64-bit versions of Java 7 being available. I plan to uninstall it once Tomcat 8.5 reaches EOL. 2. I have 32-bit Java 8 (provided by Temurin) installed, for the sake of occasionally running some legacy software. (Software that is based on old 32-bit versions of Eclipse RCP platform. That platform has native components in it (SWT). Thus it is tied to a specific processor architecture). I occasionally use this 32-bit Java 8 to test Tomcat 9. I remember fixing some tests that did not pass with memory limitations of a 32-bit JRE. I do not run Tomcat 9 on 32-bit Java for any business purpose. 3. I do not use 32-bit Java 11, though I know that it is available from Temurin. I never tested Tomcat 10.1 with it. 4. I wonder about the Windows 10 EOL date. I know some places that still use Windows XP. (It is hard to upgrade the OS on existing legacy hardware.) Thus 1. I think that providing 32-bit Windows support for Tomcat 9 (and Tomcat Native 1.2.x) has a value, as long as it continues to run on Java 8. We may reconsider if some Tomcat 9.y.x version will require a later version of Java. 2. I wonder about Tomcat 10.1 and Java 11. As a starter, we may stop publishing "apache-tomcat-10.1.x-windows-x86.zip" archives and see if anyone cares. 3. I am +1 for removing 32-bit support from Tomcat 11 onwards. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Potentially useful filter for debugging, etc.
вт, 6 июн. 2023 г. в 13:43, Mark Thomas : > > devOn 02/06/2023 18:55, Christopher Schultz wrote: > > Mark, > > > > On 6/2/23 11:00, Mark Thomas wrote: > >> On 02/06/2023 15:35, Christopher Schultz wrote: > >>> All, > >>> > >>> I've built a Filter for use with a client who has many environments, > >>> many reverse proxies, and many application servers and were getting > >>> confused about what was what. > >>> I think that Chris wants to be able to trace origins of responses. >From what servers they originated (and maybe what proxies it came through). "Adding a header" generally can be done by the well-known "urlrewrite" filter. Or by mod_header at Apache HTTPD. Is there any interest in implementing just "adding a header"? Is it the logic of managing the "Via" header that makes it interesting? BTW, specification of the Via header: https://www.rfc-editor.org/rfc/rfc9110.html#name-via Generally, there will be other proxies in front of Tomcat. Woldn't it be better to have the logic on those servers? It is rare to use Tomcat itself as a proxy. As a preceding example I am thinking about "Ray IDs" as used by Cloudflare: https://developers.cloudflare.com/fundamentals/get-started/reference/cloudflare-ray-id/ Those are hashed. It also looks like those IDs are assigned per-request. Essentially, unique IDs for requests. The general usage seems to be that the IDs are logged, and are analyzed afterwards. BTW, as an alternative, there exists the "Server" header, For an HTTP connector it can be configured with "server" and "serverRemoveAppProvidedValues" attributes on a Connector. It seems that there is no configuration for an AJP Connector. https://tomcat.apache.org/tomcat-10.1-doc/config/http.html#Standard_Implementation Specification: https://www.rfc-editor.org/rfc/rfc9110.html#name-server Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Utility Executor
пт, 28 апр. 2023 г. в 16:21, Konstantin Kolinko :
>
> чт, 27 апр. 2023 г. в 19:34, Mark Thomas :
> >
> > Hi all,
> >
> > As part of a discussion around a Spring Boot issue [1], the question has
> > been raised whether there is merit in moving the Utility executor
> > start/stop from StandardServer init/destroy to start/stop.
> >
> > I've looked at the code and I don't see any uses of the Executor until
> > sub-components are in the start phase (there is a little copying of
> > references that might need to move) so I think the change is doable.
> >
> > The main advantage is that in the embedded scenario where there might be
> > a long series of start / stop / start / stop etc, shutting down the
> > executor on stop should avoid issues where executor tasks are not
> > shutdown correctly. My brief code review suggested that Tomcat does this
> > correctly but the executor is also exposed to application code.
> >
> > Thoughts?
> >
> > Mark
> >
> > [1] https://github.com/spring-projects/spring-boot/issues/34955
>
> +1.
>
> It sounds reasonable, and thinking about Tomcat being started by
> Commons Daemon jsvc, I think that init() should not be used to start
> utility threads.
>
> If it causes a regression (I mean, if something really needs to be
> done at init() time), one may implement a Listener.
Looking at when a Connector starts its pool of threads,
o.a.c.connector.Connector.initInternal() does
// Initialize adapter
adapter = new CoyoteAdapter(this);
protocolHandler.setAdapter(adapter);
if (service != null) {
protocolHandler.setUtilityExecutor(service.getServer().getUtilityExecutor());
}
So it also needs a change.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Utility Executor
чт, 27 апр. 2023 г. в 19:34, Mark Thomas : > > Hi all, > > As part of a discussion around a Spring Boot issue [1], the question has > been raised whether there is merit in moving the Utility executor > start/stop from StandardServer init/destroy to start/stop. > > I've looked at the code and I don't see any uses of the Executor until > sub-components are in the start phase (there is a little copying of > references that might need to move) so I think the change is doable. > > The main advantage is that in the embedded scenario where there might be > a long series of start / stop / start / stop etc, shutting down the > executor on stop should avoid issues where executor tasks are not > shutdown correctly. My brief code review suggested that Tomcat does this > correctly but the executor is also exposed to application code. > > Thoughts? > > Mark > > [1] https://github.com/spring-projects/spring-boot/issues/34955 +1. It sounds reasonable, and thinking about Tomcat being started by Commons Daemon jsvc, I think that init() should not be used to start utility threads. If it causes a regression (I mean, if something really needs to be done at init() time), one may implement a Listener. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Getting listed under "Compatible Implementations" at Jakarta EE
Hi! Looking at the following specifications https://jakarta.ee/specifications/servlet/6.0/ https://jakarta.ee/specifications/pages/3.1/ https://jakarta.ee/specifications/expression-language/5.0/ https://jakarta.ee/specifications/websocket/2.1/ https://jakarta.ee/specifications/authentication/3.0/ I wonder why Apache Tomcat 10.1 is not listed under "Compatible Implementations". Maybe "Compatible Implementations" is a list of projects related to the voting process for that specification. But as such description (comment or disclaimer) is missing, it is odd to do not see Tomcat there. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Reduce default for maxParameterCount
ср, 22 мар. 2023 г. в 14:38, Mark Thomas :
>
> Any more thoughts on this?
>
1. If we cannot agree on the required behaviour, it is one more reason
to make it configurable.
As I said, it would be more useful to configure it at a Context.
2. Regarding the default behaviour,
Throwing an exception was also my first thought,
and it seems more natural.
Regarding implementation, I thought that in
org.apache.catalina.connector.Request all lines
if (!parametersParsed) {
parseParameters();
}
could be amended with "if (parseFailed) throw new
IllegalStateException(parseFailedReason)", or maybe put this "throw"
into parseParameters().
BTW, Spring Framework has a feature that routing of requests can be
configured with annotations.
https://docs.spring.io/spring-framework/docs/5.3.25/reference/html/web.html#mvc-ann-requestmapping-params-and-headers
In this case parameters parsing is hidden from the caller (done by
framework), and also a Request may be omitted from method signature
(so one wouldn't check its attributes to check for failed parsing). In
this case it makes sense to throw an exception to report a failure.
3. Regarding UserDataHelper,
1) If we rely on it, it means being too late.
At the time one considers reading the logs, data loss has already happened.
2) If you look at my mail regarding code paths (7th email in this thread),
if I have read the code correctly, I think that in case of
"d) Request.getParameter() was called, and request was "multipart/form-data"."
there is no logging.
4. Regarding the value for maxParameterCount
500 parameters may mean 100 rows of 5 values each;
100 rows may mean daily values for 3 months.
1000 parameters may mean a year of daily data with 3 values each day.
It is not what one would frequently see in practice, but it could happen.
> There hasn't been much movement from the spec EG on this, so my current
> thinking is to revert this change for 10.1.x and earlier to wait and see
> what the Servlet EG decides.
>
5. If someone is thinking about improved API,
a) I wonder whether ExtendedAccessLogValve calling of getParameter()
could be improved,
so that it does not trigger parameter parsing that includes reading
the body of a POST.
Or maybe do reading, but with a lower timeout. Essentially in the same
way as when skipping a body of a failed request.
It is not a job for an AccessLogValve to spend time on parameter parsing.
b) I wonder whether parameter parsing could be done asynchronously.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Reduce default for maxParameterCount
ср, 15 мар. 2023 г. в 13:15, Konstantin Kolinko : > > [...] > > -1 unless the behaviour of "silently dropping extra parameters" is > changed as well. > > Silent loss of data is not what I want to see in production. > > Documentation [1] says "Request parameters beyond this limit will be ignored." > [1] https://tomcat.apache.org/tomcat-8.5-doc/config/http.html > [OT] A bit of humour, regarding loss of data. A fragment of Mel Brooks' movie "History of the World, Part I" https://www.youtube.com/watch?v=w556vrpsy4w Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Reduce default for maxParameterCount
ср, 15 мар. 2023 г. в 13:29, Konstantin Kolinko :
>
> ср, 15 мар. 2023 г. в 13:15, Konstantin Kolinko :
> >
> > ср, 15 мар. 2023 г. в 12:07, Mark Thomas :
> > >
> > > On 14/03/2023 21:13, Christopher Schultz wrote:
> > > > Mark,
> > > >
> > > > On 3/14/23 13:57, Mark Thomas wrote:
> > > >> On 09/03/2023 14:23, Christopher Schultz wrote:
> > > >>> Mark,
> > > > >
> > > > > []
> > > >
> > > > I would go for a 1000 limit for all currently-supported versions. It's
> > > > *very* easy to raise the limit if it interferes with a specific
> > > > application's functions.
> > > >
> > > > I *would* add an entry in the "notable changes" for each release e.g.
> > > > https://tomcat.apache.org/migration-10.1.html#Tomcat_10.1.x_noteable_changes
> > >
> > > Makes sense.
> > >
> > > I'll do that.
> >
> > -1 unless the behaviour of "silently dropping extra parameters" is
> > changed as well.
> >
> > Silent loss of data is not what I want to see in production.
> >
> > Documentation [1] says "Request parameters beyond this limit will be
> > ignored."
> > [1] https://tomcat.apache.org/tomcat-8.5-doc/config/http.html
> >
> > More details shortly.
>
> First, some notes regarding the source code.
>
> (1) The limit is enforced in
> org.apache.tomcat.util.http.Parameters#addParameter().
>
> It throws an IllegalStateException which is either caught and retrown
> later, or caught and swallowed.
>
> (2) I see the following 4 code paths and cases:
>
> []
>
> Proposals shortly.
Additional notes:
(4) In general, there are the following kinds of errors:
- decoding errors (format errors),
- hitting limits (such as max parameter count),
- i/o errors (client disconnect).
Looking at org.apache.tomcat.util.http.Parameters.FailReason (used by
FailedRequestFilter), it is
public enum FailReason {
CLIENT_DISCONNECT,
MULTIPART_CONFIG_INVALID,
INVALID_CONTENT_TYPE,
IO_ERROR,
NO_NAME,
POST_TOO_LARGE,
REQUEST_BODY_INCOMPLETE,
TOO_MANY_PARAMETERS,
UNKNOWN,
URL_DECODING
}
(5) Skipping parameters due to decoding errors has potential for abuse,
similar to a known trick used by phishers,
combining a well-known site name in an URL with junk. E.g.
http://www.microsoft.com.blabla.phisher.site
http://www.microsoft@blabla.phisher.site
E.g.
http://foo.bar?par1=...=safety
and one is able to trigger ignoring "par2", it may be abused.
Proposals:
1. I think that maxParameterCount would better be configured per-Context.
The count of parameters is a property of a specific web application.
2. I wonder if we can make handling of the errors configurable.
I think that the following options are possible:
a) Drop parameters that exceeded the limit, or failed to decode.
b) If there is any error, ignore all parameters and behave as if none
were provided.
c) Blow up by throwing a RuntimeException for any call to
Request.getParameter() methods.
It may be an IllegalStateException.
My first thought was to go with c). I know that it contradicts with
Servlet API JavaDoc, but if it is configurable then it is a possible
option. I suppose that a web application should have error handling
configured and should be able to deal with errors.
If we go with c), it requires adding try/catch to safeguard
getParameter() calls in the following classes of Tomcat:
- org.apache.catalina.filters.FailedRequestFilter
- org.apache.catalina.valves.ExtendedAccessLogValve
(The ExtendedAccessLogValve can be configured to log the value of a parameter.)
3. I propose to change the default behaviour to b), "ignoring all parameters".
The loss of data will be clearly visible to the applications. It would
not go unnoted.
Even if one has not configured a FailedRequestFilter (or implemented
similar login in their own way) in their web application.
In case if no web application is matched to a request (no Context
configured), ignoring all parameters is a good default, as they won't
be processed.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Reduce default for maxParameterCount
ср, 15 мар. 2023 г. в 13:15, Konstantin Kolinko : > > ср, 15 мар. 2023 г. в 12:07, Mark Thomas : > > > > On 14/03/2023 21:13, Christopher Schultz wrote: > > > Mark, > > > > > > On 3/14/23 13:57, Mark Thomas wrote: > > >> On 09/03/2023 14:23, Christopher Schultz wrote: > > >>> Mark, > > >>> > > >>> On 3/9/23 05:56, Mark Thomas wrote: > > >>>> Hi all, > > >>>> > > >>>> In the context of CVE-2023-24998 (performance issues for large > > >>>> numbers of uploaded parts), I have been wondering about reducing the > > >>>> default value for maxParameterCount. > > >>>> > > >>>> The current default for maxParameterCount is 10,000. It was set > > >>>> based on it being low enough to mitigate CVE-2012-0022 (hash > > >>>> collisions in parameter names triggering performance issues) while > > >>>> being so high it was considered extremely unlikely to impact any web > > >>>> application. > > >>> > > >>> Also relevant: maxPostSize and maxHttpRequestHeaderSize which help to > > >>> limit the total size of a request, regardless of the number of > > >>> parameters. > > >> > > >> I don't think we can lower those any further by default. If anything, > > >> the trend is towards making them larger. > > >> > > >>>> The current default is sufficiently low to mitigate CVE-2023-24998. > > >>>> > > >>>> There isn't any reason I am aware of that means we need to reduce > > >>>> the default for maxParameterCount. My thinking is more along the > > >>>> lines that when we last thought about this default in 2012, it was > > >>>> considered from the perspective of "How high can we set this and > > >>>> still be sure applications aren't exposed to CVE-2012-0022 or > > >>>> something like it?". If we consider it from the perspective of "How > > >>>> low can we make this without breaking many / most / (nearly) all > > >>>> applications?" I think we'll choose a much lower number. > > >>> > > >>> +1 > > >>> > > >>>> Another benefit of a lower number is to harden Tomcat in advance > > >>>> against future vulnerabilities like CVE-2023-24998. > > >>>> > > >>>> I was wondering about a new default of 1000 or maybe even 500. > > >>>> > > >>>> This would certainly be for 11.0.x. I think it should be back-ported > > >>>> but maybe in stages (5000, 3000, 2000, 1000) and/or delayed so it is > > >>>> reduced in 10.1.x for a few releases before we reduce it in 9.0.x > > >>>> and the a few more releases before we reduce it in 8.5.x. > > >>>> > > >>>> Thoughts? > > >>> > > >>> +1 for 1000. 500 seems insane to me but I'm sure there is some > > >>> application out there which uses 1000 parameters instead of JSON, > > >>> etc. for some reason. > > >> > > >> I've reduced the default to 1,000 for 11.0.x. > > >> > > >> Thoughts on if/how to back-port this to 10.1.x and friends? > > >> > > >> Straight to 1000 for all older versions? > > >> Straight to 1000 for 10.1.x then wait a few releases for each further > > >> backport? > > >> Or more cautious and backport a gradual reduction? > > > > > > I would go for a 1000 limit for all currently-supported versions. It's > > > *very* easy to raise the limit if it interferes with a specific > > > application's functions. > > > > > > I *would* add an entry in the "notable changes" for each release e.g. > > > https://tomcat.apache.org/migration-10.1.html#Tomcat_10.1.x_noteable_changes > > > > Makes sense. > > > > I'll do that. > > -1 unless the behaviour of "silently dropping extra parameters" is > changed as well. > > Silent loss of data is not what I want to see in production. > > Documentation [1] says "Request parameters beyond this limit will be ignored." > [1] https://tomcat.apache.org/tomcat-8.5-doc/config/http.html > > More details shortly. First, some notes regarding the source code. (1) The limit is enforced in org.apache.tomcat.util.http.Parameters#addParameter().
Re: Reduce default for maxParameterCount
ср, 15 мар. 2023 г. в 12:07, Mark Thomas : > > On 14/03/2023 21:13, Christopher Schultz wrote: > > Mark, > > > > On 3/14/23 13:57, Mark Thomas wrote: > >> On 09/03/2023 14:23, Christopher Schultz wrote: > >>> Mark, > >>> > >>> On 3/9/23 05:56, Mark Thomas wrote: > >>>> Hi all, > >>>> > >>>> In the context of CVE-2023-24998 (performance issues for large > >>>> numbers of uploaded parts), I have been wondering about reducing the > >>>> default value for maxParameterCount. > >>>> > >>>> The current default for maxParameterCount is 10,000. It was set > >>>> based on it being low enough to mitigate CVE-2012-0022 (hash > >>>> collisions in parameter names triggering performance issues) while > >>>> being so high it was considered extremely unlikely to impact any web > >>>> application. > >>> > >>> Also relevant: maxPostSize and maxHttpRequestHeaderSize which help to > >>> limit the total size of a request, regardless of the number of > >>> parameters. > >> > >> I don't think we can lower those any further by default. If anything, > >> the trend is towards making them larger. > >> > >>>> The current default is sufficiently low to mitigate CVE-2023-24998. > >>>> > >>>> There isn't any reason I am aware of that means we need to reduce > >>>> the default for maxParameterCount. My thinking is more along the > >>>> lines that when we last thought about this default in 2012, it was > >>>> considered from the perspective of "How high can we set this and > >>>> still be sure applications aren't exposed to CVE-2012-0022 or > >>>> something like it?". If we consider it from the perspective of "How > >>>> low can we make this without breaking many / most / (nearly) all > >>>> applications?" I think we'll choose a much lower number. > >>> > >>> +1 > >>> > >>>> Another benefit of a lower number is to harden Tomcat in advance > >>>> against future vulnerabilities like CVE-2023-24998. > >>>> > >>>> I was wondering about a new default of 1000 or maybe even 500. > >>>> > >>>> This would certainly be for 11.0.x. I think it should be back-ported > >>>> but maybe in stages (5000, 3000, 2000, 1000) and/or delayed so it is > >>>> reduced in 10.1.x for a few releases before we reduce it in 9.0.x > >>>> and the a few more releases before we reduce it in 8.5.x. > >>>> > >>>> Thoughts? > >>> > >>> +1 for 1000. 500 seems insane to me but I'm sure there is some > >>> application out there which uses 1000 parameters instead of JSON, > >>> etc. for some reason. > >> > >> I've reduced the default to 1,000 for 11.0.x. > >> > >> Thoughts on if/how to back-port this to 10.1.x and friends? > >> > >> Straight to 1000 for all older versions? > >> Straight to 1000 for 10.1.x then wait a few releases for each further > >> backport? > >> Or more cautious and backport a gradual reduction? > > > > I would go for a 1000 limit for all currently-supported versions. It's > > *very* easy to raise the limit if it interferes with a specific > > application's functions. > > > > I *would* add an entry in the "notable changes" for each release e.g. > > https://tomcat.apache.org/migration-10.1.html#Tomcat_10.1.x_noteable_changes > > Makes sense. > > I'll do that. -1 unless the behaviour of "silently dropping extra parameters" is changed as well. Silent loss of data is not what I want to see in production. Documentation [1] says "Request parameters beyond this limit will be ignored." [1] https://tomcat.apache.org/tomcat-8.5-doc/config/http.html More details shortly. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: tomcat-native v2.0+ breaks unix domain socket support on java16-
вт, 7 мар. 2023 г. в 02:01, Graham Leggett : > > Hi all, > > A while back I added unix domain socket support to tomcat-native, and patched > tomcat to use it until java16 is available. Java 17 (LTS) is already available for a while. Is it available for your platform? > Unfortunately unix domain socket support was removed from tomcat-native 2.0+, > and now tomcat-native 2.0+ is appearing in distros, meaning that unix domain > socket support just broke. > > https://tomcat.apache.org/native-doc/miscellaneous/changelog.html > > "Remove all API methods (and supporting code) that are not used by Tomcat > 10.1.x to support the use of OpenSSL as a replacement for JSSE to provide TLS > functionality. (markt)” > > Is there a way to fix this, or has tomcat just broken everything for anyone > in a RHEL environment? Tomcat 9.0 and 8.5 are expected to run with Tomcat Native 1.2.x and that version is still supported. (They can run with Tomcat Native 2.0.x as long as APR connector is not used). Tomcat Native 2.0 is the version used by Tomcat 10.1.x and beyond. Tomcat 10.1.x does not have the APR connector. It has only NIO and NIO2. The APR connector has been removed. Is your Tomcat failing to start because it is explicitly configured to use the APR connector (Http11AprProtocol, AjpAprProtocol)? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch main updated: Align with spec
вт, 7 мар. 2023 г. в 10:14, Han Li : > > > > > On Mar 7, 2023, at 14:39, Konstantin Kolinko wrote: > > > > вт, 7 мар. 2023 г. в 09:17, mailto:li...@apache.org>>: > >> > >> This is an automated email from the ASF dual-hosted git repository. > >> > >> lihan pushed a commit to branch main > >> in repository https://gitbox.apache.org/repos/asf/tomcat.git > >> > >> > >> The following commit(s) were added to refs/heads/main by this push: > >> new 1fc4b7c95d Align with spec > >> 1fc4b7c95d is described below > >> > >> commit 1fc4b7c95dce1db3d86db9393c78023b93725f63 > >> Author: lihan > >> AuthorDate: Tue Mar 7 14:16:53 2023 +0800 > >> > >> Align with spec > > > > -1 (veto) > > > > Please revert. > Ok. > > > > The text of the specification comes with a license. > > > > I have not checked recently (with the spec is managed by Eclipse > > Foundation), but in earlier times (for specs copyrighted by Oracle) it > > was clear that you were not allowed to copy their text as you wish. > > > > You are not the first one to make such changes. There were similar > > discussions in earlier years. > > I probably understand what means, and I have another question that if I just > align code with spec there’s no problem, right? > Regarding javadoc, I think it is OK to document what Tomcat does. (What it has to do is dictated by the spec, but what it actually does is our implementation details, and can be documented). Regarding code, If you are talking about alignment of method signatures, those should already have been aligned. I know that the TCK (i.e. the set of tests that comes with specification) has tests that check signatures of all methods. As Tomcat was tested with TCK some time ago, I think those methods have already been tested. If you are talking about alignment of implementation details, there is no reason to do so, The specification is just a document (pdf) plus javadoc (and method signatures documented there), and a set of tests (TCK). If you are looking at the code that comes with the spec, that code is just a "reference implementation", serves as an example and does not define any required behaviour. If there is a bug, i.e. behaviour of Tomcat differs with that is dictated by official javadoc, it is a bug, and should be fixed as such. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch main updated: Align with spec
вт, 7 мар. 2023 г. в 09:17, : > > This is an automated email from the ASF dual-hosted git repository. > > lihan pushed a commit to branch main > in repository https://gitbox.apache.org/repos/asf/tomcat.git > > > The following commit(s) were added to refs/heads/main by this push: > new 1fc4b7c95d Align with spec > 1fc4b7c95d is described below > > commit 1fc4b7c95dce1db3d86db9393c78023b93725f63 > Author: lihan > AuthorDate: Tue Mar 7 14:16:53 2023 +0800 > > Align with spec -1 (veto) Please revert. The text of the specification comes with a license. I have not checked recently (with the spec is managed by Eclipse Foundation), but in earlier times (for specs copyrighted by Oracle) it was clear that you were not allowed to copy their text as you wish. You are not the first one to make such changes. There were similar discussions in earlier years. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 10.1.7
пн, 27 февр. 2023 г. в 23:57, Christopher Schultz : > > The proposed Apache Tomcat 10.1.7 release is now available for > voting. > > The notable changes compared to 10.1.6 are: > > - Revert the switch to using the ServiceLoader mechanism to load the > custom URL protocol handlers that Tomcat uses. The original system > property based approach has been restored. > > - Restore inline state after async operation in NIO2, to account the > fact that unexpected exceptions are sometimes thrown by the > implementation. Patch submitted by zhougang. > > - Provide a more appropriate response (501 rather than 400) when > rejecting an HTTP request using the CONNECT method. > > - Add support for txt: and rnd: rewrite map types from mod_rewrite. > Based on a pull request provided by Dimitrios Soumis. > > For full details, see the change log: > https://nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html > > Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 > without changes. Java EE applications designed for Tomcat 9 and earlier > may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat > will automatically convert them to Jakarta EE and copy them to the > webapps directory. > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.7/ > > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1426 > > The tag is: > https://github.com/apache/tomcat/tree/10.1.7 > 473ef42c637c97eb17b38c5580a6b854dfe27a02 > > The proposed 10.1.7 release is: > [ ] Broken - do not release > [x] Stable - go ahead and release as 10.1.7 Smoke tests OK with Java 11.0.18. Unit tests OK with Java 11.0.18, all connectors (NIO, NIO2) on Windows 10. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.87
пн, 27 февр. 2023 г. в 23:12, Christopher Schultz : > > The proposed Apache Tomcat 8.5.87 release is now available for voting. > > The notable changes compared to 8.5.86 are: > > - Correct a regression introduced in the fix for bug 66196 that > meant that the HTTP headers and/or request line could get > corrupted (one part overwriting another part) within a single > request. > > - Provide a more appropriate response (501 rather than 400) when > rejecting an HTTP request using the CONNECT method. > > - Add support for txt: and rnd: rewrite map types from mod_rewrite. > Based on a pull request provided by Dimitrios Soumis. > > Along with lots of other bug fixes and improvements. > > For full details, see the changelog: > https://nightlies.apache.org/tomcat/tomcat-8.5.x/docs/changelog.html > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.87/ > > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1424 > > The tag is: > https://github.com/apache/tomcat/tree/8.5.87/ > 9179f3c22aead8702936eace5c46e8860b644b3c > > The proposed 8.5.87 release is: > [ ] Broken - do not release > [ ] Stable - go ahead and release as 8.5.86 (stable) > [x] Stable - go ahead and release as 8.5.87 (stable) Smoke tests OK with Java 7u80 (32-bit) Unit test OK with Java 11.0.18, all connectors (APR, NIO, NIO2) on Windows 10. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 9.0.73
пн, 27 февр. 2023 г. в 18:52, Rémy Maucherat : > > The proposed Apache Tomcat 9.0.73 release is now available for voting. > > The notable changes compared to 9.0.72 are: > > - Correct a regression introduced in the fix for bug > 66196 that meant that the HTTP headers and/or request line > could get corrupted (one part overwriting another part) within a single > request. > > - Provide a more appropriate response (501 rather than 400) when rejecting > an HTTP request using the CONNECT method. > > - Add support for txt: and rnd: rewrite map types from mod_rewrite. Based > on a pull request provided by Dimitrios Soumis. > > Along with lots of other bug fixes and improvements. > > For full details, see the changelog: > https://nightlies.apache.org/tomcat/tomcat-9.0.x/docs/changelog.html > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.73/ > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1422 > The tag is: > https://github.com/apache/tomcat/tree/9.0.73 > 5452041bb674b46ea1390ee86b8f846728ec1236 > > The proposed 9.0.73 release is: > [ ] Broken - do not release > [x] Stable - go ahead and release as 9.0.73 Smoke tests OK with Java 8u362. Unit tests OK with Java 11.0.18, all connectors (APR, NIO, NIO2) on Windows 10. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [ANN] Apache Tomcat 9.0.72 available
пн, 27 февр. 2023 г. в 10:52, Rémy Maucherat : > > On Thu, Feb 23, 2023 at 2:14 PM Rémy Maucherat wrote: > > > > The Apache Tomcat team announces the immediate availability of Apache > > Tomcat 9.0.72. > > > > Apache Tomcat 9 is an open source software implementation of the Java > > Servlet, JavaServer Pages, Java Unified Expression Language, Java > > WebSocket and JASPIC technologies. > > > > Apache Tomcat 9.0.72 is a bugfix and feature release. The notable > > changes compared to 9.0.71 include: > > > > - Add an error report valve that allows redirecting to or proxying from an > > external web server. > > > > - Log basic information for each configured TLS certificate when > > Tomcat starts. > > > > - Add the shared address space specified by RFC 6598 (100.64.0.0/10) > >to the list of trusted proxies for RemoteIPValve/Filter. > > > > - Limit access to the examples web application to localhost by default. > > > > Along with lots of other bug fixes and improvements. > > > > Please refer to the change log for the complete list of changes: > > https://tomcat.apache.org/tomcat-9.0-doc/changelog.html > > > > > > Downloads: > > https://tomcat.apache.org/download-90.cgi > > > > Migration guides from Apache Tomcat 7.x and 8.x: > > https://tomcat.apache.org/migration.html > > Since it seems there are two identified regressions in 9.0.72, I plan > to swap 9.0.71 back in on the website (and dlcdn) while things get > fixed and we produce 9.0.73. > > Comments ? If you are about https://bz.apache.org/bugzilla/show_bug.cgi?id=66488 9.0.71 is affected as well, so rolling back to it won't help. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 10.1.6
вс, 19 февр. 2023 г. в 17:11, Christopher Schultz : > > The proposed Apache Tomcat 10.1.6 release is now available for > voting. > > The notable changes compared to 10.1.5 are: > > - Switch to using the ServiceLoader mechanism to load the custom URL >protocol handlers that Tomcat uses. > > - Update the packaged version of the Apache Tomcat Native Library to >2.0.3 to pick up the Windows binaries built with with OpenSSL 3.0.8. > > - Add the shared address space specified by RFC 6598 (100.64.0.0/10) >to the list of trusted proxies for RemoteIPValve/Filter. > > - Limit access to examples web application to localhost by default and documentation > > For full details, see the change log: > https://nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html > > Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 > without changes. Java EE applications designed for Tomcat 9 and earlier > may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat > will automatically convert them to Jakarta EE and copy them to the > webapps directory. > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.6/ > > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1421 > > The tag is: > https://github.com/apache/tomcat/tree/10.1.6 > 9829c929059f96605a3fb870700b5887970d7203 > > The proposed 10.1.6 release is: > [ ] Broken - do not release > [x] Stable - go ahead and release as 10.1.6 Smoke tests OK with Java 11.0.18. Unit tests OK, all connectors (NIO, NIO2), with or without Tomcat Native, with Java 11.0.18. on Windows 10. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 9.0.72
сб, 18 февр. 2023 г. в 12:46, Rémy Maucherat : > > The proposed Apache Tomcat 9.0.72 release is now available for voting. > > The notable changes compared to 9.0.71 are: > > - Add an error report valve that allows redirecting to or proxying from an >external web server. > > - Log basic information for each configured TLS certificate when >Tomcat starts. > > Along with lots of other bug fixes and improvements. > > For full details, see the changelog: > https://nightlies.apache.org/tomcat/tomcat-9.0.x/docs/changelog.html > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.72/ > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1418 > The tag is: > https://github.com/apache/tomcat/tree/9.0.72 > 7754d319b2a8866b5bcdf1ea0f35e68470320295 > > The proposed 9.0.72 release is: > [ ] Broken - do not release > [x] Stable - go ahead and release as 9.0.72 Smoke tests OK with Java 8u362, Tomcat Native enabled, Unit tests OK with Java 11.0.18, all connectors, on Windows 10. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.86
сб, 18 февр. 2023 г. в 16:57, Christopher Schultz : > > The proposed Apache Tomcat 8.5.86 release is now available for voting. > > The notable changes compared to 8.5.85 are: > > - Add an error report valve that allows redirecting to or proxying from >an external web server. > > - Add the shared address space specified by RFC 6598 (100.64.0.0/10) >to the list of trusted proxies for RemoteIPValve/Filter. > > - Log basic information for each configured TLS certificate when >Tomcat starts. > > - Limit access to examples web application to localhost by default and documentation web application as well > > Along with lots of other bug fixes and improvements. > > For full details, see the changelog: > https://nightlies.apache.org/tomcat/tomcat-8.5.x/docs/changelog.html > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.86/ > > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1419 > > The tag is: > https://github.com/apache/tomcat/tree/8.5.86/ > 0bf2722f4652674e321a0e22e72dca75d2ea8275 > > The proposed 8.5.86 release is: > [ ] Broken - do not release > [x] Stable - go ahead and release as 8.5.86 (stable) Smoke tests OK with Java 7u80, Tomcat Native enabled, on Windows 10. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 10.1.6
пн, 20 февр. 2023 г. в 16:16, Christopher Schultz : > > All, > > I'm getting a failure on > jakarta.servlet.http.TestHttpServletDoHeadValidWrite0.NIO on Windows > > Looks like 11 failures all of the form: > >Failed to delete at least one file > > I'm assuming that this is a spurious error, but the test keeps failing > at that point and stopping, despite having test.haltonfailure=false in > my build.properties file. > > When running ant test-status, I get only 4 tests shown under "test > suites with failed tests" and nothing showing elsewhere. A very small > number of other TEST-*.txt files exist in the logs/ directory. > > Any suggestions? Is it a virtual machine? Are other tests mentioned in the console output of Ant? Can it be that "hard drive" is full, so no more logs could be written? JVM crashed? Version of java, version of Ant =? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: February release round
вт, 31 янв. 2023 г. в 20:52, Mark Thomas : > > Hi all, > > As I started to think about preparing for the February release round, I > received the notification from the OpenSSL project that they have a > security release planned for a week today. That security release may (or > may not) trigger a Tomcat Native release. 1. A mail on OpenSSL announcements mail list says: "on Tuesday 7th February 2023 between 1300-1700 UTC." https://mta.openssl.org/pipermail/openssl-announce/2023-January/000248.html 2. There were releases of APR 1.7.1, and of APR Utils a day ago. CVE-2022-28331 fixed in APR 1.7.1 mentions "apr_socket_sendv()", and that function is used in Tomcat Native 1.2.x (and not used in Tomcat Native 2.0.x). Current Tomcat Native binaries are built with APR 1.7.0. Thus I think releases of both 1.2.x and 2.0.x branches will be needed. > I was wondering whether to delay the February release round in case we > need to pick up an new Tomcat Native release. It really only affects > Windows users since everyone else builds their own Tomcat Native > library. In the Windows case it is trivial to update the library if > required so I'm not sure if it merits delaying the releases... > > Thoughts? I am available to test and vote for Tomcat 8.5 and 9.0. I have no plans for Tomcat 10.1 and 11 now. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch main updated: Update the default HEAD response to exclude payload headers
чт, 19 янв. 2023 г. в 23:41, :
changelog.xml
> index 7570715faa..9fd2f679a3 100644
> --- a/webapps/docs/changelog.xml
> +++ b/webapps/docs/changelog.xml
> @@ -125,6 +125,10 @@
> Implement the new Servlet API methods for setting character encodings
> that accept {@code Charset} objects. (markt)
>
> +
> +The default HEAD response no longer includes the payload HTTP header
> +fields as per section 9.3.2 of RFC 9110. (markt)
> +
1. I think that you are actually referring to section 4.3.2."HEAD" of RFC 7231.
I do see words (an explicit "MAY") that allow such behaviour in
4.3.2.of RFC 7231,
but I fail to see them in 9.3.2 of RFC 9110.
I mean that RFC 7231 explicitly says
"except that the payload header fields (Section 3.3) MAY be omitted"
I do not see such words in RFC 9110.
and I do not see the term "payload HTTP header fields" (as mentioned
in our changelog) in RFC 9110.
I wish that RFC 9110 were more clear.
2. Trying to investigate, I see the following:
1) According to "B.3. Changes from RFC 7231" of RFC 9110, there was a
rename of terms:
[quote]
The terms "payload" and "payload body" have been replaced with
"content", to better align with its usage elsewhere (e.g., in field
names) and to avoid confusion with frame payloads in HTTP/2 and
HTTP/3. (Section 6.4)
[/quote]
2) A consequence is that "3.3. Payload Semantics" of RFC 7231 became
"6.4.1. Content Semantics " in RFC 9110.
The table listing "Payload header fields" in section 3.3 of RFC 7231
is gone in RFC 9110, and the term is gone.
3. I wonder whether it makes sense to make this feature configurable.
- I do not like it to be configurable, but I have a vague feeling that
I "know" about Content-Length header in responses to HEAD requests,
and that I used it for something, but I do not remember the details.
If one really used the value, I agree that such code (relying on a
Content-Length header received in response to a HEAD request) is
fragile. Has anyone seen such code in the wild?
- I agree that removing "Content-Length" and other headers makes
sense, as it aligns these responses with other no-content responses,
and as such makes behaviour more robust (and in this sense more
secure).
As such, it makes sense to backport it to earlier versions.
- It looks that we may omit any headers per 9.3.2. of RFC 9110, and
not only those four listed in 3.3 of RFC 7231:
First, 9.3.2. of RFC 9110 says "The server SHOULD send the same header fields",
It is "SHOULD", not "MUST".
Second, it mentions as an example that the "Vary" header may differ.
- Looking for examples in the wild,
https://stackoverflow.com/a/3854872
has an example of "Content-Length" / "Transfer-Encoding" headers being
present in responses generated in 2010.
4. Maybe keep this as is for Tomcat 11, but change the words in
changelog. They should not say "payload" when referring to RFC 9110,
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.85 (round 2)
чт, 12 янв. 2023 г. в 23:17, Christopher Schultz : > > The proposed Apache Tomcat 8.5.85 release is now available for voting. > > [...] > > The notable changes compared to 8.5.84 are: > > - The default value of AccessLogValue's file encoding is >now UTF-8. Chris, 1) a typo above, Value -> Valve 2) Note the EOL announcement https://tomcat.apache.org/tomcat-85-eol.html > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.85/ > > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1416 > > The tag is: > https://github.com/apache/tomcat/tree/8.5.85/ > 7b1f4ce0b82641bf76a3d763bd97d5522513b57b > > The proposed 8.5.85 release is: > [ ] Broken - do not release > [x] Stable - go ahead and release as 8.5.85 (stable) Smoke tests OK. (Installer, Java 7, Examples). Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: HTTP/2 priorities
вт, 6 дек. 2022 г. в 19:21, Mark Thomas : > > Hi all, > > I plan to implement RFC 9218 [1] for HTTP/2 in Tomcat 11. Depending on > how that goes, I may back-port the changes. > > Given the difficulties we have in prioritizing creation of responses, I > plan to continue the current approach of prioritizing the sending of > data when the connection window size is smaller than the currently > active streams have collectively requested. > > My rough plan at this stage, which is likely to change as I work through > the implementation, is: > > - remove all the code that supports the current priority tree approach > - include SETTINGS_NO_RFC7540_PRIORITIES in the initial settings > - implement the new priority scheme - expected to be a much simpler >algorithm in Http2UpgradeHandler.allocate() > > Mark > [1] https://www.rfc-editor.org/rfc/rfc9218.html#name-priority-parameters +1 Sounds reasonable. I added a link to [1] to our Specifications page on the wiki, https://cwiki.apache.org/confluence/display/TOMCAT/Specifications Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Preparing to migrate to Tomcat 10.1 / Jakarta EE
224:public static final String
ERROR_SERVLET_NAME = "javax.servlet.error.servlet_name";
RequestDispatcher.java:234:public static final String
ERROR_STATUS_CODE = "javax.servlet.error.status_code";
ServletContext.java:58:public static final String TEMPDIR =
"javax.servlet.context.tempdir";
ServletContext.java:66:public static final String ORDERED_LIBS =
"javax.servlet.context.orderedLibs";
]]]
7. If you look into implementation of
org.apache.catalina.connector.Request#getAttibute(...), you will see
the following:
[[[
public Object getAttribute(String name) {
// Special attributes
SpecialAttributeAdapter adapter = specialAttributes.get(name);
if (adapter != null) {
return adapter.get(this, name);
}
]]]
I think that this feature could be leveraged to provide mappings for
the legacy attribute names.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.84
пт, 18 нояб. 2022 г. в 21:45, Christopher Schultz : > > Han, > > On 11/17/22 05:28, Han Li wrote: > > > > > >> 2022年11月17日 17:52，Mark Thomas 写道： > >> > >> On 17/11/2022 08:23, Han Li wrote: > >>>> 2022年11月17日 16:08，Mark Thomas 写道： > >>>> > >>>> On 17/11/2022 04:04, Han Li wrote: > >>>>> I think that I encounter a problem, shown below: > >>>>> org.apache.jasper.JasperException: Unable to compile class for JSP: > >>>>> An error occurred at line: [17] in the jsp file: [/jsp/include/foo.jsp] > >>>>> System cannot be resolved > >>>>> 14: See the License for the specific language governing permissions and > >>>>> 15: limitations under the License. > >>>>> 16: > >>>>> 17: --%><%= System.currentTimeMillis() %> > >>>>> Stacktrace: > >>>>> > >>>>> org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:102) > >>>>> > >>>>> org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:213) > >>>>> > >>>>> org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:589) > >>>>> org.apache.jasper.compiler.Compiler.compile(Compiler.java:380) > >>>>> org.apache.jasper.compiler.Compiler.compile(Compiler.java:350) > >>>>> org.apache.jasper.compiler.Compiler.compile(Compiler.java:334) > >>>>> > >>>>> org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:597) > >>>>> > >>>>> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:398) > >>>>> > >>>>> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:383) > >>>>> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:331) > >>>>> javax.servlet.http.HttpServlet.service(HttpServlet.java:765) > >>>>> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) > >>>>> > >>>>> org.apache.catalina.filters.HttpHeaderSecurityFilter.doFilter(HttpHeaderSecurityFilter.java:126) > >>>>> > >>>>> org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:109) > >>>>> Ant test show passes, but there are problems. (I downloaded 8.5.83 from > >>>>> the official website, then accessed example webapp > >>>>> and also have this problem). I don’t know JDT, but I tested again by > >>>>> upgrading ecj version to 4.25 and this > >>>>> problem was solved. > >>>> > >>>> I can't repeat this. > >>>> > >>>> I downloaded the 8.5.84 RC and then tested with Oracle JDK 1.7.0_80. The > >>>> JSP include example worked. > >>>> > >>>> I then cleared out the work directory, switched to Temurin JDK > >>>> 11.0.17_08 and tested the JSP include example. That worked too. > >>>> > >>>> I made no changes to the Eclipse compiler JAR. > >>>> > >>>> Can you provide the exact steps to recreate the issue from a clean > >>>> 8.5.84 download? > >>> There are no exact steps, just need to simply access this url: > >>> http://localhost:8080/examples/jsp/include/foo.jsp > >> > >> The Java version was the key. > >> > >> Eclispe JDT 4.6.3 can't compile JSPs under Java 17 as it can't read the > >> Java 17 class files. > >> > >> We can't update JDT as that is the latest version that works with Java 7 > >> and Tomcat 8.x has a (specification mandated) minimum Java version of 7. > >> > >> Updating the JDT locally, as you found, is the way to work around this > >> problem. > > > > Got it. > > > > In that case, I think we need to mark the upper limit of JDK version on > > documentation for 8.5.x. > > +1 > > I think we should update the web site to include a note that there is > actually a "qualified upper limit" on the Java version supported by > Tomcat 8.5.x out of the box, but you can manually-upgrade jdt to version > N which is compatible with both Tomcat 8.5.x and Java 17. Previous discussions, a year ago: https://bz.apache.org/bugzilla/show_bug.cgi?id=65599 https://lists.apache.org/thread/5489jyfry6zypr3x43qypqoxx02dqz08 > > I don't think this issue imperils this release, though. Not a stopper. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Missing recent release versions in Bugzilla
Hi! Some release managers forget the step to add the version number to Bugzilla. E.g. 10.0.26, 10.1.0 are missing. See the step in https://cwiki.apache.org/confluence/display/TOMCAT/ReleaseProcess A direct lhe link for this action is https://bz.apache.org/bugzilla/editversions.cgi I usually silently did this step, but it is not my priority at the moment. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 10.1.0-M19
вт, 13 сент. 2022 г. в 20:09, Mark Thomas : > > The proposed Apache Tomcat 10.1.0-M19 release is now available for > voting. > > [...] > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.0-M19/ *.asc files are missing at dist.a.o They were missing for 10.1.0-M18 release candidate as well. apache-tomcat-10.1.0-M19.exe is signed, OK. > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1389 *.asc files are present in the Maven staging area, OK > The tag is: > https://github.com/apache/tomcat/tree/10.1.0-M19 > ff0b6c231b7a1a416688346fdd299a3d6cfb5b64 > > > The proposed 10.1.0-M19 release is: > [ ] Broken - do not release > [ ] Beta - go ahead and release as 10.1.0-M19 (beta) Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
A "tar.bz2" file in Apache Tomcat migration tool (1.0.2)
Hi! Not a showstopper, but some oddity. Looking at Maven artifacts for release candidate of Apache Tomcat migration tool for Jakarta EE 1.0.2 in maven staging repository, I am curious why does there exist the following file: "jakartaee-migration-1.0.2-src.tar.bz2" The files: https://repository.apache.org/content/repositories/orgapachetomcat-1386/org/apache/tomcat/jakartaee-migration/1.0.2/ 1. There already exists "jakartaee-migration-1.0.2-src.tar.gz". It is the first time I see a *.bz2 file in our distributions. 2. Looking at the source code, I do not see where it comes from. pom.xml: [[[ maven-assembly-plugin 3.4.2 make-assembly single package src/assembly/bin.xml src/assembly/src.xml ]]] src/assembly/bin.xml: src/assembly/src.xml: both have the following: [[[ tar.gz zip ]]] There is no "tar.bz2" above. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Question about the log variable in Filters
ср, 31 авг. 2022 г. в 13:25, tianshuang : > > Hi, > > In this commit > <https://github.com/apache/tomcat/commit/dd44360b2ce8e5e1b79c756723158944264f556e>, > the static modifier was removed from the log variable in the Filters class, > but I don't understand why it needs to be removed. As far as I know, when a > class is loaded by different classLoader, each classLoader creates its own > instance of static variable. So, is it necessary to remove the static > modifier here? > > commit url: > https://github.com/apache/tomcat/commit/dd44360b2ce8e5e1b79c756723158944264f556e See classloader hierarchy here: https://tomcat.apache.org/tomcat-10.1-doc/class-loader-howto.html https://tomcat.apache.org/tomcat-8.5-doc/class-loader-howto.html When Webapp classloader loads the Filter class, it does not "load the class" (i.e. does not read the bytes from a jar archive and does not produce a Class out of those bytes). It delegates the task to its parent in the classloader hierarchy. Thus, the Filter class is loaded by the Common classloader. At the same time, the logging configuration for each web application may be different: A web application may provide its own copy of logging.properties file by placing it into its own WEB-INF/classes/ directory. https://tomcat.apache.org/tomcat-8.5-doc/logging.html#Using_java.util.logging_(default) Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch main updated: Improve handling of EL error messages.
quot;to be smart" and does some processing for Numbers.
(5) According to oss-fuzz we now know that such processing is broken.
It assumes that any Number can be sanely formatted by a
"NumberFormat.getInstance(locale);".
5. What to do. I see the following ways for a better workaround of the JRE bug:
(a) It is possible to narrow Mark's patch:
narrowing the type test to look for BigInteger and BigDecimal instead
of a generic Number.
On the fact that
- There are known problems with some of such numbers.
- Those classes know how to print themselves better than a NumberFormat knows.
Pros: It fixes a rare edge case, and doesn't change anything else.
Cons: I think that it breaks formatting if a pattern is using an
explicit FormatType of "number" or of "choice".
(b) It is possible to obtain formats from a MessageFormat. See the
getFormatsByArgumentIndex() method.
I propose
if the format is null then format the value with String.valueOf().
I.e. interpret "{0}" as a text format.
If it causes a regression somewhere, it is possible to update a
specific format pattern to revert to the old behaviour:
just replace {0} with {0,number} for numbers, or with a pair of
{0,date} {0, time} for dates.
I assume that the type of an argument in such patterns is known.
Pros:
- Explicitly controlled behaviour.
Cons:
- If restoring the old behaviour is required in many places,
updating all them may be a notable amount of work.
Other notes:
- The default format for Dates when printed with toString() is"dow mon
dd hh:mm:ss zzz ", as documented in Javadoc
https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Date.html#toString()
It may look uglier than the old behaviour, but no data is lost: both
date and time are printed.
- I am not handling the case of nested format patterns, i.e.
the case of ChoiceFormat in the code fragment above.
I think that usage of ChoiceFormat is rare, and that it is always used
with numbers, not with some random values of unknown type.
So I think that we are safe to ignore this case.
(c) It is possible to combine (b) with a type check,
e.g. apply it for Numbers only, but skip Dates.
Is there a worth in such behaviour?
My preference is for (b).
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Migrate from Bugzilla to GitHub Issues
чт, 18 авг. 2022 г. в 15:13, Vladimir Sitnikov : > > > 1. It is better to stay with a solution owned by ASF as much as possible. > > For political reasons such as independence. > > AFAIK, the ASF is incorporated in the USA, so the organization must > follow the USA laws. > Are you sure the ASF provides "political independence"? I mean that the mission of ASF is to be a vendor-neutral place where people (employed by different companies) can collaborate to develop free software for the public good. The mission of Microsoft (the current owner of GitHub) is that of a commercial entity, and is different from ours. What Microsoft does is governed by laws of the State of Washington, US, maybe by laws of Ireland (where is their unit that provides marketing and sales for the EMEA region), and generally by their business interests. Legally, it is expressed in their written agreements, or in public agreements such as Terms of Service, EULA etc. Sometimes corporations do what they feel is in their business interests, regardless of whether there are actual laws. ASF is governed by the laws of the State of Delaware, US, and has a different mission, public image, etc. > > GitHub is not the only git hosting service out there. > > To my best knowledge, the ASF supports only two git hosting services: > a) GitBox (see https://git.apache.org/) > b) GitHub (it any case it is mirrored to GitBox) As with ASF mailing lists, that have a number of independent archives, there can be (now or in the future) any number of git mirrors. GitBox at ASF is the main repository. GitHub is a mirror. I would be happy to accept a PR from any other git hosting service. > To my best knowledge, GitHub is the only git service that integrates > issue tracking and code hosting. GitLab is certainly there and is well-known, and anyone can create their own. It is not that hard. https://docs.gitlab.com/ee/user/project/issues/ > > Just in case, GitHub uses markdown for the format, so the emails in > text form are readable. GitHub (or maybe GitBox) sends e-mails that are titled like "[GitHub] [tomcat-jakartaee-migration] aooohan commented on issue #29: ..." The result is that they are scattered all over my GMail Inbox, are split by a user name (aooohan in this case) and action (commented, created, closed). It is hard to see the whole discussion without going to the GitHub site. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Migrate from Bugzilla to GitHub Issues
чт, 18 авг. 2022 г. в 07:57, Vladimir Sitnikov : > > Hi, > > > Have you considered migrating from Bugzilla to GitHub Issues? > I am -1. 1. It is better to stay with a solution owned by ASF as much as possible. For political reasons such as independence. As well as for redundancy etc. GitHub is not the only git hosting service out there. Also, recently there were rumors about some developers being banned from GitHub. I cannot verify whether those rumors were accurate, but overall it looked like something that may happen. > GitHub allows richer comment formatting (e.g. code highlight). 2. E-mails allowed to the mailing lists have to be plain text. E-mails from Bugzilla are easier to follow. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.82
чт, 11 авг. 2022 г. в 05:21, Han Li :
>
>
>
> > 2022年8月11日 06:52，Konstantin Kolinko 写道：
> >
> > ср, 10 авг. 2022 г. в 13:25, Han Li > <mailto:aooo...@gmail.com>>:
> >>
> >> Mark,
> >>
> >> Can I make a suggestion related to the ant build script. Can we add two
> >> properties to set the values of ` -Duser.language` and `-Duser.country`,
> >> because in the course of my testing I found that some of the unit test
> >> assertions are in English, but there may be cases where the values are
> >> converted by sm, e.g. Chinese.
> >> Just like this:
> >> Assert.assertEquals("ok”,x);
> >> The variable x becomes "好" after passing through the StringManager.
> >>
> >> So this makes it a bit inconvenient for non-English speaking developers to
> >> test. I avoid this problem by adding a statement to build.xml each time I
> >> run a test.
> >>
> >>
> >>
> >> So I was wondering if we could dynamically set these two values via
> >> build.properties
> >>
> >> Thanks,
> >>
> >> Han
> >
> > I think that such tests are just broken and require fixing.
> >
> > E.g. get an instance of StringManager and read the expected message from it.
> >
> >
> > Maybe we can add -Duser.language=zh -Duser.country=CN to ANT_OPTS in
> > some Buildbot configurations, to be able to detect such tests.
>
> Sorry, my explanation may be confusing.
>
> Let me explain why with a concrete unit test. Just like this:
> org.apache.catalina.valves.TestErrorReportValve#testBug53071
>
> ```
> Assert.assertTrue(res.toString().contains("Message " +
> ErrorServlet.ERROR_TEXT + ""));
> ```
> org.apache.catalina.valves.ErrorReportValve#report
> ```
> sb.append("");
> sb.append(smClient.getString("errorReportValve.message"));
> sb.append(" ");
> ```
> Since the local of my OS is zh-CN, the response contains `信息 `
> instead of `Message ', so I’m trying to avoid this by changing
> user.language and user.country.
> Unfortunately, I can’t find any way to do this at the moment, so I have to
> manually modify the build.xml.
>
1. I think that you could add a request header
Accept-Language: en-US
using the variant of getUrl() call that accepts a "reqHead" map.
In TomcatBaseTest:
public static int getUrl(String path, ByteChunk out, Map> reqHead,
Map> resHead) throws IOException {
2. Alternatively, using StringManager:
StringManager smClient = StringManager.getManager(
Constants.Package, request.getLocales());
where Constants is org.apache.catalina.valves.Constants
ServletRequest.getLocales() is documented as:
* header. If the client request doesn't provide an Accept-Language header,
* this method returns an Enumeration containing one
* Locale, the default locale for the server.
3. BTW, I was faxing a similar failure3 years ago,
https://github.com/apache/tomcat/commit/1758f6460a8e8fbf38b88385860379a4424cc66b
Time flies fast...
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.82
ср, 10 авг. 2022 г. в 13:25, Han Li :
>
> Mark,
>
> Can I make a suggestion related to the ant build script. Can we add two
> properties to set the values of ` -Duser.language` and `-Duser.country`,
> because in the course of my testing I found that some of the unit test
> assertions are in English, but there may be cases where the values are
> converted by sm, e.g. Chinese.
> Just like this:
>Assert.assertEquals("ok”,x);
> The variable x becomes "好" after passing through the StringManager.
>
> So this makes it a bit inconvenient for non-English speaking developers to
> test. I avoid this problem by adding a statement to build.xml each time I run
> a test.
>
>
>
> So I was wondering if we could dynamically set these two values via
> build.properties
>
> Thanks,
>
> Han
I think that such tests are just broken and require fixing.
E.g. get an instance of StringManager and read the expected message from it.
Maybe we can add -Duser.language=zh -Duser.country=CN to ANT_OPTS in
some Buildbot configurations, to be able to detect such tests.
(Though
- It would be hard to read their logs, if anything happens. As the
logs will be in Chinese.
- Such an approach assumes that there is something to detect. A
broken test is only broken for languages where translation exists and
differs from the default.)
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Question ad using System.gc()
чт, 4 авг. 2022 г. в 14:45, Rony G. Flatscher (Apache) : > > While testing a taglib library that allows javax.script languages to be used > in JSPs one observation > was directed at garbage collection. It seems that Java's garbage collection > in this particular use > case is carried out quite lazily (which is fine in the general case). There > is however a use case > where resources are not only held (and visible) by Java, but also by native > code which releases its > resources only after the Java garbage collection reclaimed the Java peer > (employing > PhantomReferences and a cleaner as finalize() has been deprecated for > removal). > > In the course of stress tests there are hundreds of ScriptEngines created > (each JSP request will > cause a ScriptEngine to be created per script language used in that JSP). It > seems that the lazily > employed gc() allows situations where there are more than 100 unreferenced > ScriptEngines tangling. > The implementation of a ScriptEngine that serves as the peer for a native > programming language > instance would employ a System.gc() in the case that 100 or more such > unreferenced ScriptEngines > exist in the currently running JVM. If resources are hard to initialize or hard to clean up it might be a good idea to pool them. Is it possible to release those resources, e.g. by implementing a Tag.release() method? Making use of tag handler pooling provided by the JSP specification / Tag Extension API for "classical" tag handlers. > > The question: would you see a problem in employing System.gc() independent of > the JVM and/or Tomcat? > Theoretically it may be invoked every second or two (unless of course the > System's garbage collector > ran and allowed the unreferenced ScriptEngine resources to be cleaned). In > practice (outside of > artificial stress tests) this may never be triggered as long as the JVM > garbage collector runs from > time to time. > Problems may be a) Overheating the Planet, by doing useless work. That is what bitcoin miners already do somewhere, so I do not think that your use case adds much. If you do a "resource.close()" call to release a resource, you are specifically doing some required work. If you call a GC (via System.gc() or maybe explicitly via JMX), some work performed by GC is useless (not resulting in any memory being freed) and some is useful. What is the balance between the useless and useful work and whether the JVM can be configured to make the balance better is what determines whether calling the GC is a good idea in your use case. E.g. it might occur that it would be cheaper to just kill the whole JVM once the memory is full and start over with a new instance. b) Getting less of performance / throughput than you desire. That is what those stress tests are supposed to let you to estimate. Just rigging the tests might be a bad idea (as VW engineers found through the Dieselgate), as it may hide a problem that may be observed by real users. > > P.S.: If this question should rather be asked in the Tomcat user list please > let me know. We do discuss "[OT]" (offtopic) questions here sometimes. And this question looks to be more related to Taglibs (a set of tag library projects under Tomcat PMC) rather than to Tomcat itself. Their development is discussed here. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Updated HTTP specifications
Hi! I updated the list of specifications in our wiki with new versions of HTTP specifications. Those were published in June 2022, along with HTTP./3. https://cwiki.apache.org/confluence/display/TOMCAT/Specifications#Specifications-HTTP,HTTP/2 RFC 9110 (June 2022) - HTTP Semantics RFC 9111 (June 2022) - HTTP Caching RFC 9112 (June 2022) - HTTP/1.1 RFC 9113 (June 2022) - HTTP/2 RFC 9114 (June 2022) - HTTP/3 Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Delay between release tags and announcement
чт, 21 июл. 2022 г. в 15:23, Christopher Schultz : > > Nemo, Mark, > > On 7/21/22 04:06, Mark Thomas wrote: > > On 21/07/2022 07:06, Nemo wrote: > > > > > > > > Generally, I'd strongly discourage anyone from assuming that GitHub tag > > == ASF release. > > I generally agree with Mark, here, with one caveat: > > It would be very easy for our release tags to have multiple names. We > can tag the release as x.y.z-rc, go through the voting process, etc. and > then alias the tag to x.y.z and leave both of them there for posterity. > That way, automated tools can just ignore all tags ending in -rc and > when the /real/ x.y.z tag is available, that can trigger whatever > process they want to follow. > 1. I see no need to change the release process to be more complex, but it is up to release managers to decide if they want additional work. Changing the release process as Christopher proposes is doable for Tomcat, as long as it is built with Apache Ant, but it will result in lingering *-rc tags in the repository. Those add little value, but add some notable clutter. Changing the process for the Tomcat Migration Tool for Jakarta EE that is built with Apache Maven would be harder, as it contradicts with how Maven Release Plugin works. Personally I think that a tool that relies on GitHub tags is just broken. 2. If one wants to track the release date: When a release of Apache Tomcat is published, a) the DOAP file is updated, https://tomcat.apache.org/doap_Tomcat.rdf b) the release is published to dist.apache.org and becomes available via CDN c) artifacts are published to the Maven Central d) a release announcement is sent to annou...@tomcat.apache.org and to some other mailing lists. An automated tool may track any one of those. If one wants a release date, then a), c) and b) are available. The DOAP file (a)) is designed to be used by tools, but is less reliable than c) and b). An announcement at the front page of tomcat.apache.org and a changelog file also have the date. 3. GitHub itself makes a difference between "tags" and "releases". For Apache Tomcat project the GitHub is essentially a mirror. It mirrors the tags from the official ASF git repository. We do not publish "releases" there. https://github.com/apache/tomcat/releases 4. BTW I frequently see that in other projects a build date (signature date in signed Windows installers) and announcement date are different. E.g. OpenJDK. When I used builds from Oracle, there could be 1-2 week difference between apparent build date and the official announcement. E.g. Mozilla Firefox: - https://www.mozilla.org/en-US/firefox/102.0.1/releasenotes/ says Firefox 102.0.1 was released on July 6, 2022 and that is the official date. - The digital signature of "Firefox Setup 102.0.1.exe" installer is from July 5. - Files at https://ftp.mozilla.org/pub/firefox/releases/102.0.1/ are of July 5. For Firefox 101.0 the difference is more noticeable: May 31 (the official date) vs May 27 (signature) vs May 30 (files). Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Apache Tomcat migration tool for Jakarta EE 1.0.1
вт, 5 июл. 2022 г. в 22:49, Mark Thomas : > > The proposed Apache Tomcat migration tool for Jakarta EE 1.0.1 is now > available for voting. > > The significant changes since 1.0.0 are: > > - Add support for .groovy files > > - Better support for non-standard archives > > - Numerous library updates > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/jakartaee-migration/v1.0.1/ > > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1381/ > > The tag is: > https://github.com/apache/tomcat-jakartaee-migration/tree/1.0.1 > acf10c08b41c6ce8fa4965fd975420b6e9e2b038 > > The proposed 1.0.1 release is: > Not tested, but reviewed the distributables. Minor issues. 1. The NOTICE.txt file has not been updated for the year 2022. It says: Apache Tomcat migration tool for Jakarta EE Copyright 2021 The Apache Software Foundation instead of 2021-2022 as usual. I think it is not a stopper. I think that it is still valid from the legal point of view. 2. jakartaee-migration-1.0.1-src.zip and jakartaee-migration-1.0.1-src.tar.gz miss some files: .gitignore .travis.yml CHANGES.md .mvn/wrapper/maven-wrapper.jar Looking into mvnw.cmd and mvnw scripts, I see that they can deal with missing maven-wrapper.jar file: They will download version 0.5.6 of maven-wrapper from Maven Central, if one is missing locally. So I think it is not a stopper. 3. Version numbering, "1.0.1" vs "1.1.0" and Semantic Versioning. For reference: https://semver.org/ According to CHANGES.md, https://github.com/apache/tomcat-jakartaee-migration/blob/main/CHANGES.md I see two functionality changes that are not bug fixes: (1) "Fix #19. Add support for converting .groovy files." - From the description it sounds as an "added feature" and thus I was thinking whether it needs bumping the version number to 1.1.0, but actually it is an internal, one-liner change https://github.com/apache/tomcat-jakartaee-migration/commit/6465822873b3215cabc4a922e8444c4a960d7761 There are no new configuration options or anything like that. So I think it does not count as an "added feature". (2) "Remove deprecated -verbose command line option (remm)" https://github.com/apache/tomcat-jakartaee-migration/commit/528f05e09ba5745c56bcd66e02d88ce7ad8bb596 Removing an undocumented option that is commented as deprecated in the code is OK. I think it does not count as an "added feature". If it is breaking something, it is covered by 0.2.0 -> 1.0.0 version number change. Thus I am OK with the version number of 1.0.1. > [ ] -1: Broken. Do not release because... > [x] +1: Acceptable. Go ahead and release. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Missing front page update for Apache Tomcat Native 1.2.34
Hi! The front page of tomcat.apache.org has not been updated to announce the release of Apache Tomcat Native 1.2.34. Looking at site commits, there was r1901916 that updated the files in https://tomcat.apache.org/native-doc/ but there was no commit to update the main site. http://svn.apache.org/viewvc?rev=1901916=rev BTW, I added the version number to Bugzilla. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Any interest in a read-only JMX role?
пн, 13 июн. 2022 г. в 19:54, Konstantin Kolinko : > > пн, 13 июн. 2022 г. в 19:32, Christopher Schultz > : > > > > All, > > > > I've been thinking about the possibility of making a read-only JMX role > > available for the existing manager-jmx capability. > > > > [...] > > > > Does anyone think this is a good idea? > > > > I think it is a bad idea, because passwords (and maybe other secrets) > are visible through JMX, by design. > > It might be worth to have some "status" role, > but it has to be defined more specifically than just a "view all" role. > > Maybe the way to achieve the same result is to amend the server status page, > which is already provided by the manager app and has a dedicated role. BTW, the server status page might show session ids - in rare circumstances when session id is visible in the request URI. So it is also not safe to show the status page to an untrusted party. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Any interest in a read-only JMX role?
пн, 13 июн. 2022 г. в 19:32, Christopher Schultz : > > All, > > I've been thinking about the possibility of making a read-only JMX role > available for the existing manager-jmx capability. > > [...] > > Does anyone think this is a good idea? > I think it is a bad idea, because passwords (and maybe other secrets) are visible through JMX, by design. It might be worth to have some "status" role, but it has to be defined more specifically than just a "view all" role. Maybe the way to achieve the same result is to amend the server status page, which is already provided by the manager app and has a dedicated role. Best regards, Konstantin Kolinko. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch main updated: Update wiki links to use new locations
чт, 28 апр. 2022 г. в 14:14, :
>
> This is an automated email from the ASF dual-hosted git repository.
>
> markt pushed a commit to branch main
> in repository https://gitbox.apache.org/repos/asf/tomcat.git
>
>
> The following commit(s) were added to refs/heads/main by this push:
> new ca6c090f39 Update wiki links to use new locations
> ca6c090f39 is described below
>
> commit ca6c090f39c820e31bec8ddd6b118cb259f45b27
> Author: Mark Thomas
> AuthorDate: Thu Apr 28 12:13:46 2022 +0100
>
> Update wiki links to use new locations
> ---
> README.md | 2 +-
> webapps/ROOT/index.jsp| 10 +-
> webapps/docs/appdev/processes.xml | 2 +-
> webapps/docs/appdev/project.xml | 2 +-
> webapps/docs/appdev/source.xml| 2 +-
> webapps/docs/architecture/project.xml | 2 +-
> webapps/docs/cluster-howto.xml| 2 +-
> webapps/docs/config/context.xml | 2 +-
> webapps/docs/config/project.xml | 2 +-
> webapps/docs/developers.xml | 2 +-
> webapps/docs/index.xml| 4 ++--
> webapps/docs/introduction.xml | 6 +++---
> webapps/docs/jasper-howto.xml | 2 +-
> webapps/docs/jndi-resources-howto.xml | 8
> webapps/docs/project.xml | 4 ++--
> webapps/docs/realm-howto.xml | 2 +-
> webapps/docs/tribes/project.xml | 2 +-
> 17 files changed, 28 insertions(+), 28 deletions(-)
>
> diff --git a/README.md b/README.md
> index e1e224a189..a838d90223 100644
> --- a/README.md
> +++ b/README.md
[...]
> --- a/webapps/ROOT/index.jsp
> +++ b/webapps/ROOT/index.jsp
> @@ -38,7 +38,7 @@ request.setAttribute("tomcatExamplesUrl", "/examples/");
> href="${tomcatDocUrl}">Documentation
> href="${tomcatDocUrl}config/">Configuration
> href="${tomcatExamplesUrl}">Examples
> - href="https://wiki.apache.org/tomcat/FrontPage;>Wiki
> + href="https://cwiki.apache.org/confluence/display/tomcat/FrontPage;>Wiki
"FrontPage" at the above URL is the old page in "Migrated content".
It might be better to link to the actual front page,
https://cwiki.apache.org/confluence/display/TOMCAT/
BTW, Confluence prefers to spell Tomcat in URLs in uppercase, like the above.
> href="${tomcatUrl}lists.html">Mailing Lists
> Find
> Help
>
> @@ -93,8 +93,8 @@ request.setAttribute("tomcatExamplesUrl", "/examples/");
>
>
>
> - href="https://wiki.apache.org/tomcat/Specifications;>Servlet
> Specifications
> - href="https://wiki.apache.org/tomcat/TomcatVersions;>Tomcat Versions
> + href="https://cwiki.apache.org/confluence/display/tomcat/Specifications;>Servlet
> Specifications
> + href="https://cwiki.apache.org/confluence/display/TOMCAT/Tomcat+Versions;>Tomcat
> Versions
>
>
>
> @@ -120,7 +120,7 @@ request.setAttribute("tomcatExamplesUrl", "/examples/");
> Documentation
> Tomcat
> @VERSION_MAJOR_MINOR@ Documentation
> Tomcat
> @VERSION_MAJOR_MINOR@ Configuration
> - href="https://wiki.apache.org/tomcat/FrontPage;>Tomcat Wiki
> + href="https://cwiki.apache.org/confluence/display/tomcat/FrontPage;>Tomcat
> Wiki
> Find additional important configuration
> information in:
> $CATALINA_HOME/RUNNING.txt
> Developers may be interested in:
> @@ -184,7 +184,7 @@ request.setAttribute("tomcatExamplesUrl", "/examples/");
> href="${tomcatUrl}getinvolved.html">Overview
> Source
> Repositories
> Mailing
> Lists
> - href="https://wiki.apache.org/tomcat/FrontPage;>Wiki
> + href="https://cwiki.apache.org/confluence/display/tomcat/FrontPage;>Wiki
>
>
>
> diff --git a/webapps/docs/appdev/processes.xml
> b/webapps/docs/appdev/processes.xml
> index ef942466e4..97642151dc 100644
> --- a/webapps/docs/appdev/processes.xml
> +++ b/webapps/docs/appdev/processes.xml
[]
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat mitigations for CVE-2022-21449
пт, 29 апр. 2022 г. в 21:41, Christopher Schultz : > > All, > > CVE-2022-21449 is a bug in the JDK which allows a malicious signer using > ECDSA to forge a signature which an affected (buggy) verifier fails to > detect. > > I used deliberate language above instead of "client" and "server" > because in many csases, the server is performing verification as well > (e.g. of a client's TLS certificate in a mutually-authenticated TLS > handshake). > > This affects JDK versions from 15 - 18. Notably, Java 15 and 16 are EOL > and won't be getting any updates. This Isn't Good. > > This wasn't as popular in the press as "log4shell" nor does it have as > exciting or sensational a name given to it, but it's still a pretty big > problem. It is named "Psychic Signatures" https://neilmadden.blog/2022/04/19/psychic-signatures-in-java/ https://neilmadden.blog/2022/04/25/a-few-clarifications-about-cve-2022-21449/ > Tomcat is, of course, transiently affected by this bug under the > following conditions (all of which must be true, I believe): > > 1. The underlying JVM is affected > 2. A Connector is defined with uses mutual TLS > 3. The client's key is ECDSA 4. The SSL implementation that is used is JSSE. Those using Tomcat Native + OpenSSL are not affected. https://tomcat.apache.org/tomcat-10.1-doc/config/http.html#SSL_Support > If all of the above are true, then anyone can impersonate any client to > the server. An attacker may need to find a /useful/ client to > impersonate, but usually, simply connecting to the server and askint > which clients are allowed is enough: > > $ openssl s_client -connect host:port | grep 'Acceptable client' > Acceptable client certificate CA names > [...] Those are CA names. Luckily those are not user names. For a reference, https://security.stackexchange.com/questions/139048/acceptable-client-certificate-ca-names-openssl > > While we can't protect any *clients* against these attacks, we may be > able to protect *servers*. > > What does the community think about Tomcat trying to prevent the use of > vulnerable configurations? Is it overstepping? Would it be helpful? I > think anyone running a vulnerable configuration should /really/ know > that they are vulnerable and be able to fix their environment. But lots > of environments are on auto-pilot. > > I was thinking that on startup, we could check for a vulnerable > environment and simply refuse to start the server. > > If there are no objections, I was thinking of putting this into the > SecurityListener. I assume that all the necessary information is > available to a LifecycleListener such as being able to enumerate the > Connectors to check on items #2 and #3 above? > 1. It does look like overstepping to me. I am afraid that once we start it may result in pursuing a moving target. It is hard to whack all the moles. I think there is a worth in doing a check on the JRE version, but implementing a check that combines 4 conditions is too hard to maintain, and too limited in scope to be useful in the long run. There may be 3rd-party software to better fill the role and maintain the effort. If we add a java version check, the next question is planning on how to maintain it. Who and when updates it to start rejecting java 18? 2. Maybe as a start, add a mention of this on the "Security Considerations" page https://tomcat.apache.org/tomcat-10.1-doc/security-howto.html#Non-Tomcat_settings a) "Use a recent and supported JRE, because there are bugs that may affect your security, e.g. CVE-2022-21449". BTW maybe also b) "Plan for upgrades in advance" "Upgrading Tomcat is easiest if one is configured with separate CATALINA_HOME and CATALINA_BASE". 3. That said, I see that SecurityListener is not enabled by default, and as such I do not have a technical objection, if that is your itch. My personal requirements are that 1) org.apache.catalina.security.SecurityListener continues to be not enabled by default, 2) There should be an easy option to skip the check, e.g. javaVersionCheck="false". 4. BTW, There may be ways to additionally validate the client's certificate. E.g. "org.apache.catalina.realm.X509UsernameRetriever" (configured on a Realm with "X509UsernameRetrieverClassName" attribute) was mentioned in an unrelated discussion recently. It has access to the client's certificate. https://bz.apache.org/bugzilla/show_bug.cgi?id=66009#c3 https://tomcat.apache.org/tomcat-9.0-doc/config/realm.html https://tomcat.apache.org/tomcat-9.0-doc/api/org/apache/catalina/realm/X509UsernameRetriever.html Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [ANN] Apache Tomcat 10.1.0-M14 (alpha) available
пт, 1 апр. 2022 г. в 12:43, Martin Knoblauch : > > Hi Mark, > > seems there is a small type in the release date of 10.1.0-m14 :-) > > Martin > > On Fri, Apr 1, 2022 at 11:00 AM Mark Thomas wrote: > > > > The Apache Tomcat team announces the immediate availability of Apache > > Tomcat 10.1.0-M14 (alpha). > > (...) > > -- > -- > Martin Knoblauch > email: k n o b i AT knobisoft DOT de > www: http://www.knobisoft.de Fixed (r1899482). Thank you. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r53489 [1/2] - in /dev/tomcat/tomcat-8/v8.5.78: ./ bin/ bin/embed/ bin/extras/ src/
чт, 31 мар. 2022 г. в 19:50, : > > Author: markt > Date: Thu Mar 31 16:50:19 2022 > New Revision: 53489 > > Log: > Upload 8.5.78 for voting > > Added: > dev/tomcat/tomcat-8/v8.5.78/ > dev/tomcat/tomcat-8/v8.5.78/KEYS > dev/tomcat/tomcat-8/v8.5.78/README.html > dev/tomcat/tomcat-8/v8.5.78/RELEASE-NOTES > dev/tomcat/tomcat-8/v8.5.78/bin/ > dev/tomcat/tomcat-8/v8.5.78/bin/README.html > dev/tomcat/tomcat-8/v8.5.78/bin/apache-tomcat-8.5.78-deployer.tar.gz > (with props) > dev/tomcat/tomcat-8/v8.5.78/bin/apache-tomcat-8.5.78-deployer.tar.gz.asc > > dev/tomcat/tomcat-8/v8.5.78/bin/apache-tomcat-8.5.78-deployer.tar.gz.sha512 > dev/tomcat/tomcat-8/v8.5.78/bin/apache-tomcat-8.5.78-deployer.zip (with > props) > dev/tomcat/tomcat-8/v8.5.78/bin/apache-tomcat-8.5.78-deployer.zip.asc > dev/tomcat/tomcat-8/v8.5.78/bin/apache-tomcat-8.5.78-deployer.zip.sha512 > dev/tomcat/tomcat-8/v8.5.78/bin/apache-tomcat-8.5.78-fulldocs.tar.gz > (with props) > dev/tomcat/tomcat-8/v8.5.78/bin/apache-tomcat-8.5.78-fulldocs.tar.gz.asc > > dev/tomcat/tomcat-8/v8.5.78/bin/apache-tomcat-8.5.78-fulldocs.tar.gz.sha512 > dev/tomcat/tomcat-8/v8.5.78/bin/apache-tomcat-8.5.78-windows-x64.zip > (with props) > dev/tomcat/tomcat-8/v8.5.78/bin/apache-tomcat-8.5.78-windows-x64.zip.asc > > dev/tomcat/tomcat-8/v8.5.78/bin/apache-tomcat-8.5.78-windows-x64.zip.sha512 > dev/tomcat/tomcat-8/v8.5.78/bin/apache-tomcat-8.5.78-windows-x86.zip > (with props) > dev/tomcat/tomcat-8/v8.5.78/bin/apache-tomcat-8.5.78-windows-x86.zip.asc > > dev/tomcat/tomcat-8/v8.5.78/bin/apache-tomcat-8.5.78-windows-x86.zip.sha512 > dev/tomcat/tomcat-8/v8.5.78/bin/apache-tomcat-8.5.78.exe (with props) > dev/tomcat/tomcat-8/v8.5.78/bin/apache-tomcat-8.5.78.exe.asc > dev/tomcat/tomcat-8/v8.5.78/bin/apache-tomcat-8.5.78.exe.sha512 > dev/tomcat/tomcat-8/v8.5.78/bin/apache-tomcat-8.5.78.tar.gz (with props) > dev/tomcat/tomcat-8/v8.5.78/bin/apache-tomcat-8.5.78.tar.gz.sha512 > dev/tomcat/tomcat-8/v8.5.78/bin/apache-tomcat-8.5.78.zip (with props) > dev/tomcat/tomcat-8/v8.5.78/bin/apache-tomcat-8.5.78.zip.sha512 *.asc files are missing for .zip and .tar.gz above. The same issue as for 10.1.0-M14 RC. 10.0.20 and 9.0.62 are OK Best regards, Konstantin Kolinko > dev/tomcat/tomcat-8/v8.5.78/bin/embed/ > dev/tomcat/tomcat-8/v8.5.78/bin/embed/apache-tomcat-8.5.78-embed.tar.gz > (with props) > > dev/tomcat/tomcat-8/v8.5.78/bin/embed/apache-tomcat-8.5.78-embed.tar.gz.asc > > dev/tomcat/tomcat-8/v8.5.78/bin/embed/apache-tomcat-8.5.78-embed.tar.gz.sha512 > dev/tomcat/tomcat-8/v8.5.78/bin/embed/apache-tomcat-8.5.78-embed.zip > (with props) > dev/tomcat/tomcat-8/v8.5.78/bin/embed/apache-tomcat-8.5.78-embed.zip.asc > > dev/tomcat/tomcat-8/v8.5.78/bin/embed/apache-tomcat-8.5.78-embed.zip.sha512 > dev/tomcat/tomcat-8/v8.5.78/bin/extras/ > dev/tomcat/tomcat-8/v8.5.78/bin/extras/catalina-ws.jar (with props) > dev/tomcat/tomcat-8/v8.5.78/bin/extras/catalina-ws.jar.asc > dev/tomcat/tomcat-8/v8.5.78/bin/extras/catalina-ws.jar.sha512 > dev/tomcat/tomcat-8/v8.5.78/src/ > dev/tomcat/tomcat-8/v8.5.78/src/apache-tomcat-8.5.78-src.tar.gz (with > props) > dev/tomcat/tomcat-8/v8.5.78/src/apache-tomcat-8.5.78-src.tar.gz.asc > dev/tomcat/tomcat-8/v8.5.78/src/apache-tomcat-8.5.78-src.tar.gz.sha512 > dev/tomcat/tomcat-8/v8.5.78/src/apache-tomcat-8.5.78-src.zip (with > props) > dev/tomcat/tomcat-8/v8.5.78/src/apache-tomcat-8.5.78-src.zip.asc > dev/tomcat/tomcat-8/v8.5.78/src/apache-tomcat-8.5.78-src.zip.sha512 > > Added: dev/tomcat/tomcat-8/v8.5.78/KEYS (... diffs skipped) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch 9.0.x updated: Update repeatable build timestamp (currently unused)
чт, 31 мар. 2022 г. в 16:38, : > > This is an automated email from the ASF dual-hosted git repository. > > remm pushed a commit to branch 9.0.x > in repository https://gitbox.apache.org/repos/asf/tomcat.git > > > The following commit(s) were added to refs/heads/9.0.x by this push: > new ccbd0fd Update repeatable build timestamp (currently unused) > ccbd0fd is described below > > commit ccbd0fddff25d00655206054ffd426f0323eca07 > Author: remm > AuthorDate: Thu Mar 31 15:37:25 2022 +0200 > > Update repeatable build timestamp (currently unused) > --- > build.properties.default | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/build.properties.default b/build.properties.default > index a8db96f..d656418 100644 > --- a/build.properties.default > +++ b/build.properties.default > @@ -38,8 +38,8 @@ version.suffix=-dev > # - Reproducible builds - > # Uncomment and set to current time for reproducible builds > # Note: The value is in seconds (unlike milliseconds used by > System.currentTimeMillis()). > -#2022-03-30T00:00:00Z > -#ant.tstamp.now=1648598400 > ++#2022-03-31T12:00:00Z > ++#ant.tstamp.now=1648728000 Note doubled "++" There are leading "+" on those lines. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r53481 - in /dev/tomcat/tomcat-10/v10.1.0-M14: ./ bin/ bin/embed/ src/
чт, 31 мар. 2022 г. в 16:56, : > > Author: markt > Date: Thu Mar 31 13:56:26 2022 > New Revision: 53481 > > Log: > Upload 10.1.0-M14 for voting > > Added: > dev/tomcat/tomcat-10/v10.1.0-M14/ > dev/tomcat/tomcat-10/v10.1.0-M14/KEYS > dev/tomcat/tomcat-10/v10.1.0-M14/README.html > dev/tomcat/tomcat-10/v10.1.0-M14/RELEASE-NOTES > dev/tomcat/tomcat-10/v10.1.0-M14/bin/ > dev/tomcat/tomcat-10/v10.1.0-M14/bin/README.html > > dev/tomcat/tomcat-10/v10.1.0-M14/bin/apache-tomcat-10.1.0-M14-deployer.tar.gz > (with props) > > dev/tomcat/tomcat-10/v10.1.0-M14/bin/apache-tomcat-10.1.0-M14-deployer.tar.gz.asc > > dev/tomcat/tomcat-10/v10.1.0-M14/bin/apache-tomcat-10.1.0-M14-deployer.tar.gz.sha512 > > dev/tomcat/tomcat-10/v10.1.0-M14/bin/apache-tomcat-10.1.0-M14-deployer.zip > (with props) > > dev/tomcat/tomcat-10/v10.1.0-M14/bin/apache-tomcat-10.1.0-M14-deployer.zip.asc > > dev/tomcat/tomcat-10/v10.1.0-M14/bin/apache-tomcat-10.1.0-M14-deployer.zip.sha512 > > dev/tomcat/tomcat-10/v10.1.0-M14/bin/apache-tomcat-10.1.0-M14-fulldocs.tar.gz > (with props) > > dev/tomcat/tomcat-10/v10.1.0-M14/bin/apache-tomcat-10.1.0-M14-fulldocs.tar.gz.asc > > dev/tomcat/tomcat-10/v10.1.0-M14/bin/apache-tomcat-10.1.0-M14-fulldocs.tar.gz.sha512 > > dev/tomcat/tomcat-10/v10.1.0-M14/bin/apache-tomcat-10.1.0-M14-windows-x64.zip > (with props) > > dev/tomcat/tomcat-10/v10.1.0-M14/bin/apache-tomcat-10.1.0-M14-windows-x64.zip.asc > > dev/tomcat/tomcat-10/v10.1.0-M14/bin/apache-tomcat-10.1.0-M14-windows-x64.zip.sha512 > > dev/tomcat/tomcat-10/v10.1.0-M14/bin/apache-tomcat-10.1.0-M14-windows-x86.zip > (with props) > > dev/tomcat/tomcat-10/v10.1.0-M14/bin/apache-tomcat-10.1.0-M14-windows-x86.zip.asc > > dev/tomcat/tomcat-10/v10.1.0-M14/bin/apache-tomcat-10.1.0-M14-windows-x86.zip.sha512 > dev/tomcat/tomcat-10/v10.1.0-M14/bin/apache-tomcat-10.1.0-M14.exe (with > props) > dev/tomcat/tomcat-10/v10.1.0-M14/bin/apache-tomcat-10.1.0-M14.exe.asc > dev/tomcat/tomcat-10/v10.1.0-M14/bin/apache-tomcat-10.1.0-M14.exe.sha512 > dev/tomcat/tomcat-10/v10.1.0-M14/bin/apache-tomcat-10.1.0-M14.tar.gz > (with props) > > dev/tomcat/tomcat-10/v10.1.0-M14/bin/apache-tomcat-10.1.0-M14.tar.gz.sha512 > dev/tomcat/tomcat-10/v10.1.0-M14/bin/apache-tomcat-10.1.0-M14.zip (with > props) > dev/tomcat/tomcat-10/v10.1.0-M14/bin/apache-tomcat-10.1.0-M14.zip.sha512 Mark, note that *,asc files are missing for the above two archives. > dev/tomcat/tomcat-10/v10.1.0-M14/bin/embed/ > > dev/tomcat/tomcat-10/v10.1.0-M14/bin/embed/apache-tomcat-10.1.0-M14-embed.tar.gz >(with props) > > dev/tomcat/tomcat-10/v10.1.0-M14/bin/embed/apache-tomcat-10.1.0-M14-embed.tar.gz.asc > > dev/tomcat/tomcat-10/v10.1.0-M14/bin/embed/apache-tomcat-10.1.0-M14-embed.tar.gz.sha512 > > dev/tomcat/tomcat-10/v10.1.0-M14/bin/embed/apache-tomcat-10.1.0-M14-embed.zip > (with props) > > dev/tomcat/tomcat-10/v10.1.0-M14/bin/embed/apache-tomcat-10.1.0-M14-embed.zip.asc > > dev/tomcat/tomcat-10/v10.1.0-M14/bin/embed/apache-tomcat-10.1.0-M14-embed.zip.sha512 > dev/tomcat/tomcat-10/v10.1.0-M14/src/ > dev/tomcat/tomcat-10/v10.1.0-M14/src/apache-tomcat-10.1.0-M14-src.tar.gz > (with props) > > dev/tomcat/tomcat-10/v10.1.0-M14/src/apache-tomcat-10.1.0-M14-src.tar.gz.asc > > dev/tomcat/tomcat-10/v10.1.0-M14/src/apache-tomcat-10.1.0-M14-src.tar.gz.sha512 > dev/tomcat/tomcat-10/v10.1.0-M14/src/apache-tomcat-10.1.0-M14-src.zip > (with props) > dev/tomcat/tomcat-10/v10.1.0-M14/src/apache-tomcat-10.1.0-M14-src.zip.asc > > dev/tomcat/tomcat-10/v10.1.0-M14/src/apache-tomcat-10.1.0-M14-src.zip.sha512 > (diffs skipped) Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Re-rolling releases to pick up class loader hardening
чт, 31 мар. 2022 г. в 12:52, Mark Thomas : > > Hi all, > > My recent hardening fix to the class loader [1] provides mitigation for > a current Spring vulnerability [2]. > > While this is a Spring vulnerability, it may be the case for some users > that updating Tomcat is an easier mitigation path that updating Spring. > What are the community thoughts on cancelling the current releases, > re-tagging and releasing reasonably quickly? > > [1] > https://github.com/apache/tomcat/commit/1abcf3f4d741c824ae490009fe32ce300f10eddc > > [2] > https://github.com/apache/tomcat/commit/1abcf3f4d741c824ae490009fe32ce300f10eddc Regarding [2] I think that you meant https://tanzu.vmware.com/security/cve-2022-22963 I found this article with more details: [3] https://securityonline.info/cve-2022-22963-spring-java-framework-0-day-remote-code-execution-vulerability-alert/ So we now have "setResources(WebResourceRoot)" without accompanying "getResources()" ... 1. I think that we can roll two votes in parallel, without cancelling the old one. So that in case getResources() is used somewhere, one could use the "old" release. Essentially it is not our vulnerability. Nothing is broken with the current RCs to cancel them. 2. I do not know about the actual attack POC, but I note that there are other public methods, and setters on the classloader. [3] talks that some setters were called. I see no way to remove it or protect some of those methods with a security manager, as they are part of the public API, as I see no way to distinguish it from a proper call by the application. So I think it is up to EL to close access to object -> getClass() -> getClassLoader() -> ... It is not really our issue. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: EOL dates for Tomcat 5.0 and 4.1?
вт, 29 мар. 2022 г. в 00:47, Christopher Schultz : > > Jon, > > On 3/28/22 16:24, jonmcalexan...@wellsfargo.com.INVALID wrote: > > If nobody else does, I dub thee > > > > "The Librarian"!!! > > Stack Overflow rewards this kind of work with a badge called "Necromancer". I happen to have 3 of those, though it looks that the official cause for them is a bit different. https://stackoverflow.com/users/4116988/konstantin-kolinko?tab=badges What astonished me while looking through the archives is that I was one of the people who tested and voted for the 4.1.40 release. Time flies fast. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: EOL dates for Tomcat 5.0 and 4.1?
пн, 28 мар. 2022 г. в 19:36, Christopher Schultz : > > All, > > Did the Apache Tomcat project ever officially announce an EOL date for > Tomcat 5.0 and 4.x? Or for 3.x for that matter? > > I was looking at the Wikipedia page for Tomcat and they didn't have EOL > dates for anything before 6.0, so I filled-in the date for 5.5 but I > can't find older EOL announcements. > > This page https://tomcat.apache.org/whichversion.html contains links to > the EOL announcements for 5.5, 6.0, 7.0, and 8.0. > > I wonder if the project ever made any "official" EOL announcements for > those versions, and whether or not anyone cares enough to make those > announcements at this point, just for "posterity"? Not to fix the > Wikipedia page, but more to have something official to point to to say > "this version is officially unsupported by the vendor" just in case some > dummy somewhere wants to say "we run the latest available version of > Tomcat 4.1 from the vendor" and their product is therefore full of holes. announce@ list was created in June 2009, so all those announcements were on users@ https://lists.apache.org/thread/z6ljrkdqtjgnmxfctnk6f1v4dp42ptnw [ANN] Apache Tomcat 5.0.x no longer supported 2007-10-23 https://lists.apache.org/thread/nw4vpbwgrn480gsvn06f4qj4yhoo89v7 [ANN] Tomcat support status 2008-03-13 - It involved site cleanup, immediate EOL for 3.3, and EOL for 4.1 announced to be June 2009. BTW, if anyone is interested, announcements for the last releases of 4.0 and 3.3: https://lists.apache.org/thread/v1ccn429s9lh32ypvwwhxo26zhh1965c [ANN] Apache Tomcat 4.1.40 stable is now available 2009-06-26 "Apache Tomcat 4.1.40 is very likely to be the last release of the 4.1.x series." https://lists.apache.org/thread/q0bb1756s8zxg949ocodmm2j2o9ntpfq [ANN] Release of Tomcat 3.3.2 2004-03-09. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat Native 1.2.32
чт, 17 мар. 2022 г. в 11:48, Mark Thomas : > > Version 1.2.32 includes the following changes compared to 1.2.31 > > - Updated recommended minimum OpenSSL to 1.1.1n and build windows >binaries using that version > > - Fix release script so it works with the current git layout > > The proposed release artefacts can be found at [1], > and the build was done using tag [2]. > > The Apache Tomcat Native 1.2.32 release is > [x] Stable, go ahead and release > [ ] Broken because of ... Tested on Windows 10 Unit tests of Apache Tomcat 8.5.77 with APR Connector: (configuration details - see my vote in the VOTE thread of Tomcat 8.5.77) - Java 11 (64-bit), Java 7 (32-bit): OK Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1898989 - in /tomcat/site/trunk: ./ docs/ docs/tomcat-8.5-doc/ docs/tomcat-8.5-doc/annotationapi/ docs/tomcat-8.5-doc/annotationapi/javax/annotation/ docs/tomcat-8.5-doc/annotationapi
чт, 17 мар. 2022 г. в 16:16, : > > Author: schultz > Date: Thu Mar 17 13:15:41 2022 > New Revision: 1898989 > > URL: http://svn.apache.org/viewvc?rev=1898989=rev > Log: > Update website to announce 8.5.77 and include documentation. > > > [This commit notification would consist of 67 parts, > which exceeds the limit of 50 ones, so it was shortened to the summary.] Looking at https://svn.apache.org/viewvc?rev=1898989=rev tomcat/site/trunk/docs/index.html modified , text changed tomcat/site/trunk/docs/migration-85.html modified , text changed tomcat/site/trunk/docs/oldnews.html besides tomcat-8.5-doc/* files, only the above 3 ones in docs/* were updated. E.g. update to the downloads page has not been committed. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r53155 - in /dev/tomcat/tomcat-connectors/native/1.2.32: ./ binaries/ source/
чт, 17 мар. 2022 г. в 11:45, : > > Author: markt > Date: Thu Mar 17 08:44:59 2022 > New Revision: 53155 > > Log: > Upload Tomcat Native 1.2.32 for voting > > Added: > dev/tomcat/tomcat-connectors/native/1.2.32/ > dev/tomcat/tomcat-connectors/native/1.2.32/binaries/ > > dev/tomcat/tomcat-connectors/native/1.2.32/binaries/tomcat-native-1.2.32-openssl-1.1.1n-ocsp-win32-bin.zip >(with props) > > dev/tomcat/tomcat-connectors/native/1.2.32/binaries/tomcat-native-1.2.32-openssl-1.1.1n-ocsp-win32-bin.zip.asc > > dev/tomcat/tomcat-connectors/native/1.2.32/binaries/tomcat-native-1.2.32-openssl-1.1.1n-ocsp-win32-bin.zip.sha512 > > dev/tomcat/tomcat-connectors/native/1.2.32/binaries/tomcat-native-1.2.32-openssl-1.1.1n-win32-bin.zip >(with props) > > dev/tomcat/tomcat-connectors/native/1.2.32/binaries/tomcat-native-1.2.32-openssl-1.1.1n-win32-bin.zip.asc > > dev/tomcat/tomcat-connectors/native/1.2.32/binaries/tomcat-native-1.2.32-openssl-1.1.1n-win32-bin.zip.sha512 > dev/tomcat/tomcat-connectors/native/1.2.32/source/ > > dev/tomcat/tomcat-connectors/native/1.2.32/source/tomcat-native-1.2.32-src.tar.gz >(with props) > > dev/tomcat/tomcat-connectors/native/1.2.32/source/tomcat-native-1.2.32-src.tar.gz.asc > > dev/tomcat/tomcat-connectors/native/1.2.32/source/tomcat-native-1.2.32-src.tar.gz.sha512 > > dev/tomcat/tomcat-connectors/native/1.2.32/source/tomcat-native-1.2.32-win32-src.zip >(with props) > > dev/tomcat/tomcat-connectors/native/1.2.32/source/tomcat-native-1.2.32-win32-src.zip.asc > > dev/tomcat/tomcat-connectors/native/1.2.32/source/tomcat-native-1.2.32-win32-src.zip.sha512 > > Added: > dev/tomcat/tomcat-connectors/native/1.2.32/binaries/tomcat-native-1.2.32-openssl-1.1.1n-ocsp-win32-bin.zip > == > Binary file - no diff available. > > Propchange: > dev/tomcat/tomcat-connectors/native/1.2.32/binaries/tomcat-native-1.2.32-openssl-1.1.1n-ocsp-win32-bin.zip > -- > svn:executable = * [OT] I wonder why *-bin.zip* files in this commit have the "svn:executable" flag set. It does not make sense to me, neither from Unix nor from Windows point of view. They are not *.exe files, nor are they executable shell scripts with a shebang line. A "-src.zip" file does not have this flag, so it is not a *.zip mask (auto-properties setting?) that triggered it. Best regards, Konstantin Kolinko > Propchange: > dev/tomcat/tomcat-connectors/native/1.2.32/binaries/tomcat-native-1.2.32-openssl-1.1.1n-ocsp-win32-bin.zip > -- > svn:mime-type = application/octet-stream > [] > > Added: > dev/tomcat/tomcat-connectors/native/1.2.32/binaries/tomcat-native-1.2.32-openssl-1.1.1n-win32-bin.zip > == > Binary file - no diff available. > > Propchange: > dev/tomcat/tomcat-connectors/native/1.2.32/binaries/tomcat-native-1.2.32-openssl-1.1.1n-win32-bin.zip > -- > svn:executable = * > > Propchange: > dev/tomcat/tomcat-connectors/native/1.2.32/binaries/tomcat-native-1.2.32-openssl-1.1.1n-win32-bin.zip > -- > svn:mime-type = application/octet-stream > [...] No newline at end of file > > Added: > dev/tomcat/tomcat-connectors/native/1.2.32/source/tomcat-native-1.2.32-src.tar.gz > == > Binary file - no diff available. > > Propchange: > dev/tomcat/tomcat-connectors/native/1.2.32/source/tomcat-native-1.2.32-src.tar.gz > -- > svn:mime-type = application/octet-stream > [...] > > Added: > dev/tomcat/tomcat-connectors/native/1.2.32/source/tomcat-native-1.2.32-win32-src.zip > == > Binary file - no diff available. > > Propchange: > dev/tomcat/tomcat-connectors/native/1.2.32/source/tomcat-native-1.2.32-win32-src.zip > -- > svn:mime-type = application/octet-stream > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.77
вс, 13 мар. 2022 г. в 22:41, Christopher Schultz : > > The proposed Apache Tomcat 8.5.77 release is now available for voting. > > The notable changes compared to 8.5.76 are: > [...] > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.77/ > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1363 > The tag is: > https://github.com/apache/tomcat/tree/8.5.77 > 3931695e564dd4dd1dbf029026e900b74992408c > > The proposed 8.5.77 release is: > [ ] Broken - do not release > [ ] Stable - go ahead and release as 8.5.76 (stable) [x] Stable - go ahead and release as 8.5.77 (stable) Tested on Windows 10. Smoke tests OK (installer, Java 7, examples). Unit tests OK (Java 11), OK with well-known caveats (Java 7, 8, 17) . Unit tests with Java 17: OK as is, but one test fails. It needs an updated version of ecj library. More details are at BZ 65599 and in related discussions on dev@ https://bz.apache.org/bugzilla/show_bug.cgi?id=65599 Unit tests with Java 8: OK, with some settings in the build.properties file. The recipe is the same as when testing Tomcat 9.0.60 with Java 8, from the "Running unit tests with JVMs < 11" thread (Feb 09, 2022) https://lists.apache.org/thread/mltqyq912z97klqvzg0d5mb7h658j734 Unit tests with Java 7: OK, but in addition to the settings for Java 8 it needs older versions of easymock and objenesis libraries. The recipe - see "Running cipher-suite tests without failure" thread (Feb 24, 2022), https://lists.apache.org/thread/42rkw48o00nzoxnr11jlst2d8p2y6bh5 Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Small problem with release process: version number publication
пн, 14 мар. 2022 г. в 19:45, Christopher Schultz : > > All, > > The current release process as written ends up with the release-date of > the latest release not appearing in the changelog until the *following* > release is done. > > I think we should change this. I have tried to remember to do it myself > with 8.5.x when I do releases. > > When we have monthly releases, it's not really a huge deal. But when the > releases become less and less frequent (e.g. maintenance mode), then we > have problems like this: > > https://tomcat.apache.org/tomcat-6.0-doc/changelog.html > https://tomcat.apache.org/tomcat-7.0-doc/changelog.html > https://tomcat.apache.org/tomcat-8.0-doc/changelog.html > > According to those changelogs, the latest releases do not have a > release-date. But they were in fact released. 1. I see no real point. a. For historic releases, those 3 files and also 4th https://tomcat.apache.org/tomcat-5.5-doc/changelog.html can be hand-edited to add a release date. E.g. I can do this work. The hard part is finding the actual dates. b. For current releases, the date can be seen easily from an announcement at the front page of https://tomcat.apache.org/ Attracting more visitors to that page is a positive thing, I think. > Are there any objections to making it a policy to update those > changelogs with each actual release and not just the following release? Let's keep it simple. btw, I wonder whether release managers actually read the wiki each time https://cwiki.apache.org/confluence/display/TOMCAT/ReleaseProcess also replying to a later mail: пн, 14 мар. 2022 г. в 23:07, Christopher Schultz : > [...] > The actual release contains a changelog which says "Release in > progress." So if you look at the docs/ webapp, you'llsee that your I see that in your 8.5.x, but in 9.0,x and others it is done in a different way: - On the tag the changelog file has rtext="" (an empty string). https://github.com/apache/tomcat/commit/235730aed454e8d3619109f2c563587ff722e69d - On the source tree (on the active branch in git) it has rtext="in progress" or "release in progress" https://github.com/apache/tomcat/commit/b925f769668fee1b6febf12153205ff6bdfd1258 I think it makes more sense to do it this way (with rtext="" on the tag). Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 9.0.60
ср, 9 мар. 2022 г. в 18:40, Rémy Maucherat : > > The proposed Apache Tomcat 9.0.60 release is now available for voting. > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.60/ > ... > The proposed 9.0.60 release is: [ ] Broken - do not release [x] Stable - go ahead and release as 9.0.60 (stable) Tested on Windows 10. Smoke tests OK (installer, Java 8, examples). Unit tests OK (Java 11, Java 8, Java 17). Testing with Java 8 was done using a recipe from the "Running unit tests with JVMs < 11" thread https://lists.apache.org/thread/mltqyq912z97klqvzg0d5mb7h658j734 Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: March releases?
ср, 9 мар. 2022 г. в 00:24, Mark Thomas : > > Hi all, > > I know I suggested skipping the March releases but I'd like to revisit > that in light of two things. > > 1. The concurrency issue I fixed earlier today. [1] > It has been present for a long time and we haven't had any bug reports. > However, it just looks like a random timeout so users might not report it. > My main motivation is that a customer at $dayjob is affected by this so > I'd like to get them onto a proper release rather than the snapshot they > are currently using. > > 2. The fix for the regression caused by BZ 65757 [2] > No hard evidence for this one, just a general uneasiness about > regressions in general. > > So, thoughts on a set of releases for March? 1. The following may be a bug to be addressed before a release: See thread "Many IllegalStateException when using http2 protocol" - I wonder why the code mentioned there throws an ISE instead of an IOException (end of stream exception) when writing to a closed stream. That method declares that it throws an IOException. I commented in that thread. It is not in BZ yet. 2. +1 for rolling a release. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch 9.0.x updated: Fix Response#sendRedirect() if no request context exists.
вт, 1 мар. 2022 г. в 18:08, :
>
> This is an automated email from the ASF dual-hosted git repository.
>
> markt pushed a commit to branch 9.0.x
> in repository https://gitbox.apache.org/repos/asf/tomcat.git
>
>
> The following commit(s) were added to refs/heads/9.0.x by this push:
> new e7d4ec3 Fix Response#sendRedirect() if no request context exists.
> e7d4ec3 is described below
>
> commit e7d4ec3cd0802da3898273d55f3d0496743153a5
> Author: Knut Sander
> AuthorDate: Thu Feb 24 18:40:16 2022 +0100
>
> Fix Response#sendRedirect() if no request context exists.
>
> If no ROOT context is defined, the context may be null in special cases,
> e.g. RewriteValve may use Response#sendRedirect() without any application
> context associated.
> In this case, the Tomcat behaviors for the context attributes
> useRelativeRedirects and sendRedirectBody are assumed, but without
> considering org.apache.catalina.STRICT_SERVLET_COMPLIANCE.
> ---
> java/org/apache/catalina/connector/Response.java | 9 +++--
> webapps/docs/changelog.xml | 5 +
> 2 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/java/org/apache/catalina/connector/Response.java
> b/java/org/apache/catalina/connector/Response.java
> index 0950bcb..1295922 100644
> --- a/java/org/apache/catalina/connector/Response.java
> +++ b/java/org/apache/catalina/connector/Response.java
> @@ -1363,17 +1363,22 @@ public class Response implements HttpServletResponse {
>
> // Generate a temporary redirect to the specified location
> try {
> +Context context = getContext();
> +// If no ROOT context is defined, the context can be null.
> +// In this case, the default Tomcat values are assumed, but
> without
> +// reference to org.apache.catalina.STRICT_SERVLET_COMPLIANCE.
> +boolean reqHasContext = context == null;
I think it was meant to be (context != null) above...
> String locationUri;
> // Relative redirects require HTTP/1.1
> if
> (getRequest().getCoyoteRequest().getSupportsRelativeRedirects() &&
> -getContext().getUseRelativeRedirects()) {
> +(!reqHasContext || context.getUseRelativeRedirects())) {
> locationUri = location;
> } else {
> locationUri = toAbsolute(location);
> }
> setStatus(status);
> setHeader("Location", locationUri);
> -if (getContext().getSendRedirectBody()) {
> +if (reqHasContext && context.getSendRedirectBody()) {
> PrintWriter writer = getWriter();
> writer.print(sm.getString("coyoteResponse.sendRedirect.note",
> Escape.htmlElementContent(locationUri)));
> diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
> index c747b30..ef55841 100644
> --- a/webapps/docs/changelog.xml
> +++ b/webapps/docs/changelog.xml
> @@ -112,6 +112,11 @@
> rewrite valve should set the content type for the response, not the
> request. (markt)
>
> +
> +479: Enable the rewrite valve to redirect requests when the
> +original request cannot be mapped to a context. This typically
> happens
> +when no ROOT context is defined. Pull request by elkman. (markt)
> +
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: BuildBot 2 - builds failing due to Linux OOM task management
вт, 7 дек. 2021 г. в 16:22, Mark Thomas : > > Hi all, > > I've been investigating some recent build failures and it appears that > some builds are failing because Linux is closing tasks because of memory > pressure. > > My proposed solution is based on the following facts / observations: > > - The test node we are using has 4 cores and 16GB of RAM > > - The unit tests are currently configured to run with 6 threads > > - The test node is currently configured to run two tests concurrently > > - In local testing test thread count == core count gave the best >performance > > - In local testing increasing / decreasing test threads by 10% had a >marginal impact on test duration > > > My proposed solution is therefore: > > - reduce test thread count from 6 to 4 > > - investigate whether we can reduce the concurrent tests from 2 to 1 I wonder if there is some consistency about when that happens. (What tests are being executed, or at least time from launch.) I mean if there are tests that require a noticeable amount of memory. I have encountered such a test once, https://bz.apache.org/bugzilla/show_bug.cgi?id=65177 org.apache.tomcat.util.net.TestSsl IIRC, a fix reduced memory requirements for that test from 256Mb down to 144Mb (128 + 16) of byte arrays. Though in such a case I would expect an OutOfMemoryError in java. I think Linux OOM killer can be active for outside reasons that are out of our control. Also it looks like several builds run in parallel. Tomcat 10.1.x https://ci2.apache.org/#/builders/44 Worker bb2_worker2_ubuntu. A build started at 03:28 PM (visible if I hover mouse over "started at" time for build 113) and was running for an hour and 8 minutes (visible if I hover over build number). Tomcat 10.0.x https://ci2.apache.org/#/builders/43 Worker bb2_worker2_ubuntu A build started at 03:46 PM and is currently running (for more than an hour). Tomcat 9 https://ci2.apache.org/#/builders/37 Worker bb2_worker2_ubuntu A build started at 04:37 PM and is currently running. Even though they did not start at the same time, it looks like they overlap. I saw both 10.0.x and 9 being tested at the same time. (10.0.x has finished a few seconds ago). Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Building Tomcat 8.5.x with Java 7
чт, 11 нояб. 2021 г. в 16:53, Christopher Schultz : > > All, > > It looks like fetching the NSIS installer from downloads.sourceforge.net > is a problem with Java 7. > > I should be able to download the dependencies with Java 8, then switch > to Java 7 for the actual build. > > Is there a way to specify a JAVA_HOME for the compilation and testing, > but to use a different JAVA_HOME to invoke ant itself? The following works for me with Java 7u80 and Ant 1.9.16: 1) First, Ant options Note: the "set" command is on one line (may be wrapped by mail client) rem For Tomcat 8.5 / Java 7, see BUILDING.txt rem https://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider set "ANT_OPTS=-Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2 -Dhttps.cipherSuites=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384" 2) Second, Unlimited Strength Cryptography has to be enabled. 3) Third, CA certificate that signs https://sourceforge.net/ has to be known to Java. The file to be updated in my case was "C:\Program Files (x86)\Java\jdk1.7.0_80\jre\lib\security\cacerts" The command to update that file was "C:\Program Files (x86)\Java\jdk1.7.0_80\jre\bin\keytool.exe" -importcert -keystore cacerts -file sourceforge-net.pem Password: changeit where I used Firefox to download a certificate for the CA that signed the certificate for https://sourceforge.net/ -> certificate for "US/Let's Encrypt/R3" I am attaching it, if it helps. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch main updated: Ensure request URIs start with /
чт, 14 окт. 2021 г. в 13:37, Mark Thomas : > > On 14/10/2021 11:32, Konstantin Kolinko wrote: > > чт, 14 окт. 2021 г. в 13:01, Mark Thomas : > >> > >> On 14/10/2021 10:59, ma...@apache.org wrote: > >>> This is an automated email from the ASF dual-hosted git repository. > >>> > >>> markt pushed a commit to branch main > >>> in repository https://gitbox.apache.org/repos/asf/tomcat.git > >>> > >>> > >>> The following commit(s) were added to refs/heads/main by this push: > >>>new d33cce6 Ensure request URIs start with / > >>> d33cce6 is described below > >>> > >>> commit d33cce6c196efed8e35518711ba27af0a8c93d09 > >>> Author: Mark Thomas > >>> AuthorDate: Wed Oct 13 18:33:55 2021 +0100 > >>> > >>> Ensure request URIs start with / > >> > >> This is the third and final additional default check for consideration > >> to back-port. > >> > >> Servlet 6 also introduces the concept of "suspicious URIs" - sequences > >> like "/..;a=b/" and I'll be addressing those as an optional check in a > >> separate commit. > > > > How about an "OPTIONS * HTTP/1.1" request? > > > > https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/OPTIONS > > https://datatracker.ietf.org/doc/html/rfc7231#section-4.3.7 > > > > Does Tomcat respond to it by itself, without passing the request to > > servlets? > > That gets handled before the "starts with '/' check". Tomcat provides > the response. > > https://github.com/apache/tomcat/blob/main/java/org/apache/catalina/connector/CoyoteAdapter.java#L613 OK. Though note that line 627 is not followed by a "return" and will fall through to further processing. As such, the method parsePathParameters() changed by this commit may be called with an URL of "*". I see comments on lines 695-696: "Note we still want the mapper to find the correct host." Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch main updated: Ensure request URIs start with /
чт, 14 окт. 2021 г. в 13:01, Mark Thomas : > > On 14/10/2021 10:59, ma...@apache.org wrote: > > This is an automated email from the ASF dual-hosted git repository. > > > > markt pushed a commit to branch main > > in repository https://gitbox.apache.org/repos/asf/tomcat.git > > > > > > The following commit(s) were added to refs/heads/main by this push: > > new d33cce6 Ensure request URIs start with / > > d33cce6 is described below > > > > commit d33cce6c196efed8e35518711ba27af0a8c93d09 > > Author: Mark Thomas > > AuthorDate: Wed Oct 13 18:33:55 2021 +0100 > > > > Ensure request URIs start with / > > This is the third and final additional default check for consideration > to back-port. > > Servlet 6 also introduces the concept of "suspicious URIs" - sequences > like "/..;a=b/" and I'll be addressing those as an optional check in a > separate commit. How about an "OPTIONS * HTTP/1.1" request? https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/OPTIONS https://datatracker.ietf.org/doc/html/rfc7231#section-4.3.7 Does Tomcat respond to it by itself, without passing the request to servlets? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch main updated: Do not add a trailing / to a request URI during canonicalization.
чт, 14 окт. 2021 г. в 11:25, Mark Thomas :
>
> On 14/10/2021 09:22, ma...@apache.org wrote:
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > markt pushed a commit to branch main
> > in repository https://gitbox.apache.org/repos/asf/tomcat.git
> >
> >
> > The following commit(s) were added to refs/heads/main by this push:
> > new 70d4e9b Do not add a trailing / to a request URI during
> > canonicalization.
> > 70d4e9b is described below
> >
> > commit 70d4e9ba0a81a1d782fa50695a18d23f2f1f179c
> > Author: Mark Thomas
> > AuthorDate: Wed Oct 13 18:28:45 2021 +0100
> >
> > Do not add a trailing / to a request URI during canonicalization.
> >
> > This is part of the clarification in Servet 6.0 of the expected
> > canonicalization Servlet containers are expected to apply to request
> > URIs.
>
> All,
>
> This is the first of several clarifications. The question is do we want
> to back-port this change to earlier versions?
>
> My current thinking is that we should as the current behaviour looks
> wrong. We add a trailing "/" to simplify the normalization algorithm but
> then don't remove it after we have completed normalization.
>
Hi!
I have not thought about this in detail.
Just several quick observations / quick thoughts.
a. Generally, I like doing things correctly.
b. Looking at test example:
> doTestNormalize("/foo/.", "/foo");
It can be seen that "foo" is a directory,
and thus I think it actually behaves as follows:
Old behaviour:
1. Serve content of "/foo/"
New behaviour:
1. As "/foo" is a directory, Tomcat will likely won't serve it, but
will respond with a 302-redirect to "/foo/"
2. Serve content of "/foo/".
It is one more round-trip, but at least the browser will display a
correct normalized URL.
c. I think that browsers usually normalize URLs before making a
request, though I am not 100% sure. If so, the non-normalized URLs
will come from elsewhere, not from a browser. (And so there will be no
difference for browsers).
d. If backporting, it would better be configurable.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: ECJ, Tomcat 8.5.x and Java 17
пт, 8 окт. 2021 г. в 11:18, Mark Thomas :
>
> On 07/10/2021 20:59, Konstantin Kolinko wrote:
> > чт, 7 окт. 2021 г. в 18:46, Mark Thomas :
>
>
>
> >> Is this a problem worth solving? If it is, is there a better way?
> >
> > Hi!
> >
> > Last few days I was thinking of the following approaches:
>
>
>
>
> e) is certainly the more elegant solution but it does have some admin
> we'd need to do. a) is less elegant but avoids the admin. Maybe
> implement a) as a stop-gap while we see if e) is possible?
>
f)
Looks a bit like c) but another way around, combined with a):
1. Introduce new property
common-legacy.loader="${catalina.base}/lib/legacy/*.jar"
2. ECJ JARa are at the following locations:
${catalina.base}/lib/legacy/ecj-4.6.3.jar
- moved to legacy,
${catalina.base}/lib/ecj-4.20.jar
- added to the regular libs directory.
3. Attempt to load either
"org.eclipse.jdt.internal.compiler.batch.Main" class (their Main-Class)
or
"org.eclipse.jdt.internal.compiler.tool.EclipseCompiler" class (as
specified in their META-INF/services/javax.tools.JavaCompiler file)
or some other class usually used by Jasper (I have not checked the code).
If an attempt to load fails with
java.lang.UnsupportedClassVersionError (i.e. running with Java 7),
then exclude the library and use the paths in common-legacy.loader
property as fallback.
We routinely preload several classes at startup. An attempt to load
one more class is not much work. Loading it specifically from
ecj-4.20.jar and excluding that jar from classpath is some work/magic
to be done.
Additional notes:
a. The dependency on ECJ jar for users of Apache Maven is specified in
res/maven/tomcat-jasper.pom as
org.eclipse.jdt
ecj
3.12.3
If someone needs a newer version they may override the dependency.
b. Tomcat should be able to start successfully with no ECJ jar at classpath.
E.g. if somebody has already precompiled all their JSPs elsewhere, and
wants to run with no support for compilations of the JSPs.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: ECJ, Tomcat 8.5.x and Java 17
чт, 7 окт. 2021 г. в 22:59, Konstantin Kolinko : > чт, 7 окт. 2021 г. в 18:46, Mark Thomas : > > > Approach e) > Combine ecj-4.6.3.jar and ecj-4.20.jar (or later) into a single > multi-release jar, "ecj-4.3.6_and_4.20.jar". > See > https://openjdk.java.net/jeps/238 > > I mean that > - The META-INF/MANIFEST.MF file is replaced with one that has the > attribute "Multi-Release: true", and all other attributes except > Main-Class are removed. (I think that "Export-Package", "Bundle-Name", > "Bundle-Version", "Bundle-ClassPath" are to be removed. The > ecj-4.20.jar is signed. Those signatures are to be removed as well). > - The ecj-4.6.3.jar classes stay where they are. > - The ecj-4.20.jar classes go into META-INF/versions/9/ > A simple build file to create that jar with Apache Ant: [[[ ]]] Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: ECJ, Tomcat 8.5.x and Java 17
чт, 7 окт. 2021 г. в 18:46, Mark Thomas :
>
> Hi,
>
> As you will have seen from the 8.5.72 release vote and/or bug 65599
> there is an issue with 8.5.x, Java 17 and ECJ.
>
> In short:
> - the Java EE 7 spec requires that Tomcat 8.5.x runs on Java 7
> - Tomcat 8.5.x ships with ECJ 4.6.3, the newest version that runs on
>Java 7
> - ECJ 4.63 fails on Java 17 onwards
>
> I was wondering about shipping two versions of ECJ. Using 4.6.3 if
> running on Java 7 and 4.20 (or whatever Tomcat 9 onwards is using at the
> time) if running on Java 8.
>
> The implementation could go in ClassLoaderFactory.validateFile(). The
> idea is that it would skip adding the ECJ version that wasn't required
> to the class path. It would be a bit of a hack and it would almost
> certainly need to be hard-coded rather than configurable in anyway.
>
> This isn't the only way I can think of to do this but it is the one that
> requires the least user input (none) and is the least 'hacky'.
>
> Thoughts?
>
> Is this a problem worth solving? If it is, is there a better way?
Hi!
Last few days I was thinking of the following approaches:
(Let's count your approach of changing
"org.apache.catalina.startup.ClassLoaderFactory#validateFile()" as a))
Approach b)
Ship both ecj-4.6.3.jar and ecj-4.20.jar (or later) in separate
directories in ${catalina.home}, and let an a admin to choose one with
common.loader setting in the ${catalina.base}/conf/catalina.properties
file.
This is:
1. Create two subdirectories in "${catalina.home}/lib/": "ecj" and "ecj-legacy".
2. Move ecj-4.6.3.jar from ${catalina.home}/lib/ into
${catalina.home}/lib/ecj-legacy/
3. Add ecj-4.20.jar (or later) into ${catalina.home}/lib/ecj/
4. Add "${catalina.home}/lib/ecj-legacy/*.jar" to the default value of
common.loader setting in catalina.properties file.
Expectations:
- If one wants to run this version of Tomcat 8.5 on Java 17, they can
edit the ${catalina.base}/conf/catalina.properties file and change the
path to "${catalina.home}/lib/ecj/*.jar".
Advantage:
- It allows one to explicitly select the version of the library.
- I have personal experience with this approach. (In my dev
environment I have several database drivers in such distinct
directories in my ${catalina.home}". When I configure an instance of
Tomcat in Eclipse IDE to test my apps, I update configuration to
choose the one that I need.)
Disadvantage:
- If somebody already has a configured instance of Tomcat 8.5,
upgrading to this version will require editing the existing
catalina.properties file due to the changed defaults.
- This approach targets standalone installations of Tomcat. I have not
thought of what to do when Tomcat is launched with Tomcat class
instead of Bootstrap. I have not thought about how to update Tomcat
tests.
Approach c)
The same as b), but invent additional syntax for the "common.loader"
setting to allow excluding libraries from the class path.
This is:
- The ecj-4.6.3.jar file is not moved and stays in ${catalina.home}/lib/
- The Java 17 version of the common.loader setting looks like the following:
xxx,!"${catalina.base}/lib/ecj-4.6.3.jar","${catalina.base}/lib/ecj/*.jar",xxx
where !"foo" is the new syntax to exclude a library.
Approach d)
The same as c) but instead of the new syntax we have some magic to
remove duplicates.
- The Java 17 version of the common.loader setting looks like the following:
"${catalina.base}/lib/ecj/*.jar",xxx
- Both ecj-4.20.jar and ecj-4.6.3.jar are present in the classpath,
but some magic (a regexp? a helper class?) removes the latter as a
duplicate.
Approach e)
Combine ecj-4.6.3.jar and ecj-4.20.jar (or later) into a single
multi-release jar, "ecj-4.3.6_and_4.20.jar".
See
https://openjdk.java.net/jeps/238
I mean that
- The META-INF/MANIFEST.MF file is replaced with one that has the
attribute "Multi-Release: true", and all other attributes except
Main-Class are removed. (I think that "Export-Package", "Bundle-Name",
"Bundle-Version", "Bundle-ClassPath" are to be removed. The
ecj-4.20.jar is signed. Those signatures are to be removed as well).
- The ecj-4.6.3.jar classes stay where they are.
- The ecj-4.20.jar classes go into META-INF/versions/9/
I do not quite like this approach, but I tested it and it works.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.72
вт, 5 окт. 2021 г. в 10:49, Mark Thomas : > > On 05/10/2021 08:12, Mark Thomas wrote: > > On 05/10/2021 01:32, Christopher Schultz wrote: > >> All, > >> > >> I'm sorry about this release. The VOTE has officially passed, but I > >> fear I may have to re-roll the release as the Maven artifacts were not > >> signed properly at the time. I'm trying to decide what to do about it. > >> > >> I can re-roll the release under the same version number, but I'll have > >> to re-generate everything. I can't guarantee it will be byte-for-byte > >> identical for a few reasons, so I'm not sure how comfortable everyone > >> will be with their votes standing. > >> > >> Asking for a re-vote on a release is a little odd and may actually not > >> be okay ASF-wise. So I'm thinking maybe I should cancel the vote and > >> use a new version number which is source-identical to 8.5.72 and call > >> for a new vote with the new artifacts. > >> > >> I apologize for the confusion; I didn't notice the missing Maven items > >> at the time, and cleared-away everything after uploading everything to > >> svn. > > > > I might have a way to fix this. Given em an hour or two... > > I believe this is fixed. The Maven repository is now closed and the > staging repository in the original VOTE is available: > https://repository.apache.org/content/repositories/orgapachetomcat-1337 > > The files that were in the repository are unchanged. All I have done is > signed the files that were missing signatures (*.jar, *.zip, *.tar.gz > and *.pom) and the closed the repository. > > I suggest allowing 24 hours for anyone who voted to change their vote if > they wish and then either complete the release if the votes remain > unchanged or create a 8.5.73 release if there are any -1 votes. +1 to go. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.72
вс, 3 окт. 2021 г. в 16:10, Christopher Schultz : > > Konstantin, > > >> The Maven staging repo is: > >> https://repository.apache.org/content/repositories/orgapachetomcat-1337 > >> > > > 1. Maven repo is still 404, and > > Apologies for forgetting to close the Maven repo. Please check again. > The maven repo is still in the same state, 404 - Repository "orgapachetomcat-1337 (staging: open)" [id=orgapachetomcat-1337] exists but is not exposed. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.72
пт, 1 окт. 2021 г. в 18:47, Christopher Schultz : > > The proposed Apache Tomcat 8.5.72 release is now available for voting. > > The notable changes compared to 8.5.71 are: > > - Further robustness improvements to HTTP/2 flow control window > management > > - Fix an issue that caused some Servlet non-blocking API reads of the > HTTP request body to incorrectly use blocking IO. > > Along with lots of other bug fixes and improvements. > > For full details, see the changelog: > https://ci.apache.org/projects/tomcat/tomcat-8.5.x/docs/changelog.html > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.72/ > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1337 > The tag is: > https://github.com/apache/tomcat/tree/8.5.72 > 53c394049af76032bc7acab9de023013ad4fdc43 > > The proposed 8.5.72 release is: > [ ] Broken - do not release > [x] Stable - go ahead and release as 8.5.72 (stable) Notes: 1. Maven repo is still 404, and 2. Tomcat 8.5.72 is unusable with Java 17 unless ecj-4.6.3.jar is replaced with a later version. See https://bz.apache.org/bugzilla/show_bug.cgi?id=65599 Tested on Windows 10. Smoke tests OK with Java 7 (7u80) Unit tests pass with Java 7, 8 and 11. (32-bit 7u80, 64-bit 8u302, 11.0.12). Smoke tests and Unit tests fail with Java 17 (17.0.0): I added details to https://bz.apache.org/bugzilla/show_bug.cgi?id=65599#c2 Error handling in that case could be better, but as this is not a regression (occurs with 8.5.71 as well, as originally reported) and there is no fix for the root cause, I do not consider it a showstopper. I wonder whether now is the good time to decide on EOL schedule for Tomcat 8.5. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.72
пт, 1 окт. 2021 г. в 18:47, Christopher Schultz : > > The proposed Apache Tomcat 8.5.72 release is now available for voting. > [...] > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.72/ Just a note. The sources (apache-tomcat-8.5.72-src.tar.gz, *.zip) contain an extra file, not present in Git repository, ".build.properties.default.swp" It does not contain any secrets, as far as I see. A binary file with some chunks from the well-known "build.properties.default" file, a user name and file paths. It looks that it was created by VIM 8.2. Not a stopper. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.72
пт, 1 окт. 2021 г. в 18:47, Christopher Schultz : > > The proposed Apache Tomcat 8.5.72 release is now available for voting. > > [...] > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1337 Chris, The Maven staging repo (above) is not accessible: 404 - Repository "orgapachetomcat-1337 (staging: open)" [id=orgapachetomcat-1337] exists but is not exposed. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 9.0.54
вт, 28 сент. 2021 г. в 17:25, Rémy Maucherat : > > The proposed Apache Tomcat 9.0.54 release is now available for voting. > > The notable changes compared to 9.0.54 are: > > - Further robustness improvements to HTTP/2 flow control window >management > > - Improvements to the DataSourceUserDatabase > > - Fix an issue that caused some Servlet non-blocking API reads of the >HTTP request body to incorrectly use blocking IO. > > Along with lots of other bug fixes and improvements. > > For full details, see the changelog: > https://ci.apache.org/projects/tomcat/tomcat-9.0.x/docs/changelog.html > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.54/ > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1336 > The tag is: > https://github.com/apache/tomcat/tree/9.0.54 > 454f804f3336ec980e84eb84bb6a051e349c6d3a > > The proposed 9.0.54 release is: > [ ] Broken - do not release > [x] Stable - go ahead and release as 9.0.54 (stable) Tested on Windows 10 with 64-bit JDKs. Smoke tests OK (Java 8u302) Unit tests OK (Java 8u302, Java 11.0.12, Java 17.0.0). Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Refactoring handling of TRACE requests
пн, 27 сент. 2021 г. в 14:03, Mark Thomas : > > Hi all, > > I've been having some conversations at $work about Tomcat's handling of > TRACE requests and the allowTrace option on the Connector. Something > that was said in that discussion got me thinking. Why do we have special > handling for TRACE requests on the Connector? Why not use a security > constraint in the global web.xml? > > I've done a quick test, setting allowTrace to true on the Connector and > adding the following to the global web.xml: > > > > /* > TRACE > > > > > This blocks TRACE requests as expected. > > What do the folks here think about deprecating allowTrace on the > Connector for 10.0.x and removing it (and the special handling in > HttpServlet) in 10.1.x onwards - replacing it with the security > constraint above. In short, it does not work. See point 1.c) below and my test runs below an "~" bar. I am leaving my other points as I wrote them, for completeness. Looking at a copy of the Servlet Specification 4.0 1. How does that global constraint combine with one from webapp's web.xml and webapp's annotations? a) I am not sure: are they all combined according to the rules stated in the Servlet specification, or webapp settings override the global defaults? I think it is the former, but I do not see explicit mention in the docs (googling for "combine", "web.xml", "conf"). b) Spec ch.13.8.1 Combining Constraints "The special case of an authorization constraint that names no roles shall combine with any other constraints to override their affects and cause access to be precluded." If the answer to a) was "they are combined", it means that a web application cannot override the global "" that precludes access. c) Spec ch.13.8.3 Processing Requests "When a Servlet container receives a request, it shall use the algorithm described in “Use of URL Paths” on page 125 to select the constraints (if any) defined on the url-pattern that is the best match to the request URI." It means that the global constraint with /* is only applied when there is no better match for the URL. (It is combined only with constraints that use the same "/*", but not with any other better matches). Compare it with how filters are applied: any matching Filter is applied (ch.6.2.4), not just the best match. There is an example in ch.13.8.2: [[[ precluded methods /* /acme/wholesale/* /acme/retail/* GET POST ]]] The intent is to deny all methods except GET and POST. Note that instead of using just a "/*" pattern, it has to list the other two patterns used by other security constraints in the app. Otherwise it is not combined with them. Thus my conclusion is that not all TRACE requests are blocked with that configuration. 2. Some users upgrade Tomcat between versions by swapping the binaries (changing CATALINA_HOME). If they have to apply changes to their configurations (the files in CATALINA_BASE/conf/) to stay protected, there is a risk that the changes won't be applied. ~ Testing whether what I noted in 1.c) is true with Tomcat 10.1.0-M5: 1) default configuration Request: TRACE / HTTP/1.0 Response: HTTP/1.1 405 Allow: GET, HEAD, POST, OPTIONS Req: TRACE /tomcat.css HTTP/1.0 Resp: HTTP/1.1 405 Allow: HEAD, DELETE, POST, GET, OPTIONS, PUT 2) added allowTrace="true" on the Connector. Request: TRACE / HTTP/1.0 Response: HTTP/1.1 405 Allow: GET, HEAD, POST, OPTIONS No changes. The reason is that the above is processed by JspServlet (for index.jsp), not by DefaultServlet. Req: TRACE /tomcat.css HTTP/1.0 Resp: HTTP/1.1 200 OK. TRACE request is now allowed. 3) also added the proposed to conf/web.xml Req: TRACE / HTTP/1.0 Resp: HTTP/1.1 403 Note that it is 403 instead of 405. Req: TRACE /tomcat.css HTTP/1.0 Resp: HTTP/1.1 403 OK, denied with 403. Req: TRACE /manager/status HTTP/1.0 Resp: HTTP/1.1 401 Note that it is 401 instead of 403 or 405. 4) If I also change webapps/manager/WEB-INF/web.xml: I remove auth-constraint element from security-constraint for /status/*, i.e. to allow unauthenticated access to Status servlet Req: TRACE /manager/status HTTP/1.0 Resp: HTTP/1.1 200 The TRACE request is not denied. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.71
чт, 9 сент. 2021 г. в 22:50, Christopher Schultz : > > The proposed Apache Tomcat 8.5.71 release is now available for voting. > > The notable changes compared to 8.5.70 are: > > > For full details, see the changelog: > https://ci.apache.org/projects/tomcat/tomcat-8.0.x/docs/changelog.html > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.71/ > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1333 > The tag is: > > https://github.com/apache/tomcat/commit/9e60ee33816f3f28af81535c108e6bd23f2ef970 > > https://github.com/apache/tomcat/tree/8.5.71 > 9e60ee33816f3f28af81535c108e6bd23f2ef970 > > The proposed 8.5.71 release is: > [ ] Broken - do not release > [x] Stable - go ahead and release as 8.5.71 (stable) Tested on Windows 10. Smoke-testing OK (installer, examples with Java 7u80). Tests OK (32-bit Java 7u80, 64-bit Java 8u302, 11.0.12, 16.0.2). Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: buildbot failure in on tomcat-9.0.x
вт, 7 сент. 2021 г. в 12:48, : > > The Buildbot has detected a new failure on builder tomcat-9.0.x while > building tomcat. Full details are available at: > https://ci.apache.org/builders/tomcat-9.0.x/builds/126 > > Buildbot URL: https://ci.apache.org/ > > Buildslave for this Build: asf946_ubuntu > > Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-9.0-commit' > triggered this build > Build Source Stamp: [branch 9.0.x] bd3cfa36856aba6648c57c0b0e664c0835f98e13 > Blamelist: Mark Thomas > > BUILD FAILED: failed compile_1 The only failed test: [concat] Testsuites with failed tests: [concat] TEST-org.apache.coyote.http2.TestStreamQueryString.NIO.txt The log file: https://ci.apache.org/projects/tomcat/tomcat-9.0.x/logs/126/TEST-org.apache.coyote.http2.TestStreamQueryString.NIO.txt The only failed test there: [[[ Testcase: testQueryString[54] took 0.146 sec Caused an ERROR End of input stream java.io.IOException: End of input stream at org.apache.coyote.http2.Http2TestBase$TestInput.fill(Http2TestBase.java:979) at org.apache.coyote.http2.Http2Parser$Input.fill(Http2Parser.java:725) at org.apache.coyote.http2.Http2Parser.readFrame(Http2Parser.java:78) at org.apache.coyote.http2.Http2Parser.readFrame(Http2Parser.java:71) at org.apache.coyote.http2.Http2TestBase.readSimpleGetResponse(Http2TestBase.java:464) at org.apache.coyote.http2.TestStreamQueryString.testQueryString(TestStreamQueryString.java:93) ]]] All other tests in the series of 96 completed successfully. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r49785 - in /dev/tomcat/tomcat-10/v10.0.11: ./ bin/ bin/embed/ src/
вт, 7 сент. 2021 г. в 10:54, Mark Thomas :
>
> On 07/09/2021 08:20, Rémy Maucherat wrote:
> > On Tue, Sep 7, 2021 at 8:42 AM Konstantin Kolinko
> > wrote:
> >>
> >> пн, 6 сент. 2021 г. в 21:28, :
> >>>
> >>> Author: markt
> >>> Date: Mon Sep 6 18:28:21 2021
> >>> New Revision: 49785
> >>>
> >>> Log:
> >>> Upload 10.0.11 for voting
> >>>
> >>> Added:
>
>
>
> >>> dev/tomcat/tomcat-10/v10.0.11/bin/apache-tomcat-10.0.11.tar.gz
> >>> (with props)
> >>> dev/tomcat/tomcat-10/v10.0.11/bin/apache-tomcat-10.0.11.tar.gz.sha512
> >>> dev/tomcat/tomcat-10/v10.0.11/bin/apache-tomcat-10.0.11.zip (with
> >>> props)
> >>> dev/tomcat/tomcat-10/v10.0.11/bin/apache-tomcat-10.0.11.zip.sha512
> >>
> >> *.asc files are missing for apache-tomcat-10.0.11.tar.gz and
> >> apache-tomcat-10.0.11.zip above.
> >
> > This is a funny one. The build.xml is fine, there's no error building,
> > but the signature for these two files didn't happen. There's a bug
> > somewhere ...
>
> Indeed. I can't see what it is though. The Ant build is, as far as I am
> aware, single threaded so everything should be sequential.
I think "res/maven/mvn-pub.xml" deletes those files.
There is
[[[
...
]]]
And it is called with
file="${tomcat.release.path}/v${maven.deploy.binary.version}/bin/apache-tomcat-${maven.deploy.binary.version}"/>
and operates on the files that are in the "release" directory.
If mvn-pub.xml is called before "svn add && svn commit" (that uploads
the files to dist.a.o) completes, you may see a race.
A possible solution
- Modify mvn-pub.xml so that it uses GPG to validate existing asc
signatures for .zip and .tar.gz files, instead of deleting and
recreating them.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r49785 - in /dev/tomcat/tomcat-10/v10.0.11: ./ bin/ bin/embed/ src/
пн, 6 сент. 2021 г. в 21:28, : > > Author: markt > Date: Mon Sep 6 18:28:21 2021 > New Revision: 49785 > > Log: > Upload 10.0.11 for voting > > Added: > dev/tomcat/tomcat-10/v10.0.11/ > dev/tomcat/tomcat-10/v10.0.11/KEYS > dev/tomcat/tomcat-10/v10.0.11/README.html > dev/tomcat/tomcat-10/v10.0.11/RELEASE-NOTES > dev/tomcat/tomcat-10/v10.0.11/bin/ > dev/tomcat/tomcat-10/v10.0.11/bin/README.html > dev/tomcat/tomcat-10/v10.0.11/bin/apache-tomcat-10.0.11-deployer.tar.gz > (with props) > > dev/tomcat/tomcat-10/v10.0.11/bin/apache-tomcat-10.0.11-deployer.tar.gz.asc > > dev/tomcat/tomcat-10/v10.0.11/bin/apache-tomcat-10.0.11-deployer.tar.gz.sha512 > dev/tomcat/tomcat-10/v10.0.11/bin/apache-tomcat-10.0.11-deployer.zip > (with props) > dev/tomcat/tomcat-10/v10.0.11/bin/apache-tomcat-10.0.11-deployer.zip.asc > > dev/tomcat/tomcat-10/v10.0.11/bin/apache-tomcat-10.0.11-deployer.zip.sha512 > dev/tomcat/tomcat-10/v10.0.11/bin/apache-tomcat-10.0.11-fulldocs.tar.gz > (with props) > > dev/tomcat/tomcat-10/v10.0.11/bin/apache-tomcat-10.0.11-fulldocs.tar.gz.asc > > dev/tomcat/tomcat-10/v10.0.11/bin/apache-tomcat-10.0.11-fulldocs.tar.gz.sha512 > dev/tomcat/tomcat-10/v10.0.11/bin/apache-tomcat-10.0.11-windows-x64.zip > (with props) > > dev/tomcat/tomcat-10/v10.0.11/bin/apache-tomcat-10.0.11-windows-x64.zip.asc > > dev/tomcat/tomcat-10/v10.0.11/bin/apache-tomcat-10.0.11-windows-x64.zip.sha512 > dev/tomcat/tomcat-10/v10.0.11/bin/apache-tomcat-10.0.11-windows-x86.zip > (with props) > > dev/tomcat/tomcat-10/v10.0.11/bin/apache-tomcat-10.0.11-windows-x86.zip.asc > > dev/tomcat/tomcat-10/v10.0.11/bin/apache-tomcat-10.0.11-windows-x86.zip.sha512 > dev/tomcat/tomcat-10/v10.0.11/bin/apache-tomcat-10.0.11.exe (with props) > dev/tomcat/tomcat-10/v10.0.11/bin/apache-tomcat-10.0.11.exe.asc > dev/tomcat/tomcat-10/v10.0.11/bin/apache-tomcat-10.0.11.exe.sha512 > dev/tomcat/tomcat-10/v10.0.11/bin/apache-tomcat-10.0.11.tar.gz (with > props) > dev/tomcat/tomcat-10/v10.0.11/bin/apache-tomcat-10.0.11.tar.gz.sha512 > dev/tomcat/tomcat-10/v10.0.11/bin/apache-tomcat-10.0.11.zip (with props) > dev/tomcat/tomcat-10/v10.0.11/bin/apache-tomcat-10.0.11.zip.sha512 *.asc files are missing for apache-tomcat-10.0.11.tar.gz and apache-tomcat-10.0.11.zip above. > dev/tomcat/tomcat-10/v10.0.11/bin/embed/ > > dev/tomcat/tomcat-10/v10.0.11/bin/embed/apache-tomcat-10.0.11-embed.tar.gz > (with props) > > dev/tomcat/tomcat-10/v10.0.11/bin/embed/apache-tomcat-10.0.11-embed.tar.gz.asc > > dev/tomcat/tomcat-10/v10.0.11/bin/embed/apache-tomcat-10.0.11-embed.tar.gz.sha512 > dev/tomcat/tomcat-10/v10.0.11/bin/embed/apache-tomcat-10.0.11-embed.zip > (with props) > > dev/tomcat/tomcat-10/v10.0.11/bin/embed/apache-tomcat-10.0.11-embed.zip.asc > > dev/tomcat/tomcat-10/v10.0.11/bin/embed/apache-tomcat-10.0.11-embed.zip.sha512 > dev/tomcat/tomcat-10/v10.0.11/src/ > dev/tomcat/tomcat-10/v10.0.11/src/apache-tomcat-10.0.11-src.tar.gz > (with props) > dev/tomcat/tomcat-10/v10.0.11/src/apache-tomcat-10.0.11-src.tar.gz.asc > dev/tomcat/tomcat-10/v10.0.11/src/apache-tomcat-10.0.11-src.tar.gz.sha512 > dev/tomcat/tomcat-10/v10.0.11/src/apache-tomcat-10.0.11-src.zip (with > props) > dev/tomcat/tomcat-10/v10.0.11/src/apache-tomcat-10.0.11-src.zip.asc > dev/tomcat/tomcat-10/v10.0.11/src/apache-tomcat-10.0.11-src.zip.sha512 > > Added: dev/tomcat/tomcat-10/v10.0.11/KEYS > ... Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r49786 - in /dev/tomcat/tomcat-9/v9.0.53: ./ bin/ bin/embed/ src/
пн, 6 сент. 2021 г. в 22:16, : > > Author: remm > Date: Mon Sep 6 19:16:15 2021 > New Revision: 49786 > > Log: > Upload 9.0.53 for voting > > Added: > dev/tomcat/tomcat-9/v9.0.53/ > dev/tomcat/tomcat-9/v9.0.53/KEYS > dev/tomcat/tomcat-9/v9.0.53/README.html > dev/tomcat/tomcat-9/v9.0.53/RELEASE-NOTES > dev/tomcat/tomcat-9/v9.0.53/bin/ > dev/tomcat/tomcat-9/v9.0.53/bin/README.html > dev/tomcat/tomcat-9/v9.0.53/bin/apache-tomcat-9.0.53-deployer.tar.gz > (with props) > dev/tomcat/tomcat-9/v9.0.53/bin/apache-tomcat-9.0.53-deployer.tar.gz.asc > (with props) > > dev/tomcat/tomcat-9/v9.0.53/bin/apache-tomcat-9.0.53-deployer.tar.gz.sha512 > dev/tomcat/tomcat-9/v9.0.53/bin/apache-tomcat-9.0.53-deployer.zip (with > props) > dev/tomcat/tomcat-9/v9.0.53/bin/apache-tomcat-9.0.53-deployer.zip.asc > (with props) > dev/tomcat/tomcat-9/v9.0.53/bin/apache-tomcat-9.0.53-deployer.zip.sha512 > dev/tomcat/tomcat-9/v9.0.53/bin/apache-tomcat-9.0.53-fulldocs.tar.gz > (with props) > dev/tomcat/tomcat-9/v9.0.53/bin/apache-tomcat-9.0.53-fulldocs.tar.gz.asc > (with props) > > dev/tomcat/tomcat-9/v9.0.53/bin/apache-tomcat-9.0.53-fulldocs.tar.gz.sha512 > dev/tomcat/tomcat-9/v9.0.53/bin/apache-tomcat-9.0.53-windows-x64.zip > (with props) > dev/tomcat/tomcat-9/v9.0.53/bin/apache-tomcat-9.0.53-windows-x64.zip.asc > (with props) > > dev/tomcat/tomcat-9/v9.0.53/bin/apache-tomcat-9.0.53-windows-x64.zip.sha512 > dev/tomcat/tomcat-9/v9.0.53/bin/apache-tomcat-9.0.53-windows-x86.zip > (with props) > dev/tomcat/tomcat-9/v9.0.53/bin/apache-tomcat-9.0.53-windows-x86.zip.asc > (with props) > > dev/tomcat/tomcat-9/v9.0.53/bin/apache-tomcat-9.0.53-windows-x86.zip.sha512 > dev/tomcat/tomcat-9/v9.0.53/bin/apache-tomcat-9.0.53.exe (with props) > dev/tomcat/tomcat-9/v9.0.53/bin/apache-tomcat-9.0.53.exe.asc (with > props) > dev/tomcat/tomcat-9/v9.0.53/bin/apache-tomcat-9.0.53.exe.sha512 > dev/tomcat/tomcat-9/v9.0.53/bin/apache-tomcat-9.0.53.tar.gz (with props) > dev/tomcat/tomcat-9/v9.0.53/bin/apache-tomcat-9.0.53.tar.gz.sha512 > dev/tomcat/tomcat-9/v9.0.53/bin/apache-tomcat-9.0.53.zip (with props) > dev/tomcat/tomcat-9/v9.0.53/bin/apache-tomcat-9.0.53.zip.sha512 *.asc files are missing for apache-tomcat-9.0.53.tar.gz and apache-tomcat-9.0.53.zip above. > dev/tomcat/tomcat-9/v9.0.53/bin/embed/ > dev/tomcat/tomcat-9/v9.0.53/bin/embed/apache-tomcat-9.0.53-embed.tar.gz > (with props) > > dev/tomcat/tomcat-9/v9.0.53/bin/embed/apache-tomcat-9.0.53-embed.tar.gz.asc > (with props) > > dev/tomcat/tomcat-9/v9.0.53/bin/embed/apache-tomcat-9.0.53-embed.tar.gz.sha512 > dev/tomcat/tomcat-9/v9.0.53/bin/embed/apache-tomcat-9.0.53-embed.zip > (with props) > dev/tomcat/tomcat-9/v9.0.53/bin/embed/apache-tomcat-9.0.53-embed.zip.asc > (with props) > > dev/tomcat/tomcat-9/v9.0.53/bin/embed/apache-tomcat-9.0.53-embed.zip.sha512 > dev/tomcat/tomcat-9/v9.0.53/src/ > dev/tomcat/tomcat-9/v9.0.53/src/apache-tomcat-9.0.53-src.tar.gz (with > props) > dev/tomcat/tomcat-9/v9.0.53/src/apache-tomcat-9.0.53-src.tar.gz.asc > (with props) > dev/tomcat/tomcat-9/v9.0.53/src/apache-tomcat-9.0.53-src.tar.gz.sha512 > dev/tomcat/tomcat-9/v9.0.53/src/apache-tomcat-9.0.53-src.zip (with > props) > dev/tomcat/tomcat-9/v9.0.53/src/apache-tomcat-9.0.53-src.zip.asc (with > props) > dev/tomcat/tomcat-9/v9.0.53/src/apache-tomcat-9.0.53-src.zip.sha512 > > Added: dev/tomcat/tomcat-9/v9.0.53/KEYS > ... Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.70
сб, 14 авг. 2021 г. в 00:38, Christopher Schultz : > > Mark, > > On 8/9/21 16:05, Mark Thomas wrote: > > The proposed Apache Tomcat 8.5.70 release is now available for voting. > > > > [...] > > > > The proposed 8.5.70 release is: > > [ ] Broken - do not release > > [X] Stable - go ahead and release as 8.5.70 > > Thanks for RM'ing. > > I won't veto the release, but it appears that you signed the (non-Maven) > release artifacts with an expired PGP key. I'm not even sure how that's > possible (GPG should refuse to do such things). Before release, I would > recommend replacing the *.asc files; the originals obviously do not need > to change. I did not check the Maven artifacts for similar issues. Chris, Checking the files, gpg: assuming signed data in 'apache-tomcat-8.5.70.zip' gpg: Signature made Mon Aug 9 19:18:24 2021 RTZ gpg:using RSA key E4B2A4687C520E8EFEFB2777E94CA026DD51042F I have not tested the KEYS file, but I do not see such key at key servers, e,g, https://keyserver.ubuntu.com/ adding '0x' to search, i.e. 0xE4B2A4687C520E8EFEFB2777E94CA026DD51042F nor in Mark's profile at https://whimsy.apache.org/roster/committer/markt For comparison, looking at 10.1.0-M4 files, they were signed with a different key: gpg: assuming signed data in 'apache-tomcat-10.1.0-M4.zip' gpg: Signature made Tue Aug 3 21:58:07 2021 RTZ gpg:using RSA key A9C5DF4D22E8D9875A5110C01C5A2F6059E7 gpg: Good signature from "Mark E D Thomas " [unknown] and this key is present in Mark's profile and is known by the Key server. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.70
пн, 9 авг. 2021 г. в 23:05, Mark Thomas : > > The proposed Apache Tomcat 8.5.70 release is now available for voting. > > Chris was having some difficulties before the weekend getting the > release to build. He hasn't had time to get to the bottom of these > issues and time is ticking on so I took a look. I had different issues > on Windows but was still unable to complete the release. With the > addition of JSign, we have the option to build a full release on Linux > so I tried that and it was successful. If successful, this will be the > first release for a very long time built on Linux. > > Given the above, additional scrutiny on the release artefacts targetted > at Windows would be welcome. > > The notable changes compared to the 8.5.69 release are: > > - Correct a regression in the previous release in the HTTP/2 flow >control window management along with additional improvements to HTTP/2 >flow control > > - Make the CorsFilter simpler to extend > > - To avoid unnecessary cache revalidation, do not add an HTTP Expires >header when setting adding an HTTP header of CacheControl: private > > Along with lots of other bug fixes and improvements. > > For full details, see the changelog: > https://ci.apache.org/projects/tomcat/tomcat-8.5.x/docs/changelog.html > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.70/ > > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1329/ > > The tag is: > https://github.com/apache/tomcat/tree/8.5.70 > 3d2e8b1964d4dff3c0656618edc0b09d0d5634b8 > > The proposed 8.5.70 release is: > [ ] Broken - do not release > [x] Stable - go ahead and release as 8.5.70 Tested on Windows 10. - Smoke testing OK (with 32-bit Java 7u80 from Oracle) - Unit tests OK (32-bit Java 7u80 from Oracle, 64-bit Java 8u292 from AdoptOpenJDK, Java 11.0.12 from Eclipse Temurin - former AdoptOpenJDK, Java 16.0.2 from OpenJDK). Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: openssl-3.0.0 test failures with 9.0.x (I have not checked the other branches)
вт, 10 авг. 2021 г. в 15:02, jean-frederic clere : > > Hi, > > I have the following failure with ant test: > [concat] TEST-org.apache.tomcat.util.net.TestSSLHostConfigCompat.APR.txt > [concat] TEST-org.apache.tomcat.util.net.TestSSLHostConfigCompat.NIO.txt > [concat] > TEST-org.apache.tomcat.util.net.TestSSLHostConfigCompat.NIO2.txt > [concat] > TEST-org.apache.tomcat.util.net.openssl.ciphers.TestCipher.APR.txt > [concat] > TEST-org.apache.tomcat.util.net.openssl.ciphers.TestCipher.NIO.txt > [concat] > TEST-org.apache.tomcat.util.net.openssl.ciphers.TestCipher.NIO2.txt > [concat] > TEST-org.apache.tomcat.util.net.openssl.ciphers.TestOpenSSLCipherConfigurationParser.APR.txt > [concat] > TEST-org.apache.tomcat.util.net.openssl.ciphers.TestOpenSSLCipherConfigurationParser.NIO.txt > [concat] > TEST-org.apache.tomcat.util.net.openssl.ciphers.TestOpenSSLCipherConfigurationParser.NIO2.txt > > The ciphers ones are not new for me on fedora, the > TestSSLHostConfigCompat ones look new, is anyone seeing those? > I was trying with openssl/"master". Looking at Apache Gump, - tomcat/10.1.x (main) fails to compile Apparently Gunp tries to build it with Java 8 instead of Java 11 - tomcat//10.0.x with APR: http://vmgump.apache.org/tomcat-10.0.x/tomcat-10.0.x-test-apr/index.html Two failing tests: [concat] Testsuites with failed tests: [concat] TEST-org.apache.tomcat.util.net.openssl.ciphers.TestCipher.APR.txt [concat] TEST-org.apache.tomcat.util.net.openssl.ciphers.TestOpenSSLCipherConfigurationParser.APR.txt Content of those log files: The first one: http://vmgump.apache.org/tomcat-10.0.x/tomcat-10.0.x-test-apr/gump_file/TEST-org.apache.tomcat.util.net.openssl.ciphers.TestCipher.APR.txt.html [[[ Testsuite: org.apache.tomcat.util.net.openssl.ciphers.TestCipher Tests run: 3, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.069 sec - Standard Error - /srv/gump/public/workspace/openssl-master/dest-20210810/bin/openssl: error while loading shared libraries: libssl.so.3: cannot open shared object file: No such file or directory /srv/gump/public/workspace/openssl-master/dest-20210810/bin/openssl: error while loading shared libraries: libssl.so.3: cannot open shared object file: No such file or directory /srv/gump/public/workspace/openssl-master/dest-20210810/bin/openssl: error while loading shared libraries: libssl.so.3: cannot open shared object file: No such file or directory - --- [...] Testcase: testOpenSSLCipherAvailability took 0.001 sec FAILED Unavailable cipher suites: [...SKIPPED a list of 160 cipher names...] expected:<0> but was:<160> at org.apache.tomcat.util.net.openssl.ciphers.TestCipher.testOpenSSLCipherAvailability(TestCipher.java:97) ]]] The second one: http://vmgump.apache.org/tomcat-10.0.x/tomcat-10.0.x-test-apr/gump_file/TEST-org.apache.tomcat.util.net.openssl.ciphers.TestOpenSSLCipherConfigurationParser.APR.txt.html Clicking on "Complete File" to see the content, it is the same error throughout the file: /srv/gump/public/workspace/openssl-master/dest-20210810/bin/openssl: error while loading shared libraries: libssl.so.3: cannot open shared object file: No such file or directory Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 9.0.52
сб, 31 июл. 2021 г. в 07:35, Rémy Maucherat : > > The proposed Apache Tomcat 9.0.52 release is now available for voting. > > The notable changes compared to 9.0.52 are: > > - Correct a regression in the previous release in the HTTP/2 flow >control window management > > - Correct a regression the could cause some TLS connections to hang when >using NIO > > - Use of GraalVM native images no longer automatically disables JMX >support. > > Along with lots of other bug fixes and improvements. > > For full details, see the changelog: > https://ci.apache.org/projects/tomcat/tomcat-9.0.x/docs/changelog.html > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.52/ > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1327 > The tag is: > https://github.com/apache/tomcat/tree/9.0.52 > 4eb8a379747847fd11ab44a54cc108b05eaa82a0 > > The proposed 9.0.52 release is: > [ ] Broken - do not release > [x] Stable - go ahead and release as 9.0.52 (stable) Smoke tests OK Unit tests OK (64-bit Java 8u292, Java 11.0.11, Java 16.0.1 on Windows 10) Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 10.0.9
пт, 30 июл. 2021 г. в 01:34, Konstantin Kolinko : > > чт, 29 июл. 2021 г. в 22:07, Mark Thomas : > > > > The proposed Apache Tomcat 10.0.9 release is now available for > > voting. > > > > > > For full details, see the changelog: > > https://ci.apache.org/projects/tomcat/tomcat-10.0.x/docs/changelog.html > > > > It can be obtained from: > > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.9/ > > Looking at the list of files in "svn commit: r49073 - in > /dev/tomcat/tomcat-10/v10.0.9", > >... > dev/tomcat/tomcat-10/v10.0.9/bin/apache-tomcat-10.0.9.exe (with props) > dev/tomcat/tomcat-10/v10.0.9/bin/apache-tomcat-10.0.9.exe.asc > dev/tomcat/tomcat-10/v10.0.9/bin/apache-tomcat-10.0.9.exe.sha512 > dev/tomcat/tomcat-10/v10.0.9/bin/apache-tomcat-10.0.9.tar.gz (with > props) > dev/tomcat/tomcat-10/v10.0.9/bin/apache-tomcat-10.0.9.tar.gz.sha512 > dev/tomcat/tomcat-10/v10.0.9/bin/apache-tomcat-10.0.9.zip (with props) > dev/tomcat/tomcat-10/v10.0.9/bin/apache-tomcat-10.0.9.zip.sha512 >... > > Note that *.asc signatures are missing for the above two ones (.tar.gz and > zip) > [x] Broken Broken. The same error as I reported for 9.0.51 RC. A smoke-test test fails (Windows installer + Java 8u292 from AdoptOpenJDK, on Windows 10): The examples webapp fails to start (shows error 404). The following exception is in catalina.2021-07-30.log: 30-Jul-2021 08:54:13.792 SEVERE [main] org.apache.catalina.startup.HostConfig.deployDirectory Error deploying web application directory [C:\Program Files\Apache Software Foundation\Tomcat 10.0\webapps\examples] java.lang.IllegalStateException: Error starting child at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:729) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:698) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1188) at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:2023) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:112) at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:1098) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:480) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1708) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:320) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123) at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:423) at org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:366) at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:946) at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:886) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1396) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1386) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:134) at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:919) at org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:263) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.StandardService.startInternal(StandardService.java:432) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:927) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.startup.Catalina.start(Catalina.java:795) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:345)
Re: [VOTE] Release Apache Tomcat 9.0.51
пт, 30 июл. 2021 г. в 07:01, Rémy Maucherat : > > The proposed Apache Tomcat 9.0.51 release is now available for voting. > > ... > The proposed 9.0.51 release is: > [x] Broken - do not release > [ ] Stable - go ahead and release as 9.0.51 (stable) Broken. A smoke-test test fails (Windows installer + Java 8u292 from AdoptOpenJDK, on Windows 10): The examples webapp fails to start (shows error 404). The following exception is in catalina.2021-07-30.log: 30-Jul-2021 08:44:39.231 SEVERE [main] org.apache.catalina.startup.HostConfig.deployDirectory Error deploying web application directory [C:\Program Files\Apache Software Foundation\Tomcat 9.0\webapps\examples] java.lang.IllegalStateException: Error starting child at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:729) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:698) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:696) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1185) at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1933) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:112) at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:1095) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:477) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1618) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:319) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123) at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:423) at org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:366) at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:946) at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:835) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1396) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1386) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:134) at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:919) at org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:263) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.StandardService.startInternal(StandardService.java:432) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:927) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.startup.Catalina.start(Catalina.java:772) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:345) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:476) Caused by: org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/examples]] at org.apache.catalina.util.LifecycleBase.handleSubClassException(LifecycleBase.java:440) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:198) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:726) ... 37 more Caused by: java.lang.NullPointerException at websocket.ExamplesConfig.getAnnotatedEndpointClasses(ExamplesConfig.java:60) at org.apache.tomcat.websocket.server.WsSci.onStartup(WsSci.java:111) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5219) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) ... 38 more Best regards, Konstantin Kolinko - To unsubscribe,
Re: [VOTE] Release Apache Tomcat 10.0.9
чт, 29 июл. 2021 г. в 22:07, Mark Thomas : > > The proposed Apache Tomcat 10.0.9 release is now available for > voting. > > > For full details, see the changelog: > https://ci.apache.org/projects/tomcat/tomcat-10.0.x/docs/changelog.html > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.9/ Looking at the list of files in "svn commit: r49073 - in /dev/tomcat/tomcat-10/v10.0.9", ... dev/tomcat/tomcat-10/v10.0.9/bin/apache-tomcat-10.0.9.exe (with props) dev/tomcat/tomcat-10/v10.0.9/bin/apache-tomcat-10.0.9.exe.asc dev/tomcat/tomcat-10/v10.0.9/bin/apache-tomcat-10.0.9.exe.sha512 dev/tomcat/tomcat-10/v10.0.9/bin/apache-tomcat-10.0.9.tar.gz (with props) dev/tomcat/tomcat-10/v10.0.9/bin/apache-tomcat-10.0.9.tar.gz.sha512 dev/tomcat/tomcat-10/v10.0.9/bin/apache-tomcat-10.0.9.zip (with props) dev/tomcat/tomcat-10/v10.0.9/bin/apache-tomcat-10.0.9.zip.sha512 ... Note that *.asc signatures are missing for the above two ones (.tar.gz and zip) Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] 03/03: Add support for coercing LambdaExpression to any functional interface
пт, 9 июл. 2021 г. в 12:19, Mark Thomas : > > On 09/07/2021 09:58, Konstantin Kolinko wrote: > > Thanks Konstantin. This is good feedback. > > [...] > > > I wonder how Java itself (a java compiler) deals with coercion of > > lambdas to interfaces. Either it generates calls to some helper API, > > or it just repeats the same boilerplate code over and over. > > I'm not sure. I did look to see if there was anything in the public API > around this I could use to help but didn't find anything. I found some info: https://blogs.oracle.com/javamagazine/behind-the-scenes-how-do-lambda-expressions-really-work-in-java "Behind the scenes: How do lambda expressions really work in Java?" https://docs.oracle.com/javase/8/docs/api/java/lang/invoke/LambdaMetafactory.html >From a quick read, it looks like it does not use reflection API, but a newer invocation API. I am not sure whether it is useful at this point. Just sharing. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
