Re: cvs commit: httpd-2.0/modules/generators mod_autoindex.c
* "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote: > NOOO ;-) > seriously this option is too overloaded as it is. Let's try to > leave boolean flags in IndexOptions, but create new directive names if > they are non-trival choices. >>IndexOptions CSS=/foo/bar.css Hmm. What about *width, *height options and all the stuff? New directives? Booh. And... how do you want to switch off the css setting? IndexCSS off ? hrm. I see kinda namespace clashing here. nd
Re: cvs commit: httpd-2.0/modules/generators mod_autoindex.c
NOOO seriously this option is too overloaded as it is. Let's try to leave boolean flags in IndexOptions, but create new directive names if they are non-trival choices. Bill At 01:47 AM 11/20/2003, André Malo wrote: >* "Paul Querna" <[EMAIL PROTECTED]> wrote: > >> On Thu, 20 Nov 2003 07:18:55 +0100, André Malo wrote >> > * [EMAIL PROTECTED] wrote: >> > >> > > mod_autoindex: new directive IndexStyleSheet >> > >> > Hmm, why not new IndexOption? Isn't that what Indexoptions are for? >> > >> >> You mean somthing like: >> IndexOpion StyleSheet:/style/mystyle.css >> ? > >More consistent with the rest of the indexoptions ;-) > >IndexOptions CSS=/foo/bar.css > >This hat btw the advantage that you can easily turn off the css for >particular locations (because of the nature of IndexOptions). > >nd
Re: cvs commit: httpd-2.0/modules/generators mod_autoindex.c
André Malo wrote: * "Paul Querna" <[EMAIL PROTECTED]> wrote: On Thu, 20 Nov 2003 07:18:55 +0100, André Malo wrote * [EMAIL PROTECTED] wrote: mod_autoindex: new directive IndexStyleSheet Hmm, why not new IndexOption? Isn't that what Indexoptions are for? You mean somthing like: IndexOpion StyleSheet:/style/mystyle.css ? More consistent with the rest of the indexoptions ;-) IndexOptions CSS=/foo/bar.css This hat btw the advantage that you can easily turn off the css for particular locations (because of the nature of IndexOptions). nd I guess you could do it with that as well. my personal preference is a seperate directive, but I'm easily swayed --Ian
Re: cvs commit: httpd-2.0/modules/generators mod_autoindex.c
* "Paul Querna" <[EMAIL PROTECTED]> wrote: > On Thu, 20 Nov 2003 07:18:55 +0100, André Malo wrote > > * [EMAIL PROTECTED] wrote: > > > > > mod_autoindex: new directive IndexStyleSheet > > > > Hmm, why not new IndexOption? Isn't that what Indexoptions are for? > > > > You mean somthing like: > IndexOpion StyleSheet:/style/mystyle.css > ? More consistent with the rest of the indexoptions ;-) IndexOptions CSS=/foo/bar.css This hat btw the advantage that you can easily turn off the css for particular locations (because of the nature of IndexOptions). nd
Re: cvs commit: httpd-2.0/modules/generators mod_autoindex.c
On Thu, 20 Nov 2003 07:18:55 +0100, André Malo wrote > * [EMAIL PROTECTED] wrote: > > > mod_autoindex: new directive IndexStyleSheet > > Hmm, why not new IndexOption? Isn't that what Indexoptions are for? > You mean somthing like: IndexOpion StyleSheet:/style/mystyle.css ?
Re: cvs commit: httpd-2.0/modules/generators mod_autoindex.c
* [EMAIL PROTECTED] wrote: > mod_autoindex: new directive IndexStyleSheet Hmm, why not new IndexOption? Isn't that what Indexoptions are for? nd
Re: cvs commit: httpd-2.0/modules/generators mod_autoindex.c
[EMAIL PROTECTED] wrote: ianh2003/11/19 19:45:23 Modified:.CHANGES docs/manual/mod mod_autoindex.xml modules/generators mod_autoindex.c which prompts me to add a section on special documentation issues to my submitting-your-patch changes, since the html ought to be regenerated at the same time ;)
Re: cvs commit: httpd-2.0/modules/generators mod_autoindex.c
* Justin Erenkrantz wrote: > --On Sunday, March 2, 2003 1:45 PM + [EMAIL PROTECTED] wrote: > >> nd 2003/03/02 05:45:00 >> >> Modified:modules/generators Tag: APACHE_2_0_BRANCH mod_autoindex.c >> Log: >> WS and style issues. No code changes. > > For future reference, we should not backport style changes to the stable > branch. We need to keep the diffs as minimal as possible once we hit a > releasable state. Otherwise, it is hard to know exactly what changed from > release to release. > > Dean and Roy had our definitive thread on this a few years back (during the > 1.3 beta period). I realize you probably aren't aware of this. But, it comes > up every time someone wants to veto style changes. ok, noted and accepted - although it makes it a bit harder to backport the bugfixes (when they're done in unstable after a style cleanup). IMHO. nd -- s;.*;aoaaaoaaoaaaom:a:alataa:aaoat:a:a:a maoaa:a:laoata:a:oia:a:o:a:m:a:o:alaoooat:aaool:aaoaa matooololaaatoto:aaa:o:a:o:m;;s:\s:\::g;y;mailto:; \40\51/\134\137|ndparker <[EMAIL PROTECTED]>;;print;
Re: cvs commit: httpd-2.0/modules/generators mod_autoindex.c
--On Sunday, March 2, 2003 1:45 PM + [EMAIL PROTECTED] wrote: nd 2003/03/02 05:45:00 Modified:modules/generators Tag: APACHE_2_0_BRANCH mod_autoindex.c Log: WS and style issues. No code changes. For future reference, we should not backport style changes to the stable branch. We need to keep the diffs as minimal as possible once we hit a releasable state. Otherwise, it is hard to know exactly what changed from release to release. Dean and Roy had our definitive thread on this a few years back (during the 1.3 beta period). I realize you probably aren't aware of this. But, it comes up every time someone wants to veto style changes. No problem doing it on the unstable branch, but these shouldn't be backported to stable. -- justin
Re: cvs commit: httpd-2.0/modules/generators mod_autoindex.c
Greg Stein <[EMAIL PROTECTED]> writes: > On Fri, May 31, 2002 at 08:50:14PM -, [EMAIL PROTECTED] wrote: > > trawick 2002/05/31 13:50:14 > > > > Modified:modules/generators mod_autoindex.c > > Log: > > if we autoindex, discard the request body and check for any > > errors doing so > > When a request finishes, it will toss the request body. Why does autoindex > need to do this manually? It isn't happening (or at least it wasn't happening Friday :) ). Do you have a hint about where the code to do that is? Also, why does default_handler() discard the request body if it is going to happen automatically? -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: cvs commit: httpd-2.0/modules/generators mod_autoindex.c
On Fri, May 31, 2002 at 08:50:14PM -, [EMAIL PROTECTED] wrote: > trawick 2002/05/31 13:50:14 > > Modified:modules/generators mod_autoindex.c > Log: > if we autoindex, discard the request body and check for any > errors doing so When a request finishes, it will toss the request body. Why does autoindex need to do this manually? Cheers, -g -- Greg Stein, http://www.lyra.org/
RE: cvs commit: httpd-2.0/modules/generators mod_autoindex.c
> > > The problem is that the fast_internal_redirect is removing the > OLD_WRITE filter. > > > > I'm going to try it on my box without this patch, and with no Multiviews > (to get > > rid of fast_internal_redirects for HEADER and README). If that works > with HEAD > > as well as it did in 2.0.32, great! > > HEAD does work fine on my box without Multiviews, as you predicted. But > doing > the Right Thing w.r.t. OLD_WRITE and fast_internal_redirect just doesn't > sound > like rocket science. I have a hack in there for now. Feel free to look at how to solve it for real. I beat my head against it for a few hours this week. I'll look at it again after the 2.0.35 GA is released. Ryan
Re: cvs commit: httpd-2.0/modules/generators mod_autoindex.c
Greg Ames wrote: > > [EMAIL PROTECTED] wrote: > > The problem is that the fast_internal_redirect is removing the OLD_WRITE >filter. > > I'm going to try it on my box without this patch, and with no Multiviews (to get > rid of fast_internal_redirects for HEADER and README). If that works with HEAD > as well as it did in 2.0.32, great! HEAD does work fine on my box without Multiviews, as you predicted. But doing the Right Thing w.r.t. OLD_WRITE and fast_internal_redirect just doesn't sound like rocket science. Greg
RE: cvs commit: httpd-2.0/modules/generators mod_autoindex.c
> Ryan Bloom wrote: > > > > > [EMAIL PROTECTED] wrote: > > > > > > > > rbb 02/04/05 09:50:37 > > > > > > > > Modified:modules/generators mod_autoindex.c > > > > Log: > > > > This is a HACK! > > > > > > Why would it be difficult for the core to preserve OLD_WRITE in the > > subreq > > > filter chain? We knew how to do that in 2.0.32. One would hope we > > get > > > smarter > > > as we get more experienced. > > > > Because in pre-2.0.32 code, fast_internal_redirects didn't remove all of > > the RESOURCE filters. It does now, because that is the correct thing to > > do. The problem is that there is one RESOURCE filters that we want to > > keep, OLD_WRITE. > > OK, so maybe we proved that OLD_WRITE isn't an ordinary RESOURCE filter. > Calling it something else might do the trick. The problem is that it MUST be a RESOURCE filter, or it will be put in the wrong location in the filter stack. Ryan
Re: cvs commit: httpd-2.0/modules/generators mod_autoindex.c
Ryan Bloom wrote: > > > [EMAIL PROTECTED] wrote: > > > > > > rbb 02/04/05 09:50:37 > > > > > > Modified:modules/generators mod_autoindex.c > > > Log: > > > This is a HACK! > > > > Why would it be difficult for the core to preserve OLD_WRITE in the > subreq > > filter chain? We knew how to do that in 2.0.32. One would hope we > get > > smarter > > as we get more experienced. > > Because in pre-2.0.32 code, fast_internal_redirects didn't remove all of > the RESOURCE filters. It does now, because that is the correct thing to > do. The problem is that there is one RESOURCE filters that we want to > keep, OLD_WRITE. OK, so maybe we proved that OLD_WRITE isn't an ordinary RESOURCE filter. Calling it something else might do the trick. Greg
RE: cvs commit: httpd-2.0/modules/generators mod_autoindex.c
> [EMAIL PROTECTED] wrote: > > > > rbb 02/04/05 09:50:37 > > > > Modified:modules/generators mod_autoindex.c > > Log: > > This is a HACK! > > Why would it be difficult for the core to preserve OLD_WRITE in the subreq > filter chain? We knew how to do that in 2.0.32. One would hope we get > smarter > as we get more experienced. Because in pre-2.0.32 code, fast_internal_redirects didn't remove all of the RESOURCE filters. It does now, because that is the correct thing to do. The problem is that there is one RESOURCE filters that we want to keep, OLD_WRITE. I had thought about just having the core do this, but that gets ugly quickly, because the bug is incredibly specific to having a fast_internal_redirect inside of a content generator. Ryan
Re: cvs commit: httpd-2.0/modules/generators mod_autoindex.c
[EMAIL PROTECTED] wrote: > > rbb 02/04/05 09:50:37 > > Modified:modules/generators mod_autoindex.c > Log: > This is a HACK! Why would it be difficult for the core to preserve OLD_WRITE in the subreq filter chain? We knew how to do that in 2.0.32. One would hope we get smarter as we get more experienced. > The problem is that the fast_internal_redirect is removing the OLD_WRITE >filter. I'm going to try it on my box without this patch, and with no Multiviews (to get rid of fast_internal_redirects for HEADER and README). If that works with HEAD as well as it did in 2.0.32, great! If not, I think we need to do better. Greg p.s. why do I care? I'm working on a SpecWeb99 module for Apache 2.0. The way I see it working is using ap_rputs to generate a little bit of dynamic html, then running a subrequest to send a file, then using ap_rputs to generate a small trailer. That would work in 2.0.32. IMO it should also work in a GA release.
RE: cvs commit: httpd-2.0/modules/generators mod_autoindex.c
> Modified:modules/generators mod_autoindex.c > Log: > This is a HACK! The problem is that the fast_internal_redirect is > removing the OLD_WRITE filter. Obviously that is wrong. For right now, > the fix is to hack around the problem and just make it work. Long term, > we need to find a real solution to this, but this gets autoindex working > today. This fixes the final problems with mod_autoindex. I agree that this is not the correct long-term solution. I am deadly serious when I say I want a GA release today. The only way that 2.0 has ever made it out the door is for somebody to stand up and say that they want this more than life itself. I am saying that today. Let's ship 2.0.34 (bumped to HEAD) today, and if we need a 2.0.35 next week to fix some bugs, then we will do that next week. This thing has been five years in the making already, and it's time to go GA! Ryan
Re: cvs commit: httpd-2.0/modules/generators mod_autoindex.c
Cliff Woolley wrote: > > Reverted. Ta. 401 and 500 are (or can be) slightly special cases. 401 because we're not sure the user can access the resource and shouldn't let him know it even exists without that surety. And 500 because we're not sure what went wrong, and if the config error were fixed it might deny access. Paranoia mode. 403 is one of those on-the-fence things; we know access is categorically denied, but should we tell the user since he can (presumably) never get it? You'll find proponents on boths sides, but most security people will plump for obscuring the resource's existence. Good work, though, Cliff, and fast. :-) -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!"
Re: cvs commit: httpd-2.0/modules/generators mod_autoindex.c
On Tue, 5 Feb 2002, Rodent of Unusual Size wrote: > [EMAIL PROTECTED] wrote: > > > > List files that would result in HTTP_UNAUTHORIZED in addition to > > successes and redirections, since there's a chance the client will > > actually have the proper authorization to retrieve them. > > -1 (yes, a veto). Standard security practice: you don't > expose even meta-information without knowing the user can > access it. Reverted. --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: cvs commit: httpd-2.0/modules/generators mod_autoindex.c
[EMAIL PROTECTED] wrote: > > List files that would result in HTTP_UNAUTHORIZED in addition to > successes and redirections, since there's a chance the client will > actually have the proper authorization to retrieve them. -1 (yes, a veto). Standard security practice: you don't expose even meta-information without knowing the user can access it. Unixish systems have broken with this practice since day one by making /etc/passwd readable, but it's still visible in the login sequence: you get asked for a password even if the username exists, and the 'login incorrect' doesn't tell you that it failed because of an invalid username. Exposing the existence of something without knowing that the user can access it provides a definite target for probing and attack. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!"
