You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by co...@apache.org on 2002/01/09 20:47:03 UTC
cvs commit: apache-1.3/src/main http_core.c
coar 02/01/09 11:47:03
Modified: src/include ap_mmn.h
src/main http_core.c
Log:
Whoops, forgot to bump MMN. Major bump because of a change
to the semi-private core_dir_config structure. (Also fix a
stale comment from an earlier version of the FileETag patch.)
Revision Changes Path
1.56 +4 -2 apache-1.3/src/include/ap_mmn.h
Index: ap_mmn.h
===================================================================
RCS file: /home/cvs/apache-1.3/src/include/ap_mmn.h,v
retrieving revision 1.55
retrieving revision 1.56
diff -u -u -r1.55 -r1.56
--- ap_mmn.h 30 Nov 2001 14:08:43 -0000 1.55
+++ ap_mmn.h 9 Jan 2002 19:47:03 -0000 1.56
@@ -233,14 +233,16 @@
* 19990320.10 - add ap_is_rdirectory() and ap_stripprefix()
* 20011130.11 - Add a couple of fields, callback_data and
* filter_callback to the end of buff.h
+ * 20020108.0 - Add some fields to the end of the core_dir_config
+ * structure
*/
#define MODULE_MAGIC_COOKIE 0x41503133UL /* "AP13" */
#ifndef MODULE_MAGIC_NUMBER_MAJOR
-#define MODULE_MAGIC_NUMBER_MAJOR 19990320
+#define MODULE_MAGIC_NUMBER_MAJOR 20020108
#endif
-#define MODULE_MAGIC_NUMBER_MINOR 11 /* 0...n */
+#define MODULE_MAGIC_NUMBER_MINOR 0 /* 0...n */
/* Useful for testing for features. */
#define AP_MODULE_MAGIC_AT_LEAST(major,minor) \
1.302 +1 -1 apache-1.3/src/main/http_core.c
Index: http_core.c
===================================================================
RCS file: /home/cvs/apache-1.3/src/main/http_core.c,v
retrieving revision 1.301
retrieving revision 1.302
diff -u -u -r1.301 -r1.302
--- http_core.c 5 Jan 2002 17:13:02 -0000 1.301
+++ http_core.c 9 Jan 2002 19:47:03 -0000 1.302
@@ -3013,7 +3013,7 @@
#endif /* CHARSET_EBCDIC */
/*
- * Note whether file inodes may be used when forming ETag values.
+ * Note what data should be used when forming file ETag values.
* It would be nicer to do this as an ITERATE, but then we couldn't
* remember the +/- state properly.
*/
Re: cvs commit: apache-1.3/src/main http_core.c
Posted by Jeff Trawick <tr...@attglobal.net>.
Rodent of Unusual Size <Ke...@Golux.Com> 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 mean that you think major bumps should
> be verboten after the first security fix goes out? Or after
> we go GA with any m.n.0 version? Both are contrary to past
> behaviour.. :-)
neither... I'm not even saying that major bumps should be verboten in
a series if we haven't shipped our last security fix :) (yeah,
impossible anyway)
I just wanted a consideration of what we would lose with an API bump
vs. what we would gain.
start over...
Let A be the value to us and to Apache 1.3 users if they don't have to
deal with binary compatibility to move to some hypothetical new Apache 1.3
version that fixes some critical problem.
Let B be the value to us and to Apache 1.3 users from a new function
whose addition requires us to break binary compatibility.
If it isn't very clear that B is greater than A, then I don't think
such a change should go in.
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: cvs commit: apache-1.3/src/main http_core.c
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
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 security fix goes out? Or after
we go GA with any m.n.0 version? Both are contrary to past
behaviour.. :-)
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"All right everyone! Step away from the glowing hamburger!"
Re: cvs commit: apache-1.3/src/main http_core.c
Posted by Jeff Trawick <tr...@attglobal.net>.
Rodent of Unusual Size <Ke...@Golux.Com> 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 little development
> being done on it, but I think that's a matter of temperament,
> not policy. I do not see why functionality desired by existing
> users should be postponed indefinitely when it could be available
> now.
Since we're talking general principles...
Any improvements which require an API change need to be weighed against
the fact that an API change increases the effort required by Apache
1.3 users to pick up fixes, particularly those users which use
binary-only third-party modules.
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.
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: cvs commit: apache-1.3/src/main http_core.c
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
"William A. Rowe, Jr." wrote:
>
> From: "Roy T. Fielding" <fi...@ebuilt.com>
> 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. :-)
Okey, MMN bump being changed to minor..
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"All right everyone! Step away from the glowing hamburger!"
Re: cvs commit: apache-1.3/src/main http_core.c
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Roy T. Fielding" <fi...@ebuilt.com>
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 forthcoming?
Re: cvs commit: apache-1.3/src/main http_core.c
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
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
added to the feature-frozen development branch that would require every
single 1.3.x module on the planet to be recompiled? It has been something
like two years since the last time we allowed that.
A minor MMN bump should be sufficient. If not, the feature doesn't belong
in the 1.3 tree.
....Roy
Re: cvs commit: apache-1.3/src/main http_core.c
Posted by Jim Jagielski <ji...@jaguNET.com>.
#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 #4..
>> --
>> #ken P-)}
>>
>> Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
>> Author, developer, opinionist http://Apache-Server.Com/
>>
>> "All right everyone! Step away from the glowing hamburger!"
>>
--
===========================================================================
Jim Jagielski [|] jim@jaguNET.com [|] http://www.jaguNET.com/
"A society that will trade a little liberty for a little order
will lose both and deserve neither"
Re: cvs commit: apache-1.3/src/main http_core.c
Posted by Bill Stoddard <bi...@wstoddard.com>.
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-)}
>
> Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
> Author, developer, opinionist http://Apache-Server.Com/
>
> "All right everyone! Step away from the glowing hamburger!"
>
Re: cvs commit: apache-1.3/src/main http_core.c
Posted by Greg Stein <gs...@lyra.org>.
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,
> 3. a major MMN bump, or
> 4. reverted right out of 1.3?
>
> I'm personally cool with any except #4..
> --
> #ken P-)}
>
> Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
> Author, developer, opinionist http://Apache-Server.Com/
>
> "All right everyone! Step away from the glowing hamburger!"
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apache-1.3/src/main http_core.c
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
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-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"All right everyone! Step away from the glowing hamburger!"
Re: cvs commit: apache-1.3/src/main http_core.c
Posted by Bill Stoddard <bi...@wstoddard.com>.
> > 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.c
> > main/http_main.c
> > main/http_protocol.c
> > main/http_request.c
> > main/http_vhost.c
> > main/util_script.c
> > modules/experimental/mod_mmap_static.c
> > modules/proxy/mod_proxy.c
> > modules/standard/mod_rewrite.h
> > modules/standard/mod_so.c
> > modules/standard/mod_status.c
> > os/netware/mod_tls.c
> > os/win32/mod_isapi.c
> >
> > Whether those files actually make use of the structure is
> > another issue entirely; here are the ones that do:
> >
> > main/http_core.c
> > main/http_protocol.c
> > main/http_request.c
> > main/util_script.c
> >
> > All of those are going to get rebuilt when the http_core.h
> > file changes, so it could be justified that there be no bump
> > at all.
> >
> > However, who knows what 3P modules use the structure? They
> > probably oughtn't anyway, so I've no problem with changing
> > this to a minor bump or even none.
>
> If they do simple accesses to the structure, it shouldn;t matter since the structure was
> extended from the bottom, right? However, if they do stuff like sizeof(struct blah) and
> memcpy the Apache structure around, they are screwed. Shouldn't be doing that anyway I
> think.
>
> Bill
>
We really should note when the MMN (minor or major) is changed in the CHANGES file. If the
minor is changed, we need to explicitly state in the CHANGES file what strutures changed,
if any changed just in case someone is doing funky stuff mentioned above that relies on
knowing the size of the structure.
Bill
Re: cvs commit: apache-1.3/src/main http_core.c
Posted by Bill Stoddard <bi...@wstoddard.com>.
> 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.c
> main/http_main.c
> main/http_protocol.c
> main/http_request.c
> main/http_vhost.c
> main/util_script.c
> modules/experimental/mod_mmap_static.c
> modules/proxy/mod_proxy.c
> modules/standard/mod_rewrite.h
> modules/standard/mod_so.c
> modules/standard/mod_status.c
> os/netware/mod_tls.c
> os/win32/mod_isapi.c
>
> Whether those files actually make use of the structure is
> another issue entirely; here are the ones that do:
>
> main/http_core.c
> main/http_protocol.c
> main/http_request.c
> main/util_script.c
>
> All of those are going to get rebuilt when the http_core.h
> file changes, so it could be justified that there be no bump
> at all.
>
> However, who knows what 3P modules use the structure? They
> probably oughtn't anyway, so I've no problem with changing
> this to a minor bump or even none.
If they do simple accesses to the structure, it shouldn;t matter since the structure was
extended from the bottom, right? However, if they do stuff like sizeof(struct blah) and
memcpy the Apache structure around, they are screwed. Shouldn't be doing that anyway I
think.
Bill
Re: cvs commit: apache-1.3/src/main http_core.c
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
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.c
main/http_main.c
main/http_protocol.c
main/http_request.c
main/http_vhost.c
main/util_script.c
modules/experimental/mod_mmap_static.c
modules/proxy/mod_proxy.c
modules/standard/mod_rewrite.h
modules/standard/mod_so.c
modules/standard/mod_status.c
os/netware/mod_tls.c
os/win32/mod_isapi.c
Whether those files actually make use of the structure is
another issue entirely; here are the ones that do:
main/http_core.c
main/http_protocol.c
main/http_request.c
main/util_script.c
All of those are going to get rebuilt when the http_core.h
file changes, so it could be justified that there be no bump
at all.
However, who knows what 3P modules use the structure? They
probably oughtn't anyway, so I've no problem with changing
this to a minor bump or even none.
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 little development
being done on it, but I think that's a matter of temperament,
not policy. I do not see why functionality desired by existing
users should be postponed indefinitely when it could be available
now.
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"All right everyone! Step away from the glowing hamburger!"
Re: cvs commit: apache-1.3/src/main http_core.c
Posted by Bill Stoddard <bi...@wstoddard.com>.
I question whether this chaged required a MMN major bump. A semi-public structure was
extended (new field added to the end) which should not require a bump in the major.
Bill
----- Original Message -----
From: "Roy T. Fielding" <fi...@ebuilt.com>
To: <de...@httpd.apache.org>
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 -0000, coar@apache.org wrote:
> > coar 02/01/09 11:47:03
> >
> > Modified: src/include ap_mmn.h
> > src/main http_core.c
> > Log:
> > Whoops, forgot to bump MMN. Major bump because of a change
> > to the semi-private core_dir_config structure. (Also fix a
> > stale comment from an earlier version of the FileETag patch.)
> >
> > Revision Changes Path
> > 1.56 +4 -2 apache-1.3/src/include/ap_mmn.h
> >
> > Index: ap_mmn.h
> > ===================================================================
> > RCS file: /home/cvs/apache-1.3/src/include/ap_mmn.h,v
> > retrieving revision 1.55
> > retrieving revision 1.56
> > diff -u -u -r1.55 -r1.56
> > --- ap_mmn.h 30 Nov 2001 14:08:43 -0000 1.55
> > +++ ap_mmn.h 9 Jan 2002 19:47:03 -0000 1.56
> > @@ -233,14 +233,16 @@
> > * 19990320.10 - add ap_is_rdirectory() and ap_stripprefix()
> > * 20011130.11 - Add a couple of fields, callback_data and
> > * filter_callback to the end of buff.h
> > + * 20020108.0 - Add some fields to the end of the core_dir_config
> > + * structure
> > */
> >
> > #define MODULE_MAGIC_COOKIE 0x41503133UL /* "AP13" */
> >
> > #ifndef MODULE_MAGIC_NUMBER_MAJOR
> > -#define MODULE_MAGIC_NUMBER_MAJOR 19990320
> > +#define MODULE_MAGIC_NUMBER_MAJOR 20020108
> > #endif
> > -#define MODULE_MAGIC_NUMBER_MINOR 11 /* 0...n */
> > +#define MODULE_MAGIC_NUMBER_MINOR 0 /* 0...n */
> >
> > /* Useful for testing for features. */
> > #define AP_MODULE_MAGIC_AT_LEAST(major,minor) \
> >
> >
> >
> > 1.302 +1 -1 apache-1.3/src/main/http_core.c
> >
> > Index: http_core.c
> > ===================================================================
> > RCS file: /home/cvs/apache-1.3/src/main/http_core.c,v
> > retrieving revision 1.301
> > retrieving revision 1.302
> > diff -u -u -r1.301 -r1.302
> > --- http_core.c 5 Jan 2002 17:13:02 -0000 1.301
> > +++ http_core.c 9 Jan 2002 19:47:03 -0000 1.302
> > @@ -3013,7 +3013,7 @@
> > #endif /* CHARSET_EBCDIC */
> >
> > /*
> > - * Note whether file inodes may be used when forming ETag values.
> > + * Note what data should be used when forming file ETag values.
> > * It would be nicer to do this as an ITERATE, but then we couldn't
> > * remember the +/- state properly.
> > */
> >
> >
> >
>
Re: cvs commit: apache-1.3/src/main http_core.c
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
-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 -0000, coar@apache.org wrote:
> coar 02/01/09 11:47:03
>
> Modified: src/include ap_mmn.h
> src/main http_core.c
> Log:
> Whoops, forgot to bump MMN. Major bump because of a change
> to the semi-private core_dir_config structure. (Also fix a
> stale comment from an earlier version of the FileETag patch.)
>
> Revision Changes Path
> 1.56 +4 -2 apache-1.3/src/include/ap_mmn.h
>
> Index: ap_mmn.h
> ===================================================================
> RCS file: /home/cvs/apache-1.3/src/include/ap_mmn.h,v
> retrieving revision 1.55
> retrieving revision 1.56
> diff -u -u -r1.55 -r1.56
> --- ap_mmn.h 30 Nov 2001 14:08:43 -0000 1.55
> +++ ap_mmn.h 9 Jan 2002 19:47:03 -0000 1.56
> @@ -233,14 +233,16 @@
> * 19990320.10 - add ap_is_rdirectory() and ap_stripprefix()
> * 20011130.11 - Add a couple of fields, callback_data and
> * filter_callback to the end of buff.h
> + * 20020108.0 - Add some fields to the end of the core_dir_config
> + * structure
> */
>
> #define MODULE_MAGIC_COOKIE 0x41503133UL /* "AP13" */
>
> #ifndef MODULE_MAGIC_NUMBER_MAJOR
> -#define MODULE_MAGIC_NUMBER_MAJOR 19990320
> +#define MODULE_MAGIC_NUMBER_MAJOR 20020108
> #endif
> -#define MODULE_MAGIC_NUMBER_MINOR 11 /* 0...n */
> +#define MODULE_MAGIC_NUMBER_MINOR 0 /* 0...n */
>
> /* Useful for testing for features. */
> #define AP_MODULE_MAGIC_AT_LEAST(major,minor) \
>
>
>
> 1.302 +1 -1 apache-1.3/src/main/http_core.c
>
> Index: http_core.c
> ===================================================================
> RCS file: /home/cvs/apache-1.3/src/main/http_core.c,v
> retrieving revision 1.301
> retrieving revision 1.302
> diff -u -u -r1.301 -r1.302
> --- http_core.c 5 Jan 2002 17:13:02 -0000 1.301
> +++ http_core.c 9 Jan 2002 19:47:03 -0000 1.302
> @@ -3013,7 +3013,7 @@
> #endif /* CHARSET_EBCDIC */
>
> /*
> - * Note whether file inodes may be used when forming ETag values.
> + * Note what data should be used when forming file ETag values.
> * It would be nicer to do this as an ITERATE, but then we couldn't
> * remember the +/- state properly.
> */
>
>
>