url-pattern in filter-mapping does not work!!!
Hi all, I am using JDeveloper to develop a web application, something I want to do, is to filter all jsp pages that starts with res using the filter myfilter, snippet of my web.xml look like: filter filter-namemyfilter/filter-name filter-classmyfilter/filter-class /filter ... filter-mapping filter-namemyfilter/filter-name url-pattern/res*/url-pattern /filter-mapping Now, the filter mechanism works perfectly using the development OC4J containter from oracle, but... when I deploy the war file to tomcat, it seem it didnt recognize the pattern correctly... and acts as if there is no filter at all, and the filter does not get called!! I also tried url-pattern/res*.jsp/url-pattern and same results. here is a snippet from the application log: 2003-11-15 23:04:29 StandardContext[/myapp]: Mapping contextPath='/reserveit' with requestURI='/myapp/resWelcome.jsp' and relativeURI='/resWelcome.jsp' 2003-11-15 23:04:29 StandardContext[/myapp]: Trying exact match 2003-11-15 23:04:29 StandardContext[/myapp]: Trying prefix match 2003-11-15 23:04:29 StandardContext[/myapp]: Trying extension match 2003-11-15 23:04:29 StandardContext[/myapp]: Mapped to servlet 'jsp' with servlet path '/resWelcome.jsp' and path info 'null' and update=true any help in this case is really really appreciated... thanks in advance.
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteConnector.java CoyoteRequest.java LocalStrings.properties
Bill Barker wrote:
remm2003/11/15 01:45:02
Modified:catalina/src/share/org/apache/coyote/tomcat5
CoyoteConnector.java CoyoteRequest.java
LocalStrings.properties
Log:
- Add a limit to the size of a POST which will be processed using
getParameter
(which does allocate a significant amount of objects).
int len = getContentLength();
if (len 0) {
+if (len ((CoyoteConnector) connector).getMaxPostSize()) {
+log(sm.getString(coyoteRequest.postTooLarge));
+return;
+}
try {
byte[] formData = null;
if (len CACHED_POST_LEN) {
I'm -1 on this. It gives the Servlet no indication that anything is wrong,
and leaves junk in the input stream for the next keep-alive request. I
think that it would be better to handle this in the Adaptor's
postParseRequest method.
This is a security issues, so I'll have to ignore your -1, since you
give no alternative solution.
Remy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteConnector.java CoyoteRequest.java LocalStrings.properties
Bill Barker wrote: I'm -1 on this. It gives the Servlet no indication that anything is wrong, and leaves junk in the input stream for the next keep-alive request. I think that it would be better to handle this in the Adaptor's postParseRequest method. I disagree: the problem with this is that we allocate one array right away based on content-length, not that there's a big upload (which is fine). Obviously, keep-alive is not an option in that case (and Tomcat will attempt to swallow any remaining output). Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote Response.java
[EMAIL PROTECTED] wrote: billbarker2003/11/15 21:20:23 Modified:coyote/src/java/org/apache/coyote Response.java Log: Restore the ability to explicitly set the charset to iso-latin-1. Now, you won't get the charset unless you ask for it (so no more Content-Type: image/gif; charset=iso-8859-1). However, if you call response.setCharacterEncoding(iso-9959-1), you now get it in the respose. Constants.DEFAULT_CHARACTER_ENCODING is equal to iso-9959-1, so I do not understand how my patch prenvented setting the charset to iso-latin-1. At this point, if we could avoid gratuitous fancy fixes, it would be a lot better ... Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24005] - various issues with values of live properties
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24005. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24005 various issues with values of live properties --- Additional Comments From [EMAIL PROTECTED] 2003-11-16 12:12 --- ok, here's a recipe to reproduce issue 2 (tested with 4.1.29): - install tomcat - enable write access on webdav - connect Microsoft webfolder - copy a file with no extension to /webdav/ (this causes a PUT request with not content-type header) - PROPFIND on the resulting resource - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23999] - Litmus test case mkcol_with_body fails
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23999. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23999 Litmus test case mkcol_with_body fails [EMAIL PROTECTED] changed: What|Removed |Added Version|4.1.27 |4.1.29 --- Additional Comments From [EMAIL PROTECTED] 2003-11-16 12:22 --- I don't understand this comment. Can we please keep the issue of what is a bug or not, and whether and when it will be adressed separate? The Litmus test suite is a extremely useful tool to verify basic RFC2518 conformance. If it reports a FAIL during it's basic test suite, this is a problem, and thus should be present in the issues database. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24735] New: - DAV:displayname handling
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24735. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24735 DAV:displayname handling Summary: DAV:displayname handling Product: Tomcat 4 Version: 4.1.29 Platform: Other URL: http://greenbytes.de/tech/webdav/rfc2518.html#rfc.sectio n.13.2 OS/Version: Other Status: NEW Severity: Minor Priority: Other Component: Servlets:WebDAV AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] DAV:displayname currently defaults to the last path segment (minus escaping). This doesn't seem to be particulary useful as description of the resource. It seems that -- in absence of a an explicit description -- it is better not to return the property at all (that's how Apache mod_dav behaves). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24001] - LOCK: parsing of Timeout request header
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24001. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24001 LOCK: parsing of Timeout request header --- Additional Comments From [EMAIL PROTECTED] 2003-11-16 13:56 --- Created an attachment (id=9131) Patch for TC5 to fix this bug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24006] - PROPPATCH vs Allow header
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24006. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24006 PROPPATCH vs Allow header --- Additional Comments From [EMAIL PROTECTED] 2003-11-16 14:18 --- Procedural question: this was reported against Tomcat4, but was resolved in Tomcat5. Shouldn't the issue be left open? What's the general policy about reporting/resolving issues in Tomcat4 and Tomcat5? If the problem applies to both, should it reported twice? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24368] - Unhandled Exception in PersistentManagerBase.processExpires() kills PersistentManager thread
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24368. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24368 Unhandled Exception in PersistentManagerBase.processExpires() kills PersistentManager thread [EMAIL PROTECTED] changed: What|Removed |Added Severity|Major |Enhancement --- Additional Comments From [EMAIL PROTECTED] 2003-11-16 14:19 --- Point taken, but a severity of 'major' is no longer appropriate. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Bug report for Tomcat 3 [2003/11/16]
+---+ | 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 | | | | | | | | 258|Unc|Nor|2000-11-27|response.SendRedirect() resets/destroys Cookies th| | 2350|Ver|Nor|2001-06-27|ServletConfig.getInitParameter() requires url-patt| | 2478|Opn|Cri|2001-07-06|Passing Session variables between JSP's and Servle| | 4551|Opn|Nor|2001-10-31|Ctx( /tt01 ): IOException in: R( /tt01 + /com/abc/| | 4980|New|Min|2001-11-20|Startup message indicates incorrect log file | | 4994|New|Nor|2001-11-21|Tomcat needs a mechanism for clean and certain shu| | 5064|New|Cri|2001-11-25|Socket write error when include files is more than| | 5108|New|Maj|2001-11-26|Docs for Tomcat 3.2.x appear to be for Tomcat 3.3 | | 5137|New|Nor|2001-11-27|Null pointer in class loader after attempting to r| | 5160|Unc|Maj|2001-11-28|'IllegalStateException' | | 5331|New|Nor|2001-12-09|getPathInfo vs URL normalization | | 5510|New|Blk|2001-12-19|How to call ejb deployed in JBoss from Tomcat serv| | 5756|New|Nor|2002-01-08|jspc.bat exits with wrong ERRORLEVEL | | 5797|New|Nor|2002-01-10|UnCatched ? StringIndexOutOfBoundsException: Strin| | 6027|New|Maj|2002-01-25|Tomcat Automatically shuts down as service | | 6168|New|Blk|2002-02-01|IllegalStateException | | 6451|New|Cri|2002-02-14|Stackoverflow | | 6478|New|Enh|2002-02-14|Default Tomcat Encoding | | 6488|Ver|Maj|2002-02-15|Error: 304. Apparent bug in default ErrorHandler c| | 6648|New|Nor|2002-02-25|jakarta-servletapi build with java 1.4 javadoc err| | 6702|New|Cri|2002-02-27|win 2k services not working | | 6796|New|Cri|2002-03-01|Tomcat dies periodically | | 6989|New|Maj|2002-03-08|Unable to read tld file during parallel JSP compil| | 7008|Opn|Maj|2002-03-10|facade.HttpServletRequestFacade.getParameter(HttpS| | 7013|New|Cri|2002-03-10|Entering a servlet path with non-ISO8859-1 charact| | 7227|New|Nor|2002-03-19|error-code directive don't work | | 7236|New|Blk|2002-03-19|Permission denied to do thread.stop | | 7626|New|Nor|2002-03-29|classloader not working properly | | 7652|New|Cri|2002-04-01|Tomcat stalls periodically| | 7762|New|Enh|2002-04-05|stdout logfile handling | | 7785|New|Blk|2002-04-06|tomcat bug in context reloading | | 7789|New|Maj|2002-04-06|JSP Cookie Read/Write Fails With DNS Names| | 7863|New|Maj|2002-04-09|I have a problem when running Tomcat with IIS | | 8154|New|Nor|2002-04-16|logrotate script in RPM rotates non-existing file | | 8187|New|Cri|2002-04-17|Errors when Tomcat used with MS Access database | | 8239|New|Cri|2002-04-18|Resource temporary unavailable| | 8263|New|Cri|2002-04-18|url-pattern easy to circumvent| | 8634|New|Nor|2002-04-30|no way to specify different modules.xml file | | 8992|New|Blk|2002-05-10|IE6/XP: Limitation of POST Area within HTTP reques| | 9086|New|Enh|2002-05-14|NPE org.apache.tomcat.core.ServerSession.setAttrib| | 9250|New|Maj|2002-05-20|outOfMemoryError | | 9367|New|Maj|2002-05-23|HttpSessionBindingEvent not thrown for HttpSession| | 9390|New|Nor|2002-05-24|jasper compilation error in tomcat| | 9480|New|Nor|2002-05-29|Data connection pooling | | 9607|New|Maj|2002-06-04|precompile JSP| | 9737|New|Nor|2002-06-10|ArrayIndexOutOfBoundsException when sending just p| |1|New|Cri|2002-06-19|IOException Broken Pipe when authenticating JDBCRe| |10039|New|Nor|2002-06-20|TimeStamp will not work correctly.| |10047|New|Cri|2002-06-20|IllegalStateException | |10202|New|Maj|2002-06-25|Tomcat is not responding in time | |10357|Unc|Blk|2002-06-30|java.lang.IllegalArgumentException: Short Read|
Bug report for Tomcat 4 [2003/11/16]
+---+ | 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 | | | | | | | | 218|Unc|Nor|2000-11-02|IIS in-process tomcat BugRat Report#333 | | 3098|Opn|Maj|2001-08-11|RequestDispatcher on relative (to request path) | | 3614|Opn|Nor|2001-09-14|bug in manager webapp | | 3755|Opn|Nor|2001-09-20|freezes at shutdown | | 3888|Opn|Blk|2001-09-30|WebappClassLoader: Lifecycle error : CL stopped | | 4091|Opn|Nor|2001-10-11|custom host with unpackWARs=true don't expand wa| | 4138|Opn|Nor|2001-10-12|Processor threads have inconsistent ClassLoader st| | 4350|Ass|Nor|2001-10-22|SSLAuthenticator did not associate SSO session| | 4352|Ass|Nor|2001-10-22|JDBCRealm does not work with CLIENT-CERT auth-meth| | 5329|New|Nor|2001-12-08|NT Service exits startup before Tomcat is finished| | 5598|Opn|Maj|2001-12-27|(JSP Problem) RequestDispatcher doesn't include HT| | 5704|Ass|Maj|2002-01-05|CgiServlet corrupting images? | | 5715|Opn|Nor|2002-01-07|response.setContentType() in Filter.doFilter not c| | 5759|Opn|Maj|2002-01-09|CGI servlet mapping by extension *.cgi does not wo| | 5762|Opn|Maj|2002-01-09|CGI servlet misses to include port number in HTTP_| | 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| | 5858|New|Enh|2002-01-15|Add tomcat dir to java.library.path | | 5952|Opn|Nor|2002-01-22|Refence to $JAVACMD in tomcat.conf incorrect in R| | 5985|New|Enh|2002-01-23|Tomcat should perform a more restrictive validatio| | 6218|Opn|Nor|2002-02-04|Relative links broken for servlets| | 6229|New|Enh|2002-02-04|Need way to specify where to write catalina.out | | 6399|New|Nor|2002-02-12|unknown protocol: https | | 6408|New|Enh|2002-02-12|Starting tomcat from a cygwin bash shell using 'st| | 6582|New|Min|2002-02-20|Sample code does not match behavior | | 6600|Opn|Enh|2002-02-20|enodeURL adds 'jsession' when 'isRequestedSessionI| | 6614|New|Enh|2002-02-21|Have Bootstrap and StandardClassLoader use the sam| | 6649|New|Nor|2002-02-25|jakarta-servletapi-4 build using java 1.4 javadoc | | 6659|New|Nor|2002-02-25|HttpUtils.getRequestURL gives incorrect URL with w| | 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 | | 7080|New|Maj|2002-03-13|Interbase JDBCRealm - Bug # 5564 - Have a safe fix| | 7190|New|Nor|2002-03-18|GenericServlet spurious log's in init(), destroy()| | 7207|New|Nor|2002-03-18|Redeployment Problem under Tomcat 4.0.2 | | 7360|New|Nor|2002-03-22|res-sharing-scope not supported | | 7366|New|Enh|2002-03-22|ISAPI Redirector Replacement | | 7374|New|Enh|2002-03-22|Apache Tomcat/4.0.1 message on standard output| | 7506|New|Nor|2002-03-27|Reading InputStream returned in the following sena| | 7571|New|Nor|2002-03-28|DataInputStream readLong() Problem| | 7588|New|Nor|2002-03-28|Session cannot be established if there are multipl| | 7676|New|Enh|2002-04-02|Allow name property to use match experssions in h| | 7689|New|Min|2002-04-02|Performance problem with Xerces parser| | 7702|New|Enh|2002-04-03|[PATCH] Speed up Tomcat a tiny bit| | 7723|New|Enh|2002-04-03|[patch] additional factory for org.apache.naming.f| | 7831|New|Nor|2002-04-08|[PATCH] JNDIRealm does not work with CLIENT-CERT a| | 7880|Ver|Cri|2002-04-09|If a TLV flags flags an error during the translati| | 8026|New|Enh|2002-04-12|Exceptions in StandardHostDeployer.addChild are lo| | 8079|New|Enh|2002-04-15|Tomcat cannot start if appBase directory is access| | 8100|New|Maj|2002-04-15|Session Tracking and HttpURLConnection| | 8200|New|Nor|2002-04-17|include (PageContext) does not throw IOException i| | 8217|New|Maj|2002-04-17|Documentation references workers. prefix| |
Bug report for Watchdog [2003/11/16]
+---+ | 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| +-+---+---+--+--+ | Total 14 bugs | +---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24005] - various issues with values of live properties
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24005. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24005 various issues with values of live properties --- Additional Comments From [EMAIL PROTECTED] 2003-11-16 16:54 --- I have just check this with both TC4 and TC5 and the content type header is not returned. I have been having problems with the MS webfolders so I have been using telnet and I am 100% certain that the content-type header is not included in the response to HEAD in the circumstances you describe in 2. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/servlets WebdavServlet.java
Sorry, just spotted a silly error in my patch. The line
methodsAllowed.append(PROPFIND, );
in determineMethodsAllowed() should have been
methodsAllowed.append(, PROPFIND);
Grateful if one of the committers could fix this.
Again, apologies.
Mark
On Friday, November 14, 2003 10:16 AM, [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]
wrote:
remm2003/11/14 02:16:22
Modified:catalina/src/share/org/apache/catalina/servlets
WebdavServlet.java
Log:
- Allow header handling.
- Bug 24006, submitted by Mark Thomas.
Revision ChangesPath
1.6 +64 -31jakarta-tomcat-
catalina/catalina/src/share/org/apache/catalina/servlets/WebdavServlet.java
Index: WebdavServlet.java
===
RCS file: /home/cvs/jakarta-tomcat-
catalina/catalina/src/share/org/apache/catalina/servlets/WebdavServlet.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- WebdavServlet.java 6 Oct 2003 08:05:46 - 1.5
+++ WebdavServlet.java 14 Nov 2003 10:16:22 - 1.6
@@ -338,11 +338,8 @@
protected void doOptions(HttpServletRequest req, HttpServletResponse
resp)
throws ServletException, IOException {
-String path = getRelativePath(req);
-
resp.addHeader(DAV, 1,2);
-String methodsAllowed = null;
-
+
// Retrieve the resources
DirContext resources = getResources();
@@ -351,28 +348,10 @@
return;
}
-boolean exists = true;
-Object object = null;
-try {
-object = resources.lookup(path);
-} catch (NamingException e) {
-exists = false;
-}
-
-if (!exists) {
-methodsAllowed = OPTIONS, MKCOL, PUT, LOCK;
-resp.addHeader(Allow, methodsAllowed);
-return;
-}
-
-methodsAllowed = OPTIONS, GET, HEAD, POST, DELETE, TRACE,
-+ PROPFIND, PROPPATCH, COPY, MOVE, LOCK, UNLOCK;
-if (!(object instanceof DirContext)) {
-methodsAllowed += , PUT;
-}
-
-resp.addHeader(Allow, methodsAllowed);
+StringBuffer methodsAllowed = determineMethodsAllowed(resources,
+ req);
+resp.addHeader(Allow, methodsAllowed.toString());
resp.addHeader(MS-Author-Via, DAV);
}
@@ -385,6 +364,19 @@
throws ServletException, IOException {
if (!listings) {
+// Retrieve the resources
+DirContext resources = getResources();
+
+if (resources == null) {
+resp.sendError
(HttpServletResponse.SC_INTERNAL_SERVER_ERROR);
+return;
+}
+
+// Get allowed methods
+StringBuffer methodsAllowed = determineMethodsAllowed
(resources,
+ req);
+
+resp.addHeader(Allow, methodsAllowed.toString());
resp.sendError(WebdavStatus.SC_METHOD_NOT_ALLOWED);
return;
}
@@ -649,7 +641,7 @@
return;
}
-resp.sendError(HttpServletResponse.SC_METHOD_NOT_ALLOWED);
+resp.sendError(HttpServletResponse.SC_NOT_IMPLEMENTED);
}
@@ -697,6 +689,12 @@
// Can't create a collection if a resource already exists at the
given
// path
if (exists) {
+// Get allowed methods
+StringBuffer methodsAllowed = determineMethodsAllowed
(resources,
+ req);
+
+resp.addHeader(Allow, methodsAllowed.toString());
+
resp.sendError(WebdavStatus.SC_METHOD_NOT_ALLOWED);
return;
}
@@ -2566,6 +2564,42 @@
return creationDateValue.toString();
}
+/**
+ * Determines the methods normally allowed for the resource.
+ *
+ */
+private StringBuffer determineMethodsAllowed(DirContext resources,
+ HttpServletRequest req) {
+
+StringBuffer methodsAllowed = new StringBuffer();
+boolean exists = true;
+Object object = null;
+try {
+String path = getRelativePath(req);
+
+object = resources.lookup(path);
+} catch (NamingException e) {
+exists = false;
+}
+
+if (!exists) {
+methodsAllowed.append(OPTIONS, MKCOL, PUT, LOCK);
+return methodsAllowed;
+}
+
+
DO NOT REPLY [Bug 24006] - PROPPATCH vs Allow header
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24006. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24006 PROPPATCH vs Allow header --- Additional Comments From [EMAIL PROTECTED] 2003-11-16 17:19 --- When I have fixed all the webdav issues, I'll put them all together into a combined TC4 patch. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24005] - various issues with values of live properties
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24005. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24005 various issues with values of live properties --- Additional Comments From [EMAIL PROTECTED] 2003-11-16 17:28 --- Maybe that's correct for HEAD, but I was doing a PROPFIND. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24006] - PROPPATCH vs Allow header
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24006. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24006 PROPPATCH vs Allow header --- Additional Comments From [EMAIL PROTECTED] 2003-11-16 17:30 --- Sounds great, thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteConnector.java CoyoteRequest.java LocalStrings.properties
Bill Barker wrote: I'm -1 on this. It gives the Servlet no indication that anything is wrong, and leaves junk in the input stream for the next keep-alive request. I think that it would be better to handle this in the Adaptor's postParseRequest method. One last thing I forgot: you can't do it beforehand, because you don't know if the servlet is going to use getParameterXXX. So I don't agree on putting this check in postParseRequest. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteRequest.java
remm2003/11/16 13:05:43
Modified:catalina/src/share/org/apache/coyote/tomcat5
CoyoteRequest.java
Log:
- Revert my patch for now, but I'll reaply it tomorrow before tagging (since a fix
for the underlying issue is obviously needed) if I don't
get a convincing use case as to why it is bad :)
Revision ChangesPath
1.20 +4 -9
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java
Index: CoyoteRequest.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- CoyoteRequest.java15 Nov 2003 20:28:37 - 1.19
+++ CoyoteRequest.java16 Nov 2003 21:05:43 - 1.20
@@ -2320,11 +2320,6 @@
int len = getContentLength();
if (len 0) {
-int maxPostSize = ((CoyoteConnector) connector).getMaxPostSize();
-if ((maxPostSize 0) (len maxPostSize)) {
-log(sm.getString(coyoteRequest.postTooLarge));
-return;
-}
try {
byte[] formData = null;
if (len CACHED_POST_LEN) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 12196] - request.getRemoteUser() returns null for AJP request with remote username
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12196. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12196 request.getRemoteUser() returns null for AJP request with remote username --- Additional Comments From [EMAIL PROTECTED] 2003-11-16 21:08 --- I was using Tomcat 4.1.24 with tomcatAuthentication=false just fine. I tried 4.1.29 with exactly the same configuration and getRemoteUser() returned null! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote Response.java
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Sunday, November 16, 2003 3:05 AM Subject: Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote Response.java [EMAIL PROTECTED] wrote: billbarker2003/11/15 21:20:23 Modified:coyote/src/java/org/apache/coyote Response.java Log: Restore the ability to explicitly set the charset to iso-latin-1. Now, you won't get the charset unless you ask for it (so no more Content-Type: image/gif; charset=iso-8859-1). However, if you call response.setCharacterEncoding(iso-9959-1), you now get it in the respose. Constants.DEFAULT_CHARACTER_ENCODING is equal to iso-9959-1, so I do not understand how my patch prenvented setting the charset to iso-latin-1. At this point, if we could avoid gratuitous fancy fixes, it would be a lot better ... If I explicitly call response.setCharacterEncoding(iso-8859-1), it means I expect that the charset will be in the Content-Type header. If it is not sent, then non-western-european browsers are likely to mangle my page by using whatever their default encoding is. Of course, iso-latin-1 is just a standard alias for iso-8859-1. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteConnector.java CoyoteRequest.java LocalStrings.properties
- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Sunday, November 16, 2003 2:34 AM
Subject: Re: cvs commit:
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5
CoyoteConnector.java CoyoteRequest.java LocalStrings.properties
Bill Barker wrote:
I'm -1 on this. It gives the Servlet no indication that anything is
wrong,
and leaves junk in the input stream for the next keep-alive request. I
think that it would be better to handle this in the Adaptor's
postParseRequest method.
I disagree: the problem with this is that we allocate one array right
away based on content-length, not that there's a big upload (which is
fine).
The Adaptor can check for this:
if(POST.equalsIgnoreCase(request.getMethod())
application/x-www-form-urlencoded.equals(contentType)
request.getContentLength() connector.getMaxPostSize()) {
response.setStatus(413);
response.setMessage(POST Body exceeds maximum);
return false;
}
Obviously, keep-alive is not an option in that case (and Tomcat will
attempt to swallow any remaining output).
Remy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message is intended only for the use of the person(s) listed above as the
intended recipient(s), and may contain information that is PRIVILEGED and
CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or
distribute this message or any attachment. If you received this communication in
error, please notify us immediately by e-mail and then delete all copies of this
message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the
Internet is not secure. Do not send confidential or sensitive information, such as
social security numbers, account numbers, personal identification numbers and
passwords, to us via ordinary (unencrypted) e-mail.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteConnector.java CoyoteRequest.java LocalStrings.properties
Bill Barker wrote:
Bill Barker wrote:
I'm -1 on this. It gives the Servlet no indication that anything is
wrong,
and leaves junk in the input stream for the next keep-alive request. I
think that it would be better to handle this in the Adaptor's
postParseRequest method.
I disagree: the problem with this is that we allocate one array right
away based on content-length, not that there's a big upload (which is
fine).
The Adaptor can check for this:
if(POST.equalsIgnoreCase(request.getMethod())
application/x-www-form-urlencoded.equals(contentType)
request.getContentLength() connector.getMaxPostSize()) {
response.setStatus(413);
response.setMessage(POST Body exceeds maximum);
return false;
}
This is not very efficient (doing checks there as well as in parse
parameters), and what if the servlet intended to stream the body by
itself ? (in this case, there's no particular efficiency problem)
So that's why I did do the check lazily (like the parsing itself, which
must be lazy).
Remy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/tcp SimpleTcpCluster.java
fhanik 2003/11/16 14:22:45 Modified:modules/cluster/src/share/org/apache/catalina/cluster Member.java SessionMessage.java modules/cluster/src/share/org/apache/catalina/cluster/io XByteBuffer.java modules/cluster/src/share/org/apache/catalina/cluster/mcast McastMember.java McastService.java McastServiceImpl.java modules/cluster/src/share/org/apache/catalina/cluster/tcp SimpleTcpCluster.java Log: added in member alive time Revision ChangesPath 1.2 +12 -4 jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/Member.java Index: Member.java === RCS file: /home/cvs/jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/Member.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- Member.java 19 Feb 2003 20:57:17 - 1.1 +++ Member.java 16 Nov 2003 22:22:45 - 1.2 @@ -98,4 +98,12 @@ * @return */ public int getPort(); + +/** + * Contains information on how long this member has been online. + * The result is the number of milli seconds this member has been + * broadcasting its membership to the cluster. + * @return nr of milliseconds since this member started. + */ +public long getMemberAliveTime(); } 1.4 +10 -39 jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/SessionMessage.java Index: SessionMessage.java === RCS file: /home/cvs/jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/SessionMessage.java,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- SessionMessage.java 15 Nov 2003 00:58:20 - 1.3 +++ SessionMessage.java 16 Nov 2003 22:22:45 - 1.4 @@ -138,36 +138,10 @@ * Event type used when an attribute has been added to a session, * the attribute will be sent to all the other nodes in the cluster */ -//public static final int EVT_ATTRIBUTE_ADDED = 5; -/** - * Event type used when an attribute has been removed from a session, - * the attribute will be sent to all the other nodes in the cluster - */ -//public static final int EVT_ATTRIBUTE_REMOVED_WONOTIFY = 6; - -/** - * Event type used when an attribute has been removed from a session, - * the attribute will be sent to all the other nodes in the cluster - */ -//public static final int EVT_ATTRIBUTE_REMOVED_WNOTIFY = 8; - -/** - * Event type used when a user principal is being cached in the session - */ -//public static final int EVT_SET_USER_PRINCIPAL = 9; +public static final int EVT_SESSION_DELTA = 13; /** - * Event type used when a user principal is being cached in the session - */ -//public static final int EVT_REMOVE_SESSION_NOTE = 10; - - -/** - * Event type used when a user principal is being cached in the session - */ -//public static final int EVT_SET_SESSION_NOTE = 11; -/** - * Event type used when all sessions are sent over as binary data + * When a session state is transferred, this is the event. */ public static final int EVT_ALL_SESSION_DATA = 12; @@ -208,7 +182,7 @@ * BEVT_REMOVE_SESSION_NOTE/BBR *The parameters: sessionID, attrName * BEVT_SET_SESSION_NOTE/BBR - *The parameters: sessionID, attrName, attrValue + *The parameters: sessionID, attrName, attrValue * @param eventtype - one of the 8 event type defined in this class * @param session - the serialized byte array of the session itself * @param sessionID - the id that identifies this session @@ -263,14 +237,9 @@ case EVT_SESSION_CREATED : return SESSION-MODIFIED; case EVT_SESSION_EXPIRED_WNOTIFY : return SESSION-EXPIRED-WITH-NOTIFY; case EVT_SESSION_EXPIRED_WONOTIFY : return SESSION-EXPIRED-WITHOUT-NOTIFY; -//case EVT_ATTRIBUTE_ADDED : return SESSION-ATTRIBUTE-ADDED; -//case EVT_ATTRIBUTE_REMOVED_WNOTIFY : return SESSION-ATTRIBUTE-REMOVED-WITH-NOTIFY; -//case EVT_ATTRIBUTE_REMOVED_WONOTIFY: return SESSION-ATTRIBUTE-REMOVED-WITHOUT-NOTIFY; case EVT_SESSION_ACCESSED : return SESSION-ACCESSED; case EVT_GET_ALL_SESSIONS : return SESSION-GET-ALL; -//case EVT_SET_SESSION_NOTE: return SET-SESSION-NOTE; -//case EVT_SET_USER_PRINCIPAL : return SET-USER-PRINCIPAL; -//case
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteConnector.java
billbarker2003/11/16 16:43:54
Modified:catalina/src/share/org/apache/coyote/tomcat5
CoyoteConnector.java
Log:
This is going to be needed in the Protocol as well, to handle the case of
CLIENT-CERT auth.
Revision ChangesPath
1.33 +2 -2
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteConnector.java
Index: CoyoteConnector.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteConnector.java,v
retrieving revision 1.32
retrieving revision 1.33
diff -u -r1.32 -r1.33
--- CoyoteConnector.java 15 Nov 2003 09:45:02 - 1.32
+++ CoyoteConnector.java 17 Nov 2003 00:43:54 - 1.33
@@ -798,7 +798,7 @@
public void setMaxPostSize(int maxPostSize) {
this.maxPostSize = maxPostSize;
-
+setProperty(maxPostSize, String.valueOf(maxPostSize));
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24739] New: - Control of secure flag when establishing sessions through https using cookies
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24739. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24739 Control of secure flag when establishing sessions through https using cookies Summary: Control of secure flag when establishing sessions through https using cookies Product: Tomcat 4 Version: 4.1.29 Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: Minor Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Because the secure flag is always set to yes when a session is created through an https connection, these session are lost when a user visits a non-secured page. The reverse is NOT true -- if the first page is a non-secure page, the cookie will work on both secured and un-secured connections. Developers should have explicit control over whether the secure flag is set to yes. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
