On Sun, 21 Jul 2002, Mladen Turk wrote: > All that I'm trying is to skip the need to use the Apache machanism for > the uri-space->file-space translation. > If the TC says that _its_ uri-space can be translated to the file-space > only than map_to_storage can provide the real finfo and serve the static > context.
What I'm trying to say: - if you don't serve static files with apache - there is no problem, anything goes to tomcat ( dirs, etc ). - if you do serve static files with apache, then you need to use _both_ file info and mappings to deal with directories. Or just forward the directory to tomcat as a simple solution. You need file info for the static files ( if index.html is found, it must be used ) and mappings for dynamic files ( /examples/index.jsp may be mapped with a servlet mapping to a generated index$jsp.class - and the file itself doesn't exists ). > Look how the mod_proxy is implemented. All the mapping is done through > mod_proxy directives, as in our case through workers2.properties > I think we shouldn't allow that mod_dir provides the default context > using dir walking even for a situation where the tc's uri-space can be > translated to the local file system. The TC should decide in that case > what to do with a such request. Whether it will serve the index.jsp or > something else its up to it thought. That's one solution - i.e. let tomcat handle directories. It's the simplest solution. Given that tomcat will issue a redirect, apache will still serve index.html as static file. If you want to see the directory list served by apache - then you can't avoid using both finfo and mappings, that's what the servlet spec requires. > The directory browsing in either case should go through TC and not > through mod_autoindex. I don't agree - while it is easier to go through TC, it is also a valid solution to let apache serve the file. But mod_autoindex won't work corectly - because servlet spec requires a different behavior for 'dirs' than what all web servers do. That's unfortunate - but we can't change it. Short term - I would vote for passing dirs to TC, long term or if someone really have the time we should let apache do it. ( same is true for IIS, NES, etc ). Costin > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > Sent: Sunday, July 21, 2002 5:47 PM > > To: Tomcat Developers List > > Subject: RE: cvs commit: > > jakarta-tomcat-connectors/jk/native2/server/apache2mod_jk2.c > > > > > > On Sun, 21 Jul 2002, Mladen Turk wrote: > > > > > We have a two situations, with the TC on the same box as > > apache, and > > > on the remote one. Well, that is only the partially > > correct, cause the > > > load balancing brakes that. > > > > Actually, I think we have 2 situations: > > - one if the webapp files are on the apache server file and jk is > > configured to let apache serve static files. The app may be > > load balanced and all dynamic resources ( including index.jsp > > ) will be served by one or more tomcats ( and you don't even > > need to run tomcat on the apache server - just to have the > > static files ). > > > > - if you don't keep the static files on the apache server, or > > you don't use apache for static files - the problem is trivial, > > you just forward everthing to tomat anyway. > > > > In the first case, there are 2 possible solutions: > > - for directories, just forward to tomcat. That's simple. > > - if you want apache to serve the dir, you must implement what the > > servlet spec requires: take the list of index files and check if > > any can be found. That involves both static and dynamic resources. > > > > If no index file or dynamic resource is found - apache can > > display the dir. > > > > If an index file is found - and is static, apache can display it. > > > > If index.jsp is found ( or another dynamic one ) - tomcat > > will handle it using the normal lb. > > > > Costin > > > > > So what we have is the following for example > > > > > > /someapp/ > > > ------>/somelocation1/someapp/ > > > ------>/somelocation2/someapp/ > > > ------>10.0.0.1/someapp/ > > > ------>10.0.0.2/someapp/ > > > ...etc > > > > > > Basically this is something like a reverse proxy situation. > > All that > > > has to be mapped inside the apache's directory tree at the > > > /opt/apache2 but can go to the any physical location above, or any > > > virtual one. You can serve the static mime-type context > > only from the > > > first two cases. The Load balancer have no idea about the > > fact where > > > the app is located (local or remote), so the .gif will get served > > > according to the lb state, not its potential context > > performance, but > > > that is another story. > > > > > > Your patches brakes the entire lb concept, and that is the > > reason that > > > I don't like it. Its not the problem with the static > > context (probably > > > it's a performance gain), but the default index.jsp will get served > > > only from the local TC no matter what the lb thinks about > > that. He may > > > mark the 10.0.0.2 as a active env, and you will map that to a local > > > /somelocation1. > > > > > > What we need IMO is that lb informs the map_to_storage > > whether we are > > > serving local or remote, so that we don't force the local > > context all > > > the time if present. > > > > > > > > > > > I mentioned in the previous e-mails that aliases have not > > > > been covered with this patch at all (that's why Mark's having > > > > problems with them). They would have to be dealt with as well. > > > > > > > > > > As I said (perhaps I'm totally wrong) you shouldn't suppose > > that the > > > context is inside the local file system. It has nothing to > > do with the > > > static context serving, and you don't have enough info to > > decide where > > > the context is situated. > > > > > > My suggestion are: > > > > > > 1. Let see how can we get the info whether the context is > > from local > > > or remote storage (and then use the map_to_storage > > accordingly) 2. Let > > > the TC decide what the default served file will be for a particular > > > uri (Dropping the entire DirectoryIndex fuzziness) 3. See how to > > > enable the DirectoryRoot mapping > > > > > > MT. > > > > > > > > > -- > > > 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]> > > > > > > > > > -- > 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]>
