Re: Support RFC6265 cookie processing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24/12/2013 01:21, Jeremy Boynes wrote: > In comments on issue #55917, there was suggestion for refactoring > cookie support along the lines described in RFC6265. No, that isn't what I said. What I said was that now might be a good time to refactor the cookie parsing to use the HttpParser and that if we did that, that we should keep RFC6265 in mind. My intention was to suggest that if there were places where RFC6265 suggested relaxing the parsing rules and those rules could be relaxed without creating ambiguities or security concerns then we should consider such a change. I also hinted at the 'fun' we have had with cookies in the past. I strongly recommend that you go and read all the various discussions and bug reports relating to cookie parsing. In particular, the requirements of RFC2616 for HTTP headers were often overlooked. > Reading this RFC, it appears to be more of an effort to standardize > the actual behaviour seen on the Internet for different browser and > server implementations. The observation is the RFC2109 has received > limited adoption and RFC2965 virtually none at all, with most > implementations falling back to the original specification released > by Netscape that contains certain ambiguities. While I agree that RFC2965 has received little adoption, I disagree with the remainder. With the exception of internet explorer (and this might have changed in the few years since I last looked) the browsers all had pretty good support for RFC2109. > The Servlet spec’s JavaDoc for Cookie refers to RFC2109 behaviour > with caveats around interoperability. It defines version 0 as > complying with Netscape’s original specification and version 1 as > complying RFC2109 (with the note “Since RFC 2109 is still somewhat > new, consider version 1 as experimental; do not use it yet on > production sites”). That text is unchanged since at least Servlet 2.3 (12 years) so I wouldn't give it too much weight. The important part is that the Servlet spec requires support for the Netscape spec and RFC2109. > The current implementation uses a number of system properties to > control how cookies are validated. In implementing RFC6265 I hope > that some of these can be eliminated. If not, I would propose to > add configuration options on the Connector or Host objects to allow > the configuration to be set separately for different host domains. Every single one of those options was created for a good reason. As a minimum, the discussion that lead to the creation of the option needs to be reviewed before dropping the option. Per connector or per host options are unlikely to be useful. Per context options are more likely to be a better choice. > RFC6265 has separate sections in respect for generating and > parsing cookie headers. It follows the practice that generation be > strict but parsing be more tolerant of invalid input. Our current > implementation generally follows that trend by suppressing invalid > input data (after logging). However, for some input data, primary > CTLs, it throws an IllegalArgumentException from the connector > which does not allow the application to recover. In refactoring, I > would propose to simply ignore that input thereby allowing the > application to handle it, for example by parsing the header field > manually. Cookie parsing in particular needs to be tolerant of > cookies set by other sources, including different servers handling > other parts of the domain and JavaScript or other client-side code > setting values in the browser. What do you mean by ignoring the input? It could be any of: a) skipping the CTL character but otherwise processing the cookie b) replacing the CTL with a space c) ignoring the individual cookie d) ignoring the entire cookie header I'd support c) but am unlikely to support a) b) or d) > In light of this, I propose separating the “Set-Cookie” generation > side from the “Cookie” parsing side. A complete separation may not be appropriate. They share a lot of common code. > Generation == The general principle here would be to use > the version property of Cookie to determine the level of > verification to perform: if 0 follow RFC6265, if 1 use RFC2109. The > primary verification point would be in > HttpServletRequest#addCookie() which would use the version in the > Cookie instance. Characters will always be converted to octets > using the ISO-8859-1 charset; unmappable values will result in an > IAE. That is what used to happen and will lead to invalid cookies being generated. For valid cookies to be generated, the automatic switching from v0 to v1 needs to be retained. (As an aside, I believe the logic for this is correct but the comments and the method names appear to be misleading.) > The Servlet spec requires an IAE be thrown in Cookie’s constructor > if the name is not valid pre RFC2109. Both RFC6265 and RFC2109 > define the name to be a “token” (per RFC2616 HTTP/1.1) so I w
Re: svn commit: r1553187 - in /tomcat/trunk: java/org/apache/tomcat/util/http/Cookies.java test/org/apache/tomcat/util/http/TestCookies.java webapps/docs/changelog.xml
On 23/12/2013 19:15, jboy...@apache.org wrote:
> Author: jboynes
> Date: Mon Dec 23 19:15:35 2013
> New Revision: 1553187
>
> URL: http://svn.apache.org/r1553187
> Log:
> fix #55917 by allowing 8-bit ISO-8859-1 characters in V0 cookie values
-1 (veto)
The Tomcat community has (to date) always taken the view that cookie
headers should be restricted (as per RFC2616 section 4.2) to
"combinations of token, separators, and quoted-string".
That does not permit 0x80 to 0xFF in tokens.
Mark
> Modified:
> tomcat/trunk/java/org/apache/tomcat/util/http/Cookies.java
> tomcat/trunk/test/org/apache/tomcat/util/http/TestCookies.java
> tomcat/trunk/webapps/docs/changelog.xml
>
> Modified: tomcat/trunk/java/org/apache/tomcat/util/http/Cookies.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/http/Cookies.java?rev=1553187&r1=1553186&r2=1553187&view=diff
> ==
> --- tomcat/trunk/java/org/apache/tomcat/util/http/Cookies.java (original)
> +++ tomcat/trunk/java/org/apache/tomcat/util/http/Cookies.java Mon Dec 23
> 19:15:35 2013
> @@ -508,14 +508,7 @@ public final class Cookies {
> private static final int getTokenEndPosition(byte bytes[], int off, int
> end,
> int version, boolean isName){
> int pos = off;
> -while (pos < end &&
> -(!CookieSupport.isHttpSeparator((char)bytes[pos]) ||
> - version == 0 &&
> -CookieSupport.ALLOW_HTTP_SEPARATORS_IN_V0 &&
> -bytes[pos] != '=' &&
> -!CookieSupport.isV0Separator((char)bytes[pos]) ||
> - !isName && bytes[pos] == '=' &&
> - CookieSupport.ALLOW_EQUALS_IN_VALUE)) {
> +while (pos < end && allowInToken(bytes[pos], version, isName)) {
> pos++;
> }
>
> @@ -525,6 +518,34 @@ public final class Cookies {
> return pos;
> }
>
> +private static boolean allowInToken(byte b, int version, boolean isName)
> {
> +// byte is signed so cast into a positive int for comparisons
> +int octet = ((int)b) & 0xff;
> +
> +// disallow all controls
> +if (octet < 0x20 && octet != 0x09 || octet >= 0x7f && octet < 0xa0) {
> +throw new IllegalArgumentException(
> +"Control character in cookie value or attribute.");
> +}
> +
> +// values 0xa0-0xff are allowed in V0 values, otherwise disallow
> +if (octet >= 0x80) {
> +if (isName || version != 0) {
> +throw new IllegalArgumentException(
> +"Control character in cookie value or attribute.");
> +}
> +return true;
> +}
> +
> +return !CookieSupport.isHttpSeparator((char) b) ||
> +version == 0 &&
> +CookieSupport.ALLOW_HTTP_SEPARATORS_IN_V0 &&
> +b != '=' &&
> +!CookieSupport.isV0Separator((char) b) ||
> +!isName && b == '=' &&
> +CookieSupport.ALLOW_EQUALS_IN_VALUE;
> +}
> +
> /**
> * Given a starting position after an initial quote character, this gets
> * the position of the end quote. This escapes anything after a '\' char
>
> Modified: tomcat/trunk/test/org/apache/tomcat/util/http/TestCookies.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/tomcat/util/http/TestCookies.java?rev=1553187&r1=1553186&r2=1553187&view=diff
> ==
> --- tomcat/trunk/test/org/apache/tomcat/util/http/TestCookies.java (original)
> +++ tomcat/trunk/test/org/apache/tomcat/util/http/TestCookies.java Mon Dec 23
> 19:15:35 2013
> @@ -17,9 +17,113 @@
>
> package org.apache.tomcat.util.http;
>
> +import java.nio.charset.StandardCharsets;
> +
> +import javax.servlet.http.Cookie;
> +
> +import org.junit.Assert;
> +import org.junit.Before;
> +import org.junit.Ignore;
> import org.junit.Test;
>
> public class TestCookies {
> +private Cookies cookies;
> +
> +@Before
> +public void init() {
> +this.cookies = new Cookies(null);
> +}
> +
> +@Test
> +public void skipJsonInV0Value() {
> +process("bad={\"v\":1,\"x\":2}; a=b");
> +expect(makeCookie("a", "b", 0));
> +}
> +
> +@Test(expected = IllegalArgumentException.class)
> +public void disallow8bitInName() {
> +process("f\u00f6o=bar");
> +}
> +
> +@Test(expected = IllegalArgumentException.class)
> +public void disallowControlInName() {
> +process("f\010o=bar");
> +}
> +
> +@Test(expected = IllegalArgumentException.class)
> +public void disallow8BitControlInName() {
> +process("f\210o=bar");
> +}
> +
> +@Test
> +public void allow8BitInV0Value() {
> +pr
svn commit: r1553290 - in /tomcat/trunk: java/org/apache/tomcat/util/http/Cookies.java test/org/apache/tomcat/util/http/TestCookies.java webapps/docs/changelog.xml
Author: jboynes
Date: Tue Dec 24 15:36:25 2013
New Revision: 1553290
URL: http://svn.apache.org/r1553290
Log:
revert 1553187
Modified:
tomcat/trunk/java/org/apache/tomcat/util/http/Cookies.java
tomcat/trunk/test/org/apache/tomcat/util/http/TestCookies.java
tomcat/trunk/webapps/docs/changelog.xml
Modified: tomcat/trunk/java/org/apache/tomcat/util/http/Cookies.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/http/Cookies.java?rev=1553290&r1=1553289&r2=1553290&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/http/Cookies.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/http/Cookies.java Tue Dec 24
15:36:25 2013
@@ -508,7 +508,14 @@ public final class Cookies {
private static final int getTokenEndPosition(byte bytes[], int off, int
end,
int version, boolean isName){
int pos = off;
-while (pos < end && allowInToken(bytes[pos], version, isName)) {
+while (pos < end &&
+(!CookieSupport.isHttpSeparator((char)bytes[pos]) ||
+ version == 0 &&
+CookieSupport.ALLOW_HTTP_SEPARATORS_IN_V0 &&
+bytes[pos] != '=' &&
+!CookieSupport.isV0Separator((char)bytes[pos]) ||
+ !isName && bytes[pos] == '=' &&
+ CookieSupport.ALLOW_EQUALS_IN_VALUE)) {
pos++;
}
@@ -518,34 +525,6 @@ public final class Cookies {
return pos;
}
-private static boolean allowInToken(byte b, int version, boolean isName) {
-// byte is signed so cast into a positive int for comparisons
-int octet = ((int)b) & 0xff;
-
-// disallow all controls
-if (octet < 0x20 && octet != 0x09 || octet >= 0x7f && octet < 0xa0) {
-throw new IllegalArgumentException(
-"Control character in cookie value or attribute.");
-}
-
-// values 0xa0-0xff are allowed in V0 values, otherwise disallow
-if (octet >= 0x80) {
-if (isName || version != 0) {
-throw new IllegalArgumentException(
-"Control character in cookie value or attribute.");
-}
-return true;
-}
-
-return !CookieSupport.isHttpSeparator((char) b) ||
-version == 0 &&
-CookieSupport.ALLOW_HTTP_SEPARATORS_IN_V0 &&
-b != '=' &&
-!CookieSupport.isV0Separator((char) b) ||
-!isName && b == '=' &&
-CookieSupport.ALLOW_EQUALS_IN_VALUE;
-}
-
/**
* Given a starting position after an initial quote character, this gets
* the position of the end quote. This escapes anything after a '\' char
Modified: tomcat/trunk/test/org/apache/tomcat/util/http/TestCookies.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/tomcat/util/http/TestCookies.java?rev=1553290&r1=1553289&r2=1553290&view=diff
==
--- tomcat/trunk/test/org/apache/tomcat/util/http/TestCookies.java (original)
+++ tomcat/trunk/test/org/apache/tomcat/util/http/TestCookies.java Tue Dec 24
15:36:25 2013
@@ -17,113 +17,9 @@
package org.apache.tomcat.util.http;
-import java.nio.charset.StandardCharsets;
-
-import javax.servlet.http.Cookie;
-
-import org.junit.Assert;
-import org.junit.Before;
-import org.junit.Ignore;
import org.junit.Test;
public class TestCookies {
-private Cookies cookies;
-
-@Before
-public void init() {
-this.cookies = new Cookies(null);
-}
-
-@Test
-public void skipJsonInV0Value() {
-process("bad={\"v\":1,\"x\":2}; a=b");
-expect(makeCookie("a", "b", 0));
-}
-
-@Test(expected = IllegalArgumentException.class)
-public void disallow8bitInName() {
-process("f\u00f6o=bar");
-}
-
-@Test(expected = IllegalArgumentException.class)
-public void disallowControlInName() {
-process("f\010o=bar");
-}
-
-@Test(expected = IllegalArgumentException.class)
-public void disallow8BitControlInName() {
-process("f\210o=bar");
-}
-
-@Test
-public void allow8BitInV0Value() {
-process("foo=b\u00e1r");
-expect(makeCookie("foo", "b\u00e1r", 0));
-}
-
-@Test(expected = IllegalArgumentException.class)
-public void disallow8bitInV1UnquotedValue() {
-process("$Version=1; foo=b\u00e1r");
-}
-
-@Test
-public void allow8bitInV1QuotedValue() {
-process("$Version=1; foo=\"b\u00e1r\"");
-expect(makeCookie("foo", "b\u00e1r", 1));
-}
-
-@Test(expected = IllegalArgumentException.class)
-public void disallowControlInV0Value() {
-process("foo=b\010r");
-}
-
-@Test(expected = IllegalArgumentException.class)
[Bug 55917] Cookie parsing fails hard with ISO-8859-1 values
https://issues.apache.org/bugzilla/show_bug.cgi?id=55917 --- Comment #7 from Jeremy Boynes --- The patch for this has been reverted from trunk -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1553290 - in /tomcat/trunk: java/org/apache/tomcat/util/http/Cookies.java test/org/apache/tomcat/util/http/TestCookies.java webapps/docs/changelog.xml
jboy...@apache.org wrote:
>Author: jboynes
>Date: Tue Dec 24 15:36:25 2013
>New Revision: 1553290
>
>URL: http://svn.apache.org/r1553290
>Log:
>revert 1553187
Thanks.
I'm not saying that there isn't something that needs to be fixed here (I'm sure
there are changes required) but given the history of problems whenever we have
changed the cookie code we need to be very sure of what we are doing and why.
Maybe the place to start is just with the test cases that demonstate the issue
(we can comment out ones that fail).
My concern as soon as we step outside the RFCs is if different elements (user
agents, proxies, origin servers) deviate from the spec on different ways there
is a risk of security issues. We have seen issues along these lines in the past
so I'd like to be very sure there is no scope for similar mischief with cookies
if we relax our parsing rules.
I also think any changes should be focussed on solving observed issues rather
than trying to address all the issues we can think of reading the specs.
Refactoring the current cookie code is overdue but is probably best handled as
a separate issue. I'm not sure of it would be better to refactor before or
after fixing the recently raised issues with the current cookie processing.
Mark
>
>Modified:
>tomcat/trunk/java/org/apache/tomcat/util/http/Cookies.java
>tomcat/trunk/test/org/apache/tomcat/util/http/TestCookies.java
>tomcat/trunk/webapps/docs/changelog.xml
>
>Modified: tomcat/trunk/java/org/apache/tomcat/util/http/Cookies.java
>URL:
>http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/http/Cookies.java?rev=1553290&r1=1553289&r2=1553290&view=diff
>==
>--- tomcat/trunk/java/org/apache/tomcat/util/http/Cookies.java
>(original)
>+++ tomcat/trunk/java/org/apache/tomcat/util/http/Cookies.java Tue Dec
>24 15:36:25 2013
>@@ -508,7 +508,14 @@ public final class Cookies {
>private static final int getTokenEndPosition(byte bytes[], int off, int
>end,
> int version, boolean isName){
> int pos = off;
>-while (pos < end && allowInToken(bytes[pos], version, isName))
>{
>+while (pos < end &&
>+(!CookieSupport.isHttpSeparator((char)bytes[pos]) ||
>+ version == 0 &&
>+CookieSupport.ALLOW_HTTP_SEPARATORS_IN_V0 &&
>+bytes[pos] != '=' &&
>+!CookieSupport.isV0Separator((char)bytes[pos])
>||
>+ !isName && bytes[pos] == '=' &&
>+ CookieSupport.ALLOW_EQUALS_IN_VALUE)) {
> pos++;
> }
>
>@@ -518,34 +525,6 @@ public final class Cookies {
> return pos;
> }
>
>-private static boolean allowInToken(byte b, int version, boolean
>isName) {
>-// byte is signed so cast into a positive int for comparisons
>-int octet = ((int)b) & 0xff;
>-
>-// disallow all controls
>-if (octet < 0x20 && octet != 0x09 || octet >= 0x7f && octet <
>0xa0) {
>-throw new IllegalArgumentException(
>-"Control character in cookie value or
>attribute.");
>-}
>-
>-// values 0xa0-0xff are allowed in V0 values, otherwise
>disallow
>-if (octet >= 0x80) {
>-if (isName || version != 0) {
>-throw new IllegalArgumentException(
>-"Control character in cookie value or
>attribute.");
>-}
>-return true;
>-}
>-
>-return !CookieSupport.isHttpSeparator((char) b) ||
>-version == 0 &&
>-CookieSupport.ALLOW_HTTP_SEPARATORS_IN_V0 &&
>-b != '=' &&
>-!CookieSupport.isV0Separator((char) b) ||
>-!isName && b == '=' &&
>-CookieSupport.ALLOW_EQUALS_IN_VALUE;
>-}
>-
> /**
>* Given a starting position after an initial quote character, this gets
>* the position of the end quote. This escapes anything after a '\' char
>
>Modified:
>tomcat/trunk/test/org/apache/tomcat/util/http/TestCookies.java
>URL:
>http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/tomcat/util/http/TestCookies.java?rev=1553290&r1=1553289&r2=1553290&view=diff
>==
>--- tomcat/trunk/test/org/apache/tomcat/util/http/TestCookies.java
>(original)
>+++ tomcat/trunk/test/org/apache/tomcat/util/http/TestCookies.java Tue
>Dec 24 15:36:25 2013
>@@ -17,113 +17,9 @@
>
> package org.apache.tomcat.util.http;
>
>-import java.nio.charset.StandardCharsets;
>-
>-import javax.servlet.http.Cookie;
>-
>-import org.junit.Assert;
>-import org.junit.Before;
>-import org.junit.Ignore;
> import org.junit.Test;
>
> public class TestCookies {
>-private Cookies cookies;
>-
>-@Before
>-public void init() {
>-this.cookies = new Cookies(null);
>-}
>-
>-
8-bit text in cookie values, was: svn commit: r1553187
On Dec 24, 2013, at 2:29 AM, Mark Thomas wrote: > On 23/12/2013 19:15, jboy...@apache.org wrote: >> Author: jboynes >> Date: Mon Dec 23 19:15:35 2013 >> New Revision: 1553187 >> >> URL: http://svn.apache.org/r1553187 >> Log: >> fix #55917 by allowing 8-bit ISO-8859-1 characters in V0 cookie values > > -1 (veto) > > The Tomcat community has (to date) always taken the view that cookie > headers should be restricted (as per RFC2616 section 4.2) to > "combinations of token, separators, and quoted-string". > > That does not permit 0x80 to 0xFF in tokens. I thought the V2 patch had addressed your concern about limiting cookie names to tokens so went ahead and applied it. RFC2616 4.2 defines “message-header” as message-header = field-name ":" [ field-value ] field-name = token field-value= *( field-content | LWS ) field-content = where TEXT is defined in 2.2 as TEXT = The change only allows these characters in values if version == 0 where Netscape’s rather than RFC2109’s syntax applies (per the Servlet spec). The Netscape spec is vague in that it does not define “OPAQUE_STRING" at all and defines “VALUE” as containing equally undefined “characters” although historically[1] those have been taken to be OCTETs as permitted by RFC2616’s “*TEXT” variant of “field-content.” The change will continue to reject these characters in names and in unquoted values when version != 0 (RFC2109’s “word" rule) I don’t want to proliferate them but would it help to add another system property gating this behaviour? Perhaps with 3 values: “reject” (the default, causing an IAE as now), “skip” (logged but not returned to the application), and “allow” (returned to the application). Thanks Jeremy [1] based on comments by Fielding et al. on http-state and what I’ve seen in the wild signature.asc Description: Message signed with OpenPGP using GPGMail
Françoise Rebel est absente.
Je serai absent(e) du 24/12/2013 au 06/01/2014. Je répondrai à votre message dès mon retour. En cas d'urgence, vous pouvez contacter le BIJ au 05 61 02 86 10 - 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.0.0-RC10
On 19.12.2013 19:38, Mark Thomas wrote: > The proposed Apache Tomcat 8.0.0 release candidate 10 is now available > for voting. > > Given this is a release candidate I am working on the basis that it is > equivalent to an alpha. The main changes since RC5 are: > - Better handling of generic types in the WebSocket 1.0 implementation > - Refactor resource handling for the class loader > - Add Cobertura support to the unit tests > - Remove anti-Jar locking feature and replace it with open stream > tracking > - Update to a post Commons Pool 2.0 release snapshot > - Complete refactoring of TLD handling including caching of parsed TLDs > - More consistent handling of XML validation options > - Much more detailed visibility of DBCP connections pools in JMX > - Better organisation of JMX beans in the default JConsole view > - Performance improvements > - Numerous bug fixes > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.0-RC10/ > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-002/ > The svn tag is: > http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_8_0_0_RC10/ > > The proposed 8.0.0-RC10 release is: > [ ] Broken - do not release > [X] Alpha - go ahead and release as 8.0.0-RC10 alpha +1 as alpha. Overview: - One special observation in unit tests: Test org.apache.catalina.core.TestDefaultInstanceManager throws 3 NullPointerExceptions, that seem to indicate a broken test (see below). - JMX shows that websocket filter is configured for all default apps. I didn't check, where this comes from, but should it really be active by default? - MBeans "Catalina:context=/...,host=localhost,type=WebResourceRoot" and "Catalina:context=/...,host=localhost,name=Cache,type=WebResourceRoot" very similar in name (same type). All of the numeric data moved from the first to the second (plus additional interesting data in the second), in the first it is only left traceLockedFiles, stateName, cachingAllowed, traceResources and allowLinking which is all boolean or enum type. Should we make the two MBeans differ by "type"? - Same MBean: new attributes traceLockedFiles (boolean) and traceResources (Array): should the second be named tracedResources (additional "d") to distinguish the Array list of resources from the boolean to trace or not to trace switch? - MD5 OK - signatures OK - key in KEYS file - gz and zip for src and bin consistent - src consistent with svn tag - builds fine but - Very few warnings about unsafe or unchecked operations, a little less than for RC5. See full list at end of mail. - build result looks consistent with binaries - no checkstyle complaints - no Javadoc warnings - No unit test failures, great! - Warnings a bit lower than RC 5, errors and exception counts during unit tests higher than for RC 5, mostly in TestHostConfigAutomaticDeployment. - JMX MBean-Comparison with RC 5: - 5 new MBeans Catalina:context=/...,host=localhost,name=Cache,type=WebResourceRoot - Old MBeans Catalina:context=/...,host=localhost,type=WebResourceRoot dropped attributes cacheMaxObjectSize, cacheTtl and cacheMaxSize moved to the new MBean, attributes objectName and domain completely removed, attributes traceLockedFiles (boolean) and traceResources (Array) added. - ordering of tokens in ObjectName and attributes "objectName", "children" and "servlets" changed to be more logical - some filter name changes - from "org.apache.tomcat.websocket.server.WsFilter" to "Tomcat WebSocket (JSR356) Filter" - from "Timing filter" to "Timing Filter" (upper case "f") - MBean j2eeType=WebModule removed attribute antiJARLocking, added attribute tldValidation with value false - MBean ThreadPool added attribute executorTerminationTimeoutMillis with value 5000 - MBean WebappClassLoader removed attributes jarPath and antiJARLocking For the examples webapp also changed order of URLs (jstl.jar and standard.jar switched position) - MBean Loader attribute loaderRepositoriesString simple path names like "/WEB-INF/classes/" changed to file URLs like "file:/.../output/build/webapps/examples/WEB-INF/classes/". The same in the loaderRepositories array. - MBean OperatingSystem attribute OpenFileDescriptorCount up from 86 to 87 Build and tests were done using Java 1.7.0_45. OS was Solaris 10 Sparc, tcnative was 1.1.29 based on APR 1.4.8 and OpenSSL 1.0.1e (plus a few patches). Maybe broken test org.apache.catalina.core.TestDefaultInstanceManager = Running org.apache.catalina.core.TestDefaultInstanceManager 20-Dec-2013 11:08:00.021 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["http-bio-127.0.0.1-auto-1"] 20-Dec-2013 11:08:00.125 INFO [main] org.apache.catalina.core.StandardService.startInternal Starting servic
[Bug 55929] New: error link
https://issues.apache.org/bugzilla/show_bug.cgi?id=55929 Bug ID: 55929 Summary: error link Product: Tomcat 8 Version: 8.0.0-RC5 Hardware: PC OS: Windows XP Status: NEW Severity: normal Priority: P2 Component: Manager Assignee: dev@tomcat.apache.org Reporter: 67166...@qq.com Created attachment 31152 --> https://issues.apache.org/bugzilla/attachment.cgi?id=31152&action=edit two error link in manager page. two error link in manager page. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 55929] error link
https://issues.apache.org/bugzilla/show_bug.cgi?id=55929 liu fuzhong <67166...@qq.com> changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
