httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: 1.3.18 is tagged and rolled, ready for testing
Date Wed, 21 Feb 2001 04:14:11 GMT
From: "Jim Jagielski" <>
Sent: Tuesday, February 20, 2001 9:58 PM

> Obviously, 1.3.18 is pulled (and I've removed them from /dist)
> and we'll need to release 1.3.19. I seem to recall, however,
> a quick little patch committed soon after I tagged, but can't find
> that email (and can't find where the CVS emails are being archived
> on So I'm hesitant to use the current CVS as
> a basis. Anyone recall either that commit or, even better,
> remind me where the CVS emails are archived?
> I'd also like to request that we *seriously* do a code freeze
> right now, so when we tag we are actually dealing with a known
> quantity. No more patches. No more commits. We freeze the code,
> test the snot out of it, and *then* t/r. These last minute
> patches are killing us :)
> Anyone else interested in being RM for 1.3.19 :)

Thanks for your efforts, Jim.  I agree that the code freeze is appropriate,
and sorry that this patch wasn't here over a week ago [the new Win32 cruft.]
However, I'd like to see our existing patches retained and move from here.
What isn't here tonight shouldn't be introduced prior to rolling, say on
Thursday, and then we can go on.  If someone offers a bugfix in that time,
post it to the list, and we can elect to push out the date.  But I'd like to
see a tree stable for three days before tagging.

I've already req'd the modperl list to try 'unpatching' the quick hack they
introduced to get around the problem that this patch addresses, and assure
Win32 is stable.  I'd like to propose a Friday date for that attempt.

My problem?  I could tag and roll, but I'm not entirely certain how Configure
is generated, and if I have an easy way to do so.  Other than that, I'd be
happy to rm.  Suppose I ought to brush up on 'rolling the tarballs'.

Agree last minute patches are hurting.  I'm not sure what this suggests to
Roy's model (this is the _stable_ side of development :-) but I think we need
to factor in these problems when we look at how we intend to morph the release
process for 2.0.

All that said ... I'm still happy to see 'finds' like Dean's 'broken' patch 
since this was a very appropriate fix.  Years later and we still find bugs ...
it goes to show that 2.0 will have issues for the next year - and not everyone
will be willing to 'adapt' to them.


p.s. The patch I think you are thinking of might be:

dreid       01/02/19 15:56:22

  Modified:    src/include ap_config.h
  Reflect the version of BeOS we're running on correctly.  Also, tidy
  up the defines we need.
  Revision  Changes    Path
  1.305     +2 -1      apache-1.3/src/include/ap_config.h
  Index: ap_config.h
  RCS file: /home/cvs/apache-1.3/src/include/ap_config.h,v
  retrieving revision 1.304
  retrieving revision 1.305
  diff -u -r1.304 -r1.305
  --- ap_config.h 2001/02/14 14:26:28 1.304
  +++ ap_config.h 2001/02/19 23:56:20 1.305
  @@ -910,9 +910,10 @@
   #define S_IEXEC S_IXUSR
   #elif defined(BONE)
  +#undef PLATFORM
  +#define PLATFORM "BeOS BONE"
   #define NO_KILLPG
  -#define PF_INET AF_INET
   #define S_IEXEC S_IXUSR
   #elif defined(_CX_SX)

or maybe this one:

martin      01/02/17 06:24:00

  Modified:    .        STATUS
               src/main http_vhost.c
  This patch works around dereferencing a zero server pointer.
  The assumption is that these come from a misconfiguration, and don't
  hurt the running server (because the vhost resolution works in the
  opposite direction, from server to vhost). It only hurts in the "-S"
  command, and that can be avoided by printing a WARNING about the
  Revision  Changes    Path
  1.922     +6 -6      apache-1.3/STATUS
  Index: STATUS
  RCS file: /home/cvs/apache-1.3/STATUS,v
  retrieving revision 1.921
  retrieving revision 1.922
  diff -u -u -r1.921 -r1.922
  --- STATUS 2001/02/17 14:18:21 1.921
  +++ STATUS 2001/02/17 14:23:58 1.922
  @@ -1,5 +1,5 @@
     1.3 STATUS:
  -  Last modified at [$Date: 2001/02/17 14:18:21 $]
  +  Last modified at [$Date: 2001/02/17 14:23:58 $]
  @@ -36,11 +36,6 @@
  -    * Martin observed a core dump because a ipaddr_chain struct contains
  -      a NULL-"server" pointer when being dereferenced by invoking "httpd -S".
  -      See Message-ID: <>
  -      Status: Others attempting to duplicate
       * Segfault potential when forming a URI string from a
         uri_components structure, if the structure lacks a scheme.
         There are 3 proposed patches, one of which must be folded
  @@ -53,6 +48,11 @@
                  Fix#3 (ap_unparse_uri_components): Martin +0 (after 1.3.18?)
  +    * Martin observed a core dump because a ipaddr_chain struct contains
  +      a NULL-"server" pointer when being dereferenced by invoking "httpd -S".
  +      See Message-ID: <>
  +      Status: Workaround enabled. Clean solution can come after 1.3.18
       * long pathnames with many components and no AllowOverride None
         Workaround is to define <Directory /> with AllowOverride None,
  1.27      +4 -1      apache-1.3/src/main/http_vhost.c
  Index: http_vhost.c
  RCS file: /home/cvs/apache-1.3/src/main/http_vhost.c,v
  retrieving revision 1.26
  retrieving revision 1.27
  diff -u -u -r1.26 -r1.27
  --- http_vhost.c 2001/02/17 11:17:45 1.26
  +++ http_vhost.c 2001/02/17 14:24:00 1.27
  @@ -432,7 +432,10 @@
   buf[len-1] = '*';
       if (ic->names == NULL) {
  - fprintf(f, "%-22s %s (%s:%u)\n", buf, ic->server->server_hostname,
  + if (ic->server == NULL)
  +     fprintf(f, "%-22s WARNING: No <VirtualHost> defined for this NameVirtualHost!\n",
  + else
  +     fprintf(f, "%-22s %s (%s:%u)\n", buf, ic->server->server_hostname,
   ic->server->defn_name, ic->server->defn_line_number);

View raw message