* "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,
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:1
> 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
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 Sty
* "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:
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
?
* [EMAIL PROTECTED] wrote:
> mod_autoindex: new directive IndexStyleSheet
Hmm, why not new IndexOption? Isn't that what Indexoptions are for?
nd
[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
* 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 sho
--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
branc
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 doin
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 reques
> > > 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
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 wor
> 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
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
> [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
[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 smart
> 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 t
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 fi
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 (y
[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
22 matches
Mail list logo
