RE: [users@httpd] RE: IndexIgnore list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> -----Original Message-----
> From: Stuart McGraw [mailto:smcg4191@xxxxxxxx] 
> Sent: Donnerstag, 30. März 2006 11:41
> 
> Please take my comment in the context on someone using Apache 
> for the first time, starting yesterday.  I am pretty clueless.
>  I said "surely" because without the ability to override the 
> list in subdirectories, it seems like its usefulness is hugely 
> limited.  

No problem, I completely understand your position :-)

I understand that you have a particular application in mind and have found that apache doesn't easily support it. So from your POV, that's obviously a limitation. All the same, I've been on this list for a few years and you're the first person to ask this question so I wouldn't say people are exactly clamouring for it...

Whenever you run up against a brick wall like this, it's always worth checking if you're really going the right way. I guess that you have a large directory hierarchy and you want to use apache as a file-system browser. But, you want to mask certain files in certain directories on a fairly ad hoc basis. As we see, you can't switch on and off IndexIgnore on a per-directory basis so maybe you have to think about the directory structure and/or the filenaming conventions? 

For example, AFAIK, IndexIgnore is additive going *down* the hierarchy but resets itself going *across* the filesystem, eg:

/dir1
  IndexIgnore .abc
  /dir1/subdir1
    IndexIgnore .def
	--> .abc and .def ignored in /dir1/subdir1
/dir2
  IndexIgnore .uvw
  /dir1/subdir2
    IndexIgnore .xyz
	--> .uvw and .xyz ignored in /dir2/subdir2

So maybe by re-arranging your files, you can get the result you want?

> There is no natural reason that subdirectories would 
> always want to have more restrictions on what files are shown, 
> than their parent's directories is there?  And it seems unreasonable 
> to require a directory hierarchy to be determined by which ones 
> have the most restrictive ignore lists.  So, the ignore list is 
> in generally only going to be useful if it is a global setting, 
> applied to all directories.  To me this seems unnaturally 
> restrictive, 
> to a degree that I found it hard to believe that a product as 
> mature as Apache would have a restriction like this. 

It sounds a bit like you think that the main reason apache was invented was to allow filesystem browsing :-)

In fact, this functionality is almost a bonus feature... I guess the ignore feature was added in emulation of the similar feature in CVS, and that's additive too :-(

BTW, I wouldn't really call it a restriction - rather, you desire a functionality that isn't present. Apache can't make tea either, but I wouldn't say it has a no-tea-making restriction...

Rgds,
Owen Boyle
Disclaimer: Any disclaimer attached to this message may be ignored. 

> But perhaps 
> I misunderstand it's purpose...I am a very much a newbie.
> 
> > Wacky off-the-top-of-my-head, untried, untested "workarounds":
> > 
> > - Make a separate VH, on port 8080 for example, with 
> docroot set to the target dir and have no IndexIgnore in this VH. 
> > Then, in the main VH, proxy requests for that dir to the 
> port 8080 VH. Maybe that would work? 
> 
> I'll look into this tomorrow but it seems like driving 100 miles up 
> one side of a river, crossing, and driving back down the other 
> side, because there is no local bridge.  :-(
> 
> > - a one-off hack to suit your situation: Extend the 
> add_ignore method so that if it encounters a certain pattern (eg, 
> > CLEAR_INDEX_IGNORE_LIST), then it empties the array. You 
> could then put "IndexIgnore CLEAR_INDEX_IGNORE_LIST" in the 
> > directory you want to free up. [NB - no idea if this would 
> really work - it might clear the list for all dirs!)
> 
> You're talking about modifying the code and rebuilding?
> 
> Hmm, I think I will rethink my requirements.  But I do very much 
> appreciate getting your thoughts on this.
> 
> 
> ---------------------------------------------------------------------
> The official User-To-User support forum of the Apache HTTP 
> Server Project.
> See <URL:http://httpd.apache.org/userslist.html> for more info.
> To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
>    "   from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
> For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
> 
> 
Diese E-mail ist eine private und persönliche Kommunikation. Sie hat keinen Bezug zur Börsen- bzw. Geschäftstätigkeit der SWX Gruppe. This e-mail is of a private and personal nature. It is not related to the exchange or business activities of the SWX Group. Le présent e-mail est un message privé et personnel, sans rapport avec l'activité boursière du Groupe SWX.
 
 
This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
   "   from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx



[Index of Archives]     [Open SSH Users]     [Linux ACPI]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Squid]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux