Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@apache.org Received: (qmail 65952 invoked from network); 22 Jul 2002 06:03:53 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 22 Jul 2002 06:03:53 -0000 Received: (qmail 8790 invoked by uid 97); 22 Jul 2002 06:04:13 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-dev@jakarta.apache.org Received: (qmail 8739 invoked by uid 97); 22 Jul 2002 06:04:12 -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 8727 invoked by uid 98); 22 Jul 2002 06:04:12 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) To: Tomcat Developers List Subject: RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c Message-ID: <1027318010.3d3ba0fa97643@imp.rexursive.com> Date: Mon, 22 Jul 2002 16:06:50 +1000 (EST) From: Bojan Smojver References: <1027315322.3d3b967a3f870@imp.rexursive.com> In-Reply-To: <1027315322.3d3b967a3f870@imp.rexursive.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.7 X-Originating-IP: 203.53.38.230 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N My apologies everyone... Just ignore the part of my previous e-mail marked here with between the stars. It just plain stupid :-( ********************************************************************** Quoting Bojan Smojver : > Quoting costinm@covalent.net: > > > > > > > > > > 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 > > > > That's actually a problem - map_uri_to_worker would find a match ( > > using *.jsp extension mapping ). > > Sorry, I meant, but never wrote, that the problem would be if there was > no > explicit extension mapping. If there was, the match would be found and > that > wouldn't be one of the problem cases because we'd simulate > r->finfo.filetype by > setting it explicitly to APR_REG. Then mod_dir would engage the real > request > based on that with handler set to JK_HANDLER, which would then call > Tomcat. > > > > 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 > > > > If jk_map_to_storage finds an exact or prefix mapping - then the > > problem is solved, the request goes to tomcat. > > Well, yes, but at this stage we are not doing the request. mod_dir is > just > checking if the request should go there or not. And since the real > request would > be originated by mod_dir, which filename would mod_dir use: index.jsp > or > index.vm? That would be a real problem case, I think. > > > If it finds an extension mapping - I have no idea. > > > > If it doesn't find any mapping - then it's not a request for tomcat > > and you can look for static files ( or let mod_dir do it ). > > > > > 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). > > > > No, you don't need to go back. For each attempted index you make a > > subrequest and you need to determine if tomcat could handle it. > > You mean here like this? Following code from mod_dir: > > --------------- > rr = ap_sub_req_lookup_uri(name_ptr, r, NULL); > --------------- > > Wouldn't that just end up going through jk_map_to_storage() again? ********************************************************************** -- To unsubscribe, e-mail: For additional commands, e-mail: