"William A. Rowe, Jr." wrote:
> Please note that this is -why- 1.3 is in R-T-C mode, unlike 2.0. Please
> post patches first for that tree. Sorry if it appeared that Aaron, Cliff
> and I didn't follow that protocol, since the review happened off-list
> in security@ due to the nature of the patc
At 08:49 AM 3/21/2002, you wrote:
>Joshua Slive wrote:
>
> > Perhaps I missed something here, but isn't this exactly what the
> > UseCanonicalName directive is for? Why are you hard-coding this?
>
>Hmmm - got me there - wasn't aware that the UseCanonicalName did this.
>Will change it back :)
Ple
Joshua Slive wrote:
> Perhaps I missed something here, but isn't this exactly what the
> UseCanonicalName directive is for? Why are you hard-coding this?
Hmmm - got me there - wasn't aware that the UseCanonicalName did this.
Will change it back :)
Regards,
Graham
--
--
Certainly, isn't this better addressed by UseCanonicalName? We
depend on ap_get_server_name() to do the "right thing" depending
on that setting... This doesn't seem right to me.
[EMAIL PROTECTED] wrote:
>
> minfrin 02/03/21 06:37:43
>
> Modified:src CHANGES
>src/m
On 21 Mar 2002 [EMAIL PROTECTED] wrote:
> minfrin 02/03/21 06:37:43
>
> Modified:src CHANGES
>src/main http_core.c
> Log:
> Change ap_construct_url() so that the r->hostname is used in
> the URL instead of the value of the ServerName directive. This
> stops
Option 2. I seem to recall the same conversation about structure extensions
a couple years ago or so. Consensus seemed to say minor bump.
Cheers,
-g
On Thu, Jan 10, 2002 at 11:05:40AM -0500, Rodent of Unusual Size wrote:
> So.. should this be changed to
>
> 1. no MMN bump,
> 2. a minor MMN bump
"William A. Rowe, Jr." wrote:
>
> From: "Roy T. Fielding" <[EMAIL PROTECTED]>
> Sent: Thursday, January 10, 2002 5:47 PM
>
> And no features should be added to 1.3 without the parallel patch to 2.0,
> if it is at all relevant. Ken, is there a patch forthcoming?
You betcha. Docco too. :-)
Oke
From: "Roy T. Fielding" <[EMAIL PROTECTED]>
Sent: Thursday, January 10, 2002 5:47 PM
> No new features should be added to 1.3, period, but I am not vetoing that.
And no features should be added to 1.3 without the parallel patch to 2.0,
if it is at all relevant. Ken, is there a patch forthcomin
No new features should be added to 1.3, period, but I am not vetoing that.
What I did veto is a major MMN bump for the sake of a new feature. We have
been explicitly forbidding bug fixes that would cause such a bump, so why
on earth do you think we should allow a new, non-critical feature to be
a
#2 as well.
>My opinion is 2. With a note in CHANGES about which structure changed and how it
>changed.
>
>Bill
>
>> So.. should this be changed to
>>
>> 1. no MMN bump,
>> 2. a minor MMN bump,
>> 3. a major MMN bump, or
>> 4. reverted right out of 1.3?
>>
>> I'm personally cool with any except
Rodent of Unusual Size <[EMAIL PROTECTED]> writes:
> Jeff Trawick wrote:
> >
> > No Apache user would want to wait for a crucial third-party module to
> > be rebuilt for the API change before being able to move to Apache
> > 1.3.whatever to pick up a security fix.
>
> True enough. Does that me
My opinion is 2. With a note in CHANGES about which structure changed and how it
changed.
Bill
> So.. should this be changed to
>
> 1. no MMN bump,
> 2. a minor MMN bump,
> 3. a major MMN bump, or
> 4. reverted right out of 1.3?
>
> I'm personally cool with any except #4..
> --
> #ken P-)}
>
So.. should this be changed to
1. no MMN bump,
2. a minor MMN bump,
3. a major MMN bump, or
4. reverted right out of 1.3?
I'm personally cool with any except #4..
--
#kenP-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.C
Jeff Trawick wrote:
>
> No Apache user would want to wait for a crucial third-party module to
> be rebuilt for the API change before being able to move to Apache
> 1.3.whatever to pick up a security fix.
True enough. Does that mean that you think major bumps should
be verboten after the first s
> > Bill Stoddard wrote:
> > >
> > > I question whether this chaged required a MMN major bump.
> >
> > *shrug* The core config record is exposed only to files
> > that #define CORE_PRIVATE. In our base package, that means
> >
> > include/http_config.h
> > include/http_request.h
> > main/http_con
> Bill Stoddard wrote:
> >
> > I question whether this chaged required a MMN major bump.
>
> *shrug* The core config record is exposed only to files
> that #define CORE_PRIVATE. In our base package, that means
>
> include/http_config.h
> include/http_request.h
> main/http_config.c
> main/http_
Rodent of Unusual Size <[EMAIL PROTECTED]> writes:
> I *do* have a problem with what appears to be a non-technical
> veto, Roy. 2.0 isn't going to be out for months; even after it
> is take-up will take many more, and I dispute the statement that
> we're 'done' with 1.3. Certainly there's littl
Bill Stoddard wrote:
>
> I question whether this chaged required a MMN major bump.
*shrug* The core config record is exposed only to files
that #define CORE_PRIVATE. In our base package, that means
include/http_config.h
include/http_request.h
main/http_config.c
main/http_core.c
main/http_log.
D]>
Sent: Wednesday, January 09, 2002 4:38 PM
Subject: Re: cvs commit: apache-1.3/src/main http_core.c
> -1. If this change required a MMN bump, it should never have been made
> to the 1.3 branch. That branch is done.
>
> Roy
>
>
> On Wed, Jan 09, 2002 at 07:47:03PM -,
-1. If this change required a MMN bump, it should never have been made
to the 1.3 branch. That branch is done.
Roy
On Wed, Jan 09, 2002 at 07:47:03PM -, [EMAIL PROTECTED] wrote:
> coar02/01/09 11:47:03
>
> Modified:src/include ap_mmn.h
>src/main http_cor
20 matches
Mail list logo
