DO NOT REPLY [Bug 45618] Selector is not closed.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45618 Mark Thomas <[EMAIL PROTECTED]> changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #6 from Mark Thomas <[EMAIL PROTECTED]> 2008-10-09 05:37:12 PST --- The fix has been applied to 6.0.x and will be included in 6.0.19 onwards. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat trunk - changelog
Filip Hanik - Dev Lists wrote: > I'd like for us to start using the changelog for trunk, we're losing a > lot of changes being documented, not everything gets ported to 6.0 etc > do you guys have any thoughts on this? There is a need to do a diff of trunk against 6.0.x and check that nothing has fallen through the cracks. I suspect there will be the odd commit here and there. I started to do this but got side-tracked. On reflection it makes sense to temporarily add a short text file to trunk just to record what has been checked and what hasn't. That way we can do it package by package as people have the time. Assuming that trunk becomes the basis for 7.x then I think the only entries that are in it should be the ones that aren't in 6.0.x. We didn't start the 6.x changelog with the 5.5.x changelog we started with a clean sheet and I think 7.x should be the same. ie the trunk/7.x changelog should be the differences between trunk and 6.0.x, not trunk and 5.5.x. The trunk changelog can be updated as part of the trunk/6.0.x diff. Mark > > 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]
DO NOT REPLY [Bug 45975] New: JAAS Login Module fails to load on Windows in directories with spaces in the path
https://issues.apache.org/bugzilla/show_bug.cgi?id=45975 Summary: JAAS Login Module fails to load on Windows in directories with spaces in the path Product: Tomcat 5 Version: Unknown Platform: PC OS/Version: Windows XP Status: NEW Severity: major Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: [EMAIL PROTECTED] Tomcat is unable to load jaas configuration file, if tomcat installtion path contains spaces in them. Following is stack trace. SEVERE: Unexpected error java.lang.SecurityException: C:\tomcat%205526\webapps\apps\WEB-INF\classes\c om\login.conf (The system cannot find the path specified) at com.sun.security.auth.login.ConfigFile.(ConfigFile.java:97) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstruct orAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingC onstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at java.lang.Class.newInstance0(Class.java:350) at java.lang.Class.newInstance(Class.java:303) at javax.security.auth.login.Configuration$3.run(Configuration.java:216) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.Configuration.getConfiguration(Configuratio n.java:210) at javax.security.auth.login.LoginContext$1.run(LoginContext.java:237) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.LoginContext.init(LoginContext.java:234) at javax.security.auth.login.LoginContext.(LoginContext.java:403) at org.apache.catalina.realm.JAASRealm.authenticate(JAASRealm.java:348) at org.apache.catalina.authenticator.FormAuthenticator.authenticate(Form Authenticator.java:258) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authentica torBase.java:417) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j ava:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j ava:117) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal ve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav a:174) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java :874) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.p rocessConnection(Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpo int.java:528) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFol lowerWorkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP ool.java:689) at java.lang.Thread.run(Thread.java:595) Caused by: java.io.FileNotFoundException: C:\tomcat%205526\webapps\apps\WEB- INF\classes\com\login.conf (The system cannot find the path specified) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.(FileInputStream.java:106) at java.io.FileInputStream.(FileInputStream.java:66) at com.sun.security.auth.login.ConfigFile.getInputStream(ConfigFile.java :552) at com.sun.security.auth.login.ConfigFile.init(ConfigFile.java:216) at com.sun.security.auth.login.ConfigFile.init(ConfigFile.java:163) at com.sun.security.auth.login.ConfigFile.(ConfigFile.java:95) ... 26 more -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 45975] JAAS Login Module fails to load on Windows in directories with spaces in the path
https://issues.apache.org/bugzilla/show_bug.cgi?id=45975 Vivek Kumar <[EMAIL PROTECTED]> changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #1 from Vivek Kumar <[EMAIL PROTECTED]> 2008-10-09 05:41:04 PST --- Tomcat home is Using CATALINA_BASE: C:\tomcat 5526 Using CATALINA_HOME: C:\tomcat 5526 Using CATALINA_TMPDIR: C:\tomcat 5526\temp Using JRE_HOME:C:/Program Files/Java/jdk1.5.0_16 -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Byte Serving and PDFs with the DefaultServlet
Hello, I'm new to the list. Hello to every one. Sorry if I'm posting this
message in the wrong place. If so please advise me to fix it.
I was asked to make a PDF functionality called Fast Web View work in a
Tomcat application. In my initial tests, as I will describe, it did not
worked.
I started downloading the version 6.0.18 and after that I downloaded the
trunk SVN branch and compiled every thing (comment: a hard job at the
first time, ah? sorry, I had many web proxy issues),
I wrote a small HTML just for testing purpose. The "index.html" file is
something like:
http://www.w3.org/TR/html4/strict.dtd";>
FIRST_FAST_WEB_VIEW_READY.PDF
32.09 MB
SECOND_FAST_WEB_VIEW_READY.PDF
41.72 MB
NTH_FAST_WEB_VIEW_READY.PDF
25.83 MB
I just created a folder in the webapps folder named PDFs and placed
everything there.
When I started Tomcat, opened the page and click on the first PDF link (on
other link the result was the same) with the address
http://localhost:8080/PDFs/, I got the following result:
- The file was found by Tomcat
- Adobe Reader works properlly requesting a "byte served" content (I also
configured the property useAcceptRanges on the web.xml file)
- Tomcat returned a header response 200 OK and some data
- Adobe requests a partial content with a few range descriptors like:
500-999, 7000-7999 (I rounded the sample here)
- Tomcat send a response (http 206) multipart/byterange for the above
ranges
- Adobe Reader locks and don't ask any more ranges
- The browser also locks and after a long wait time it returns a error
message of problems on file.
I started them analysing the response stream with an http protocol
analyser plug-in for the browser.
In the RFC2616 I noted that the response should be as the below sample
cutted from the RFC2616:
HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
--THIS_STRING_SEPARATES
Content-type: application/pdf
Content-range: bytes 500-999/8000
...the first range...
--THIS_STRING_SEPARATES
Content-type: application/pdf
Content-range: bytes 7000-7999/8000
...the second range
--THIS_STRING_SEPARATES--
But I noted that Tomcat was returning the following stream:
HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
--THIS_STRING_SEPARATES
Content-range: bytes 500-999/8000
...the first range...
--THIS_STRING_SEPARATES
Content-range: bytes 7000-7999/8000
...the second range
--THIS_STRING_SEPARATES--
Please note the lack of the "Content-type: application/pdf" message and
additional line break from the RFC sample and the Tomcat stream.
After some research I found the DefaultServlet Class where the stream for
partial content and multi range requests are served.
On Tomcat 6.0 at java\org\apache\catalina\servlets and on Tomcat 5.5 at
container\catalina\src\share\org\apache\catalina\servlets
The first thing that happens to make it work was the add of
"useAcceptRanges" on the config file (web.xml) and the fix for it on
Tomcat 6.0.x class source code on the SVN repository (thankyou). It really
made difference because the HTTP header response must have "Accept-Ranges:
bytes" string to allow clients make byte requests (at least Adobe Reader).
The second thing is in the "copy" methods. There is a check for the
"contentType" variable and for any reason the method that try to retrieve
its value, before the call for "copy" method, is always returning null.
So, in the if statement within the "copy" methods:
if (contentType != null)
ostream.println("Content-Type: " + contentType);
and
if (contentType != null)
writer.println("Content-type: " + contentType);
I added a "forced" result of :
if (contentType != null)
ostream.println("Content-type: " + contentType);
else
ostream.println("Content-type: application/pdf");
and
if (contentType != null)
writer.println("Content-type: " + contentType);
else
writer.println("Content-type: application/pdf");
In my environment it is sufficient because my big deal is with PDF files,
but I know that it is not the most elegant solution neither can be a
definitive solution.
As I am not a java programmer, I ask for the list to handle this issue.
If it sound completely nuts please forgive me.
I'm available to help with tests for this issue. Please contact me through
the list or directly.
Best regards to all.
Sincerely,
Antonio Vitor Elias Swaid Jr
Technical Publications
svn commit: r703154 - in /tomcat/tc6.0.x/trunk: ./ STATUS.txt java/org/apache/catalina/tribes/transport/nio/ParallelNioSender.java webapps/docs/changelog.xml
Author: markt
Date: Thu Oct 9 05:37:06 2008
New Revision: 703154
URL: http://svn.apache.org/viewvc?rev=703154&view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=45618
Make sure selector is closed. Unlikely to be an issue for most (all?)
circumstances but technically needs fixing.
Modified:
tomcat/tc6.0.x/trunk/ (props changed)
tomcat/tc6.0.x/trunk/STATUS.txt
tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/transport/nio/ParallelNioSender.java
tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml
Propchange: tomcat/tc6.0.x/trunk/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Thu Oct 9 05:37:06 2008
@@ -1 +1 @@
-/tomcat/trunk:673796,673820,683982,684001,684081,684234,684269-684270,687503,687645,690781,691805,692748,695053,695311,698012,698227,698236,698613
+/tomcat/trunk:673796,673820,683982,684001,684081,684234,684269-684270,687503,687645,690781,691392,691805,692748,695053,695311,698012,698227,698236,698613
Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=703154&r1=703153&r2=703154&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Thu Oct 9 05:37:06 2008
@@ -88,14 +88,6 @@
+1: markt, remm
-1:
-* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=45618
- Make sure selector is closed.
- Unlikely to be an issue for most (all?) circumstances but technically
- needs fixing,
- http://svn.apache.org/viewvc?rev=691392&view=rev
- +1: markt, rjung, fhanik
- -1:
-
* ETag improvement: https://issues.apache.org/bugzilla/show_bug.cgi?id=45735
+1: remm, markt, rjung
-1:
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/transport/nio/ParallelNioSender.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/transport/nio/ParallelNioSender.java?rev=703154&r1=703153&r2=703154&view=diff
==
---
tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/transport/nio/ParallelNioSender.java
(original)
+++
tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/transport/nio/ParallelNioSender.java
Thu Oct 9 05:37:06 2008
@@ -275,6 +275,7 @@
public void finalize() {
try {disconnect(); }catch ( Exception ignore){}
+try {selector.close();} catch (Exception ignore) {}
}
public boolean keepalive() {
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=703154&r1=703153&r2=703154&view=diff
==
--- tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml Thu Oct 9 05:37:06 2008
@@ -146,6 +146,10 @@
Document the multicast recovery options. (fhanik)
+
+45618: Make sure NIO selector is closed when no longer used.
+Unlikely to be an issue in normal usage. (markt)
+
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Byte Serving and PDFs with the DefaultServlet
[EMAIL PROTECTED] wrote:
> Hello, I'm new to the list. Hello to every one. Sorry if I'm posting this
> message in the wrong place. If so please advise me to fix it.
>From a quick scan of your e-mail it looks like you have a valid bug
here. To make sure this doesn't get lost, please add it to the Tomcat
issue tracker at http://issues.apache.org/bugzilla
Cheers,
Mark
>
> I was asked to make a PDF functionality called Fast Web View work in a
> Tomcat application. In my initial tests, as I will describe, it did not
> worked.
>
> I started downloading the version 6.0.18 and after that I downloaded the
> trunk SVN branch and compiled every thing (comment: a hard job at the
> first time, ah? sorry, I had many web proxy issues),
>
> I wrote a small HTML just for testing purpose. The "index.html" file is
> something like:
>
> http://www.w3.org/TR/html4/strict.dtd";>
>
>
>
>
>
>
>
>type='application/pdf'>FIRST_FAST_WEB_VIEW_READY.PDF
>
> 32.09 MB
>
>
> type='application/pdf'>SECOND_FAST_WEB_VIEW_READY.PDF
>
> 41.72 MB
>
>
>type='application/pdf'>NTH_FAST_WEB_VIEW_READY.PDF
>
> 25.83 MB
>
>
>
>
>
> I just created a folder in the webapps folder named PDFs and placed
> everything there.
>
> When I started Tomcat, opened the page and click on the first PDF link (on
> other link the result was the same) with the address
> http://localhost:8080/PDFs/, I got the following result:
> - The file was found by Tomcat
> - Adobe Reader works properlly requesting a "byte served" content (I also
> configured the property useAcceptRanges on the web.xml file)
> - Tomcat returned a header response 200 OK and some data
> - Adobe requests a partial content with a few range descriptors like:
> 500-999, 7000-7999 (I rounded the sample here)
> - Tomcat send a response (http 206) multipart/byterange for the above
> ranges
> - Adobe Reader locks and don't ask any more ranges
> - The browser also locks and after a long wait time it returns a error
> message of problems on file.
>
> I started them analysing the response stream with an http protocol
> analyser plug-in for the browser.
>
> In the RFC2616 I noted that the response should be as the below sample
> cutted from the RFC2616:
>
> HTTP/1.1 206 Partial Content
>Date: Wed, 15 Nov 1995 06:25:24 GMT
>Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
>Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
>
>--THIS_STRING_SEPARATES
>Content-type: application/pdf
>Content-range: bytes 500-999/8000
>
>...the first range...
>--THIS_STRING_SEPARATES
>Content-type: application/pdf
>Content-range: bytes 7000-7999/8000
>
>...the second range
>--THIS_STRING_SEPARATES--
>
> But I noted that Tomcat was returning the following stream:
>
> HTTP/1.1 206 Partial Content
>Date: Wed, 15 Nov 1995 06:25:24 GMT
>Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
>Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
>
>--THIS_STRING_SEPARATES
>Content-range: bytes 500-999/8000
>
>
>...the first range...
>--THIS_STRING_SEPARATES
>Content-range: bytes 7000-7999/8000
>
>
>...the second range
>--THIS_STRING_SEPARATES--
>
>
> Please note the lack of the "Content-type: application/pdf" message and
> additional line break from the RFC sample and the Tomcat stream.
>
> After some research I found the DefaultServlet Class where the stream for
> partial content and multi range requests are served.
> On Tomcat 6.0 at java\org\apache\catalina\servlets and on Tomcat 5.5 at
> container\catalina\src\share\org\apache\catalina\servlets
>
> The first thing that happens to make it work was the add of
> "useAcceptRanges" on the config file (web.xml) and the fix for it on
> Tomcat 6.0.x class source code on the SVN repository (thankyou). It really
> made difference because the HTTP header response must have "Accept-Ranges:
> bytes" string to allow clients make byte requests (at least Adobe Reader).
>
> The second thing is in the "copy" methods. There is a check for the
> "contentType" variable and for any reason the method that try to retrieve
> its value, before the call for "copy" method, is always returning null.
> So, in the if statement within the "copy" methods:
>
> if (contentType != null)
> ostream.println("Content-Type: " + contentType);
>
> and
>
> if (contentType != null)
> writer.println("Content-type: " + contentType);
>
> I added a "forced" result of :
>
> if (contentType != null)
> ostream.println("Content-type: " + contentType);
> else
> ostream.println("Content-type: application/pdf");
>
> and
>
> if (contentType != null)
> writer.println("Con
DO NOT REPLY [Bug 45977] New: Duplicate comment in code - CoyoteAdapter.java
https://issues.apache.org/bugzilla/show_bug.cgi?id=45977
Summary: Duplicate comment in code - CoyoteAdapter.java
Product: Tomcat 6
Version: 6.0.18
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
AssignedTo: dev@tomcat.apache.org
ReportedBy: [EMAIL PROTECTED]
The XXX comments below seem to say the same thing. Not sure what the XXX
represents.
/**
* Parse additional request parameters.
*/
protected boolean postParseRequest(org.apache.coyote.Request req,
Request request,
org.apache.coyote.Response res,
Response response)
throws Exception {
// XXX the processor needs to set a correct scheme and port prior to
this point,
// in ajp13 protocols dont make sense to get the port from the
connector..
// XXX the processor may have set a correct scheme and port prior to
this point,
// in ajp13 protocols dont make sense to get the port from the
connector...
// otherwise, use connector configuration
if (! req.scheme().isNull()) {
// use processor specified scheme to determine secure state
request.setSecure(req.scheme().equals("https"));
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Byte Serving and PDFs with the DefaultServlet
On 09/10/2008, Mark Thomas <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > Hello, I'm new to the list. Hello to every one. Sorry if I'm posting this > > message in the wrong place. If so please advise me to fix it. > > > From a quick scan of your e-mail it looks like you have a valid bug > here. To make sure this doesn't get lost, please add it to the Tomcat > issue tracker at http://issues.apache.org/bugzilla > Just wondering if it is to do with the case of the filetype? The files are .PDF files rather than .pdf files - could that be the cause of the missing content-type? > Cheers, > > Mark > > > > > > I was asked to make a PDF functionality called Fast Web View work in a > > Tomcat application. In my initial tests, as I will describe, it did not > > worked. > > > > I started downloading the version 6.0.18 and after that I downloaded the > > trunk SVN branch and compiled every thing (comment: a hard job at the > > first time, ah? sorry, I had many web proxy issues), > > > > I wrote a small HTML just for testing purpose. The "index.html" file is > > something like: > > > > > http://www.w3.org/TR/html4/strict.dtd";> > > > > > > > > > > > > > > > > > type='application/pdf'>FIRST_FAST_WEB_VIEW_READY.PDF > > > > 32.09 MB > > > > > > > type='application/pdf'>SECOND_FAST_WEB_VIEW_READY.PDF > > > > 41.72 MB > > > > > > > type='application/pdf'>NTH_FAST_WEB_VIEW_READY.PDF > > > > 25.83 MB > > > > > > > > > > > > I just created a folder in the webapps folder named PDFs and placed > > everything there. > > > > When I started Tomcat, opened the page and click on the first PDF link (on > > other link the result was the same) with the address > > http://localhost:8080/PDFs/, I got the following result: > > - The file was found by Tomcat > > - Adobe Reader works properlly requesting a "byte served" content (I also > > configured the property useAcceptRanges on the web.xml file) > > - Tomcat returned a header response 200 OK and some data > > - Adobe requests a partial content with a few range descriptors like: > > 500-999, 7000-7999 (I rounded the sample here) > > - Tomcat send a response (http 206) multipart/byterange for the above > > ranges > > - Adobe Reader locks and don't ask any more ranges > > - The browser also locks and after a long wait time it returns a error > > message of problems on file. > > > > I started them analysing the response stream with an http protocol > > analyser plug-in for the browser. > > > > In the RFC2616 I noted that the response should be as the below sample > > cutted from the RFC2616: > > > > HTTP/1.1 206 Partial Content > >Date: Wed, 15 Nov 1995 06:25:24 GMT > >Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT > >Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES > > > >--THIS_STRING_SEPARATES > >Content-type: application/pdf > >Content-range: bytes 500-999/8000 > > > >...the first range... > >--THIS_STRING_SEPARATES > >Content-type: application/pdf > >Content-range: bytes 7000-7999/8000 > > > >...the second range > >--THIS_STRING_SEPARATES-- > > > > But I noted that Tomcat was returning the following stream: > > > > HTTP/1.1 206 Partial Content > >Date: Wed, 15 Nov 1995 06:25:24 GMT > >Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT > >Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES > > > >--THIS_STRING_SEPARATES > >Content-range: bytes 500-999/8000 > > > > > >...the first range... > >--THIS_STRING_SEPARATES > >Content-range: bytes 7000-7999/8000 > > > > > >...the second range > >--THIS_STRING_SEPARATES-- > > > > > > Please note the lack of the "Content-type: application/pdf" message and > > additional line break from the RFC sample and the Tomcat stream. > > > > After some research I found the DefaultServlet Class where the stream for > > partial content and multi range requests are served. > > On Tomcat 6.0 at java\org\apache\catalina\servlets and on Tomcat 5.5 at > > container\catalina\src\share\org\apache\catalina\servlets > > > > The first thing that happens to make it work was the add of > > "useAcceptRanges" on the config file (web.xml) and the fix for it on > > Tomcat 6.0.x class source code on the SVN repository (thankyou). It really > > made difference because the HTTP header response must have "Accept-Ranges: > > bytes" string to allow clients make byte requests (at least Adobe Reader). > > > > The second thing is in the "copy" methods. There is a check for the > > "contentType" variable and for any reason the method that try to retrieve > > its value, before the call for "copy" method, is always returning null. > > So, in the if statement within the "
DO NOT REPLY [Bug 45978] New: Some brackets are not in jkstatus.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45978 Summary: Some brackets are not in jkstatus. Product: Tomcat Connectors Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: minor Priority: P2 Component: Common AssignedTo: dev@tomcat.apache.org ReportedBy: [EMAIL PROTECTED] Created an attachment (id=22704) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=22704) patch When the status worker displays worker information, one of the brackets that enclose the commands is not displayed as follows. S|E|R] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat trunk - changelog
Costin Manolache wrote: I never understood the use of the manual changelog - as opposed to svn log and good commit messages. Could we just use that ? that would be nice if we then could generate the 'changelog' to ship with the release. for an admin that is about to upgrade, it's much nicer to have the changelog to see what bugs got fixed, what changes were implemented, then have to scan the SVN repository. the changelog. the changelog is widely used by admins during upgrade scenarios best Filip Costin On Wed, Oct 8, 2008 at 4:24 PM, Filip Hanik - Dev Lists <[EMAIL PROTECTED]>wrote: I'd like for us to start using the changelog for trunk, we're losing a lot of changes being documented, not everything gets ported to 6.0 etc do you guys have any thoughts on this? 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 trunk - changelog
On Wed, 2008-10-08 at 21:45 -0700, Costin Manolache wrote: > I never understood the use of the manual changelog - as opposed to svn log > and good commit messages. > Could we just use that ? I don't see how it would be readable. The formatting is inconsistent, it would likely have no links, etc. OTOH, it obviously does the job of listing the changes. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat trunk - changelog
On Thu, Oct 9, 2008 at 9:18 AM, Filip Hanik - Dev Lists <[EMAIL PROTECTED]>wrote: > Costin Manolache wrote: > >> I never understood the use of the manual changelog - as opposed to svn log >> and good commit messages. >> Could we just use that ? >> > that would be nice if we then could generate the 'changelog' to ship with > the release. > for an admin that is about to upgrade, it's much nicer to have the > changelog to see what bugs got fixed, what changes were implemented, then > have to scan the SVN repository. > the changelog. the changelog is widely used by admins during upgrade > scenarios Just include the bug number and links in the commit message. Whatever you put in the CHANGES you can put in the commit log as well. I don't know if SVN supports templates - most likely it does. The formatting seems ok - it's not very different from the manual file - and shouldn't be very hard to write a script to change the layout. I've seen projects that generate the 'changelog' using automated tools, based on the source control system. The extra benefit is that better commit messages would make it easier to understand the changes when browsing the svn. Example: jsvn log -l 5 r699128 | markt | 2008-09-25 16:20:48 -0700 (Thu, 25 Sep 2008) | 1 line Partial fix for 45878. If we are happy with this approach for the spec JARs, extend it to the remaining Tomcat JARs. r699126 | markt | 2008-09-25 16:00:57 -0700 (Thu, 25 Sep 2008) | 1 line Update default year r698925 | markt | 2008-09-25 04:07:44 -0700 (Thu, 25 Sep 2008) | 1 line Add NOTICE file to uninstall section. r698892 | jfclere | 2008-09-25 02:29:23 -0700 (Thu, 25 Sep 2008) | 2 lines Use lastest tc-native version. r698629 | markt | 2008-09-24 09:21:25 -0700 (Wed, 24 Sep 2008) | 2 lines Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=45879 Move the NOTICE file to the install dir Costin > > best > Filip > > Costin >> >> On Wed, Oct 8, 2008 at 4:24 PM, Filip Hanik - Dev Lists >> <[EMAIL PROTECTED]>wrote: >> >> >> >>> I'd like for us to start using the changelog for trunk, we're losing a >>> lot >>> of changes being documented, not everything gets ported to 6.0 etc >>> do you guys have any thoughts on this? >>> >>> 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: Byte Serving and PDFs with the DefaultServlet
Hello Mark, you are right. The mime extension is not working on a case insensitive basis. Now my Tomcat 5.5 does byte serving with the web.xml portion below: pdf application/pdf PDF application/pdf Although this worked without the "else"s forced as in the previous e-mail sent, There is still the need of the "useAcceptRanges" stuff that appeared after Tomcat 6.018. Shouldn't mime type be case insensitive? Would this be a bug yet? As before should this be placed on bugzilla or is this just a configuration matter? Thankyou. Best regards, Antonio Vitor Elias Swaid Jr Technical Publications Development EMBRAER - São José dos Campos Fone: +55 12 3927-8364 Fax: +55 12 3927-3132 This message is intended solely for the use of its addressee and may contain privileged or confidential information. If you are not the addressee you should not distribute, copy or file this message. In this case, please notify the sender and destroy its contents immediately. Esta mensagem é para uso exclusivo de seu destinatário e pode conter informações privilegiadas e confidenciais. Se você não é o destinatário não deve distribuir, copiar ou arquivar a mensagem. Neste caso, por favor, notifique o remetente da mesma e destrua imediatamente a mensagem.
svn commit: r703238 - /tomcat/connectors/trunk/jk/native/common/jk_status.c
Author: rjung
Date: Thu Oct 9 12:39:02 2008
New Revision: 703238
URL: http://svn.apache.org/viewvc?rev=703238&view=rev
Log:
9BZ 45978: Fix status worker display broken by introducing
single lb member display.
Thanks to Eiji Takahashi for reporting this.
Modified:
tomcat/connectors/trunk/jk/native/common/jk_status.c
Modified: tomcat/connectors/trunk/jk/native/common/jk_status.c
URL:
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_status.c?rev=703238&r1=703237&r2=703238&view=diff
==
--- tomcat/connectors/trunk/jk/native/common/jk_status.c (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_status.c Thu Oct 9 12:39:02
2008
@@ -2221,7 +2221,7 @@
ajp_worker_t *aw = (ajp_worker_t *)swr->worker->worker_private;
if (mime == JK_STATUS_MIME_HTML) {
-jk_puts(s, "\n");
+jk_puts(s, "\n[");
jk_puts(s, "S");
if (!read_only) {
jk_puts(s, "|");
@@ -2235,8 +2235,8 @@
status_write_uri(s, p, "T", JK_STATUS_CMD_RECOVER,
JK_STATUS_MIME_UNKNOWN,
name, sub_name, 0, 0, "", l);
}
-jk_puts(s, "]");
}
+jk_puts(s, "]");
jk_puts(s, " ");
}
display_worker_ajp_details(s, p, aw, swr, lb, ms_min, ms_max, 0,
l);
@@ -2247,7 +2247,7 @@
ajp_worker_t *aw = (ajp_worker_t *)wr->worker->worker_private;
if (mime == JK_STATUS_MIME_HTML) {
-jk_puts(s, "\n");
+jk_puts(s, "\n[");
status_write_uri(s, p, "S", JK_STATUS_CMD_SHOW,
JK_STATUS_MIME_UNKNOWN,
name, sub_name, 0, 0, "", l);
if (!read_only) {
@@ -2262,8 +2262,8 @@
status_write_uri(s, p, "T", JK_STATUS_CMD_RECOVER,
JK_STATUS_MIME_UNKNOWN,
name, sub_name, 0, 0, "", l);
}
-jk_puts(s, "]");
}
+jk_puts(s, "]");
jk_puts(s, " ");
}
display_worker_ajp_details(s, p, aw, wr, lb, ms_min, ms_max,
0, l);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 45979] New: META-INF/context.xml does not replace conf/Catalina//[hostname]/ [appname].xml when war deployed
https://issues.apache.org/bugzilla/show_bug.cgi?id=45979 Summary: META-INF/context.xml does not replace conf/Catalina//[hostname]/ [appname].xml when war deployed Product: Tomcat 5 Version: 5.5.25 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: [EMAIL PROTECTED] I just discovered that if you update your META-INF/context.xml, create a war file, put it into a stopped tomcat container, and delete the old expanded war file contents - when tomcat starts - it does not replace the Catalina/[hostname]/[appname].xml file when the war file is deployed. It remains the file from the previous (now replaced) war file. I see this has come up before, and it was commented that that was a design decision. https://issues.apache.org/bugzilla/show_bug.cgi?id=32284#c8 I think that is wrong. Now, rather than having a self-contained application - if I need to specify something in the context.xml file - I can't just put it there, and allow my installer programs to just put the war file in the correct place in tomcat. Now, my installer utilities must be smart enough to go find and delete the Catalina/[hostname]/[appname].xml file every single time I make an update. Why should the onus be on my installers to do that job? I didn't even ask tomcat to put that file there in the first place. I put it in META-INF/context.xml. Tomcat copied it to the conf subfolder. And now Tomcat neglects to copy the updated file there. Additionally, the documentation http://tomcat.apache.org/tomcat-5.5-doc/config/context.html for this context.xml feature makes no mention of the fact that it simply copies the file once (and only once - never noting future changes) into the server conf folder. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 45978] Some brackets are not in jkstatus.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45978 Rainer Jung <[EMAIL PROTECTED]> changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Rainer Jung <[EMAIL PROTECTED]> 2008-10-09 12:39:28 PST --- Fixed. Thanks for closely following our changes. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 45979] META-INF/context.xml does not replace conf/Catalina//[hostname]/ [appname].xml when war deployed
https://issues.apache.org/bugzilla/show_bug.cgi?id=45979 Dan Armbrust <[EMAIL PROTECTED]> changed: What|Removed |Added CC||[EMAIL PROTECTED] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 45979] META-INF/context.xml does not replace conf/Catalina//[hostname]/ [appname].xml when war deployed
https://issues.apache.org/bugzilla/show_bug.cgi?id=45979 Remy Maucherat <[EMAIL PROTECTED]> changed: What|Removed |Added CC|[EMAIL PROTECTED] | --- Comment #1 from Remy Maucherat <[EMAIL PROTECTED]> 2008-10-09 12:46:56 PST --- Too bad, I don't care ... -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 45981] New: Missing temp directory never gets recreated
https://issues.apache.org/bugzilla/show_bug.cgi?id=45981 Summary: Missing temp directory never gets recreated Product: Tomcat 6 Version: 6.0.14 Platform: Macintosh OS/Version: Mac OS X 10.4 Status: NEW Severity: major Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: [EMAIL PROTECTED] It has been necessary when using some web applications in tomcat to remove everything in the work/ and temp/ directories before restarting. However, if the temp directory itself is removed it is not recreated causing web applications to throw java.io.IOExceptions when a user attempts to download a file. java.io.IOException: No such file or directory java.io.UnixFileSystem.createFileExclusively(Native Method) java.io.File.checkAndCreate(File.java:1704) java.io.File.createTempFile(File.java:1793) java.io.File.createTempFile(File.java:1830) Tomcat should be checking and recreating the temp directory if it is not there at start up. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 45981] Missing temp directory never gets recreated
https://issues.apache.org/bugzilla/show_bug.cgi?id=45981 Mark Thomas <[EMAIL PROTECTED]> changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #1 from Mark Thomas <[EMAIL PROTECTED]> 2008-10-09 14:56:44 PST --- You can't delete part of an installed application (in the case the temp directory) and expect it to continue to work. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 45979] META-INF/context.xml does not replace conf/Catalina//[hostname]/ [appname].xml when war deployed
https://issues.apache.org/bugzilla/show_bug.cgi?id=45979 --- Comment #2 from Mark Thomas <[EMAIL PROTECTED]> 2008-10-09 15:00:19 PST --- There is no need to add a committer as a cc to a bug. Doing this is considered extremely rude. We are all subscribed to the dev list and we all see every comment on every bug. The design decision isn't going to change but we can make the documentation clearer. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 45981] Missing temp directory never gets recreated
https://issues.apache.org/bugzilla/show_bug.cgi?id=45981 Sarah <[EMAIL PROTECTED]> changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Comment #2 from Sarah <[EMAIL PROTECTED]> 2008-10-09 15:02:06 PST --- Then either 1) the temp directory needs to clear itself out when tomcat is stopped/started. There are applications that do not work properly if this is not done (especially when dealing with jsp's). Or 2) Tomcat needs to check that all of it's directories are in place and fail to startup with an error if they aren't. There were no errors in the logs after restarting several times. This cost me nearly a day in debugging an issue that does not exist in my code but was caused by someone messing up the distribution and tomcat not noticing. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 45981] Missing temp directory never gets recreated
https://issues.apache.org/bugzilla/show_bug.cgi?id=45981 --- Comment #3 from Mark Thomas <[EMAIL PROTECTED]> 2008-10-09 15:25:59 PST --- re 1) The application that creates the files should be responsible for any necessary housekeeping. Tomcat can't make assumptions about what housekeeping is required. re 2) It isn't practical to test for every required file and library on startup. If Tomcat tried to use the temp directory and failed to log an error then if you provide enough details to reproduce the problem then an appropriate error message can be added. If it was web app code that tried to use temp and failed then the error handling needs to be added there. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 45979] META-INF/context.xml does not replace conf/Catalina//[hostname]/ [appname].xml when war deployed
https://issues.apache.org/bugzilla/show_bug.cgi?id=45979 --- Comment #3 from Dan Armbrust <[EMAIL PROTECTED]> 2008-10-09 15:31:48 PST --- Well, that explains his response, which I thought was rude :) I had no intention on being rude. I only added him because he specifically said that he made the design decision in the other bug report, and I thought he might have some useful input as to why this should or shouldn't be changed. And I know that I certainly don't have time to pay attention to ever e-mail that comes into my bulk e-mail bins -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r703284 - in /tomcat/site/trunk: docs/security-4.html docs/security-5.html xdocs/security-4.xml xdocs/security-5.xml
Author: markt Date: Thu Oct 9 15:39:48 2008 New Revision: 703284 URL: http://svn.apache.org/viewvc?rev=703284&view=rev Log: Update with details of CVE-2008-3271 Modified: tomcat/site/trunk/docs/security-4.html tomcat/site/trunk/docs/security-5.html tomcat/site/trunk/xdocs/security-4.xml tomcat/site/trunk/xdocs/security-5.xml Modified: tomcat/site/trunk/docs/security-4.html URL: http://svn.apache.org/viewvc/tomcat/site/trunk/docs/security-4.html?rev=703284&r1=703283&r2=703284&view=diff == --- tomcat/site/trunk/docs/security-4.html (original) +++ tomcat/site/trunk/docs/security-4.html Thu Oct 9 15:39:48 2008 @@ -618,6 +618,22 @@ +low: Information disclosure + http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3271";> + CVE-2008-3271 + + + +https://issues.apache.org/bugzilla/show_bug.cgi?id=25835";> +Bug 25835 can, in rare circumstances - this has only been reproduced +using a debugger to force a particular processing sequence for two threads - +allow a user from a non-premitted IP address to gain access to a context +that is protected with a valve that extends RemoteFilterValve. This includes +the standard RemoteAddrValve and RemoteHostValve implementations. + +Affects: 4.1.0-4.1.31 + + important: Information disclosure http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1858";> CVE-2007-1858 Modified: tomcat/site/trunk/docs/security-5.html URL: http://svn.apache.org/viewvc/tomcat/site/trunk/docs/security-5.html?rev=703284&r1=703283&r2=703284&view=diff == --- tomcat/site/trunk/docs/security-5.html (original) +++ tomcat/site/trunk/docs/security-5.html Thu Oct 9 15:39:48 2008 @@ -899,6 +899,45 @@ + +Fixed in Apache Tomcat 5.5.1 + + + + + + + + + +low: Information disclosure + http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3271";> + CVE-2008-3271 + + + +https://issues.apache.org/bugzilla/show_bug.cgi?id=25835";> +Bug 25835 can, in rare circumstances - this has only been reproduced +using a debugger to force a particular processing sequence for two threads - +allow a user from a non-premitted IP address to gain access to a context +that is protected with a valve that extends RemoteFilterValve. This includes +the standard RemoteAddrValve and RemoteHostValve implementations. + +Affects: 5.5.0 (5.0.x unknown) + + + + + + + + + + + + + + Not a vulnerability in Tomcat Modified: tomcat/site/trunk/xdocs/security-4.xml URL: http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/security-4.xml?rev=703284&r1=703283&r2=703284&view=diff == --- tomcat/site/trunk/xdocs/security-4.xml (original) +++ tomcat/site/trunk/xdocs/security-4.xml Thu Oct 9 15:39:48 2008 @@ -296,6 +296,19 @@ +low: Information disclosure + http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3271";> + CVE-2008-3271 + +https://issues.apache.org/bugzilla/show_bug.cgi?id=25835";> +Bug 25835 can, in rare circumstances - this has only been reproduced +using a debugger to force a particular processing sequence for two threads - +allow a user from a non-premitted IP address to gain access to a context +that is protected with a valve that extends RemoteFilterValve. This includes +the standard RemoteAddrValve and RemoteHostValve implementations. + +Affects: 4.1.0-4.1.31 + important: Information disclosure http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1858";> CVE-2007-1858 Modified: tomcat/site/trunk/xdocs/security-5.xml URL: http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/security-5.xml?rev=703284&r1=703283&r2=703284&view=diff == --- tomcat/site/trunk/xdocs/security-5.xml (original) +++ tomcat/site/trunk/xdocs/security-5.xml Thu Oct 9 15:39:48 2008 @@ -385,6 +385,21 @@ Affects: 5.0.0-5.0.30, 5.5.0-5.5.6 + +low: Information disclosure + http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3271";> + CVE-2008-3271 + +https://issues.apache.org/bugzilla/show_bug.cgi?id=25835";> +Bug 25835 can, in rare circumstances - this has only been reproduced +using a debugger to force a particular processing sequence for two threads - +allow a user from a non-premitted IP address to gain access to a context +that is protected with a valve that extends RemoteFilterValve. This includes +the standard RemoteAddrValve and RemoteHostValve implementations. + +Affects: 5.5.0 (5.0.x unknown) + + JavaMail information disclosure http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1754";> ---
DO NOT REPLY [Bug 45979] META-INF/context.xml does not replace conf/Catalina//[hostname]/ [appname].xml when war deployed
https://issues.apache.org/bugzilla/show_bug.cgi?id=45979 --- Comment #4 from Dan Armbrust <[EMAIL PROTECTED]> 2008-10-09 15:44:25 PST --- WRT the design, I do not know all of the other use cases. I expect that this decision was arrived at to simplify complexity, or other reasonable reasons. But from my use case, the behaviour certainly violates the Principals of Least Surprises. It seems that if Tomcat had a way to know that it placed a copy of the context.xml file into the conf subfolder, then it would be trivial to have it automatically replace it again, whenever it re-expands the war file. Yes? All that follows is based on what may be faulty guesses about how things currently work: So the real issue becomes knowing if config file was placed in the conf subfolder by tomcat, or by an administrator? Couldn't Tomcat just place a flag (even just a comment - rather hackish but effective) into the xml file when it copies it? Then later, check for the presence of that flag to determine if it should overwrite it when redeploying a war file? No flag - current behaviour. Flag - overwrite the file with the one from the war. If the behaviour stays as it - is seems like tomcat should be throwing out a warning when it will be ignoring a context.xml file found in a war file, because one already existed in the conf subfolder. Otherwise, users can run into all sorts of hard to track when the file they think is being used, isn't. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[SECURITY] CVE-2008-3271 - Apache Tomcat information disclosure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 CVE-2008-3271: Tomcat information disclosure vulnerability Severity: Low Vendor: The Apache Software Foundation Versions Affected: Tomcat 4.1.0 to 4.1.31 Tomcat 5.5.0 Tomcat 6.0.x is not affected The unsupported Tomcat 3.x, 4.0.x and 5.0.x versions may be also affected Description: Bug 25835 (https://issues.apache.org/bugzilla/show_bug.cgi?id=25835) can, in very rare circumstances, permit a user from a non-permitted IP address to gain access to a context protected with a valve that extends RemoteFilterValve. Mitigation: Upgrade to: 4.1.32 or later 5.5.1 or later 6.0.0 or later Example: This has only been reproduced using a debugger to force a particular processing sequence across two threads. 1. Set a breakpoint right after the place where a value is to be entered in the instance variable of regexp (search:org.apache.regexp.CharacterIterator). 2. Send a request from the IP address* which is not permitted. (stopped at the breakpoint) *About the IP address which is not permitted. The character strings length of the IP address which is set in RemoteAddrValve must be same. 3. Send a request from the IP address which was set in RemoteAddrValve. (stopped at the breakpoint) In this way, the instance variable is to be overwritten here. 4. Resume the thread which is processing the step 2 above. 5. The request from the not permitted IP address will succeed. Credit: This issue was discovered by Kenichi Tsukamoto (Development Dept. II, Application Management Middleware Div., FUJITSU LIMITED) and reported to the Tomcat security team via JPCERT. References: http://tomcat.apache.org/security.html Mark Thomas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjuibsACgkQb7IeiTPGAkO33wCgiBY0nBdTaXBC8oPoHqMWH4mt OtgAmQHjgnxg0vKKSp43vez8XaBIZpOj =9Z/F -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r703286 - /tomcat/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
Author: markt
Date: Thu Oct 9 15:58:03 2008
New Revision: 703286
URL: http://svn.apache.org/viewvc?rev=703286&view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=45977
Trivial comment clean up. No plans to backport this.
Modified:
tomcat/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
Modified: tomcat/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java?rev=703286&r1=703285&r2=703286&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java Thu Oct
9 15:58:03 2008
@@ -351,8 +351,6 @@
Response response)
throws Exception {
-// XXX the processor needs to set a correct scheme and port prior to
this point,
-// in ajp13 protocols dont make sense to get the port from the
connector..
// XXX the processor may have set a correct scheme and port prior to
this point,
// in ajp13 protocols dont make sense to get the port from the
connector...
// otherwise, use connector configuration
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 45977] Duplicate comment in code - CoyoteAdapter.java
https://issues.apache.org/bugzilla/show_bug.cgi?id=45977 Mark Thomas <[EMAIL PROTECTED]> changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Mark Thomas <[EMAIL PROTECTED]> 2008-10-09 15:58:39 PST --- I have fixed this in trunk. I don't intend proposing it for back port to 6.0.x, 5.5.x or 4.1.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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 #19 from David Lewis <[EMAIL PROTECTED]> 2008-10-09 17:07:29 PST --- Can anyone confirm that this fix is included with the recent Tomcat 5.5.27 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 45983] New: catalina.sh fails to start tomcat if conf/logging.properties is missing
https://issues.apache.org/bugzilla/show_bug.cgi?id=45983 Summary: catalina.sh fails to start tomcat if conf/logging.properties is missing Product: Tomcat 6 Version: 6.0.18 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: [EMAIL PROTECTED] JRE: Sun 1.6.0_10 Upon upgrading from 6.0.13 to 6.0.18 I couldn't get my Tomcat instances to start. I run 11 separate Tomcat instances on the same server all from the same CATALINA_HOME by specifying different a different CATALINA_BASE for each. After upgrading to 6.0.18 I could only get the following: Exception in thread "main" java.lang.NoClassDefFoundError: Caused by: java.lang.ClassNotFoundException: at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:307) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:252) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320) Could not find the main class: . Program will exit. I discovered that it was because I don't have logging.properties in CATALINA_BASE/conf/ and by putting one there (or simply creating a blank one) it would start OK. Without logging.properties, catalina.sh builds the start command to be (obtained by substituting echo for exec inside the "run" section, edited for bugzilla): /bin/java -Djava.endorsed.dirs=/endorsed -classpath :/bin/bootstrap.jar -Dcatalina.base= -Dcatalina.home= -Djava.io.tmpdir=/temp org.apache.catalina.startup.Bootstrap start And with logging.properties the start command becomes: /bin/java -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.util.logging.config.file=/conf/logging.properties -Djava.endorsed.dirs=/endorsed -classpath :/bin/bootstrap.jar -Dcatalina.base= -Dcatalina.home= -Djava.io.tmpdir=/temp org.apache.catalina.startup.Bootstrap start I can't suggest why this causes the JVM to have ClassLoader issues and the interesting thing is that if I copy and paste the exact start command of the no-logging.properties version (above) straight into the command-line then it starts so it's only when doing the exec inside catalina.sh that it fails. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat trunk - changelog
Costin Manolache wrote: On Thu, Oct 9, 2008 at 9:18 AM, Filip Hanik - Dev Lists <[EMAIL PROTECTED]>wrote: Costin Manolache wrote: I never understood the use of the manual changelog - as opposed to svn log and good commit messages. Could we just use that ? that would be nice if we then could generate the 'changelog' to ship with the release. for an admin that is about to upgrade, it's much nicer to have the changelog to see what bugs got fixed, what changes were implemented, then have to scan the SVN repository. the changelog. the changelog is widely used by admins during upgrade scenarios Just include the bug number and links in the commit message. Whatever you put in the CHANGES you can put in the commit log as well. Well I don't agree because in several case a real fix only appears after several commits a changelog entry will be a summary of those. Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
