Re: DO NOT REPLY [Bug 46416] New: Include order in jk_global.h breaks mod_jk build on Windows + Visual Studio 2005
I'd like to but got now VC2005 to check it ,( 2009/1/29 Tim Whittington : > Any chance of anyone fixing this? > > I¹d submit a patch myself, but it¹s trivial, and some more tidying than a > quick fix might be in order. > > cheers > tim > > > > From: > Reply-To: Tomcat Developers List > Date: Thu, 18 Dec 2008 14:04:22 -0800 (PST) > To: > Subject: DO NOT REPLY [Bug 46416] New: Include order in jk_global.h breaks > mod_jk build on Windows + Visual Studio 2005 > > https://issues.apache.org/bugzilla/show_bug.cgi?id=46416 > > Summary: Include order in jk_global.h breaks mod_jk build on >Windows + Visual Studio 2005 > Product: Tomcat Connectors > Version: 1.2.27 > Platform: PC >OS/Version: Windows XP >Status: NEW > Severity: blocker > Priority: P1 > Component: mod_jk >AssignedTo: dev@tomcat.apache.org >ReportedBy: tim.whitting...@orionhealth.com > > > Building against the 1.2.27 tag, I've come across an issue with the order of > includes in jk_global.h that breaks the build using Visual Studio 2005. > > Some recent changes to keepalive code started using the tcp_keepalive struct > in > , which is only included in jk_global.h if _WINDOWS_ is not > already > defined - i.e. if has not already been included. > > Unfortunately is included by APR (at least in the Apache 2.0 > build > I have), and the APR headers are included before the #ifndef _WINDOWS_ > block. > Switching the APR includes to below the #ifdef WIN32 block fixes the build. > > It appears there's some fragility in the includes - it seems a bit odd that > mod_jk is sensitive to being the first to import - but I didn't > look hard enough at all the other defines/includes in there to say it could > be > separated out entirely. > > (On a side note, is included in jk_mt.h, which may not be > necessary). > > > -- > 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 > > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: DO NOT REPLY [Bug 46416] New: Include order in jk_global.h breaks mod_jk build on Windows + Visual Studio 2005
oups no VC2005 ;( 2009/1/29 Henri Gomez : > I'd like to but got now VC2005 to check it ,( > > 2009/1/29 Tim Whittington : >> Any chance of anyone fixing this? >> >> I¹d submit a patch myself, but it¹s trivial, and some more tidying than a >> quick fix might be in order. >> >> cheers >> tim >> >> >> >> From: >> Reply-To: Tomcat Developers List >> Date: Thu, 18 Dec 2008 14:04:22 -0800 (PST) >> To: >> Subject: DO NOT REPLY [Bug 46416] New: Include order in jk_global.h breaks >> mod_jk build on Windows + Visual Studio 2005 >> >> https://issues.apache.org/bugzilla/show_bug.cgi?id=46416 >> >> Summary: Include order in jk_global.h breaks mod_jk build on >>Windows + Visual Studio 2005 >> Product: Tomcat Connectors >> Version: 1.2.27 >> Platform: PC >>OS/Version: Windows XP >>Status: NEW >> Severity: blocker >> Priority: P1 >> Component: mod_jk >>AssignedTo: dev@tomcat.apache.org >>ReportedBy: tim.whitting...@orionhealth.com >> >> >> Building against the 1.2.27 tag, I've come across an issue with the order of >> includes in jk_global.h that breaks the build using Visual Studio 2005. >> >> Some recent changes to keepalive code started using the tcp_keepalive struct >> in >> , which is only included in jk_global.h if _WINDOWS_ is not >> already >> defined - i.e. if has not already been included. >> >> Unfortunately is included by APR (at least in the Apache 2.0 >> build >> I have), and the APR headers are included before the #ifndef _WINDOWS_ >> block. >> Switching the APR includes to below the #ifdef WIN32 block fixes the build. >> >> It appears there's some fragility in the includes - it seems a bit odd that >> mod_jk is sensitive to being the first to import - but I didn't >> look hard enough at all the other defines/includes in there to say it could >> be >> separated out entirely. >> >> (On a side note, is included in jk_mt.h, which may not be >> necessary). >> >> >> -- >> 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 >> >> >> > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 46623] New: Tomcat/IIS closes socket after http response has completed
https://issues.apache.org/bugzilla/show_bug.cgi?id=46623 Summary: Tomcat/IIS closes socket after http response has completed Product: Tomcat Connectors Version: 1.2.27 Platform: PC OS/Version: Windows Server 2003 Status: NEW Severity: major Priority: P2 Component: isapi AssignedTo: dev@tomcat.apache.org ReportedBy: kpec...@gmail.com Created an attachment (id=23189) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=23189) WireShark response description, when connecting directly to JBoss and via IIS I am using JBoss 4.0.2, which has Tomcat Servlet Container 5.5. I also have IIS 6.0 redirected to this JBoss. (via IIS tomcat connector, which is used as ISAPI filter in IIS). All is working OK, configured the workers as described in documentation. Here is a piece of workers.properties file of the connector: worker.jboss0_ajp13.port=8009 worker.jboss0_ajp13.type=ajp13 worker.jboss0_ajp13.host=localhost worker.jboss0_ajp13.socket_keepalive=1 worker.jboss0_ajp13.socket_timeout=300 But when connecting to the application via IIS (port 80), for each completed HTTP response for HTTP request, the socket is closed (FIN is sent on the TCP layer and "Connection: close" is sent on the HTTP layer). This causes severe slowdowns, since the application is working over WAN. (for each closed socket, another one needed to be established, which takes 500ms). This is not happening when connecting to JBoss web server directly, and also not happening when connecting to a different virtual directory on the same WebSite of IIS (i.e. Keep-Alive in IIS is also configured). This happens with the latest version of tomcat IIS connector (1.2.27). Attaching WireShark description of the response w/wo IIS redirection. -- 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 46623] Tomcat/IIS closes socket after http response has completed
https://issues.apache.org/bugzilla/show_bug.cgi?id=46623 Tim Whittington changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #1 from Tim Whittington 2009-01-29 02:01:00 PST --- Up until 1.2.27 this was the behaviour of the IIS connector (IIS forces all ISAPI extensions to implement their own HTTP keep alive, and the IIS connector didn't do this). In 1.2.27 there's experimental, build-time, support for HTTP 1.1 chunked encoding, which should permit persistent connections. (I've been using pretty much the same code in production systems for about 4 years, but it should be considered experimental in the JK codebase until it's been stable for a while). Grab the -chunked binary from one of the download mirrors and read about how to configure chunked encoding in the 1.2.27 release notes (you have to get the right build, and enable it in your config). You can verify that the connector is using chunked encoding with debug logging on, and a TCP/Wireshark trace should show connections being reused. If you're still getting closed connections, and the logs show that the connector is attempting (or should be attempting) chunked encoding, then it's probably best to discuss on the users list and then reopen with another Wireshark trace + connector debug log once you're sure there's an issue. -- 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 #36 from Mark Thomas 2009-01-29 02:04:16 PST --- I have tried to keep my response as brief as possible. v0 cookies and '=' I do not see anything in the v0 spec that indicates that '=' is not permitted in the cookie name - hence the ambiguity. I am open to revisiting this if it can be shown clearly that the v0 spec does not permit '=' in the cookie name. v1 cookies Regardless of one's views of the v1 spec, Tomcat has to support v1 cookies. I don't see any issues with Tomcat 6's v1 cookie handling in the text above but if I have missed something, please create a separate Bugzilla entry for it. v2 cookies The servlet API only supports v0 and v1 cookies. I am all for adding v2 support but this would be better handled through the Expert Group (EG). Servlet spec issues This are best handled through the EG. httpOnly This is in the 3.0 servlet spec and will be supported in Tomcat 7. There are patches proposed to backport this to 6.0.x and 5.5.x but they need to be reviewed in light of the 3.0 spec changes to try and keep things consistent. Strict servlet compliance See the specification section of http://tomcat.apache.org/tomcat-6.0-doc/config/systemprops.html %XX encoding in cookie headers I did some testing of this when looking at the cookie parsing some time ago and couldn't get it to work. My tests could have been bad. The wording in the v0 spec for %XX encoding is such that relying on any encoding scheme is going to be risky - this is one of the issues with the v0 spec. -- 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 46538] ETag must differ between compressed and uncompressed resource versions
https://issues.apache.org/bugzilla/show_bug.cgi?id=46538 --- Comment #1 from Oliver Schoett 2009-01-29 03:42:56 PST --- Created an attachment (id=23190) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=23190) Patch to correct ETags and Vary headers for compression Here is a patch that corrects the ETag and Vary behaviour: - ETags differ for gzipped and ungzipped output - Vary: Accept-Encoding ist sent whenever a gzipped version is available The latter change makes it possible for users of differently capable browsers to receive gzipped and ungzipped reponses through the same proxy cache. Previously, an ungzipped cached version would be delivered also to compression-capable browsers, because the cache could not know there was a gzipped version available. This patch will be put in production on an e-commerce website shortly. -- 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 46538] ETag must differ between compressed and uncompressed resource versions
https://issues.apache.org/bugzilla/show_bug.cgi?id=46538 --- Comment #2 from Oliver Schoett 2009-01-29 03:56:52 PST --- Here is the new behaviour when a resource is fetched without and with compression enabled: curl -v -HPragma: http://tomcat6.example.com/web3/js/hbx.js > GET /web3/js/hbx.js HTTP/1.1 > User-Agent: curl/7.16.3 (i686-pc-cygwin) libcurl/7.16.3 OpenSSL/0.9.8i > zlib/1.2.3 libssh2/0.15-CVS > Host: tomcat6.example.com > Accept: */* < Server: Apache-Coyote/1.1 < Expires: Thu, 29 Jan 2009 13:27:07 GMT < ETag: W/"15453-1233218608000" < Last-Modified: Thu, 29 Jan 2009 08:43:28 GMT < Vary: Accept-Encoding < Content-Type: text/javascript < Content-Length: 15453 < Date: Thu, 29 Jan 2009 11:27:07 GMT curl -v -HPragma: --compressed http://tomcat6.example.com/web3/js/hbx.js | wc -c > GET /web3/js/hbx.js HTTP/1.1 > User-Agent: curl/7.16.3 (i686-pc-cygwin) libcurl/7.16.3 OpenSSL/0.9.8i > zlib/1.2.3 libssh2/0.15-CVS > Host: tomcat6.example.com > Accept: */* > Accept-Encoding: deflate, gzip < HTTP/1.1 200 OK < Server: Apache-Coyote/1.1 < Expires: Thu, 29 Jan 2009 13:26:48 GMT < ETag: W/"15453-1233218608000-gz" < Last-Modified: Thu, 29 Jan 2009 08:43:28 GMT < Vary: Accept-Encoding < Content-Type: text/javascript < Transfer-Encoding: chunked < Content-Encoding: gzip < Date: Thu, 29 Jan 2009 11:26:48 GMT Note that the first response also has a Vary header, and the second response has a different ETag. When this patch is employed, the work-around configured by default in Squid caches (broken_vary_encoding) is no longer necessary. If you want to avoid this work-around for your server, you might configure a server string that does NOT start with "Apache". -- 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 46538] ETag must differ between compressed and uncompressed resource versions
https://issues.apache.org/bugzilla/show_bug.cgi?id=46538 --- Comment #3 from Oliver Schoett 2009-01-29 09:05:04 PST --- Warning: the patch I submitted does not work well in connection with the Akamai CDN. First, the Akamai edge servers transparently decompress content without changing the ETag (so that compressed and uncompressed versions are sent with the same Etag). Second, the Akamai servers treat responses with Vary: Accept-Encoding but without Content-Encoding header as uncacheable (ESConfigGuide-Customer, p. 54, Note: TTL and the Vary Header). My patch triggers this in the case of uncompressed responses (due to missing client capability) that the server would be willing to compress. -- 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 #37 from Peter Pichler 2009-01-29 10:13:12 PST --- (In reply to comment #36) > I have tried to keep my response as brief as possible. > > v0 cookies and '=' > I do not see anything in the v0 spec that indicates that '=' is not permitted > in the cookie name - hence the ambiguity. I am open to revisiting this if it > can be shown clearly that the v0 spec does not permit '=' in the cookie name. It is an lack in the Netscape Draft... With good will it is possible to interpretate the draft like... "it is clear, that it is not possible to have cookie names containing an equal mark, because the equal mark is the delimiter for the cookie name"... for sure you can argue otherwise also... (Other forbidden characters are mentioned explicitly... so the cookie draft allows the equal mark for cookie names...) The cookie draft can not be changed any more... so we have to look how to handle it... Because it is impossible to implement a Cookie-Handling allowing "=" in the cookie name... it makes no sense trying to support it... > v1 cookies > Regardless of one's views of the v1 spec, Tomcat has to support v1 cookies. I > don't see any issues with Tomcat 6's v1 cookie handling in the text above but > if I have missed something, please create a separate Bugzilla entry for it. You are right, cause the servlet spec requires cookie1 support (but they say cookie1 is experimental and should not be used on production side... because of that - and because cookie1 is obsolete since more than 8 years - it may be clever to put not to much effort in the cookie1 support a private meaning... My topic is the cookie0 support... the cookie1 topic came up, cause others are arguing with cookie1 when talking about cookie0) > v2 cookies, httpOnly... You are right... v2 Cookie-Support, HttpOnly-Support should be defined first in the servlet-spec... > %XX encoding in cookie headers > I did some testing of this when looking at the cookie parsing some time ago > and > couldn't get it to work. My tests could have been bad. The wording in the v0 > spec for %XX encoding is such that relying on any encoding scheme is going to > be risky - this is one of the issues with the v0 spec. This is what I do in applications with cookie values previously used base64 encoding (to eliminate slash and equal-mark... I use base64 and URL-Encoding after, because this produces shorter result strings) ... Until now it seems to work fine . If there are realy problems with this kind of work-around... it would be interesting for me... (but we are testing our software with serveral browsers and environments - and until now no problem has been reported) -- 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 46632] New: mod_jk's sockets close prematurely when the server forks a child
https://issues.apache.org/bugzilla/show_bug.cgi?id=46632 Summary: mod_jk's sockets close prematurely when the server forks a child Product: Tomcat Connectors Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: mod_jk AssignedTo: dev@tomcat.apache.org ReportedBy: jles...@placebase.com mod_jk registers its cleanup handler to be called both during plain_cleanup and child_cleanup: apr_pool_cleanup_register(p, s, jk_apr_pool_cleanup, jk_apr_pool_cleanup); So, whenever a server forks a child, ie, when mod_cgi creates its child process, jk_apr_pool_cleanup() gets called. jk_apr_pool_cleanup() does a shutdown() on its sockets, which closes down the socket for the parent process. Maybe it should use close() instead of shutdown(), or be registered as apr_pool_cleanup_register(p, s, jk_apr_pool_cleanup, jk_apr_pool_cleanup_null); ? Note, with mod_jk 1.2.18, a load balancing worker isn't able to recover from this, and it brings down the whole LB worker for awhile. 1.2.27 seems to be able to recover. After a CGI is hit and jk's sockets get closed underneath it, the logs look like: [Wed Jan 28 21:39:50 2009] [22841:42432] [info] ajp_send_request::jk_ajp_common.c (1178): Socket 75 is not connected any more (errno=-1) [Wed Jan 28 21:39:50 2009] [22841:42432] [info] ajp_send_request::jk_ajp_common.c (1202): Error sending request. Will try another pooled connection [Wed Jan 28 21:39:50 2009] [22841:42432] [info] ajp_send_request::jk_ajp_common.c (1224): All endpoints are disconnected or dead [Wed Jan 28 21:39:50 2009] [22841:42432] [info] ajp_service::jk_ajp_common.c (1783): Sending request to tomcat failed, recoverable operation attempt=1 -- 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
svn commit: r739171 - /tomcat/trunk/webapps/docs/config/http.xml
Author: markt Date: Fri Jan 30 05:05:25 2009 New Revision: 739171 URL: http://svn.apache.org/viewvc?rev=739171&view=rev Log: Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=46563 Modified: tomcat/trunk/webapps/docs/config/http.xml Modified: tomcat/trunk/webapps/docs/config/http.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/config/http.xml?rev=739171&r1=739170&r2=739171&view=diff == --- tomcat/trunk/webapps/docs/config/http.xml (original) +++ tomcat/trunk/webapps/docs/config/http.xml Fri Jan 30 05:05:25 2009 @@ -480,8 +480,9 @@ you might want to increase this value as well. Default value is 1. -(int)The number of threads to be used to run for the polling events. Default value is 1. - Can't see a reason to go above that. But experiment and find your own results. +(int)The number of threads to be used to run for the polling events. +Default value is 1 per processor. Can't see a reason to go +above that. But experiment and find your own results. (int)The priority of the poller threads. @@ -670,8 +671,7 @@ Certificate, but not fail if one isn't presented. A false value (which is the default) will not require a certificate chain unless the client requests a resource protected by a security - constraint that uses CLIENT-CERT authentication. See the - SSL HowTo for an example. + constraint that uses CLIENT-CERT authentication. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r739173 - in /tomcat/tc6.0.x/trunk/webapps/docs: changelog.xml config/http.xml
Author: markt Date: Fri Jan 30 05:06:47 2009 New Revision: 739173 URL: http://svn.apache.org/viewvc?rev=739173&view=rev Log: Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=46563 Modified: tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml tomcat/tc6.0.x/trunk/webapps/docs/config/http.xml Modified: tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml?rev=739173&r1=739172&r2=739173&view=diff == --- tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml (original) +++ tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml Fri Jan 30 05:06:47 2009 @@ -453,6 +453,10 @@ Fix broken URL mapping in the examples. (markt) + +46563: Update doc for correct default for pollerThreadCount. +(markt) + Modified: tomcat/tc6.0.x/trunk/webapps/docs/config/http.xml URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/config/http.xml?rev=739173&r1=739172&r2=739173&view=diff == --- tomcat/tc6.0.x/trunk/webapps/docs/config/http.xml (original) +++ tomcat/tc6.0.x/trunk/webapps/docs/config/http.xml Fri Jan 30 05:06:47 2009 @@ -415,8 +415,9 @@ you might want to increase this value as well. Default value is 1. -(int)The number of threads to be used to run for the polling events. Default value is 1. - Can't see a reason to go above that. But experiment and find your own results. +(int)The number of threads to be used to run for the polling events. +Default value is 1 per processor. Can't see a reason to go +above that. But experiment and find your own results. (int)The priority of the poller threads. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 46563] NIO protocol states default pollerThreadCount is 1, actually is # processors
https://issues.apache.org/bugzilla/show_bug.cgi?id=46563 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Mark Thomas 2009-01-29 21:07:14 PST --- Thanks for the report. This has been fixed in trunk and 6.0.x and will be included in the next release. -- 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
svn commit: r739176 - /tomcat/trunk/java/org/apache/jasper/compiler/Validator.java
Author: markt
Date: Fri Jan 30 05:30:23 2009
New Revision: 739176
URL: http://svn.apache.org/viewvc?rev=739176&view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=46564
Encoding test should be case insensitive
Modified:
tomcat/trunk/java/org/apache/jasper/compiler/Validator.java
Modified: tomcat/trunk/java/org/apache/jasper/compiler/Validator.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/compiler/Validator.java?rev=739176&r1=739175&r2=739176&view=diff
==
--- tomcat/trunk/java/org/apache/jasper/compiler/Validator.java (original)
+++ tomcat/trunk/java/org/apache/jasper/compiler/Validator.java Fri Jan 30
05:30:23 2009
@@ -374,16 +374,16 @@
* Compares page encodings specified in various places, and throws
* exception in case of page encoding mismatch.
*
- * @param pageDirEnc The value of the pageEncoding attribute of the
page
+ * @param thePageDirEnc The value of the pageEncoding attribute of the
page
* directive @param pageDir The page directive node
*
* @throws JasperException in case of page encoding mismatch
*/
-private void compareTagEncodings(String pageDirEnc,
+private void compareTagEncodings(String thePageDirEnc,
Node.TagDirective pageDir) throws JasperException {
Node.Root root = pageDir.getRoot();
-
+String pageDirEnc = thePageDirEnc.toUpperCase();
/*
* Compare the 'pageEncoding' attribute of the page directive with
* the encoding specified in the XML prolog (only for XML syntax,
@@ -392,7 +392,7 @@
* identical.
*/
if ((root.isXmlSyntax() && root.isEncodingSpecifiedInProlog()) ||
root.isBomPresent()) {
-String pageEnc = root.getPageEncoding();
+String pageEnc = root.getPageEncoding().toUpperCase();
if (!pageDirEnc.equals(pageEnc)
&& (!pageDirEnc.startsWith("UTF-16") || !pageEnc
.startsWith("UTF-16"))) {
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r739177 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: markt Date: Fri Jan 30 05:31:28 2009 New Revision: 739177 URL: http://svn.apache.org/viewvc?rev=739177&view=rev Log: Propose fix for 46564 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=739177&r1=739176&r2=739177&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Fri Jan 30 05:31:28 2009 @@ -179,3 +179,8 @@ http://svn.apache.org/viewvc?rev=734743&view=rev +1: markt, fhanik -1: + +* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=46564 + Make page encoding test case insensitive + +1: markt + -1: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 46564] .tagx files don't compile if the document and page encoding casing differs
https://issues.apache.org/bugzilla/show_bug.cgi?id=46564 --- Comment #1 from Mark Thomas 2009-01-29 21:32:16 PST --- Looks like I missed a case when I fixed 44986. Trunk has been fixed and the patch proposed for 6.0.x -- 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
svn commit: r739181 - /tomcat/trunk/webapps/docs/ssl-howto.xml
Author: markt Date: Fri Jan 30 05:35:25 2009 New Revision: 739181 URL: http://svn.apache.org/viewvc?rev=739181&view=rev Log: Minor clarification as a result of bug 46498 Modified: tomcat/trunk/webapps/docs/ssl-howto.xml Modified: tomcat/trunk/webapps/docs/ssl-howto.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/ssl-howto.xml?rev=739181&r1=739180&r2=739181&view=diff == --- tomcat/trunk/webapps/docs/ssl-howto.xml (original) +++ tomcat/trunk/webapps/docs/ssl-howto.xml Fri Jan 30 05:35:25 2009 @@ -424,6 +424,9 @@ all SSL clients to present a client Certificate in order to use this socket. Set this value to want if you want Tomcat to request a client Certificate, but not fail if one isn't presented. +A false value (which is the default) will not require a +certificate chain unless the client requests a resource protected by a +security constraint that uses CLIENT-CERT authentication. SSLEnabled - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r739182 - /tomcat/tc6.0.x/trunk/webapps/docs/ssl-howto.xml
Author: markt Date: Fri Jan 30 05:36:33 2009 New Revision: 739182 URL: http://svn.apache.org/viewvc?rev=739182&view=rev Log: Minor clarification as a result of bug 46498 Modified: tomcat/tc6.0.x/trunk/webapps/docs/ssl-howto.xml Modified: tomcat/tc6.0.x/trunk/webapps/docs/ssl-howto.xml URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/ssl-howto.xml?rev=739182&r1=739181&r2=739182&view=diff == --- tomcat/tc6.0.x/trunk/webapps/docs/ssl-howto.xml (original) +++ tomcat/tc6.0.x/trunk/webapps/docs/ssl-howto.xml Fri Jan 30 05:36:33 2009 @@ -421,6 +421,9 @@ all SSL clients to present a client Certificate in order to use this socket. Set this value to want if you want Tomcat to request a client Certificate, but not fail if one isn't presented. +A false value (which is the default) will not require a +certificate chain unless the client requests a resource protected by a +security constraint that uses CLIENT-CERT authentication. SSLEnabled - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 46498] Client certificate is not requested when clientAuth is false and resource is protected by security constraint
https://issues.apache.org/bugzilla/show_bug.cgi?id=46498 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #1 from Mark Thomas 2009-01-29 21:40:11 PST --- Tomcat will request a certificate in this case however, the browser will not prompt the user unless the user has a cert that is trusted by Tomcat. Additionally, some browsers will not prompt for a certificate if there is only one that Tomcat will trust - it is provided automatically. I have made some minor tweaks to the docs to improve clarity. If you need assistance configuring CLIENT-CERT authentication and the associated certificates please use the users list. -- 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
