Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@apache.org Received: (qmail 51263 invoked from network); 22 Jul 2002 05:18:08 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 22 Jul 2002 05:18:08 -0000 Received: (qmail 26143 invoked by uid 97); 22 Jul 2002 05:18:27 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-dev@jakarta.apache.org Received: (qmail 26105 invoked by uid 97); 22 Jul 2002 05:18:26 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Developers List" Reply-To: "Tomcat Developers List" Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 26093 invoked by uid 98); 22 Jul 2002 05:18:26 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Message-ID: <01ac01c2313f$f5b3d7e0$b5c22e04@dslverizon.net> From: "Bill Barker" To: "Tomcat Developers List" References: <1027311566.3d3b87ce38337@imp.rexursive.com> Subject: Re: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c Date: Sun, 21 Jul 2002 22:23:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Archived: msg.XXrP1aNQ@sneezy X-Scanned-By: MIMEDefang 2.11 (www dot roaringpenguin dot com slash mimedefang) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N ----- Original Message ----- From: "Bojan Smojver" To: "Tomcat Developers List" Sent: Sunday, July 21, 2002 9:19 PM Subject: RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c > Quoting costinm@covalent.net: > > > You don't need to ask tomcat - jk should have all the mappings, and > > it can already map any URI. All it has to do is: > > - for each index: > > -- concatenate with the current uri > > -- do the jk mapping ( or internal redirect if you use > > instead of the internal mapper ). If a match is found - forward to > > tomcat. > > -- check if a file exists. If yes - serve it as static ( since > > we already checked all servlet mappings ). > > - if no match is found, use mod_dir to display the directory. > > Just reading the algorithm and thinking about the implementation of it. Some of > the things might present themselves as big problems here in relation to servlet > mappings... > > An example configuration: > > > > The order of events would be: > > 1. mod_dir does a sub request for index.jsp > 2. jk_map_to_storage() receives the request > 3. jk_map_to_storage() engages map_uri_to_worker() <-- this would be new code > 4. map_uri_to_worker() finds nothing because it has no mapping to anything that > matches *.jsp > > Now, the next step is rather tricky and is the key to the whole thing. Does > jk_map_to_storage(): > > a) assume that there is index.jsp in one of the mappings that match the URI > minus the filename; jk_map_to_storage() could be very wrong about this - maybe > there is a default file there, but not index.jsp - this would then result in a > failed request > b) continue processing with the next index file (in this case index.vm) and > possibly miss both index.jsp and index.vm in one of the servlet mappings > > Keep in mind that these are sub-requests that don't actually result in the file > being served. It's just mod_dir's way of checking what would happen if there > was a file like that 'in the file system'. So, one cannot 'go back' and do all > this again, unless mod_dir is changed to do this kind of thing twice (which is > definitely a bad idea). > > I actually think that it is not possible to establish if there is such a file, > unless mod_jk somehow knows about their exisitence. I'm not all that familir > with mappings, but I reckon that isn't the case. > > And then, when everybody thought all was lost... ;-) > > If my old kludge is applied (with the correct test this time) to jk_handler(), > things might be better. The kludge involved jk_handler() responding not just to > JK_HANDLER requests but also to DIR_MAGIC_TYPE requests. Now, jk_handler() would > find the mapping (since the request is for a directory, not a file) and the > request would be served by Tomcat. > > Would this work? I think it might... > At the moment, the servlet-mapping issue is somewhat of a red-herring, since only 3.3.2-dev supports it (and even there, it is disabled by default). For now, mod_jk(2) might as well assume that the physical jsp/vm file is there, since Tomcat requires that it is. The real issue is that jk_map_to_storage was a kludgy attempt to bypass tree-walking by Apache (and save the time to do all of those stat calls). Your fix at least removes the "kludgy" part. ;-) I *really* don't like the idea of passing DIR_MAGIC_TYPE requests to Tomcat, since I tend to set up directories with only static content that only Apache knows about. Sending them to Tomcat just gives me very many 404 errors, so I'd be forced to use a branched copy of mod_jk. If you have: JkMount /myapp/*.jsp ajp13 JkMount /myapp/*.vm ajp13 Then jk_translate will grab the request for /myapp/index.jsp and set the handler. If the file is physically there, then jk_map_to_storage will stat it, and everyone is happy. Otherwise, jk_translate will grab the request for /myapp/index.vm and set the handler and do the same check for a physical file. In Apache 1.3.x, this is basically what happens except that the "physical file" test is done by Apache's tree-walk. > Bojan > > -- > To unsubscribe, e-mail: > For additional commands, e-mail: > -- To unsubscribe, e-mail: For additional commands, e-mail: