Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper Mapper.java
[EMAIL PROTECTED] wrote: jfarcand2004/08/25 12:25:46 Modified:util/java/org/apache/tomcat/util/http/mapper Mapper.java Log: Add missing case to support the following web.xml: servlet display-nameServletTest/display-name servlet-nameServletTest/servlet-name servlet-classtest.ServletTest/servlet-class /servlet servlet-mapping servlet-nameServletTest/servlet-name url-pattern*.screen/url-pattern /servlet-mapping welcome-file-list welcome-filewelcome.screen/welcome-file /welcome-file-list All Servlet TCKs passed. Please review (I recall some discussion on welcome file but can't find those emails). -1, this was on purpose. Extension mapping in welcome files cannot work. Since you have no way of testing if the resource exists or not, the request will *always* be redirected to the welcome file. It also means that, with the default settings and mappings, all requests to a folder will end up being redirected to index.jsp. I thought this was obvious enough. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper Mapper.java
Remy Maucherat wrote: [EMAIL PROTECTED] wrote: jfarcand2004/08/25 12:25:46 Modified:util/java/org/apache/tomcat/util/http/mapper Mapper.java Log: Add missing case to support the following web.xml: servlet display-nameServletTest/display-name servlet-nameServletTest/servlet-name servlet-classtest.ServletTest/servlet-class /servlet servlet-mapping servlet-nameServletTest/servlet-name url-pattern*.screen/url-pattern /servlet-mapping welcome-file-list welcome-filewelcome.screen/welcome-file /welcome-file-list All Servlet TCKs passed. Please review (I recall some discussion on welcome file but can't find those emails). -1, this was on purpose. Extension mapping in welcome files cannot work. Since you have no way of testing if the resource exists or not, the request will *always* be redirected to the welcome file. It also means that, with the default settings and mappings, all requests to a folder will end up being redirected to index.jsp. I thought this was obvious enough. Not enough for me ;-). So if it's impossible, the spec should be updated, righ? -- Jeanfrancois Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper Mapper.java
Jeanfrancois Arcand wrote: Remy Maucherat wrote: [EMAIL PROTECTED] wrote: jfarcand2004/08/25 12:25:46 Modified:util/java/org/apache/tomcat/util/http/mapper Mapper.java Log: Add missing case to support the following web.xml: servlet display-nameServletTest/display-name servlet-nameServletTest/servlet-name servlet-classtest.ServletTest/servlet-class /servlet servlet-mapping servlet-nameServletTest/servlet-name url-pattern*.screen/url-pattern /servlet-mapping welcome-file-list welcome-filewelcome.screen/welcome-file /welcome-file-list All Servlet TCKs passed. Please review (I recall some discussion on welcome file but can't find those emails). -1, this was on purpose. Extension mapping in welcome files cannot work. Since you have no way of testing if the resource exists or not, the request will *always* be redirected to the welcome file. It also means that, with the default settings and mappings, all requests to a folder will end up being redirected to index.jsp. I thought this was obvious enough. Not enough for me ;-). So if it's impossible, the spec should be updated, righ? Sorry, I'm almost certain I had talked about it earlier: that's the reason for my comment. I really don't see any way to implement it (if you find one ...), so IMO the spec is broken for extension mapping with welcome files (since they'll always match *.jsp with index.jsp - ok, I know, it's a static file, so there's a way to check in the special case). For exact or wildcard mappings, there's no problem. If you want more spec issues, let me know :) (right now, I have session handling with cross context, and also request dispatching and wrapping) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper Mapper.java
Remy Maucherat wrote: Jeanfrancois Arcand wrote: Remy Maucherat wrote: [EMAIL PROTECTED] wrote: jfarcand2004/08/25 12:25:46 Modified:util/java/org/apache/tomcat/util/http/mapper Mapper.java Log: Add missing case to support the following web.xml: servlet display-nameServletTest/display-name servlet-nameServletTest/servlet-name servlet-classtest.ServletTest/servlet-class /servlet servlet-mapping servlet-nameServletTest/servlet-name url-pattern*.screen/url-pattern /servlet-mapping welcome-file-list welcome-filewelcome.screen/welcome-file /welcome-file-list All Servlet TCKs passed. Please review (I recall some discussion on welcome file but can't find those emails). -1, this was on purpose. Extension mapping in welcome files cannot work. Since you have no way of testing if the resource exists or not, the request will *always* be redirected to the welcome file. It also means that, with the default settings and mappings, all requests to a folder will end up being redirected to index.jsp. I thought this was obvious enough. Not enough for me ;-). So if it's impossible, the spec should be updated, righ? Sorry, I'm almost certain I had talked about it earlier: that's the reason for my comment. I really don't see any way to implement it (if you find one ...), so IMO the spec is broken for extension mapping with welcome files (since they'll always match *.jsp with index.jsp - ok, I know, it's a static file, so there's a way to check in the special case). OK I will investigate more. For exact or wildcard mappings, there's no problem. If you want more spec issues, let me know :) (right now, I have session handling with cross context, and also request dispatching and wrapping) Actually, yes, raise them :-) This is the perfect time for raising issues to the spec leads if we want a fix for the next spec revision. This mapping issue was sent by the spec leads, so probably somebody else complained about that. Thanks -- Jeanfrancois Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper Mapper.java
Jeanfrancois Arcand wrote: Actually, yes, raise them :-) This is the perfect time for raising issues to the spec leads if we want a fix for the next spec revision. This mapping issue was sent by the spec leads, so probably somebody else complained about that. I have two issues: a) I don't understand the lifecycle of sessions with cross context (I had sent you a private email in relation to the portlet spec TCK, which somehow considers this as something which can be tested; I suppose it was tested with TC 4.1 ;) ) b) there are a lot of requirements when dispatching requests, which needs wrapping, and at the same time, the spec wants to disallow wrapping in some cases (obviously, we always wrap in Tomcat) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper Mapper.java
Remy Maucherat wrote: Jeanfrancois Arcand wrote: Actually, yes, raise them :-) This is the perfect time for raising issues to the spec leads if we want a fix for the next spec revision. This mapping issue was sent by the spec leads, so probably somebody else complained about that. I have two issues: a) I don't understand the lifecycle of sessions with cross context (I had sent you a private email in relation to the portlet spec TCK, which somehow considers this as something which can be tested; I suppose it was tested with TC 4.1 ;) ) Yes, that one is in progress :-) b) there are a lot of requirements when dispatching requests, which needs wrapping, and at the same time, the spec wants to disallow wrapping in some cases (obviously, we always wrap in Tomcat) OK I will see what I can do with that one (I need to read the spec again and pinpoint exactly where it should be re-phrased Thanks! -- Jeanfrancois Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper Mapper.java MappingData.java
[EMAIL PROTECTED] wrote: luehe 2004/03/16 11:24:59 Modified:util/java/org/apache/tomcat/util/http/mapper Mapper.java MappingData.java Log: Fix for Bugzilla 27664 (Welcome files not found in combination with jsp-property-group) Rather than having the JspServlet know about welcome files, the mapper algorithm has been amended to search for welcome files in URI spaces that match a url-pattern in a jsp-property-group. Please review carefully and let me know what you think. Obviously I hate it. Since when the mapper must have JSP stuff in it ? It just shows the specification is broken. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper Mapper.java MappingData.java
Remy Maucherat wrote: [EMAIL PROTECTED] wrote: luehe 2004/03/16 11:24:59 Modified:util/java/org/apache/tomcat/util/http/mapper Mapper.java MappingData.java Log: Fix for Bugzilla 27664 (Welcome files not found in combination with jsp-property-group) Rather than having the JspServlet know about welcome files, the mapper algorithm has been amended to search for welcome files in URI spaces that match a url-pattern in a jsp-property-group. Please review carefully and let me know what you think. Obviously I hate it. Since when the mapper must have JSP stuff in it ? It just shows the specification is broken. And to think you're likely going to do something even uglier to fix bug 27704. I can't wait ;) Seriously: the specification needs to be fixed, as I do not plan to integrate these changes in any release. I thought about something a little bit cleaner to address the bugs. I think you need to remove the extra servlet mappings for the JSP servlets jsp-property-group. Then add something to the context valve (calling a utility class to do the mapping = change the servlet from the default servlet or other to the JSP servlet if it matches a jsp-property-group; the algorithms are very similar to filter mapping). Unfortunately, the request dispatcher will also have to call this utility class :( This adds a significant amount of complexity in the servlet layer ... I can suggest sensible erratas to the specification if you need them. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper Mapper.java MappingData.java
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, March 16, 2004 12:47 PM Subject: Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper Mapper.java MappingData.java Remy Maucherat wrote: [EMAIL PROTECTED] wrote: luehe 2004/03/16 11:24:59 Modified:util/java/org/apache/tomcat/util/http/mapper Mapper.java MappingData.java Log: Fix for Bugzilla 27664 (Welcome files not found in combination with jsp-property-group) Rather than having the JspServlet know about welcome files, the mapper algorithm has been amended to search for welcome files in URI spaces that match a url-pattern in a jsp-property-group. Please review carefully and let me know what you think. Obviously I hate it. Since when the mapper must have JSP stuff in it ? My opinion is much like Remy's here. It just shows the specification is broken. And to think you're likely going to do something even uglier to fix bug 27704. I can't wait ;) Seriously: the specification needs to be fixed, as I do not plan to integrate these changes in any release. I thought about something a little bit cleaner to address the bugs. I think you need to remove the extra servlet mappings for the JSP servlets jsp-property-group. Then add something to the context valve (calling a utility class to do the mapping = change the servlet from the default servlet or other to the JSP servlet if it matches a jsp-property-group; the algorithms are very similar to filter mapping). Unfortunately, the request dispatcher will also have to call this utility class :( This adds a significant amount of complexity in the servlet layer ... Since from section 3.3 of the JSP spec, jsp-property-groups are translation time mappings, the only clean solution I can see would be to implement something like the TC 3.3 JspInterceptor (obviously, changed to a JspValve :) that would handle the pre-compilation checks with the required jsp-property-group applied. This would still be bending the spec a bit, but not as much as this patch does. I can suggest sensible erratas to the specification if you need them. Rémy - 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-connectors/util/java/org/apache/tomcat/util/http/mapper Mapper.java MappingData.java
Bill Barker wrote: Since from section 3.3 of the JSP spec, jsp-property-groups are translation time mappings, the only clean solution I can see would be to implement something like the TC 3.3 JspInterceptor (obviously, changed to a JspValve :) that would handle the pre-compilation checks with the required jsp-property-group applied. This would still be bending the spec a bit, but not as much as this patch does. Jan's solution seems unfortunately the least worst (my favorite by far is to not fix anything): the problem is that with TC 4 (I know, this sucks), the valve will not be invoked for request dispatching :( So, patatras, it becomes much slower and much more complex (the valve has access to the lower level stuff, while the RD does not). I suppose a filter-like algorithm wouldn't be too bad (works on Strings without GC), but it's another mapping operation and additional complexity (I believe the mapping rules have subtle differences :) ). :( :( :( I suppose it's when implementing specs completely that you uncover issues, and this is quite bad :( Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper Mapper.java MappingData.java
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, March 16, 2004 2:13 PM Subject: Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper Mapper.java MappingData.java Bill Barker wrote: Since from section 3.3 of the JSP spec, jsp-property-groups are translation time mappings, the only clean solution I can see would be to implement something like the TC 3.3 JspInterceptor (obviously, changed to a JspValve :) that would handle the pre-compilation checks with the required jsp-property-group applied. This would still be bending the spec a bit, but not as much as this patch does. Jan's solution seems unfortunately the least worst (my favorite by far is to not fix anything): the problem is that with TC 4 (I know, this sucks), the valve will not be invoked for request dispatching :( Point taken. One other possibility would be to go the whole route to JspInterceptor, and have a JspListener (which is much more like how JspInterceptor is implemented, than like JspValve). This would listen for a (new) MAPPING_EVENT to handle the translation phase of the JSP if necessary. Of course, the best solution would be for the JSR-152 expert group to issue an Errata clearing this up :). So, patatras, it becomes much slower and much more complex (the valve has access to the lower level stuff, while the RD does not). I suppose a filter-like algorithm wouldn't be too bad (works on Strings without GC), but it's another mapping operation and additional complexity (I believe the mapping rules have subtle differences :) ). :( :( :( I suppose it's when implementing specs completely that you uncover issues, and this is quite bad :( Rémy - 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-connectors/util/java/org/apache/tomcat/util/http/mapper Mapper.java
Host[] newHosts = new Host[hosts.length + 1];
Host newHost = new Host();
+ ContextList contextList = new ContextList();
newHost.name = name;
+ newHost.contextList = contextList;
newHost.object = host;
if (insertMap(hosts, newHosts, newHost)) {
hosts = newHosts;
}
+ for (int i = 0; i aliases.length; i++) {
+ newHosts = new Host[hosts.length + 1];
+ newHost = new Host();
+ newHost.name = aliases[i];
+ newHost.contextList = contextList;
+ newHost.object = host;
+ if (insertMap(hosts, newHosts, newHost)) {
+ hosts = newHosts;
+ }
+ }
}
The Tab-police are going to be after you big-time for this ;-).
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-connectors/util/java/org/apache/tomcat/util/http/mapper Mapper.java
Hi Bill, I had closed the bug because Remy told me it was already fixed in 5.0. I guess it wasn't. If you do any more work on it you should indicate the bug which is 14616. Keith | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] | Sent: Thursday, March 13, 2003 1:18 AM | To: [EMAIL PROTECTED] | Subject: cvs commit: | jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper | Mapper.java | | | billbarker2003/03/12 22:17:53 | | Modified:util/java/org/apache/tomcat/util/http/mapper Mapper.java | Log: | Initial support to do a redirect to a directory where the URL doesn't end in '/'. | | This prevents browsers from becoming confused when they get a 401 response for e.g. /foo. With this turned on, the | browser will get a 302 response to /foo/ before authentication is checked. | - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper Mapper.java
[EMAIL PROTECTED] wrote:
billbarker2003/03/12 22:17:53
Modified:util/java/org/apache/tomcat/util/http/mapper Mapper.java
Log:
Initial support to do a redirect to a directory where the URL doesn't
end in '/'.
This prevents browsers from becoming confused when they get a 401
response for e.g. /foo. With this turned on, the browser will get a 302
response to /foo/ before authentication is checked.
It is currently off by default to save the cost of a JNDI lookup on each
request.
IMHO - it should be on if it improves the situation with the auth.
Tomcat5 will have plenty of performance improvements - and we can break
some defaults if we think it is right.
Costin
Revision ChangesPath
1.11 +39 -0
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper/Mapper.java
Index: Mapper.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper/Mapper.java,v
retrieving revision 1.10 retrieving revision 1.11
diff -u -r1.10 -r1.11
--- Mapper.java 7 Mar 2003 16:03:33 - 1.10
+++ Mapper.java 13 Mar 2003 06:17:53 - 1.11
@@ -97,6 +97,12 @@
*/
protected boolean processWelcomeResources = true;
+/**
+ * Flag indicating that we should redirect to a directory when the
URL
+ * doesn't end in a '/'. It overrided the Authenticator, so the
redirect
+ * done before authentication.
+ */
+protected boolean redirectDirectories = false;
// - Public
Methods
@@ -143,6 +149,21 @@
this.processWelcomeResources = processWelcomeResources;
}
+/**
+ * Get the flag that indicates if we redirect to directories that
don't
+ * end a '/'.
+ */
+public boolean getRedirectDirectories() {
+return redirectDirectories;
+}
+
+/**
+ * Set the flag that indicates if we redirect to directories that
don't
+ * end in a '/'.
+ */
+public void setRedirectDirectories(boolean rd) {
+redirectDirectories = rd;
+}
/**
* Add a new host to the mapper.
@@ -570,6 +591,24 @@
(path.getBuffer(), path.getStart(),
path.getLength());
mappingData.wrapperPath.setChars
(path.getBuffer(), path.getStart(),
path.getLength());
+}
+if( redirectDirectories ) {
+char[] buf = path.getBuffer();
+if( context.resources != null buf[pathEnd -1 ] !=
'/') {
+Object file = null;
+try {
+file =
context.resources.lookup(path.toString());
+} catch(NamingException nex) {
+// Swallow, since someone else handles the 404
+}
+if(file != null file instanceof DirContext ) {
+CharChunk dirPath = path.getClone();
+dirPath.append('/');
+mappingData.redirectPath.setChars
+(dirPath.getBuffer(), dirPath.getStart(),
+ dirPath.getLength());
+}
+}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
