You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Doug MacEachern <do...@covalent.net> on 2001/08/10 03:59:08 UTC
Listen vs. Port
if Listen is used to set the server port, and Port is not configured,
ap_get_server_port returns the default port (80). this breaks mod_dir
redirects if Listen is something other than 80. should Listen also set
the server->port (as in the patch below) or is it required that Port must
also be configured?
Index: server/listen.c
===================================================================
RCS file: /home/cvs/httpd-2.0/server/listen.c,v
retrieving revision 1.59
diff -u -r1.59 listen.c
--- server/listen.c 2001/07/26 16:36:40 1.59
+++ server/listen.c 2001/08/10 01:51:35
@@ -353,6 +353,10 @@
return "Port must be specified";
}
+ if (!cmd->server->port) {
+ cmd->server->port = port;
+ }
+
alloc_listener(cmd->server->process, host, port);
return NULL;
Re: SV: PerlIO
Posted by Doug MacEachern <do...@covalent.net>.
On Sun, 12 Aug 2001, Arthur Bergman wrote:
> A perl compiled with perlio, how does it work with apache which is
> compiled with stdio? I guess apache 2.0 must hopefully be doing some
> good tricks with the unsafe stdio functions to achive speed, is there
> any way for perlio to use that?
apache has its own i/o wrappers in libapr, if there is something that
needs locking it is taken care of in there. i'm sure it would be possible
to define a perlio layer in terms of libapr functions. the only place
apache and perlio currently come anywhere near each other would be writing
to stderr i believe.
> How does apache 2.0 deal with reentrant _r functions? Are there any
> potenial clashes? Can we borrow thier work, will our redefining of
> functions to become _r create any problems?
these are also wrapped in libapr, i don't think there are any potential
clashes.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
SV: PerlIO
Posted by Arthur Bergman <ar...@contiller.se>.
> On Sat, 11 Aug 2001, Arthur Bergman wrote:
>
> >
> > How does mod_perl 2.0 deal with, and interact with PerlIO?
>
> it doesn't, yet. we still use tied filehandles. PerlIO needs some work
> before it is production ready, i'd rather wait until it is stable before
> working on hooking into it from modperl-2.0.
>
I didn't mean at the perl level, I meant deeper down, actually it boils down to.
A perl compiled with perlio, how does it work with apache which is compiled with stdio? I guess apache 2.0 must hopefully be doing some good tricks with the unsafe stdio functions to achive speed, is there any way for perlio to use that?
How does apache 2.0 deal with reentrant _r functions? Are there any potenial clashes? Can we borrow thier work, will our redefining of functions to become _r create any problems?
I guess the best way for me to find out is to install apache 2.0 and mod_perl 2.0 and 5.7.2 and try it :) I better do that.
Arthur
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: PerlIO
Posted by Doug MacEachern <do...@covalent.net>.
On Sat, 11 Aug 2001, Arthur Bergman wrote:
>
> How does mod_perl 2.0 deal with, and interact with PerlIO?
it doesn't, yet. we still use tied filehandles. PerlIO needs some work
before it is production ready, i'd rather wait until it is stable before
working on hooking into it from modperl-2.0.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
PerlIO
Posted by Arthur Bergman <ar...@contiller.se>.
How does mod_perl 2.0 deal with, and interact with PerlIO?
Any document/source file can read to gain knowledge?
Thanks
Arthur
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: Listen vs. Port
Posted by Doug MacEachern <do...@covalent.net>.
On Sat, 11 Aug 2001, Stas Bekman wrote:
> And in mod_perl during the configuration stage s->port returns 0, if you
> don't explicitly specify Port in the main server config. So if you print
> any warnings using: modperl_server_desc(s,p), which doesn't seem very
> clean to me, but I see no other option. If you have more than one Listen
> directive in the main server configuration, which one is to be used for
> Port?
yeah, we pretty much need to configure a Port for stuff like this.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: Listen vs. Port
Posted by Stas Bekman <st...@stason.org>.
Doug MacEachern wrote:
> if Listen is used to set the server port, and Port is not configured,
> ap_get_server_port returns the default port (80). this breaks mod_dir
> redirects if Listen is something other than 80. should Listen also set
> the server->port (as in the patch below) or is it required that Port must
> also be configured?
And in mod_perl during the configuration stage s->port returns 0, if you
don't explicitly specify Port in the main server config. So if you print
any warnings using: modperl_server_desc(s,p), which doesn't seem very
clean to me, but I see no other option. If you have more than one Listen
directive in the main server configuration, which one is to be used for
Port?
> Index: server/listen.c
> ===================================================================
> RCS file: /home/cvs/httpd-2.0/server/listen.c,v
> retrieving revision 1.59
> diff -u -r1.59 listen.c
> --- server/listen.c 2001/07/26 16:36:40 1.59
> +++ server/listen.c 2001/08/10 01:51:35
> @@ -353,6 +353,10 @@
> return "Port must be specified";
> }
>
> + if (!cmd->server->port) {
> + cmd->server->port = port;
> + }
> +
> alloc_listener(cmd->server->process, host, port);
>
> return NULL;
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: Listen vs. Port
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "dean gaudet" <dg...@arctic.org>
Sent: Saturday, August 11, 2001 3:31 PM
> just put the port into the servername, it makes more sense as one
> directive.
And the scheme :-? ++1
ServerName https://www.foo.net:8443/
solves all of our longstanding problems.
Bill
> On Fri, 10 Aug 2001, Ryan Bloom wrote:
>
> > On Friday 10 August 2001 05:06, Bill Stoddard wrote:
> > > > On Thu, 9 Aug 2001, Cliff Woolley wrote:
> > > > > On Thu, 9 Aug 2001, Doug MacEachern wrote:
> > > > > > if Listen is used to set the server port, and Port is not configured,
> > > > > > ap_get_server_port returns the default port (80). this breaks
> > > > > > mod_dir redirects if Listen is something other than 80.
> > > > >
> > > > > I thought that was the whole point of the Port directive in the first
> > > > > place.
> > > >
> > > > Sorry for stating the obvious, I missed the point of your message. The
> > > > answer is still that this is the expected behaviour, though, at least
> > > > according to my reading of the docs for the Listen directive, which say:
> > > >
> > > > "Note that you may still require a Port directive so that URLs that
> > > > Apache generates that point to your server still work."
> > > >
> > > > <shrug>
> > >
> > > Bleh... We've had this discussion before and I think the conclusion was to
> > > get rid of the Port directive entirely. The behaviour Doug reports is
> > > nonintuitive in the extreme and should be eliminated IHO.
> >
> > You can not get rid of the Port directive. It is an important directive that is there to
> > allow admins to configure their server to report a different port than it actually
> > uses. This is the exact same as the ServerName directive, which is another
> > one that can't go away.
> >
> > Ryan
> > _____________________________________________________________________________
> > Ryan Bloom rbb@apache.org
> > Covalent Technologies rbb@covalent.net
> > -----------------------------------------------------------------------------
> >
>
>
Re: Listen vs. Port
Posted by dean gaudet <dg...@arctic.org>.
just put the port into the servername, it makes more sense as one
directive.
-dean
On Fri, 10 Aug 2001, Ryan Bloom wrote:
> On Friday 10 August 2001 05:06, Bill Stoddard wrote:
> > > On Thu, 9 Aug 2001, Cliff Woolley wrote:
> > > > On Thu, 9 Aug 2001, Doug MacEachern wrote:
> > > > > if Listen is used to set the server port, and Port is not configured,
> > > > > ap_get_server_port returns the default port (80). this breaks
> > > > > mod_dir redirects if Listen is something other than 80.
> > > >
> > > > I thought that was the whole point of the Port directive in the first
> > > > place.
> > >
> > > Sorry for stating the obvious, I missed the point of your message. The
> > > answer is still that this is the expected behaviour, though, at least
> > > according to my reading of the docs for the Listen directive, which say:
> > >
> > > "Note that you may still require a Port directive so that URLs that
> > > Apache generates that point to your server still work."
> > >
> > > <shrug>
> >
> > Bleh... We've had this discussion before and I think the conclusion was to
> > get rid of the Port directive entirely. The behaviour Doug reports is
> > nonintuitive in the extreme and should be eliminated IHO.
>
> You can not get rid of the Port directive. It is an important directive that is there to
> allow admins to configure their server to report a different port than it actually
> uses. This is the exact same as the ServerName directive, which is another
> one that can't go away.
>
> Ryan
> _____________________________________________________________________________
> Ryan Bloom rbb@apache.org
> Covalent Technologies rbb@covalent.net
> -----------------------------------------------------------------------------
>
Re: Listen vs. Port
Posted by Joshua Slive <sl...@commerce.ubc.ca>.
On Wed, 15 Aug 2001, Lars Eilebrecht wrote:
> According to Joshua Slive:
>
> > But what most people want is "Listen to all IP addresses".
> > This is the current default behaviour. How do we express
> > that?
>
> I see your point, but do we really want to express that?
> If one has two or more interfaces configured he's usually
> dealing with virtual hosting, so what's wrong with
> a <VirtualHost> directive _and_ a related Listen directive?
> I've seen more than on setup where Apache was listening on
> all interfaces, but that behaviour actually was not intended.
> E.g., what's the point in listening on 127.0.0.1?
I think I disagree. I believe that the naive user generally does want to
listen on all interfaces. Listening on 127.0.0.1 is often very valuable
for testing purposes. I expect a great increase in "Apache won't respond
even though it is running" problem reports if we change this behaviour.
The most common problem I hear about is people behind port-forwarding (or
NAT) firewalls. These people have a very hard time figuring out what to
put in NameVirtualHost and VirtualHost directives. The new
"NameVirtualHost *" configuration, in conjunction with the default
behaviour of listening on all interfaces, is great for these people.
Sure, it is a crutch for people who don't understand what is going on, but
I don't see that it opens up any problems.
Joshua.
Re: Listen vs. Port
Posted by Lars Eilebrecht <la...@hyperreal.org>.
According to Joshua Slive:
> But what most people want is "Listen to all IP addresses".
> This is the current default behaviour. How do we express
> that?
I see your point, but do we really want to express that?
If one has two or more interfaces configured he's usually
dealing with virtual hosting, so what's wrong with
a <VirtualHost> directive _and_ a related Listen directive?
I've seen more than on setup where Apache was listening on
all interfaces, but that behaviour actually was not intended.
E.g., what's the point in listening on 127.0.0.1?
> Another minor issue with your proposal: currently,
> if <VirtualHost> is specified without an explicit
> port, is uses the Port directive. Would you
> want to change that to default to the same
> behaviour as <VirtualHost ip.address:*>?
Well, I've no opinion on that one, but basically
I'm in favour of making some changes to the vhost
configuration for 2.0. There's way to much magic in it.
The vhost configuration has always been a source for
misconfigurations and IMHO we should try to simplify
it for 2.0, shouldn't we?
ciao...
--
Lars Eilebrecht - Why be normal?!
lars@hyperreal.org
Re: Listen vs. Port
Posted by Joshua Slive <jo...@slive.ca>.
On Mon, 13 Aug 2001, Lars Eilebrecht wrote:
> - Make Listen require an IP address, e.g., 123.45.67.89:80
> if only an address is given it should default to port 80.
> The definition of Listen should be mandatory.
But what most people want is "Listen to all IP addresses".
This is the current default behaviour. How do we express
that?
> If we do these changes it might be a good idea to start
> re-thinking our virtual host configuration, especially
> the concept of main server vs. default server vs. vhost.
>
Another minor issue with your proposal: currently,
if <VirtualHost> is specified without an explicit
port, is uses the Port directive. Would you
want to change that to default to the same
behaviour as <VirtualHost ip.address:*>?
Joshua.
Re: Listen vs. Port
Posted by Lars Eilebrecht <la...@hyperreal.org>.
According to Ryan Bloom:
> You can not get rid of the Port directive. It is an important directive
> that is there to allow admins to configure their server to report a
> different port than it actually uses. This is the exact same as the
> ServerName directive, which is another one that can't go away.
Yes, that's true, we cannot get rid of the funtionality provided by
the Port directive.
But maybe we should think about a different way to configure this
in Apache 2.0, because in some situations (e.g., you're behind
a load balancing device or reverse proxy and need to configure a
different name and port number for self-referencing replies
or any CGIs using SERVER_NAME etc.). But the configuration is
often not very intuitional.
Basically we have three different directives manimuplation
the servername and port number in replies: ServerName, Port
and UseCanonicalName.
I like Dean's idea to combine ServerName and Port, but then
there's still UseCanonicalName.
How about this idea (for 2.0):
- Remove Port directive and make Listen the only directive
defining ports to listen on.
- Make Listen require an IP address, e.g., 123.45.67.89:80
if only an address is given it should default to port 80.
The definition of Listen should be mandatory.
- Make ServerName accept only a FQDN followed by a port
number as an argument, e.g., www.domain.tld:8080.
This value should be used for any self-referencing replies
and as a source for the variables SERVER_NAME, SERVER_PORT
SCRIPT_URI (FQDN part) and SERVER_SIGNATURE.
Default values should be the port number and IP address
from the Listen directive.
Add a special argument, e.g., "auto" to provide the
functionality of "UseCanonicalName On" (use the values
supplied by the client's host header).
(Should we continue to provide the functionality of
"UseCanonicalName DNS"? IMHO we should not.)
- Remove UseCanonicalName directive
Any comments?
If we do these changes it might be a good idea to start
re-thinking our virtual host configuration, especially
the concept of main server vs. default server vs. vhost.
ciao...
--
Lars Eilebrecht - The chief cause of problems is solutions.
lars@hyperreal.org (Eric Sevareid)
Re: Listen vs. Port
Posted by Ryan Bloom <rb...@covalent.net>.
On Friday 10 August 2001 05:06, Bill Stoddard wrote:
> > On Thu, 9 Aug 2001, Cliff Woolley wrote:
> > > On Thu, 9 Aug 2001, Doug MacEachern wrote:
> > > > if Listen is used to set the server port, and Port is not configured,
> > > > ap_get_server_port returns the default port (80). this breaks
> > > > mod_dir redirects if Listen is something other than 80.
> > >
> > > I thought that was the whole point of the Port directive in the first
> > > place.
> >
> > Sorry for stating the obvious, I missed the point of your message. The
> > answer is still that this is the expected behaviour, though, at least
> > according to my reading of the docs for the Listen directive, which say:
> >
> > "Note that you may still require a Port directive so that URLs that
> > Apache generates that point to your server still work."
> >
> > <shrug>
>
> Bleh... We've had this discussion before and I think the conclusion was to
> get rid of the Port directive entirely. The behaviour Doug reports is
> nonintuitive in the extreme and should be eliminated IHO.
You can not get rid of the Port directive. It is an important directive that is there to
allow admins to configure their server to report a different port than it actually
uses. This is the exact same as the ServerName directive, which is another
one that can't go away.
Ryan
_____________________________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
-----------------------------------------------------------------------------
Re: Listen vs. Port
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Bill Stoddard" <bi...@wstoddard.com>
Sent: Friday, August 10, 2001 7:06 AM
> Bleh... We've had this discussion before and I think the conclusion was to get rid of the
> Port directive entirely. The behaviour Doug reports is nonintuitive in the extreme and
> should be eliminated IHO.
+1
Re: Listen vs. Port
Posted by Bill Stoddard <bi...@wstoddard.com>.
> On Thu, 9 Aug 2001, Cliff Woolley wrote:
>
> > On Thu, 9 Aug 2001, Doug MacEachern wrote:
> >
> > > if Listen is used to set the server port, and Port is not configured,
> > > ap_get_server_port returns the default port (80). this breaks mod_dir
> > > redirects if Listen is something other than 80.
> >
> > I thought that was the whole point of the Port directive in the first
> > place.
> >
>
> Sorry for stating the obvious, I missed the point of your message. The
> answer is still that this is the expected behaviour, though, at least
> according to my reading of the docs for the Listen directive, which say:
>
> "Note that you may still require a Port directive so that URLs that Apache
> generates that point to your server still work."
>
> <shrug>
>
Bleh... We've had this discussion before and I think the conclusion was to get rid of the
Port directive entirely. The behaviour Doug reports is nonintuitive in the extreme and
should be eliminated IHO.
Bill
Re: Listen vs. Port
Posted by Doug MacEachern <do...@covalent.net>.
On Thu, 9 Aug 2001, Cliff Woolley wrote:
> Sorry for stating the obvious, I missed the point of your message. The
> answer is still that this is the expected behaviour, though, at least
> according to my reading of the docs for the Listen directive, which say:
>
> "Note that you may still require a Port directive so that URLs that Apache
> generates that point to your server still work."
doh, didn't think to check the docs.
Re: Listen vs. Port
Posted by Cliff Woolley <cl...@yahoo.com>.
On Thu, 9 Aug 2001, Cliff Woolley wrote:
> On Thu, 9 Aug 2001, Doug MacEachern wrote:
>
> > if Listen is used to set the server port, and Port is not configured,
> > ap_get_server_port returns the default port (80). this breaks mod_dir
> > redirects if Listen is something other than 80.
>
> I thought that was the whole point of the Port directive in the first
> place.
>
Sorry for stating the obvious, I missed the point of your message. The
answer is still that this is the expected behaviour, though, at least
according to my reading of the docs for the Listen directive, which say:
"Note that you may still require a Port directive so that URLs that Apache
generates that point to your server still work."
<shrug>
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: Listen vs. Port
Posted by Cliff Woolley <cl...@yahoo.com>.
On Thu, 9 Aug 2001, Doug MacEachern wrote:
> if Listen is used to set the server port, and Port is not configured,
> ap_get_server_port returns the default port (80). this breaks mod_dir
> redirects if Listen is something other than 80.
I thought that was the whole point of the Port directive in the first
place.
>From docs/manual/mod/core.html#port:
--------------------------------------------------------------
In the absence of any Listen directives specifying a port number, a Port
directive given in the "main server" (i.e., outside any <VirtualHost>
section) sets the network port on which the server listens. If there are
any Listen directives specifying :number then Port has no effect on what
address the server listens at.
The Port directive sets the SERVER_PORT environment variable (for CGI and
SSI), and is used when the server must generate a URL that refers to
itself (for example when creating an external redirect to itself). This
behaviour is modified by UseCanonicalName.
In no event does a Port setting affect what ports a VirtualHost responds
on, the VirtualHost directive itself is used for that.
The primary behaviour of Port should be considered to be similar to that
of the ServerName directive. The ServerName and Port together specify what
you consider to be the canonical address of the server. (See also
UseCanonicalName.)
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA