Re: [5.0] [PROPOSAL] Refactored mapper
On Thu, 2002-08-15 at 15:37, Remy Maucherat wrote: [...] Yes, but welcome files for non physical resources cannot be implemented (since you have no way of asking a servlet if it can or cannot process a resource). I'll implement something which works and which is very close to what the spec requires. Again, I have sent many messages to the spec leads about this issue without any result, so I give up ... I don't completely understand the issue(s), but consider this, servlet-mapping servlet-nameBooServlet/servlet-name url-pattern/*.boo/url-pattern /servlet-mapping welcome-file-list welcome-fileindex.jsp/welcome-file welcome-fileindex.boo/welcome-file /welcome-file-list Is the problem that by the time the 'welcome file logic' gets a chance to handle the request, the logic that would have been able to pass this request off to a servlet is way too far up the call stack?It is almost like the DefaultServlet would need to open a connection to the loopback and check each welcome file URI to find one that gets to something useful (this is just a mental exercise, don't get excited I wouldn't think of implementing this.) Cheers, -bob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Refactored mapper
Bob Herrmann wrote: On Thu, 2002-08-15 at 15:37, Remy Maucherat wrote: [...] Yes, but welcome files for non physical resources cannot be implemented (since you have no way of asking a servlet if it can or cannot process a resource). I'll implement something which works and which is very close to what the spec requires. Again, I have sent many messages to the spec leads about this issue without any result, so I give up ... I don't completely understand the issue(s), but consider this, servlet-mapping servlet-nameBooServlet/servlet-name url-pattern/*.boo/url-pattern /servlet-mapping welcome-file-list welcome-fileindex.jsp/welcome-file welcome-fileindex.boo/welcome-file /welcome-file-list Is the problem that by the time the 'welcome file logic' gets a chance to handle the request, the logic that would have been able to pass this request off to a servlet is way too far up the call stack?It is almost like the DefaultServlet would need to open a connection to the loopback and check each welcome file URI to find one that gets to something useful (this is just a mental exercise, don't get excited I wouldn't think of implementing this.) It means that in that case, no matter what the URL is (as long as it ends with a '/'), it will end up to your_url/index.boo, which isn't good since it may be completely stupid (and your other entries in the welcome file list would get ignored), unless you have a way to verify that it is intelligent to forward to index.boo (it's easy to do for physical files, as you can check to see if it exists, but you can't do it in the general case). So it's possible to implement what is in the spec for physical files *or* for exact servlet mappings (where you consider that if a servlet is mapped to an exact URL without wildcards, and that you match that URL with a welcome file, you can assume it's a good idea to redirect). However, it's not possible for non physical resources (which is a new requirement). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Refactored mapper
On Thu, 2002-08-15 at 18:38, Patrick Luby wrote: Remy and Costin, I found the following draft wording that is being considered for the Servlet 2.4 spec. The exact wording may change, but the context should stay the same. Are there any unimplementable pieces in this proposed wording: The wording in the 4th paragraph in section 9.10 of the Servlet 2.4 spec may change to: The web server must append each welcome file in the order specified in the deployment descriptor to the partial request and check whether a [static] resource [or servlet] in the WAR is mapped to that request URI. The web container must send the request to the first resource in the WAR that matches [in the order of 1. a static resource, 2. a servlet that matches exactly, 3. a servlet that matches according to the path mapping rule]. Patrick Humm... how does this help? First, note that the extension mapping is not mentioned, so things like *.jsp, *.boo are not relevant to welcome files. Consider this, servlet-mapping servlet-nameBooServlet/servlet-name url-pattern/boo/*/url-pattern /servlet-mapping servlet-mapping servlet-nameFooServlet/servlet-name url-pattern/boo/foo/*/url-pattern /servlet-mapping servlet-mapping servlet-nameExServlet/servlet-name url-patternexactMatch/url-pattern /servlet-mapping welcome-file-list welcome-fileindex.html/welcome-file welcome-file/boo/AlwaysGoesHere/welcome-file welcome-file/boo/foo/NeverGetsHere/welcome-file welcome-fileexactMatch/welcome-file welcome-fileindex.jsp/welcome-file !-- how come extension mapping is ok here? or is it not ok. -- /welcome-file-list Somewhat confused (typical), Bob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Refactored mapper
Bob Herrmann wrote: On Thu, 2002-08-15 at 18:38, Patrick Luby wrote: Remy and Costin, I found the following draft wording that is being considered for the Servlet 2.4 spec. The exact wording may change, but the context should stay the same. Are there any unimplementable pieces in this proposed wording: The wording in the 4th paragraph in section 9.10 of the Servlet 2.4 spec may change to: The web server must append each welcome file in the order specified in the deployment descriptor to the partial request and check whether a [static] resource [or servlet] in the WAR is mapped to that request URI. The web container must send the request to the first resource in the WAR that matches [in the order of 1. a static resource, 2. a servlet that matches exactly, 3. a servlet that matches according to the path mapping rule]. Patrick Humm... how does this help? First, note that the extension mapping is not mentioned, so things like *.jsp, *.boo are not relevant to welcome files. Consider this, servlet-mapping servlet-nameBooServlet/servlet-name url-pattern/boo/*/url-pattern /servlet-mapping servlet-mapping servlet-nameFooServlet/servlet-name url-pattern/boo/foo/*/url-pattern /servlet-mapping servlet-mapping servlet-nameExServlet/servlet-name url-patternexactMatch/url-pattern /servlet-mapping welcome-file-list welcome-fileindex.html/welcome-file welcome-file/boo/AlwaysGoesHere/welcome-file welcome-file/boo/foo/NeverGetsHere/welcome-file welcome-fileexactMatch/welcome-file welcome-fileindex.jsp/welcome-file !-- how come extension mapping is ok here? or is it not ok. -- /welcome-file-list Somewhat confused (typical), And imagine what users will say ;-) Basically, I read it as not using extension mapping for non physical resources, but only for physical resources (otherwise the default home page of Tomcat when you set it up won't work, which is a problem IMO ;-)). It now looks doable with the standalone Tomcat. It may still be unimplementable through Apache, though. My wish would be that only physical resources can be used as welcome files, so that the spec is implementable through a native webserver. (Quite frankly, the use case for the rest is very limited, and very confusing; plus it would impose a complex wording in the spec - still not right in that version) Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Refactored mapper
Remy, Remy Maucherat wrote: It now looks doable with the standalone Tomcat. It may still be unimplementable through Apache, though. My wish would be that only physical resources can be used as welcome files, so that the spec is implementable through a native webserver. (Quite frankly, the use case for the rest is very limited, and very confusing; plus it would impose a complex wording in the spec - still not right in that version) I really don't like this spec change either. After carefully reading the revised wording, it still seems that spec is saying if I can't find any of the listed static welcome files, start looking for anything that can serve up a response. OK, maybe I am being overly dramatic, but it seems that the spec is trying to apply complex pattern matching rules to when the user requests the / resource and the webapp is missing all of the static welcome file resources. As far as I can tell, the only time the servlet mapping gets used is when the webapp has, for example /index.html as a welcome file and then then the webapp developer forget to put a index.html file in the webapp. Am I missing some bigger and better feature? Or is this spec trying to solve a problem that can be easily handled with the existing welcome file behavior? Patrick -- Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Refactored mapper
On Fri, 16 Aug 2002, Remy Maucherat wrote: The wording in the 4th paragraph in section 9.10 of the Servlet 2.4 spec may change to: The web server must append each welcome file in the order specified in the deployment descriptor to the partial request and check whether a [static] resource [or servlet] in the WAR is mapped to that request URI. The web container must send the request to the first resource in the WAR that matches [in the order of 1. a static resource, 2. a servlet that matches exactly, 3. a servlet that matches according to the path mapping rule]. Patrick Humm... how does this help? First, note that the extension mapping is not mentioned, so things like *.jsp, *.boo are not relevant to welcome files. Very good point Bob. The new wording brakes other pieces. My wish would be that only physical resources can be used as welcome files, so that the spec is implementable through a native webserver. (Quite frankly, the use case for the rest is very limited, and very confusing; plus it would impose a complex wording in the spec - still not right in that version) +1 My view of the correct behavior ( and others have spent more time with that than me, and they should speak ): - first check for static files. If one is found, that'll do it. That's what the server does - if the file is present. Normal extension mapping will be used on the file. - check for exact or prefix mappings. That will cover precompiled JSPs. - don't check for extension mapping if no physical file is present. There is no way to know if an extension-mapped resource actually exist - so any way you turn it, it can't be used for welcome files without some extra info. The file existence can do that. Keep in mind that extension mapping is a fundamental concept from web servers that was screwed in the servlet spec - no existing server does extension mapping without a physical file. PathInfo is just another victim of 'redefining' and 'extending' a de-facto standard. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Refactored mapper
On Fri, 16 Aug 2002, Patrick Luby wrote: I really don't like this spec change either. After carefully reading the revised wording, it still seems that spec is saying if I can't find any of the listed static welcome files, start looking for anything that can serve up a response. OK, maybe I am being overly dramatic, but it seems that the spec is trying to apply complex pattern matching rules to when the user requests the / resource and the webapp is missing all of the static welcome file resources. As far as I can tell, the only time the servlet mapping gets used is when the webapp has, for example /index.html as a welcome file and then then the webapp developer forget to put a index.html file in the webapp. Or index.jsp ? If index.jsp has been precompiled - you need path mapping. What if you have struts and index.do ? With no real file in the dir, but some definition in an xml file ? Am I missing some bigger and better feature? Or is this spec trying to solve a problem that can be easily handled with the existing welcome file behavior? There is no 'existing welcome file behavior' in the servlet spec. The spec has allways been broken, and people just ignored it and implemented what the web servers are doing and users expect. The root of the problem is the extension mapping definition that can't check for existence of the resource ( since the resource is no longer there ). You either exclude extension mapping, or allow only 'normal' extension mapping ( the one used by web servers ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Refactored mapper
Bob Herrmann wrote: On Thu, 2002-08-15 at 13:23, Remy Maucherat wrote: Hi, I have been hinting at rewriting the main Catalina mapper for Tomcat 5. The proposal is designed to improve performance, avoid generating uneeded garbage String objects, and optimize the welcome files processing. FYI, The 2.4 spec seems to allow servlets to handle welcome file processing too. Not sure I understand this completely, but I am looking into it (with an eye towards implementing something to satisfy the 2.4 Spec's servlets as providers of welcome files. Perhaps welcome page would be better than 'welcome file.', but I digress) Yes, but welcome files for non physical resources cannot be implemented (since you have no way of asking a servlet if it can or cannot process a resource). I'll implement something which works and which is very close to what the spec requires. Again, I have sent many messages to the spec leads about this issue without any result, so I give up ... Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Refactored mapper
On Thu, 15 Aug 2002, Remy Maucherat wrote: Yes, but welcome files for non physical resources cannot be implemented (since you have no way of asking a servlet if it can or cannot process a resource). I'll implement something which works and which is very close to what the spec requires. Again, I have sent many messages to the spec leads about this issue without any result, so I give up ... The current specification is not implementable for Apache ( or any other web server ) - and it breaks every pattern that was used in the web. I don't know if we have any representative in the expert group or what's the procedure that apache follows in voting for JCP specs - but if this is not resolved I'll do my best to find out. I'm also curious to who is representing apache ( if any ) in the JSP spec - I'm still strugling to understand how the TLD stuff happened and nobody noticed or complained in any way - the whole 'config in web.xml' model is now screwed, with any file ( including jars ) potentially storing config for web applications. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Refactored mapper
[EMAIL PROTECTED] wrote: The current specification is not implementable for Apache ( or any other web server ) - and it breaks every pattern that was used in the web. I don't know if we have any representative in the expert group or what's the procedure that apache follows in voting for JCP specs - but if this is not resolved I'll do my best to find out. I have heard that Pier is in the Expert Group. But I could be wrong. I think the Servlet 2.4 spec is going Public Final Draft this month (not sure exactly when), but you can e-mail the expert group directly at: [EMAIL PROTECTED] Also, the latest draft of the spec is at: http://www.jcp.org/jsr/detail/154.jsp Patrick -- _ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Refactored mapper
Remy and Costin, I found the following draft wording that is being considered for the Servlet 2.4 spec. The exact wording may change, but the context should stay the same. Are there any unimplementable pieces in this proposed wording: The wording in the 4th paragraph in section 9.10 of the Servlet 2.4 spec may change to: The web server must append each welcome file in the order specified in the deployment descriptor to the partial request and check whether a [static] resource [or servlet] in the WAR is mapped to that request URI. The web container must send the request to the first resource in the WAR that matches [in the order of 1. a static resource, 2. a servlet that matches exactly, 3. a servlet that matches according to the path mapping rule]. Patrick [EMAIL PROTECTED] wrote: On Thu, 15 Aug 2002, Remy Maucherat wrote: Yes, but welcome files for non physical resources cannot be implemented (since you have no way of asking a servlet if it can or cannot process a resource). I'll implement something which works and which is very close to what t spec requires. Again, I have sent many messages to the spec leads about this issue without any result, so I give up ... The current specification is not implementable for Apache ( or any other web server ) - and it breaks every pattern that was used in the web. I don't know if we have any representative in the expert group or what's the procedure that apache follows in voting for JCP specs - but if this is not resolved I'll do my best to find out. I'm also curious to who is representing apache ( if any ) in the JSP spec - I'm still strugling to understand how the TLD stuff happened and nobody noticed or complained in any way - the whole 'config in web.xml' model is now screwed, with any file ( including jars ) potentially storing config for web applications. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- _ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Refactored mapper
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, August 15, 2002 10:23 AM Subject: [5.0] [PROPOSAL] Refactored mapper Hi, I have been hinting at rewriting the main Catalina mapper for Tomcat 5. The proposal is designed to improve performance, avoid generating uneeded garbage String objects, and optimize the welcome files processing. The following changes are proposed: - Expose the decoded URI MessageBytes in the main Request interface of Catalina, so that the mapper doesn't have to pay the b2c cost - Implement the new mappers as a separate set of classes in j-t-c/util/../mapper I'm hoping that this doesn't imply a dependency in j-t-c/util on o.a.c.Mapper. It's mostly the TC3.3 build that I'm worried about. The new mappers will use exclusively bytes to match contexts/servlets and will rewrite the original URIs to handle welcome files without sending a redirect back to the client (in most cases). +1 (i.e. I'm willing to help out, if you want). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
