httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: Multi Language Error Documents
Date Mon, 20 Aug 2001 04:10:15 GMT
From: "Marc Slemko" <marcs@znep.com>
Sent: Sunday, August 19, 2001 9:23 PM


> On Sun, 19 Aug 2001, William A. Rowe, Jr. wrote:
> 
> > 4. Change the default document list to serve index.html index.html.var in that order.
> >    This will shortcut a ton of time negotating the content by stat() calls, since
> >    without Multiviews we won't look for index.html.*, but we will catch the typemap
:)
> 
> Note that this doesn't work when people do silly things like use
> "/index.html" instead of "/".  Typically many people creating content use
> the two interchangeably.  But that's ok, I think... since random people
> shouldn't be making documents linking to the default index page.  
> Although we should perhaps make sure there are no silly links in the docs
> that reference /index.html.
> 
> Hrm.  When you committed the DirectoryIndex change, you did .html.var
> first then .html.  Shouldn't it be the other way around (like you stated
> above)?  In the current order, if someone sticks there own index.html in
> there, it will not behave entirely as expected in odd (to the user)
> ways...

When I proposed it, I blew it.  I agree it might be 'unexpected' unless we document
it well, but we have a basic problem.  If we go index.html -> index.html.var, we get
an extra stat.  Worse, we may (if they've toggle multiviews themselves) end up walking
the multiview search, and then finding the .var which toggles it's own negotation.

What I committed was the most -optimal- solution, not necessarily the more predictable
one.  I think we should change the docco to tell the user to edit the docroot (and
assign it's permissions) rather than encouraging them to change the contents of our
distribution htdocs directory.  But that's just my 2c.

> So I like the idea of using a type map so multiviews don't have to be
> enabled for "/".  The performance for / requests will still be 

??? pretty fast.  We have another issue.  We need to stop stat'ing to get file sizes.
It's bogus.  Heck, SSI and CGI are generally 'smaller' than precomposed pages.  But
I sure don't think they save us a thing.  Testing the size wastes more cpu than just
serving our first best match.  Once that is done, this should be _very_ optimal.

Can everyone else agree we aught to drop the size test?  Simply drop in a '1' for the
size of any typemap-negotatied resource?

> Leaving multiviews enabled for the docs subtree is ok from a performance
> and random bugs standpoint... there are still possibilities for security
> issues, but they should be minimal.

Not if I did my job with the last patches :)  OTOH, I really agree with your comment
about testing.  I believe that we should enable as many features as possible, in
different (appropriate) places, so we, and the user, has a chance to uncover as many
bugs as possible durring this alpha/beta testing phase.

> But... we still have the original question of the multi-lingual error
> messages, and if they should be enabled by default and, if so, then how.  

By using a Type Map with integrated content (one file per error) - see my commit tommorow
:)



Mime
View raw message