DO NOT REPLY [Bug 46603] Cookies retrieved from tomcat server is not correct
https://issues.apache.org/bugzilla/show_bug.cgi?id=46603 Flavio Crispim changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Flavio Crispim 2009-01-27 03:04:35 PST --- *** This bug has been marked as a duplicate of bug 44679 *** -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 44679] Cookies are treated differently between 6.0.16 and 6.0.14
https://issues.apache.org/bugzilla/show_bug.cgi?id=44679 Flavio Crispim changed: What|Removed |Added CC||carl.sky...@gmail.com --- Comment #32 from Flavio Crispim 2009-01-27 03:04:35 PST --- *** Bug 46603 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 46607] java.lang.OutOfMemoryError on AIX6.1
https://issues.apache.org/bugzilla/show_bug.cgi?id=46607 Flavio Crispim changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #1 from Flavio Crispim 2009-01-27 03:11:19 PST --- This is not a user support list. Please send it to (us...@tomcat.apache.org) -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 46607] java.lang.OutOfMemoryError on AIX6.1
https://issues.apache.org/bugzilla/show_bug.cgi?id=46607 Santhosh changed: What|Removed |Added Status|RESOLVED|CLOSED -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 44679] Cookies are treated differently between 6.0.16 and 6.0.14
https://issues.apache.org/bugzilla/show_bug.cgi?id=44679
--- Comment #33 from Peter Pichler 2009-01-27 07:12:07
PST ---
(In reply to comment #30)
>
> The cookie 0 spec has a number of ambiguities (eg %XX encoding is suggested
> but
> not supported by many (all?) browsers, the '=' character is not listed as one
> that must be quoted if used in a name or value despite the obvious issues this
> would cause, etc).
?? Which browser does not support URL-encoded (%XX encoding) cookie values. I
know that IE 6. and 7, Firefox and Opera accecpt URL encoded Cookie values. And
I do not know any browser, which does not support it... ???
It is not written explitly, but the definition "NAME=VALUE" says, that the Name
Part ends with an equal mark... so it should be clear, that it is not possible
to use an equal char for the name of a cookie...
You are right... within a cookie value it is not forbidden to use an equal mark
by the cookie0 spec...
> If you read the Tomcat source you will see that the Tomcat developers are well
> aware of the various cookie specs.
If you aware of the various cookie specs you should know, that cookie1 is
already obsoleted... and as the servlet spec says cookie0 is still state of the
art... and brings the best interoperability.
> We know the auto conversion isn't spec compliant. That is why if you use
> strict servlet compliance, the automatic conversion doesn't happen.
What is servlet spec compliance? There is one sentence in the set cookie
comment ("should not use... equal mark..., slash,..") and there are at least
two sentences saying the opposite...
Because you ignored them, I will repeat them...
Cookie Constructor:
The value can be anything the server chooses to send. Its value is probably
of interest only to the server
...
(see
http://java.sun.com/products/servlet/2.3/javadoc/javax/servlet/http/Cookie.html#Cookie(java.lang.String,%20java.lang.String)
Cookie.setValue(...):
Assigns a new value to a cookie after the cookie is created. If you use a
binary value, you may want to use BASE64 encoding.
(see
http://java.sun.com/products/servlet/2.3/javadoc/javax/servlet/http/Cookie.html#setValue(java.lang.String)
I think you mentioned already, I am not an english native speaker... but I am
sure there is a difference between "should not" and "must not". I do not know a
definition for "should" and "should not" in the servlet spec... RFC 2119 (Key
words for use in RFCs to Indicate Requirement Levels) gives a definition for
the term "SHOULD NOT"...
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed
before implementing any behavior described with this label.
I think it is ok to use this RFC also for the interpretation of the servlet
spec... If there is no differend definition for "SHOULD NOT" in the
servlet-spec, it is not correct to say an equal mark in a cookie value is
forbidden by the servlet spec... It is definitly NOT RECOMMENDED, but it is
allowed
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- 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
Fw: Tomcat 6 Cluster Deployer object
http://tomcat.apache.org/tomcat-6.0-doc/config/cluster-deployer.html According to the tomcat site, the Cluster Deployer Object is broken. Does anyone know if there is an eta to have this fixed?
svn commit: r738293 - /tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/DataSourceFactory.java
Author: fhanik Date: Tue Jan 27 23:05:10 2009 New Revision: 738293 URL: http://svn.apache.org/viewvc?rev=738293&view=rev Log: Initialize connection pool upon data source creation instead of request for first connection Modified: tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/DataSourceFactory.java Modified: tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/DataSourceFactory.java URL: http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/DataSourceFactory.java?rev=738293&r1=738292&r2=738293&view=diff == --- tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/DataSourceFactory.java (original) +++ tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/DataSourceFactory.java Tue Jan 27 23:05:10 2009 @@ -397,7 +397,8 @@ dataSource.getPoolProperties().setUseEquals(Boolean.parseBoolean(value)); } - +//initialize the pool itself +dataSource.createPool(); // Return the configured DataSource instance return dataSource; } - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
