You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe, Jr." <wr...@lnd.com> on 2000/06/11 20:57:17 UTC
[patch 1.3.13] defaulted servername
My proposed solution is attached. I'm sure someone else could
do better, or improve upon this...
> From: William A. Rowe, Jr. [mailto:wrowe@lnd.com]
> Sent: Sunday, June 11, 2000 1:17 PM
>
> This is -not- a Win32 post, for those trying to avoid filling their
> heads with that drivel :-) Please read on...
>
> I've been waiting for some space on my overly full plate to look for
> the 'correct' solution to this...
>
> > From: stoddard@locus.apache.org [mailto:stoddard@locus.apache.org]
> > Sent: Wednesday, May 24, 2000 12:53 PM
> >
> > stoddard 00/05/24 10:53:20
> >
> > Modified: conf httpd.conf-dist-win
> > src CHANGES
> > Log:
> > Win32: Set ServerName to 127.0.0.1 in the default windows
> httpd.conf file.
> > PR: 5509, 5783, 5953, 5903, 5983, 5259, 5515, 5858
> >
> > Submitted by: Oliver Wendemuth <ow...@ko.hbv.de>
> >
> > Index: httpd.conf-dist-win
> >
> ===================================================================
> > @@ -230,7 +230,7 @@
> > # You will have to access it by its address (e.g.,
> http://123.45.67.89/)
> > # anyway, and this will make redirections work in a sensible way.
> > #
> > -#ServerName new.host.name
> > +ServerName 127.0.0.1
>
> Why then, doesn't the existing default code work in Win32?
>
> First, MS allows a user to 'name' their machine with a
> completely bogus
> name, and this is what is being retrieved (joes pc would be
> an example).
>
> Second, ap_get_local_host() has the following code (BEOS path omitted)
>
> if (gethostname(str, sizeof(str) - 1) != 0) {
> perror("Unable to gethostname");
> exit(1);
> } // we are good so far...
> str[sizeof(str) - 1] = '\0';
> if ((!(p = gethostbyname(str))) || (!(server_hostname =
> find_fqdn(a, p)))) {
> // and we land here because find_fdqn fails...
> fprintf(stderr, "%s: cannot determine local host
> name.\n", ap_server_argv0);
>
> Ok, so digging down into find_fdqn()
>
> if (!strchr(p->h_name, '.')) { // we refuse any name
> sans the '.'s
> for (x = 0; p->h_aliases[x]; ++x) {
> if (strchr(p->h_aliases[x], '.') &&
> (!strncasecmp(p->h_aliases[x], p->h_name,
> strlen(p->h_name))))
> return ap_pstrdup(a, p->h_aliases[x]);
> }
> return NULL; // and uneqivocably die here...
>
> so this is no solution. Two options from here (others may choose):
>
> 1) On failure of find_fdqn, return the ip address string
> -rather than die-
>
> 2) Accept bogosity of a non-'.' name with -strong warnings-
> that the private
> name will not be recognized by the network-at-large, and continue.
>
> In -either- case we will proceed to look for an fdqn, if one
> is available.
>
> Neither solution is complete - we should be attempting a true
> reverse-dns
> test, but I'll let someone else commit that if it's their desire.
>
> Which solution (or what other solution) can we live with to kill the
> explicit ServerName in the 1.3.13 httpd.conf-dist-win?
This patch is a variation of option 1, with additional warnings that
assumptions have been made...
Re: voting and vetoes (was: Re: [patch 1.3.13] defaulted servername)
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Jun 12, 2000 at 08:13:24PM -0500, William A. Rowe, Jr. wrote:
>...
> But my point is that a veto must be backed by a -reason-, and I've
> never believed that "I just don't like it" is a reason... but
> perhaps that's why I've been single again for these years :-)
Yup. But a -1 without a reason (for safety) should be read as "veto, but I
forgot to clarify why."
:-)
--
Greg Stein, http://www.lyra.org/
Re: voting and vetoes (was: Re: [patch 1.3.13] defaulted servername)
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Greg Stein wrote:
>
> Um... let's clarify here people...
>
> -0 means "I don't like it. This is not a veto."
> -1 means "veto"
Um, no. Go read the guidelines again. -0 means "I don't
like it, and I may or may not be able to explain why, but
I'm not going to stand in the way." -1 is a vote against,
and only a veto when consensus is needed -- which it isn't
here. Bill has used -1 correctly.
--
#ken P-)}
Ken Coar <http://Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Apache-Server.Com/>
"Apache Server Unleashed" <http://ApacheUnleashed.Com/>
RE: voting and vetoes (was: Re: [patch 1.3.13] defaulted servername)
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: Monday, June 12, 2000 7:56 PM
>
> On Mon, Jun 12, 2000 at 07:40:57PM -0500, William A. Rowe, Jr. wrote:
> >...
> > > RTFM. I'm -1 (not a veto though).
> >...
> > If anyone has comments, please post them to the list before
> > tommorow evening. I wouldn't consider your -1 a veto, in any
> > case Bill, because you really didn't explain -what- bothers
> > you exactly :-)
>
> Um... let's clarify here people...
>
> -0 means "I don't like it. This is not a veto."
> -1 means "veto"
>
> We can introduce some middle ground, but a lot of this "-1
> but not a veto"
> is starting to get confusing. I rue the day when somebody vetoes, but
> another person just sees it as a vote :-)
That's what I originally thought of a -1. Other comments have been
implying otherwise (what, a non-veto -1 and four +1's is the +3
required? sillyness :-)
But my point is that a veto must be backed by a -reason-, and I've
never believed that "I just don't like it" is a reason... but
perhaps that's why I've been single again for these years :-)
voting and vetoes (was: Re: [patch 1.3.13] defaulted servername)
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Jun 12, 2000 at 07:40:57PM -0500, William A. Rowe, Jr. wrote:
>...
> > RTFM. I'm -1 (not a veto though).
>...
> If anyone has comments, please post them to the list before
> tommorow evening. I wouldn't consider your -1 a veto, in any
> case Bill, because you really didn't explain -what- bothers
> you exactly :-)
Um... let's clarify here people...
-0 means "I don't like it. This is not a veto."
-1 means "veto"
We can introduce some middle ground, but a lot of this "-1 but not a veto"
is starting to get confusing. I rue the day when somebody vetoes, but
another person just sees it as a vote :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
RE: [patch 1.3.13] defaulted servername
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
> From: Bill Stoddard [mailto:stoddard@raleigh.ibm.com]
> Sent: Monday, June 12, 2000 8:10 AM
>
> > My proposed solution is attached. I'm sure someone else could
> > do better, or improve upon this...
>
> I don't like the direction this is going in. Adding
> complexity (and potentially
> non-intuitive behaviour) to Apache in an attempt to
> accomodate people who don't bother to
> RTFM. I'm -1 (not a veto though).
I really strongly disagree with your disagreement, after thinking
this through.
Right now we create a ServerName and go quietly on. If the
server name has no dots, we die.
This is stupid.
My patch already warns that it is making an assumption of
the ServerName (and we all know what happens when we ass u me
things, right kids :-?) and displays the assumed name.
Ok, no dotted name? Then have an IP (still displayed that
the server is assuming the name...)
I believe I ought to wrap it with ap_log_error bleh. Other
than that, I find no reason not to commit this patch.
If anyone has comments, please post them to the list before
tommorow evening. I wouldn't consider your -1 a veto, in any
case Bill, because you really didn't explain -what- bothers
you exactly :-)
Bill
RE: [patch 1.3.13] defaulted servername
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
> From: Bill Stoddard [mailto:stoddard@raleigh.ibm.com]
> Sent: Monday, June 12, 2000 8:10 AM
>
> > My proposed solution is attached. I'm sure someone else could
> > do better, or improve upon this...
> >
>
> I don't like the direction this is going in. Adding
> complexity (and potentially
> non-intuitive behaviour) to Apache in an attempt to
> accomodate people who don't bother to
> RTFM. I'm -1 (not a veto though).
But adding in a hardcoded ServerName is -far- worse.
IMHO, we strip out the ap_get_local_host and find_fqdn code
(which is arguably bogus, anyway), or we do it right with the
ip address string as the name of a machine with a bogus name.
Re: [patch 1.3.13] defaulted servername
Posted by Bill Stoddard <st...@raleigh.ibm.com>.
> My proposed solution is attached. I'm sure someone else could
> do better, or improve upon this...
>
I don't like the direction this is going in. Adding complexity (and potentially
non-intuitive behaviour) to Apache in an attempt to accomodate people who don't bother to
RTFM. I'm -1 (not a veto though).
Bill
RE: [patch-final 1.3.13] defaulted servername
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
Yes, but thanks for the tickler... since we are piloting a new
install script, now would be the time for that suggestion :-)
Frankly, I trust winsock to pick a better name than the average
user would :-)
> -----Original Message-----
> From: Manoj Kasichainula [mailto:manoj@io.com]
> Sent: Thursday, June 15, 2000 1:48 AM
> To: new-httpd@apache.org
> Subject: Re: [patch-final 1.3.13] defaulted servername
>
>
> On Wed, Jun 14, 2000 at 03:04:04PM -0500, William A. Rowe, Jr. wrote:
> > Here is the final patch... it gets around several otherwise fatal
> > errors by using a numeric IP hostname. Failure of gethostname()
> > is compensated by the host name "127.0.0.1". In all cases (unlike
> > the current code) their assumption is reported and logged as an
> > error, to push them to properly set the ServerName directive.
>
> No opinion on this, but did my earlier suggestion of just asking for
> the ServerName during the installation get through to the list?
>
Re: [patch-final 1.3.13] defaulted servername
Posted by Manoj Kasichainula <ma...@io.com>.
On Wed, Jun 14, 2000 at 03:04:04PM -0500, William A. Rowe, Jr. wrote:
> Here is the final patch... it gets around several otherwise fatal
> errors by using a numeric IP hostname. Failure of gethostname()
> is compensated by the host name "127.0.0.1". In all cases (unlike
> the current code) their assumption is reported and logged as an
> error, to push them to properly set the ServerName directive.
No opinion on this, but did my earlier suggestion of just asking for
the ServerName during the installation get through to the list?
Re: [patch-final 1.3.13] defaulted servername
Posted by Bill Stoddard <st...@raleigh.ibm.com>.
+1
Consider changing the ServerName 127.0.0.1 back to ServerName your.host.name (or whatever
the string was).
Bill
----- Original Message -----
From: William A. Rowe, Jr. <wr...@lnd.com>
To: <ne...@apache.org>
Sent: Wednesday, June 14, 2000 4:04 PM
Subject: RE: [patch-final 1.3.13] defaulted servername
> Here is the final patch... it gets around several otherwise fatal
> errors by using a numeric IP hostname. Failure of gethostname()
> is compensated by the host name "127.0.0.1". In all cases (unlike
> the current code) their assumption is reported and logged as an
> error, to push them to properly set the ServerName directive.
>
> *Please* review and vote... I agree with the assertion that the
> users should RTFM... but that doesn't always happen, even in Unix :-)
> These error messages are more comprehensive, and I've localized all
> the changes to the ap_get_local_host function.
>
> Bill
>
> p.s. I consider change to httpd.conf-dist-win manditory, since it is
> now out of sync with httpd.conf-dist.
>
> > From: William A. Rowe, Jr. [mailto:wrowe@lnd.com]
> > Sent: Sunday, June 11, 2000 1:57 PM
> >
> > My proposed solution is attached. I'm sure someone else could
> > do better, or improve upon this...
> >
> > > From: William A. Rowe, Jr. [mailto:wrowe@lnd.com]
> > > Sent: Sunday, June 11, 2000 1:17 PM
> > >
> > > This is -not- a Win32 post, for those trying to avoid filling their
> > > heads with that drivel :-) Please read on...
> > >
> > > I've been waiting for some space on my overly full plate to
> > > look for the 'correct' solution to this...
> > >
> > > > From: stoddard@locus.apache.org [mailto:stoddard@locus.apache.org]
> > > > Sent: Wednesday, May 24, 2000 12:53 PM
> > > >
> > > > stoddard 00/05/24 10:53:20
> > > >
> > > > Modified: conf httpd.conf-dist-win
> > > > src CHANGES
> > > > Log:
> > > > Win32: Set ServerName to 127.0.0.1 in the default windows
> > > httpd.conf file.
> > > > PR: 5509, 5783, 5953, 5903, 5983, 5259, 5515, 5858
> > > >
> > > > Submitted by: Oliver Wendemuth <ow...@ko.hbv.de>
> > > >
> > > > Index: httpd.conf-dist-win
> > > >
> > > ===================================================================
> > > > @@ -230,7 +230,7 @@
> > > > # You will have to access it by its address (e.g.,
> > > http://123.45.67.89/)
> > > > # anyway, and this will make redirections work in a sensible way.
> > > > #
> > > > -#ServerName new.host.name
> > > > +ServerName 127.0.0.1
> > >
> > > Why then, doesn't the existing default code work in Win32?
> > >
> > > First, MS allows a user to 'name' their machine with a
> > > completely bogus
> > > name, and this is what is being retrieved (joes pc would be
> > > an example).
> > >
> > > Second, ap_get_local_host() has the following code (BEOS
> > path omitted)
> > >
> > > if (gethostname(str, sizeof(str) - 1) != 0) {
> > > perror("Unable to gethostname");
> > > exit(1);
> > > } // we are good so far...
> > > str[sizeof(str) - 1] = '\0';
> > > if ((!(p = gethostbyname(str))) || (!(server_hostname =
> > > find_fqdn(a, p)))) {
> > > // and we land here because find_fdqn fails...
> > > fprintf(stderr, "%s: cannot determine local host
> > > name.\n", ap_server_argv0);
> > >
> > > Ok, so digging down into find_fdqn()
> > >
> > > if (!strchr(p->h_name, '.')) { // we refuse any name
> > > sans the '.'s
> > > for (x = 0; p->h_aliases[x]; ++x) {
> > > if (strchr(p->h_aliases[x], '.') &&
> > > (!strncasecmp(p->h_aliases[x], p->h_name,
> > > strlen(p->h_name))))
> > > return ap_pstrdup(a, p->h_aliases[x]);
> > > }
> > > return NULL; // and uneqivocably die here...
> > >
> > > so this is no solution. Two options from here (others may choose):
> > >
> > > 1) On failure of find_fdqn, return the ip address string
> > > -rather than die-
>
> This is the attached patch.
>
> > > 2) Accept bogosity of a non-'.' name with -strong warnings-
> > > that the private name will not be recognized by the
> > > network-at-large, and continue.
>
> I finally rejected this solution out of hand.
>
> > > In -either- case we will proceed to look for an fdqn, if one
> > > is available.
> > >
> > > Neither solution is complete - we should be attempting a true
> > > reverse-dns
> > > test, but I'll let someone else commit that if it's their desire.
> > >
> > > Which solution (or what other solution) can we live with to kill the
> > > explicit ServerName in the 1.3.13 httpd.conf-dist-win?
> >
> > This patch is a variation of option 1, with additional warnings that
> > assumptions have been made...
>
> And I think this is key for *ALL* platforms to be warned that the server
> conf is an assumption!
>
Re: [patch-final 1.3.13] defaulted servername
Posted by Bill Stoddard <st...@raleigh.ibm.com>.
I'll review it but it will be later this evening or tomorrow.
Bill
----- Original Message -----
From: William A. Rowe, Jr. <wr...@lnd.com>
To: <ne...@apache.org>
Sent: Wednesday, June 14, 2000 4:04 PM
Subject: RE: [patch-final 1.3.13] defaulted servername
> Here is the final patch... it gets around several otherwise fatal
> errors by using a numeric IP hostname. Failure of gethostname()
> is compensated by the host name "127.0.0.1". In all cases (unlike
> the current code) their assumption is reported and logged as an
> error, to push them to properly set the ServerName directive.
>
> *Please* review and vote... I agree with the assertion that the
> users should RTFM... but that doesn't always happen, even in Unix :-)
> These error messages are more comprehensive, and I've localized all
> the changes to the ap_get_local_host function.
>
> Bill
>
> p.s. I consider change to httpd.conf-dist-win manditory, since it is
> now out of sync with httpd.conf-dist.
>
> > From: William A. Rowe, Jr. [mailto:wrowe@lnd.com]
> > Sent: Sunday, June 11, 2000 1:57 PM
> >
> > My proposed solution is attached. I'm sure someone else could
> > do better, or improve upon this...
> >
> > > From: William A. Rowe, Jr. [mailto:wrowe@lnd.com]
> > > Sent: Sunday, June 11, 2000 1:17 PM
> > >
> > > This is -not- a Win32 post, for those trying to avoid filling their
> > > heads with that drivel :-) Please read on...
> > >
> > > I've been waiting for some space on my overly full plate to
> > > look for the 'correct' solution to this...
> > >
> > > > From: stoddard@locus.apache.org [mailto:stoddard@locus.apache.org]
> > > > Sent: Wednesday, May 24, 2000 12:53 PM
> > > >
> > > > stoddard 00/05/24 10:53:20
> > > >
> > > > Modified: conf httpd.conf-dist-win
> > > > src CHANGES
> > > > Log:
> > > > Win32: Set ServerName to 127.0.0.1 in the default windows
> > > httpd.conf file.
> > > > PR: 5509, 5783, 5953, 5903, 5983, 5259, 5515, 5858
> > > >
> > > > Submitted by: Oliver Wendemuth <ow...@ko.hbv.de>
> > > >
> > > > Index: httpd.conf-dist-win
> > > >
> > > ===================================================================
> > > > @@ -230,7 +230,7 @@
> > > > # You will have to access it by its address (e.g.,
> > > http://123.45.67.89/)
> > > > # anyway, and this will make redirections work in a sensible way.
> > > > #
> > > > -#ServerName new.host.name
> > > > +ServerName 127.0.0.1
> > >
> > > Why then, doesn't the existing default code work in Win32?
> > >
> > > First, MS allows a user to 'name' their machine with a
> > > completely bogus
> > > name, and this is what is being retrieved (joes pc would be
> > > an example).
> > >
> > > Second, ap_get_local_host() has the following code (BEOS
> > path omitted)
> > >
> > > if (gethostname(str, sizeof(str) - 1) != 0) {
> > > perror("Unable to gethostname");
> > > exit(1);
> > > } // we are good so far...
> > > str[sizeof(str) - 1] = '\0';
> > > if ((!(p = gethostbyname(str))) || (!(server_hostname =
> > > find_fqdn(a, p)))) {
> > > // and we land here because find_fdqn fails...
> > > fprintf(stderr, "%s: cannot determine local host
> > > name.\n", ap_server_argv0);
> > >
> > > Ok, so digging down into find_fdqn()
> > >
> > > if (!strchr(p->h_name, '.')) { // we refuse any name
> > > sans the '.'s
> > > for (x = 0; p->h_aliases[x]; ++x) {
> > > if (strchr(p->h_aliases[x], '.') &&
> > > (!strncasecmp(p->h_aliases[x], p->h_name,
> > > strlen(p->h_name))))
> > > return ap_pstrdup(a, p->h_aliases[x]);
> > > }
> > > return NULL; // and uneqivocably die here...
> > >
> > > so this is no solution. Two options from here (others may choose):
> > >
> > > 1) On failure of find_fdqn, return the ip address string
> > > -rather than die-
>
> This is the attached patch.
>
> > > 2) Accept bogosity of a non-'.' name with -strong warnings-
> > > that the private name will not be recognized by the
> > > network-at-large, and continue.
>
> I finally rejected this solution out of hand.
>
> > > In -either- case we will proceed to look for an fdqn, if one
> > > is available.
> > >
> > > Neither solution is complete - we should be attempting a true
> > > reverse-dns
> > > test, but I'll let someone else commit that if it's their desire.
> > >
> > > Which solution (or what other solution) can we live with to kill the
> > > explicit ServerName in the 1.3.13 httpd.conf-dist-win?
> >
> > This patch is a variation of option 1, with additional warnings that
> > assumptions have been made...
>
> And I think this is key for *ALL* platforms to be warned that the server
> conf is an assumption!
>
RE: [patch-final 1.3.13] defaulted servername
Posted by James Sutherland <ja...@cam.ac.uk>.
On Wed, 14 Jun 2000, William A. Rowe, Jr. wrote:
> Here is the final patch... it gets around several otherwise fatal
> errors by using a numeric IP hostname. Failure of gethostname()
> is compensated by the host name "127.0.0.1". In all cases (unlike
> the current code) their assumption is reported and logged as an
> error, to push them to properly set the ServerName directive.
>
> *Please* review and vote... I agree with the assertion that the
> users should RTFM... but that doesn't always happen, even in Unix :-)
> These error messages are more comprehensive, and I've localized all
> the changes to the ap_get_local_host function.
+1, if I have a say in things - RTFM is all well and good, but defaults
should still be as sane as possible :-)
James.
RE: [patch-final 1.3.13] defaulted servername
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
Here is the final patch... it gets around several otherwise fatal
errors by using a numeric IP hostname. Failure of gethostname()
is compensated by the host name "127.0.0.1". In all cases (unlike
the current code) their assumption is reported and logged as an
error, to push them to properly set the ServerName directive.
*Please* review and vote... I agree with the assertion that the
users should RTFM... but that doesn't always happen, even in Unix :-)
These error messages are more comprehensive, and I've localized all
the changes to the ap_get_local_host function.
Bill
p.s. I consider change to httpd.conf-dist-win manditory, since it is
now out of sync with httpd.conf-dist.
> From: William A. Rowe, Jr. [mailto:wrowe@lnd.com]
> Sent: Sunday, June 11, 2000 1:57 PM
>
> My proposed solution is attached. I'm sure someone else could
> do better, or improve upon this...
>
> > From: William A. Rowe, Jr. [mailto:wrowe@lnd.com]
> > Sent: Sunday, June 11, 2000 1:17 PM
> >
> > This is -not- a Win32 post, for those trying to avoid filling their
> > heads with that drivel :-) Please read on...
> >
> > I've been waiting for some space on my overly full plate to
> > look for the 'correct' solution to this...
> >
> > > From: stoddard@locus.apache.org [mailto:stoddard@locus.apache.org]
> > > Sent: Wednesday, May 24, 2000 12:53 PM
> > >
> > > stoddard 00/05/24 10:53:20
> > >
> > > Modified: conf httpd.conf-dist-win
> > > src CHANGES
> > > Log:
> > > Win32: Set ServerName to 127.0.0.1 in the default windows
> > httpd.conf file.
> > > PR: 5509, 5783, 5953, 5903, 5983, 5259, 5515, 5858
> > >
> > > Submitted by: Oliver Wendemuth <ow...@ko.hbv.de>
> > >
> > > Index: httpd.conf-dist-win
> > >
> > ===================================================================
> > > @@ -230,7 +230,7 @@
> > > # You will have to access it by its address (e.g.,
> > http://123.45.67.89/)
> > > # anyway, and this will make redirections work in a sensible way.
> > > #
> > > -#ServerName new.host.name
> > > +ServerName 127.0.0.1
> >
> > Why then, doesn't the existing default code work in Win32?
> >
> > First, MS allows a user to 'name' their machine with a
> > completely bogus
> > name, and this is what is being retrieved (joes pc would be
> > an example).
> >
> > Second, ap_get_local_host() has the following code (BEOS
> path omitted)
> >
> > if (gethostname(str, sizeof(str) - 1) != 0) {
> > perror("Unable to gethostname");
> > exit(1);
> > } // we are good so far...
> > str[sizeof(str) - 1] = '\0';
> > if ((!(p = gethostbyname(str))) || (!(server_hostname =
> > find_fqdn(a, p)))) {
> > // and we land here because find_fdqn fails...
> > fprintf(stderr, "%s: cannot determine local host
> > name.\n", ap_server_argv0);
> >
> > Ok, so digging down into find_fdqn()
> >
> > if (!strchr(p->h_name, '.')) { // we refuse any name
> > sans the '.'s
> > for (x = 0; p->h_aliases[x]; ++x) {
> > if (strchr(p->h_aliases[x], '.') &&
> > (!strncasecmp(p->h_aliases[x], p->h_name,
> > strlen(p->h_name))))
> > return ap_pstrdup(a, p->h_aliases[x]);
> > }
> > return NULL; // and uneqivocably die here...
> >
> > so this is no solution. Two options from here (others may choose):
> >
> > 1) On failure of find_fdqn, return the ip address string
> > -rather than die-
This is the attached patch.
> > 2) Accept bogosity of a non-'.' name with -strong warnings-
> > that the private name will not be recognized by the
> > network-at-large, and continue.
I finally rejected this solution out of hand.
> > In -either- case we will proceed to look for an fdqn, if one
> > is available.
> >
> > Neither solution is complete - we should be attempting a true
> > reverse-dns
> > test, but I'll let someone else commit that if it's their desire.
> >
> > Which solution (or what other solution) can we live with to kill the
> > explicit ServerName in the 1.3.13 httpd.conf-dist-win?
>
> This patch is a variation of option 1, with additional warnings that
> assumptions have been made...
And I think this is key for *ALL* platforms to be warned that the server
conf is an assumption!