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...@rowe-clan.net> on 2001/03/22 17:43:40 UTC
BindAddress and Listen
With a far greater understanding than I had 24 hours ago...
Is there any reason not to just _Drop_ the BindAddress directive and strictly
use the Listen directive for Apache 2.0?
I'd even go so far as depreciate the Port directive in favor of a more
decorated ServerName directive (joespages.org:80) where port 80 is assumed.
These directives are very confusing, somewhat misleading and guarenteed to
keep bug reports trickling in for the life of the Apache project. As we
jump forward into IPV6, I'd suspect this would make everyone's lives easier.
Bill
Re: BindAddress and Listen
Posted by Jeff Trawick <tr...@bellsouth.net>.
"William A. Rowe, Jr." <ad...@rowe-clan.net> writes:
> From: "Jeff Trawick" <tr...@bellsouth.net>
> Sent: Thursday, March 22, 2001 11:15 AM
>
>
> > "William A. Rowe, Jr." <wr...@rowe-clan.net> writes:
> >
> > > I'd even go so far as depreciate the Port directive in favor of a more
> > > decorated ServerName directive (joespages.org:80) where port 80 is
> > > assumed.
> >
> > If we don't really need Port ('cause we don't need a port number in
> > addition to what is specified on the Listen statement), then I'm all
> > for dropping Port. But if we need the functionality of Port I'd
> > rather see it remain as-is than overload ServerName like that.
>
> How is that 'Overloading'? ServerName specifies the name the server answers as.
> Port (when Listen is specified) degrades to specifing the port the
> server answers as.
"when Listen is specified"
>
> It's (if I've got this right) nothing more than identity, no? I wouldn't
> consider that 'overloading'
but if Listen isn't specified it is overloading...
> I'm certain IPv6 and other protocols introduce
> all sorts of naming/identity issues...
such as?
And what does that have to do with ServerName? I guess you want
ServerName to always make sense to whatever protocol is being used,
and for any such identity to be encoded in ServerName such that if
this is an HTTP engine it is name+port and if it is some other
protocol then it could be something completely different?
This means that whatever funky protocol-specific syntax is needed to
jam protocol-specific info in a string can't be checked very well by a
protocol-neutral directive processing function, so what is the point?
Let the protocol-specific module provide whatever it needs for this
concept (if anything).
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: BindAddress and Listen
Posted by "William A. Rowe, Jr." <ad...@rowe-clan.net>.
From: "Jeff Trawick" <tr...@bellsouth.net>
Sent: Thursday, March 22, 2001 11:15 AM
> "William A. Rowe, Jr." <wr...@rowe-clan.net> writes:
>
> > I'd even go so far as depreciate the Port directive in favor of a more
> > decorated ServerName directive (joespages.org:80) where port 80 is
> > assumed.
>
> If we don't really need Port ('cause we don't need a port number in
> addition to what is specified on the Listen statement), then I'm all
> for dropping Port. But if we need the functionality of Port I'd
> rather see it remain as-is than overload ServerName like that.
How is that 'Overloading'? ServerName specifies the name the server answers as.
Port (when Listen is specified) degrades to specifing the port the server answers as.
It's (if I've got this right) nothing more than identity, no? I wouldn't
consider that 'overloading' ... I'm certain IPv6 and other protocols introduce
all sorts of naming/identity issues, and this just brings them together in the
'right place'.
Bill
Re: BindAddress and Listen
Posted by rb...@covalent.net.
> > I'd even go so far as depreciate the Port directive in favor of a more
> > decorated ServerName directive (joespages.org:80) where port 80 is
> > assumed.
>
> If we don't really need Port ('cause we don't need a port number in
> addition to what is specified on the Listen statement), then I'm all
> for dropping Port. But if we need the functionality of Port I'd
> rather see it remain as-is than overload ServerName like that.
Port is used to tell the server what Port to report it is on, regardless
of what port it is actually on. We must retain the feature of Port,
although it could be done with the ServerName directive.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: BindAddress and Listen
Posted by Jeff Trawick <tr...@bellsouth.net>.
"William A. Rowe, Jr." <wr...@rowe-clan.net> writes:
> With a far greater understanding than I had 24 hours ago...
>
> Is there any reason not to just _Drop_ the BindAddress directive and strictly
> use the Listen directive for Apache 2.0?
We already did as near as I can tell ("grep -i BindAddress" in all .c
and .h).
> I'd even go so far as depreciate the Port directive in favor of a more
> decorated ServerName directive (joespages.org:80) where port 80 is
> assumed.
If we don't really need Port ('cause we don't need a port number in
addition to what is specified on the Listen statement), then I'm all
for dropping Port. But if we need the functionality of Port I'd
rather see it remain as-is than overload ServerName like that.
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: BindAddress and Listen
Posted by dean gaudet <dg...@arctic.org>.
On Thu, 22 Mar 2001, William A. Rowe, Jr. wrote:
> With a far greater understanding than I had 24 hours ago...
>
> Is there any reason not to just _Drop_ the BindAddress directive and strictly
> use the Listen directive for Apache 2.0?
>
> I'd even go so far as depreciate the Port directive in favor of a more
> decorated ServerName directive (joespages.org:80) where port 80 is assumed.
+1
that seems much nicer than the old wacked out Port meanings. (i sure wish
we could have dropped Port earlier. long live NCSA compatibility!)
-dean
>
> These directives are very confusing, somewhat misleading and guarenteed to
> keep bug reports trickling in for the life of the Apache project. As we
> jump forward into IPV6, I'd suspect this would make everyone's lives easier.
>
> Bill
>
>