On Sun, Sep 02, 2001 at 01:04:24PM -0500, Ian Bicking wrote:
> [EMAIL PROTECTED] (Mike Orr) wrote:
> > On Sun, Sep 02, 2001 at 10:49:42AM -0500, Ian Bicking wrote:
> > > I think this can be better than simply telling the web server to serve
> > > certain kinds of files, because it allows you to do complicated
> > > URL->filename mappings, and to implement your own security for file
> > > access. These situations have already come up on the list, and I
> > > could use this sort of functionality myself.
> >
> > Much as I like having the web server serve static files, it is
> > incompatible with having Webware automatically supply the filename
> > extension.
> >
> > Also, even though alternative webservers are great in theory, in
> > practice most professional deployments will probably have to use
> > Apache anyway, because they need access to other Apache features
> > like allow/deny based on client IP, rewriting, virtual hosts, having some
> > virtual hosts on the same IP be Webware and some not, etc. Unless we want to
> > port all of these features to another webserver.
>
> I'm confused...? This would be more adapter-level. I.e., you send
> something like:
>
> serve-static: /var/www/some-file
>
> And the web server serves that file. I'm not sure, but maybe Apache
> already does this with local redirects... but that wouldn't work with
> files that weren't URL-accessible.
And I'm confused by what you mean. I'm talking about having the
webserver broker all requests, and then through mod_rewrite, AddHandler
for *.py, or somehow, having it invoke Webware only for dynamic files.
This is what Tux is designed to do, although it's not as infinitely
configurable as Apache is.
Anyway, if the webserver brokers all requests and passes only the
dynamic ones on to Webware, WW never gets a chance to get its clean
little hands (as opposed to grubby little hands) on the other requests
to see if they could benefit from automatic extension-adding.
As for serve-static:, who would be sending that message to who?
WW could send that to the webserver, but the webserver wouldn't know
what to do with it. Would the adapter (or HTTPServer) handle static
requests? I suppose so, but then the extension-adding feature would
have to be moved to the adapter or it would be lost.
Anyway, my second point was that many sites will need to keep Apache
anyway, for a hundred different reasons we can't predict. For
instance, as sites age they get reorganized, because what seemed like
a good idea then doesn't seem like a good idea now. And if you want
to honor existing bookmarks and links, you need mod_rewrite. Unless
we're going to fully duplicate it in Python, which seems redundant.
Or use the servlet-forward thingy, which seems like a lot of overhead for
a simple little task, and means cluttering up your context with objects
that have no purpose except to represent legacy URLs.
Finally, we haven't yet determined that HTTPserver or Tux can
necessarily take over Apache's job of serving several NameVirtualHosts,
some of which are served by Webware and others not, while maintaining
the same performance for all sites that Apache does.
BTW, Tux's handling of virtual hosts is pretty sweet. You just set
an option, and put your virtual-host directories straight under the
document root. Then when a request comes in for that host, Tux just
looks for a subdirectory named after that site. Quick and simple.
Of course, that doesn't leave you any place to put non-URL-accessible
support files with your site, but I suppose the virtual host directory
could be a symbolic link to the actual docroot in the site's project
directory.
--
-Mike (Iron) Orr, [EMAIL PROTECTED] (if mail problems: [EMAIL PROTECTED])
http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol
_______________________________________________
Webware-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-devel
