Re: Cookies are broken in 6.0.16?

[David Jencks]

On Feb 10, 2008, at 2:42 PM, Filip Hanik - Dev Lists wrote:


Remy Maucherat wrote:

On Sun, 2008-02-10 at 11:17 -0700, Filip Hanik - Dev Lists wrote:


Remy Maucherat wrote:


On Sun, 2008-02-10 at 11:44 -0500, Jim Manico wrote:

Filip - you are 100% correct on this thread. Are you basically  
the traffic cop guarding the core of Tomcat?



I understand, you are not impacted by the behavior change, and as a
result this allows you to be "fair", I suppose. The issue is  
that the

behavior of Tomcat has been different, in all prior releases, and
changing it of all a sudden without any configuration capability  
because
it feels nice to play "spec lawyer" is wrong to me. Similar  
decisions
have been made in the past, and this did cause problems, it's  
simply

faster to add the appropriate options right away.

what about my suggestion, to add a flag to default to v1 cookies.  
they get quoted and old behavior will continue to work.




This is the sort of configuration option which seems appropriate.

essentially, browsers treated our previous v0 cookies as v1 when we  
quoted them.
question, obviously it would be easiest for us to put the global  
flag in the javax.servlet.http.Cookie class directly

-private int version = 0;// ;Version=1 ... means RFC 2109++ style
+private int version = Integer.parseInt(System.getProperty 
("org.apache.catalina.cookie.version","1")); // ;Version=1 ...  
means RFC 2109++ style


Would this be ok, given its a spec class? or do we have to leave  
this class untouched and modify it elsewhere, in which case it'd be  
more of a hack.


I would hope that you would put this behavior in a non javax class  
since it's possible that tomcat may be used with other peoples  
servlet spec jars.  I think consistent behavior independent of which  
spec jar you happen to pick would be desirable.


thanks
david jencks



Filip


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: tomcat native documentation

[jean-frederic clere]

Henri Gomez wrote:

Good.

Just a point :

INFO: Loaded APR based Apache Tomcat Native library 1.1.12.

==>

INFO: Loaded APR based Apache Tomcat Native library 1.1.13.


I have put x.y ;-)

Cheers

Jean-Frederic



:-)

2008/2/9, jean-frederic clere <[EMAIL PROTECTED]>:

Hi,

I have prepared a doc for the tomcat native library.

http://people.apache.org/~jfclere/tc-native-docs/

The idea is to add it like http://tomcat.apache.org/tc-native-docs

Comments?

Cheers

Jean-Frederic

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r620434 - /tomcat/connectors/trunk/jni/xdocs/index.xml

[jfclere]

Author: jfclere
Date: Sun Feb 10 23:41:37 2008
New Revision: 620434

URL: http://svn.apache.org/viewvc?rev=620434&view=rev
Log:
Don't put a real version in the example.

Modified:
tomcat/connectors/trunk/jni/xdocs/index.xml

Modified: tomcat/connectors/trunk/jni/xdocs/index.xml
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jni/xdocs/index.xml?rev=620434&r1=620433&r2=620434&view=diff
==
--- tomcat/connectors/trunk/jni/xdocs/index.xml (original)
+++ tomcat/connectors/trunk/jni/xdocs/index.xml Sun Feb 10 23:41:37 2008
@@ -147,7 +147,7 @@
Start tomcat and check for the messages like this ones:

 Feb 8, 2008 12:27:41 PM org.apache.catalina.core.AprLifecycleListener init
-INFO: Loaded APR based Apache Tomcat Native library 1.1.12.
+INFO: Loaded APR based Apache Tomcat Native library 1.x.y.
 Feb 8, 2008 12:27:41 PM org.apache.catalina.core.AprLifecycleListener init
 INFO: APR capabilities: IPv6 [true], sendfile [true], accept filters 
[false], random [true].
 Feb 8, 2008 12:27:41 PM org.apache.coyote.http11.Http11AprProtocol init
@@ -169,7 +169,7 @@
 Start tomcat and check for the messages like this ones:
   
 Feb 8, 2008 2:48:17 PM org.apache.catalina.core.AprLifecycleListener init
-INFO: Loaded APR based Apache Tomcat Native library 1.1.12.
+INFO: Loaded APR based Apache Tomcat Native library 1.x.y.
 Feb 8, 2008 2:48:17 PM org.apache.catalina.core.AprLifecycleListener init
 INFO: APR capabilities: IPv6 [false], sendfile [true], accept filters 
[false], random [true].
 Feb 8, 2008 2:48:18 PM org.apache.coyote.http11.Http11AprProtocol init



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Bug report for Tomcat 5 [2008/02/10]

[bugzilla]

+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=CriticalMAJ=Major |
| |   |   MIN=Minor   NOR=Normal  ENH=Enhancement   |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
|27122|Opn|Enh|2004-02-20|IE plugins cannot access components through Tomcat|
|28039|Opn|Enh|2004-03-30|Cluster Support for SingleSignOn  |
|29160|Ver|Enh|2004-05-23|precompile problem: _jspx_meth_* (javax.servlet.js|
|29494|Inf|Enh|2004-06-10|No way to set PATH when running as a service on Wi|
|29936|Opn|Blk|2004-07-06|XML parser loading problems by container  |
|30241|Ver|Enh|2004-07-21|Enhance build script to use branch argument when c|
|31257|Opn|Cri|2004-09-16|java.endorsed.dirs is not used when JSP compilatio|
|33262|Inf|Enh|2005-01-27|Service Manager autostart should check for adminis|
|33453|Opn|Enh|2005-02-08|Jasper should recompile JSP files whose datestamps|
|33650|Inf|Enh|2005-02-19|Jasper performance for multiple files processing  |
|33671|Opn|Enh|2005-02-21|Manual Windows service installation with custom na|
|34526|Opn|Nor|2005-04-19|Truncated content in decompressed requests from mo|
|34801|New|Enh|2005-05-08|PATCH: CGIServlet does not terminate child after a|
|34805|Ass|Enh|2005-05-08|warn about invalid security constraint url pattern|
|34868|Ass|Enh|2005-05-11|allow to register a trust store for a session that|
|35054|Inf|Enh|2005-05-25|warn if appBase is not existing as a File or direc|
|35869|Inf|Enh|2005-07-26|Can't run as a service on Windows Server 2003 64-B|
|35959|Opn|Enh|2005-08-01|mod_jk not independant of UseCanonicalName|
|36133|Inf|Enh|2005-08-10|Support JSS SSL implementation|
|36169|New|Enh|2005-08-12|[PATCH] Enable chunked encoding for requests in II|
|36362|New|Enh|2005-08-25|missing check for Java reserved keywords in tag fi|
|36569|Inf|Enh|2005-09-09|Redirects produce illegal URL's   |
|36837|Inf|Enh|2005-09-28|Looking for ProxyHandler implementation of Http re|
|36922|Inf|Enh|2005-10-04|setup.sh file mis-advertised and missing  |
|36923|New|Nor|2005-10-05|Deactivated EL expressions are not parsed for jsp |
|37018|Ass|Enh|2005-10-11|Document how to use tomcat-SSL with a pkcs11 token|
|37084|Opn|   |2005-10-14|JspC from ant fails on JSPs that use custom taglib|
|37334|Inf|Enh|2005-11-02|Realm digest property not aligned with the adminis|
|37449|Opn|Enh|2005-11-10|Two UserDatabaseRealm break manager user  |
|37485|Inf|Enh|2005-11-14|I'd like to run init SQL after JDBC Connection cre|
|37498|Inf|Nor|2005-11-14|[PATCH] NPE in org.apache.catalina.core.ContainerB|
|37515|Inf|Nor|2005-11-15|smap not generated by JspC when used from Ant for |
|37627|Opn|Nor|2005-11-24|Slow and incomplete dynamic content generation aft|
|37785|Inf|Nor|2005-12-05|Changing startup type via Tomcat Monitor does not |
|37794|Opn|Nor|2005-12-05|getParameter() fails on POST with transfer-encodin|
|37797|Inf|Maj|2005-12-05|Configure Tomcat utility truncates classpath to 96|
|37822|Opn|Nor|2005-12-07|WebappClassLoader interfering with Catalina core c|
|37847|Ass|Enh|2005-12-09|Allow User To Optionally Specify Catalina Output F|
|37869|Opn|Nor|2005-12-12|Cannot obtain client certificate with SSL / client|
|37918|Inf|Nor|2005-12-15|EL cannot find valid getter from object when using|
|37984|New|Nor|2005-12-21|JNDIRealm.java not able to handle MD5 password|
|38046|Ass|   |2005-12-27|apache-tomcat-5.5.14-deployer doesn't work (Illega|
|38197|Opn|Maj|2006-01-09|taglib pool bug when tag is used with jsp:attribut|
|38216|Inf|Enh|2006-01-10|Extend Jmxproxy to allow call of MBean Operations |
|38268|Inf|Enh|2006-01-13|User friendly: Need submit button on adding/deleti|
|38352|Inf|Nor|2006-01-22|Additional Entries for Default catalina.policy fil|
|38360|Inf|Enh|2006-01-24|Domain for session cookies|
|38367|Inf|Nor|2006-01-24|Executing any Catalina Ant task results in an exce|
|38372|Inf|Cri|2006-01-25|tcnative-1.dll response overflow corruption, parti|
|38427|Inf|Nor|2006-01-27|ServletContextListener Notified Multiple Times Whe|
|38483|Inf|Nor|2006-02-01|access log valve uses simpledateformat in tread-un|
|38484|

Bug report for Tomcat 4 [2008/02/10]

[bugzilla]

+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=CriticalMAJ=Major |
| |   |   MIN=Minor   NOR=Normal  ENH=Enhancement   |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
| 3839|Opn|Enh|2001-09-26|Problem bookmarking login page|
| 4227|Opn|Enh|2001-10-17|Invalid CGI path  |
| 5329|New|Enh|2001-12-08|NT Service exits startup before Tomcat is finished|
| 5795|New|Enh|2002-01-10|Catalina Shutdown relies on localhost causing prob|
| 5829|New|Enh|2002-01-13|StandardManager needs to cope with sessions throwi|
| 5985|New|Enh|2002-01-23|Tomcat should perform a more restrictive validatio|
| 6600|Opn|Enh|2002-02-20|enodeURL adds 'jsession' when 'isRequestedSessionI|
| 6614|New|Enh|2002-02-21|Have Bootstrap and StandardClassLoader use the sam|
| 6671|New|Enh|2002-02-25|Simple custom tag example uses old declaration sty|
| 7043|New|Enh|2002-03-12|database user and password for JDBC Based Store   |
| 7374|New|Enh|2002-03-22|Apache Tomcat/4.0.1 message on standard output|
| 7676|New|Enh|2002-04-02|Allow name property to use match experssions in  without className in server.xml produces N|
|11069|Opn|Enh|2002-07-23|Tomcat not flag error if tld is outside of /WEB-IN|
|11129|New|Enh|2002-07-24|New valve for putting the sessionIDs in the reques|
|11248|New|Enh|2002-07-29|DefaultServlet doesn't send expires header|
|11754|Opn|Enh|2002-08-15|Synchronous shutdown script - shutdown.sh should w|
|12069|New|Enh|2002-08-27|Creation of more HttpSession objects for one previ|
|12428|Opn|Enh|2002-09-09|request.getUserPrincipal(): Misinterpretation of s|
|12658|New|Enh|2002-09-15|a proxy host and port at the  element level |
|12766|New|Enh|2002-09-18|Tomcat should use tld files in /WEB-INF/ over vers|
|13309|Opn|Enh|2002-10-04|Catalina calls System.exit()  |
|13634|New|Enh|2002-10-15|Allowing system properties to be substituted in co|
|13689|Opn|Enh|2002-10-16|Classloader paths for 'Common' classes and librari|
|13731|New|Enh|2002-10-17|Final request, response, session and other variabl|
|13941|New|Enh|2002-10-24|reload is VERY slow   |
|13965|New|Enh|2002-10-25|Catalina.sh correction request for Tru64 Unix |
|14097|New|Enh|2002-10-30|hardcoded registry value for vm lets tomcat servic|
|14416|New|Enh|2002-11-10|blank tag name in TLD cause NullPointerException  |
|14635|New|Enh|2002-11-18|Should be possible not to have -MM-DD in log f|
|14766|New|Enh|2002-11-22|Redirect Vavle|
|14993|New|Enh|2002-12-02|Possible obselete synchronized declaration|
|15115|New|Enh|2002-12-05|correct docs... XML parser *cannot* be overridden |
|15417|Opn|Enh|2002-12-16|Add port for forced compilation of JSP pages  |
|15688|New|Enh|2002-12-27|full-qualified names instead of imports   |
|15941|New|Enh|2003-01-10|Expose rootCause exceptions at deeper levels  |
|16294|New|Enh|2003-01-21|Configurable URL Decoding.|
|16357|New|Enh|2003-01-23|"connection timeout reached"  |
|16531|New|Enh|2003-01-29|Updating already deployed ".war" files in a single|
|16579|New|Enh|2003-01-30|documentation page layout/style breaks wrapping to|
|16596|New|Enh|2003-01-30|option for disabling log rotation |
|17070|New|Enh|2003-02-14|The Catalina Ant tasks do not allow for 'reusable'|
|17146|New|Enh|2003-02-18|Simplify build.xml using 

Bug report for Watchdog [2008/02/10]

[bugzilla]

+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=CriticalMAJ=Major |
| |   |   MIN=Minor   NOR=Normal  ENH=Enhancement   |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
|  278|Unc|Nor|2000-12-04|Bug in GetParameterValuesTestServlet.java file Bug|
|  279|Unc|Nor|2000-12-04|Logical Error in GetParameterValuesTestServlet Bug|
|  469|Unc|Nor|2001-01-17|in example-taglib.tld "urn" should be "uri" BugRat|
|  470|Unc|Nor|2001-01-17|FAIL positiveForward.jsp and positiveInclude.jsp B|
| 9634|New|Enh|2002-06-05|No tests exist for ServletContext.getResourcePaths|
|10703|New|Enh|2002-07-11|Need to test getRequestURI after RequestDispatcher|
|11336|New|Enh|2002-07-31|Test wrapped path methods with RD.foward()|
|11663|New|Maj|2002-08-13|JSP precompile tests rely on Jasper specific behav|
|11664|New|Maj|2002-08-13|A sweep is needed of all Watchdog 4.0 tag librarie|
|11665|New|Maj|2002-08-13|ServletToJSPErrorPageTest and ServletToServletErro|
|11666|New|Maj|2002-08-13|SetBufferSize_1TestServlet is invalid.|
|14004|New|Maj|2002-10-28|Incorrent behaviour of all attribute-related lifec|
|15504|New|Nor|2002-12-18|JSP positiveGetValues test relies on order preserv|
|24649|New|Nor|2003-11-12|getRemoteHost fails when agent has uppercase chara|
|29398|New|Nor|2004-06-04|Update site and note current status   |
+-+---+---+--+--+
| Total   15 bugs   |
+---+

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Bug report for Tomcat 3 [2008/02/10]

[bugzilla]

+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=CriticalMAJ=Major |
| |   |   MIN=Minor   NOR=Normal  ENH=Enhancement   |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
| 2350|Ver|Nor|2001-06-27|ServletConfig.getInitParameter() requires url-patt|
| 5331|Ass|Nor|2001-12-09|getPathInfo vs URL normalization  |
| 6027|Inf|Maj|2002-01-25|Tomcat  Automatically shuts down as service   |
| 6488|Ver|Maj|2002-02-15|Error: 304. Apparent bug in default ErrorHandler c|
| 7785|Inf|Blk|2002-04-06|tomcat bug in context reloading   |
| 7863|Inf|Maj|2002-04-09|I have a problem when running Tomcat with IIS |
| 8187|Inf|Cri|2002-04-17|Errors when Tomcat used with MS Access database   |
| 9737|Ver|Nor|2002-06-10|ArrayIndexOutOfBoundsException when sending just p|
|10047|Ass|Cri|2002-06-20|IllegalStateException |
|10406|Ass|Cri|2002-07-02|IllegalStateException |
|11087|Inf|Blk|2002-07-23|IllegalStateException |
|12156|Inf|Cri|2002-08-29|Apache and Tomcat 3.3.1 Interworking problem  |
|16363|Ass|Cri|2003-01-23|Stack Overflow accessing compiled JSP - Tomcat 3.2|
|39250|Inf|Cri|2006-04-07|Tomcat 3.2.1 + JDK 1.4|
+-+---+---+--+--+
| Total   14 bugs   |
+---+

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Cookies are broken in 6.0.16?

[Filip Hanik - Dev Lists]

Mark Thomas wrote:

Filip Hanik - Dev Lists wrote:
Would this be ok, given its a spec class? or do we have to leave this 
class untouched and modify it elsewhere, in which case it'd be more 
of a hack.


I think, as long as we leave the public interface unchanged, changing 
the spec class would be fine.


The spec says that RFC 2109 should be used by default so if 
org.apache.catalina.STRICT_SERVLET_COMPLIANCE is true I think v0 
cookies should be 
I would agree with this assessment. and it would work for other 
frameworks that use our servlet-api.jar, as we don't force one version 
or the other, we just set a default.


Filip


Mark


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Cookies are broken in 6.0.16?

[Filip Hanik - Dev Lists]

Bill Barker wrote:
"Remy Maucherat" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
  

On Sun, 2008-02-10 at 23:29 +, Mark Thomas wrote:


Filip Hanik - Dev Lists wrote:
  

Would this be ok, given its a spec class? or do we have to leave this
class untouched and modify it elsewhere, in which case it'd be more of 
a

hack.


I think, as long as we leave the public interface unchanged, changing the
spec class would be fine.

The spec says that RFC 2109 should be used by default so if
org.apache.catalina.STRICT_SERVLET_COMPLIANCE is true I think v0 cookies
should be used.
  

There's also an opportunity to force the version in addCookie. Not as
nice, but this may cause less problems.




+1 to put in addCookie or in ServerCookie.  Other projects use Tomcat's 
version of the servlet-api.jar, and I don't like the idea of publishing one 
that isn't strictly spec compliant.  Of course, as Remy pointed out, this 
has the effect of forcing v1 cookies as a downside.


Probably better than forcing the version is to revert to 'always quote' in 
ServerCookie unless the STRICT_SERVLET_COMPIANCE flag is true.  We did the 
'always quote' in the first place because it is more browser friendly (at 
least for 21st century browsers).
  

this comes with all the other side effects of strict servlet compliance.
I'm open to either option, ie forcing cookies, or always quoting, but 
would prefer a separate flag


Filip

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43925] - org.apache.jasper.runtime.BodyContentImpl causing huge memory allocations

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43925





--- Additional Comments From [EMAIL PROTECTED]  2008-02-10 18:20 ---
Ok, so I not sure I got everything, but:
- I don't see where memory usage is bounded in the code (if it's not, you should
compare performance with the unbounded mode of Jasper, which will never
reallocate anything); that's a problem
- The opportunity is the ability to share the buffer list per thread, so the
CharBuffer.bufList should be ThreadLocal (and should be limited in
size, which should solve item 1); as a configuration option, it could be a
concurrent static structure, for use with thread intensive connectors
- CharBuffer.toArray is expensive (no other option, though), so you should try
to show a (real) test result

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Cookies are broken in 6.0.16?

[Bill Barker]

"Remy Maucherat" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> On Sun, 2008-02-10 at 23:29 +, Mark Thomas wrote:
>> Filip Hanik - Dev Lists wrote:
>> > Would this be ok, given its a spec class? or do we have to leave this
>> > class untouched and modify it elsewhere, in which case it'd be more of 
>> > a
>> > hack.
>>
>> I think, as long as we leave the public interface unchanged, changing the
>> spec class would be fine.
>>
>> The spec says that RFC 2109 should be used by default so if
>> org.apache.catalina.STRICT_SERVLET_COMPLIANCE is true I think v0 cookies
>> should be used.
>
> There's also an opportunity to force the version in addCookie. Not as
> nice, but this may cause less problems.
>

+1 to put in addCookie or in ServerCookie.  Other projects use Tomcat's 
version of the servlet-api.jar, and I don't like the idea of publishing one 
that isn't strictly spec compliant.  Of course, as Remy pointed out, this 
has the effect of forcing v1 cookies as a downside.

Probably better than forcing the version is to revert to 'always quote' in 
ServerCookie unless the STRICT_SERVLET_COMPIANCE flag is true.  We did the 
'always quote' in the first place because it is more browser friendly (at 
least for 21st century browsers).

> Rémy 




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Cookies are broken in 6.0.16?

[Remy Maucherat]

On Sun, 2008-02-10 at 23:29 +, Mark Thomas wrote:
> Filip Hanik - Dev Lists wrote:
> > Would this be ok, given its a spec class? or do we have to leave this 
> > class untouched and modify it elsewhere, in which case it'd be more of a 
> > hack.
> 
> I think, as long as we leave the public interface unchanged, changing the 
> spec class would be fine.
> 
> The spec says that RFC 2109 should be used by default so if 
> org.apache.catalina.STRICT_SERVLET_COMPLIANCE is true I think v0 cookies 
> should be used.

There's also an opportunity to force the version in addCookie. Not as
nice, but this may cause less problems.

Rémy



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Cookies are broken in 6.0.16?

[Mark Thomas]

Filip Hanik - Dev Lists wrote:
Would this be ok, given its a spec class? or do we have to leave this 
class untouched and modify it elsewhere, in which case it'd be more of a 
hack.


I think, as long as we leave the public interface unchanged, changing the 
spec class would be fine.


The spec says that RFC 2109 should be used by default so if 
org.apache.catalina.STRICT_SERVLET_COMPLIANCE is true I think v0 cookies 
should be used.


Mark


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r620354 - /tomcat/tc6.0.x/trunk/STATUS.txt

[fhanik]

Author: fhanik
Date: Sun Feb 10 14:59:24 2008
New Revision: 620354

URL: http://svn.apache.org/viewvc?rev=620354&view=rev
Log:
cast vote

Modified:
tomcat/tc6.0.x/trunk/STATUS.txt

Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=620354&r1=620353&r2=620354&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Sun Feb 10 14:59:24 2008
@@ -73,7 +73,7 @@
 * Fix http://issues.apache.org/bugzilla/show_bug.cgi?id=44337
   Dir listing crashes if no readme-file present
   http://svn.apache.org/viewvc?rev=618150&view=rev
-  +1: funkman, markt
+  +1: funkman, markt, fhanik
   -1:
 
 * Fix http://issues.apache.org/bugzilla/show_bug.cgi?id=43741



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Cookies are broken in 6.0.16?

[Filip Hanik - Dev Lists]

Remy Maucherat wrote:

On Sun, 2008-02-10 at 11:17 -0700, Filip Hanik - Dev Lists wrote:
  

Remy Maucherat wrote:


On Sun, 2008-02-10 at 11:44 -0500, Jim Manico wrote:
  
  
Filip - you are 100% correct on this thread. Are you basically the 
traffic cop guarding the core of Tomcat?



I understand, you are not impacted by the behavior change, and as a
result this allows you to be "fair", I suppose. The issue is that the
behavior of Tomcat has been different, in all prior releases, and
changing it of all a sudden without any configuration capability because
it feels nice to play "spec lawyer" is wrong to me. Similar decisions
have been made in the past, and this did cause problems, it's simply
faster to add the appropriate options right away.
  
  
what about my suggestion, to add a flag to default to v1 cookies. they 
get quoted and old behavior will continue to work.



This is the sort of configuration option which seems appropriate.
  
essentially, browsers treated our previous v0 cookies as v1 when we 
quoted them.
question, obviously it would be easiest for us to put the global flag in 
the javax.servlet.http.Cookie class directly

-private int version = 0;// ;Version=1 ... means RFC 2109++ style
+private int version = 
Integer.parseInt(System.getProperty("org.apache.catalina.cookie.version","1")); 
// ;Version=1 ... means RFC 2109++ style


Would this be ok, given its a spec class? or do we have to leave this 
class untouched and modify it elsewhere, in which case it'd be more of a 
hack.


Filip


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r620335 - in /tomcat/trunk/webapps/docs: config/project.xml config/systemprops.xml tomcat-docs.xsl

[Mark Thomas]

[EMAIL PROTECTED] wrote:

Author: markt
Date: Sun Feb 10 13:33:35 2008
New Revision: 620335

URL: http://svn.apache.org/viewvc?rev=620335&view=rev
Log:
Add a page to the config docs detailing the various system properties that are 
available.


The recent discussion on configuration options reminded me of something I 
have been meaning to do for a while. This is intended as a first draft. If 
you spot a mistake, omission or have a better way of formatting the page or 
arranging the options - please go for it.


My intention is to leave in trunk for a while to settle down and propose it 
for inclusion in 6.0.x sometime before the next release.


Mark

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 44383] - Possible leak: tomcat does not release Jasper compilation contexts

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=44383





--- Additional Comments From [EMAIL PROTECTED]  2008-02-10 13:38 ---
I think I understand the issue now. If the JspServlet (Jasper) is in development
mode (the default) the compiler (JDTCompiler) keeps the Node information of the
page after the compilation to provide the source line in case of an error.

On our production server, this mode of operation more than doubles the needed
memory to run the applications.

I think this should be clarified in the documentation as it only relates the
option "development" to the behaviour with respect to modifications and not to
the extra memory cost of this information.

Thanks Mark for your response.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r620335 - in /tomcat/trunk/webapps/docs: config/project.xml config/systemprops.xml tomcat-docs.xsl

[markt]

Author: markt
Date: Sun Feb 10 13:33:35 2008
New Revision: 620335

URL: http://svn.apache.org/viewvc?rev=620335&view=rev
Log:
Add a page to the config docs detailing the various system properties that are 
available.

Added:
tomcat/trunk/webapps/docs/config/systemprops.xml   (with props)
Modified:
tomcat/trunk/webapps/docs/config/project.xml
tomcat/trunk/webapps/docs/tomcat-docs.xsl

Modified: tomcat/trunk/webapps/docs/config/project.xml
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/config/project.xml?rev=620335&r1=620334&r2=620335&view=diff
==
--- tomcat/trunk/webapps/docs/config/project.xml (original)
+++ tomcat/trunk/webapps/docs/config/project.xml Sun Feb 10 13:33:35 2008
@@ -74,6 +74,10 @@
 
 
 
+
+
+
+
   
 
 

Added: tomcat/trunk/webapps/docs/config/systemprops.xml
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/config/systemprops.xml?rev=620335&view=auto
==
--- tomcat/trunk/webapps/docs/config/systemprops.xml (added)
+++ tomcat/trunk/webapps/docs/config/systemprops.xml Sun Feb 10 13:33:35 2008
@@ -0,0 +1,295 @@
+
+
+
+]>
+
+
+  &project;
+
+  
+System Properties
+  
+
+
+
+
+  The follow sections list the system properties that may be set to modify
+  the default Tomcat behaviour.
+
+
+
+
+  
+
+
+  If true, the clustering module will attempt to use DNS to
+  resolve any host names provided in the cluster configuration. If not
+  specified, the default value of false will be used.
+
+
+  
+
+
+
+
+
+  
+
+
+  The name of the variable to use for the expression language expression
+  factory. If not specified, the default value of
+  _el_expressionfactory will be used.
+
+
+
+  The name of the variable to use for the instance manager factory. If
+  not specified, the default value of _jsp_instancemanager 
will
+  be used.
+
+
+
+  If true, any tag buffer that expands beyond
+  org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE will be
+  destroyed and a new buffer created of the default size. If not specified,
+  the default value of false will be used.
+
+
+
+  If true, a ThreadLocal PageContext pool will
+  be used. If not specified, the default value of true will be
+  used.
+
+
+
+  The size of the ThreadLocal PageContext. If not 
specified,
+  the default value of 8 will be used.
+
+
+
+  The base class of the Servlets generated from the JSPs. If not
+  specified, the default value of
+  org.apache.jasper.runtime.HttpJspBase will be used.
+
+
+
+  The name of the service method called by the base class. If not
+  specified, the default value of _jspService will be 
used.
+
+
+
+  The name of the ServletContext attribute that provides the classpath
+  for the JSP. If not specified, the default value of
+  org.apache.catalina.jsp_classpath will be used.
+
+
+
+  The name of the request attribute for 
+  element of a servlet definition. If present on a request, this overrides
+  the value returned by request.getServletPath() to select the
+  JSP page to be executed. If not specified, the default value of
+  org.apache.catalina.jsp_file will be used.
+
+
+
+  The name of the query parameter that causes the JSP engine to just
+  pregenerate the servlet but not invoke it. If not specified, the default
+  value of org.apache.catalina.jsp_precompile will be 
used.
+
+
+
+  The default package name for compiled jsp pages. If not specified, the
+  default value of org.apache.jsp will be used.
+
+
+
+  The default package name for tag handlers generated from tag files. If
+  not specified, the default value of org.apache.jsp.tag will
+  be used.
+
+
+
+  The servlet context attribute under which the alternate deployment
+  descriptor for this web application is stored. If not specified, the
+  default value of org.apache.catalina.deploy.alt_dd will
+  be used.
+
+
+
+  Prefix to use for generated temporary variable names. If not 
specified,
+  the default value of _jspx_temp will be used.
+
+
+
+  If true, the instance manager is used to obtain tag
+  handler instances. If not specified, false will be used.
+
+
+  
+
+
+
+
+
+
+  
+
+
+  If this is true or if a security manager is in use a new
+  facade object will be created for each request. If not specified, the
+  default value of false will be used.
+
+
+
+  If this is true the '\' character will be permitted as a
+  path delimiter. If not specified, the default value of false
+  will be used.
+
+
+
+  If this is true '%2F' and '%5C' will be permitted as p

Re: Cookies are broken in 6.0.16?

[Remy Maucherat]

On Sun, 2008-02-10 at 11:17 -0700, Filip Hanik - Dev Lists wrote:
> Remy Maucherat wrote:
> > On Sun, 2008-02-10 at 11:44 -0500, Jim Manico wrote:
> >   
> >> Filip - you are 100% correct on this thread. Are you basically the 
> >> traffic cop guarding the core of Tomcat?
> >> 
> >
> > I understand, you are not impacted by the behavior change, and as a
> > result this allows you to be "fair", I suppose. The issue is that the
> > behavior of Tomcat has been different, in all prior releases, and
> > changing it of all a sudden without any configuration capability because
> > it feels nice to play "spec lawyer" is wrong to me. Similar decisions
> > have been made in the past, and this did cause problems, it's simply
> > faster to add the appropriate options right away.
> >   
> what about my suggestion, to add a flag to default to v1 cookies. they 
> get quoted and old behavior will continue to work.

This is the sort of configuration option which seems appropriate.

Rémy



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Cookies are broken in 6.0.16?

[Filip Hanik - Dev Lists]

Remy Maucherat wrote:

On Sun, 2008-02-10 at 11:44 -0500, Jim Manico wrote:
  
Filip - you are 100% correct on this thread. Are you basically the 
traffic cop guarding the core of Tomcat?



I understand, you are not impacted by the behavior change, and as a
result this allows you to be "fair", I suppose. The issue is that the
behavior of Tomcat has been different, in all prior releases, and
changing it of all a sudden without any configuration capability because
it feels nice to play "spec lawyer" is wrong to me. Similar decisions
have been made in the past, and this did cause problems, it's simply
faster to add the appropriate options right away.
  
what about my suggestion, to add a flag to default to v1 cookies. they 
get quoted and old behavior will continue to work.


Filip

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Cookies are broken in 6.0.16?

[Jim Manico]

That post was meant to go to Filip only, since he is an old friend. I 
was not trying to poke fun at your perspective on this public list, 
Remy. I'm going exit stage left and stop adding my thoughts to this thread.


My apologies.

- Jim

On Sun, 2008-02-10 at 11:44 -0500, Jim Manico wrote:
  
Filip - you are 100% correct on this thread. Are you basically the 
traffic cop guarding the core of Tomcat?



I understand, you are not impacted by the behavior change, and as a
result this allows you to be "fair", I suppose. The issue is that the
behavior of Tomcat has been different, in all prior releases, and
changing it of all a sudden without any configuration capability because
it feels nice to play "spec lawyer" is wrong to me. Similar decisions
have been made in the past, and this did cause problems, it's simply
faster to add the appropriate options right away.

Rémy



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

  

Re: Cookies are broken in 6.0.16?

[Remy Maucherat]

On Sun, 2008-02-10 at 11:44 -0500, Jim Manico wrote:
> Filip - you are 100% correct on this thread. Are you basically the 
> traffic cop guarding the core of Tomcat?

I understand, you are not impacted by the behavior change, and as a
result this allows you to be "fair", I suppose. The issue is that the
behavior of Tomcat has been different, in all prior releases, and
changing it of all a sudden without any configuration capability because
it feels nice to play "spec lawyer" is wrong to me. Similar decisions
have been made in the past, and this did cause problems, it's simply
faster to add the appropriate options right away.

Rémy



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Cookies are broken in 6.0.16?

[Filip Hanik - Dev Lists]

Mark Thomas wrote:

Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:

Jim Manico wrote:
> I guess we could throw a run time exception if the value 
contained any of those. other than that, I'm not sure how to behave


I think this is the best case scenario for v0 cookies. Perhaps, if 
you really want to get fancy, you can add a flag to let legacy 
solutions roll back to the old/non-standard cookie handling 
methodology?
no, we wont do that. we fixed the cookie behavior in this release 
due to security issues filed against the old parsing.


The security issue only exists because of a fundamentally broken 
servlet in the examples, and assumes the user will click on a URL. 
That's not what I call a security problem.


The root cause of the issue wasn't the servlet in the examples. If it 
were, that servlet would have been fixed.


The issue was a number of bugs/inconsistencies in the handling of 
cookie headers, particularly around quoting and unquoting which 
enabled XSS attacks in some instances. That said the issues were all 
hard to exploit and required the application to use user provided data 
directly as the cookie value. This was why these issues were rated as 
low severity.


An enhancement request to log when Tomcat ignores/truncates a value or 
identifies some other issue when parsing cookies seems reasonable to me.
I just thought some more on this, the easiest suggestion I would come up 
with would be to have a flag that defaults all cookies to v1.

turning on this flag, will make all values work correctly.

Filip

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Cookies are broken in 6.0.16?

[Jim Manico]

Filip - you are 100% correct on this thread. Are you basically the 
traffic cop guarding the core of Tomcat?


- Jim

Mark Thomas wrote:

Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:

Jim Manico wrote:
> I guess we could throw a run time exception if the value 
contained any of those. other than that, I'm not sure how to behave


I think this is the best case scenario for v0 cookies. Perhaps, if 
you really want to get fancy, you can add a flag to let legacy 
solutions roll back to the old/non-standard cookie handling 
methodology?
no, we wont do that. we fixed the cookie behavior in this release 
due to security issues filed against the old parsing.


The security issue only exists because of a fundamentally broken 
servlet in the examples, and assumes the user will click on a URL. 
That's not what I call a security problem.


The root cause of the issue wasn't the servlet in the examples. If it 
were, that servlet would have been fixed.


The issue was a number of bugs/inconsistencies in the handling of 
cookie headers, particularly around quoting and unquoting which 
enabled XSS attacks in some instances. That said the issues were all 
hard to exploit and required the application to use user provided 
data directly as the cookie value. This was why these issues were 
rated as low severity.


An enhancement request to log when Tomcat ignores/truncates a value 
or identifies some other issue when parsing cookies seems reasonable 
to me.
the thing is, the javadoc as very very clear on this, to create a v0 
cookie, and put == in the end, is obviously not good :)


Mark

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Cookies are broken in 6.0.16?

[Filip Hanik - Dev Lists]

Mark Thomas wrote:

Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:

Jim Manico wrote:
> I guess we could throw a run time exception if the value 
contained any of those. other than that, I'm not sure how to behave


I think this is the best case scenario for v0 cookies. Perhaps, if 
you really want to get fancy, you can add a flag to let legacy 
solutions roll back to the old/non-standard cookie handling 
methodology?
no, we wont do that. we fixed the cookie behavior in this release 
due to security issues filed against the old parsing.


The security issue only exists because of a fundamentally broken 
servlet in the examples, and assumes the user will click on a URL. 
That's not what I call a security problem.


The root cause of the issue wasn't the servlet in the examples. If it 
were, that servlet would have been fixed.


The issue was a number of bugs/inconsistencies in the handling of 
cookie headers, particularly around quoting and unquoting which 
enabled XSS attacks in some instances. That said the issues were all 
hard to exploit and required the application to use user provided data 
directly as the cookie value. This was why these issues were rated as 
low severity.


An enhancement request to log when Tomcat ignores/truncates a value or 
identifies some other issue when parsing cookies seems reasonable to me.
the thing is, the javadoc as very very clear on this, to create a v0 
cookie, and put == in the end, is obviously not good :)


Mark

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Cookies are broken in 6.0.16?

[Jim Manico]

>  The security issue only exists because of a fundamentally broken 
servlet in the examples, and assumes the user will click on a URL. 
That's not what I call a security problem.


There is a whole class of security problems that are driven by bad 
server code and user interaction, such as reflective XSS due to poor 
input validation. Low risk as Filip saz, but a security problem 
none-the-less.


- Jim


Filip Hanik - Dev Lists wrote:

Jim Manico wrote:
> I guess we could throw a run time exception if the value contained 
any of those. other than that, I'm not sure how to behave


I think this is the best case scenario for v0 cookies. Perhaps, if 
you really want to get fancy, you can add a flag to let legacy 
solutions roll back to the old/non-standard cookie handling 
methodology?
no, we wont do that. we fixed the cookie behavior in this release due 
to security issues filed against the old parsing.


The security issue only exists because of a fundamentally broken 
servlet in the examples, and assumes the user will click on a URL. 
That's not what I call a security problem.


Rémy


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 41861] - Tomcat Windows installer behaves unexpectedly

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41861


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




--- Additional Comments From [EMAIL PROTECTED]  2008-02-10 06:26 ---
in order to use the apache-tomcat-6.0.16.exe installer and to avoid the
service creation error message i simply renamed my running "Apache Tomcat"
5.5 service with the sc command in a dos box:

sc config "tomcat5" DisplayName= "Apache Tomcat 5.5.20"
[SC] ChangeServiceConfig SUCCESS

Now, the apache-tomcat-6.0.16.exe installer runs as expected.

bye, marco

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Cookies are broken in 6.0.16?

[Mark Thomas]

Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:

Jim Manico wrote:
> I guess we could throw a run time exception if the value contained 
any of those. other than that, I'm not sure how to behave


I think this is the best case scenario for v0 cookies. Perhaps, if 
you really want to get fancy, you can add a flag to let legacy 
solutions roll back to the old/non-standard cookie handling methodology?
no, we wont do that. we fixed the cookie behavior in this release due 
to security issues filed against the old parsing.


The security issue only exists because of a fundamentally broken servlet 
in the examples, and assumes the user will click on a URL. That's not 
what I call a security problem.


The root cause of the issue wasn't the servlet in the examples. If it were, 
that servlet would have been fixed.


The issue was a number of bugs/inconsistencies in the handling of cookie 
headers, particularly around quoting and unquoting which enabled XSS 
attacks in some instances. That said the issues were all hard to exploit 
and required the application to use user provided data directly as the 
cookie value. This was why these issues were rated as low severity.


An enhancement request to log when Tomcat ignores/truncates a value or 
identifies some other issue when parsing cookies seems reasonable to me.


Mark

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Cookies are broken in 6.0.16?

[Remy Maucherat]

Filip Hanik - Dev Lists wrote:

Jim Manico wrote:
> I guess we could throw a run time exception if the value contained 
any of those. other than that, I'm not sure how to behave


I think this is the best case scenario for v0 cookies. Perhaps, if you 
really want to get fancy, you can add a flag to let legacy solutions 
roll back to the old/non-standard cookie handling methodology?
no, we wont do that. we fixed the cookie behavior in this release due to 
security issues filed against the old parsing.


The security issue only exists because of a fundamentally broken servlet 
in the examples, and assumes the user will click on a URL. That's not 
what I call a security problem.


Rémy


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]