httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@ai.mit.edu (Robert S. Thau)
Subject Re: Bad choice of directory names for info- & status-modules
Date Wed, 24 Jul 1996 19:25:02 GMT
  I suppose I'd be amenable to changing the behavior of Location if and only
  if it really did match "path segments", not slashes. i.e. you could still
  use "/some/file.txt" and not have it only match "/some/file.txt/". What's
  the best way of doing this; I think thusly: if the last character of the
  <Location> entry is not a "/", check to see if the first character after
  the length of the entry in the URL is '/' or '\0' - if it isn't, don't
  match. That'd work, right? 

OK --- I'd lost track of the '/' subtlety, and was just assuming that
that whole business was an awkward way of saying "it matches the full
path segment".  What you've worked through above is one way to
implement that, I believe.  (There is simlar logic in mod_access.c to
prevent 'allow from good.com' to let in clients from, say,
badguy.nogood.com).

  I don't think anyone is using <Location /info>
  to intentionally match /info1, /info2 and /info3. If they are, they
  could just use <Location /info*> instead.

No one's using it this way *deliberately*, but people are tripping
over it --- this whole convesation started with the observation that
it's undersirable for <Location /info> to sweep up requests for
'/information'.

  We also need (as I've said before), a <Files> (that's the Netscape Server
  directive name) that matches any file, not just a directory (I agree with
  the behavior of <Directory> in tacking on a / - it's called Directory,
  after all). I haven't figured out the best way to make this work in
  .htaccess files, though (this is a feature people have requested - and I
  agree with). The simple way (ignore what's in between a <Files> that
  doesn't apply) doesn't work with the htaccess cache, so it'd need to be
  disabled for the rest of the request. If we cache .htaccess files longer
  (as we've discussed), this could be a real performance hit.

  Thoughts?

Well, to me, the obvious thing is to add a per-directory version of
the table that matches <Directory> strings to per-dir config
vectors...  (the relation of this to the current <Directory> machinery
would be *roughly* analogous to the relation of the per-directory
Redirect table to the old per-server one).

rst


Mime
View raw message