You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Bojan Smojver <bo...@rexursive.com> on 2002/08/28 15:27:18 UTC
Spec question: RE BUG 12052
Craig,
I think this bug report is invalid, since Tomcat/Apache has no knowledge
of load balancers and firewalls, so it is unrealistic to expect to
return port numbers that it doesn't know about. What do you think?
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12052
Other opinions welcome :-)
Bojan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Spec question: RE BUG 12052
Posted by Bojan Smojver <bo...@rexursive.com>.
On Thu, 2002-08-29 at 02:14, Craig R. McClanahan wrote:
> Consider Apache running on port 80, forwarding to Tomcat on 8009 (the
> default setup). I think it's reasonable for the application developer to
> assume that getServerPort() is going to return 80 and not 8009, because
> they should conceptually view the entire "Apache+Tomcat" thing as a single
> server.
To avoid confusion, I have tested what comes back. The combo is Apache
2.0.40, mod_jk 1.2.0, Tomcat 3.3.x. The port 80 comes back over HTTP and
443 over SSL. This is also indicated by the current source in the bug
report.
The real problem is that the bug report asks to go a step further and to
fake the ports when there is a load balancer or firewall in front of
Apache/Tomcat combo. I don't think we should do that - load balancer or
firewall is not part of the container.
Bojan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Spec question: RE BUG 12052
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 28 Aug 2002, John Trollinger wrote:
> Date: Wed, 28 Aug 2002 12:19:19 -0400
> From: John Trollinger <ja...@trollingers.com>
> Reply-To: Tomcat Developers List <to...@jakarta.apache.org>
> To: 'Tomcat Developers List' <to...@jakarta.apache.org>
> Subject: RE: Spec question: RE BUG 12052
>
>
>
> > -----Original Message-----
> > From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> > Sent: Wednesday, August 28, 2002 12:15 PM
> > To: Tomcat Developers List
> > Subject: Re: Spec question: RE BUG 12052
> >
> >
> >
> >
> > On 28 Aug 2002, Bojan Smojver wrote:
> >
> > > Date: 28 Aug 2002 23:27:18 +1000
> > > From: Bojan Smojver <bo...@rexursive.com>
> > > Reply-To: Tomcat Developers List <to...@jakarta.apache.org>
> > > To: Tomcat Dev List <to...@jakarta.apache.org>
> > > Subject: Spec question: RE BUG 12052
> > >
> > > Craig,
> > >
> > > I think this bug report is invalid, since Tomcat/Apache has no
> > > knowledge of load balancers and firewalls, so it is unrealistic to
> > > expect to return port numbers that it doesn't know about.
> > What do you
> > > think?
> > >
> > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12052
> > >
> > > Other opinions welcome :-)
> > >
> >
> > There are circumstances when we're not going to know the port
> > number, but normal use of Tomcat behind JK doesn't seem to be
> > one of them, IMHO.
> >
> > Consider Apache running on port 80, forwarding to Tomcat on
> > 8009 (the default setup). I think it's reasonable for the
> > application developer to assume that getServerPort() is going
> > to return 80 and not 8009, because they should conceptually
> > view the entire "Apache+Tomcat" thing as a single server.
>
> I have to disagree with you there. If a request comes to the servlet
> engine
> on port 8009 then getServerPort() should return that.
In other words, you're going to tell application developers "sorry --
there is no way to construct a URL that will come back to this webapp
unless you encode your own knowledge of what port number to include".
That doesn't sound at all useful. In addition, it's inconsistent with the
results you'd get if you run the same webapp under Tomcat standalone
(where you do get the right answer already).
> It is bad to have Tomcat try and guess where its requests are coming from.
Agreed. I'm not advocating a guess -- I'm advocating that the Apache side
of JK tell Tomcat what port the request came in on, so that
getServerPort() can tell the application.
Craig
>
> >
> > As for implementing this, a couple of possibilities:
> >
> > * Include the port number along with the host name (haven't checked
> > if this is already happening)
> >
> > * Add a protocol variable in the JK protocol so that the web server
> > can forward which port number the request was received on.
> >
> > * Add a Connector property saying the port number that should be
> > used for getServerPort() for all requests processed by this
> > connector
> > (the deprecated HttpConnector code had proxyPort for this purpose).
> >
> > If a load balancer or proxy *ahead* of Apache is doing the
> > port shifting, there's not a lot we can do. But we should
> > cover the case for requests that come in to the web server
> > and get forwarded by us.
> >
> > > Bojan
> >
> > Craig
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:tomcat-dev-> unsubscribe@jakarta.apache.org>
> > For
> > additional commands,
> > e-mail: <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Spec question: RE BUG 12052
Posted by Bojan Smojver <bo...@rexursive.com>.
Quoting Bill Barker <wb...@wilshire.com>:
> Not anymore. ;-) In the current 2.4 spec draft it is required to be taken
> from the Host header.
Huh, I guess that's that then. The bug does seem to be valid. At least according
to the newer spec.
Bojan
-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Spec question: RE BUG 12052
Posted by Bojan Smojver <bo...@rexursive.com>.
Quoting costinm@covalent.net:
> So: getServerPort() should return the same as the CGI variable SERVER_PORT
> ( which returns the server port, not the host header ! ), meaning the
> value of the part after : in the Host header.
>
> I didn't know that the servlet spec can define new meanings for the
> CGI spec.
Pretty cool, ha?
:-))
Bojan
-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Spec question: RE BUG 12052
Posted by Costin Manolache <cm...@yahoo.com>.
To answer my own email - with a summary:
- what the user really wants is to know how to form URLs - that's
how the server name and port are used in most cases
- the real problem is getServerName(). In CGI it is the 'canonical'
name. A server may have multiple aliases for a host, and in many
cases it is desirable to return URLs that point to the 'canonical'
or main name.
- Host: header allways returns the host and port the user typed in.
- the 'canonical name' is no longer available for servlets, if
getServletName() is to return the info from Host ( i.e. the alias that
the user typed ). That IMO is a _major_ loss.
- Another cause to worry is the comment in apache2 core.c:
There are two options regarding what the "name" of a server is. The
"canonical" name as defined by ServerName and Port, or the "client's
name" as supplied by a possible Host: header or full URI. We never
trust the port passed in the client's headers, we always use the
port of the actual socket.
For tomcat, I would propose adding 1 'implementation specific' attribute
( allowed by the spec AFAIK ) to compensate for the loss of info.
This attribute ( say 'CANONICAL_HOST' ?) would pass the 'official'
name of the server ( and port ). Another option is to make this a
context attribute.
getServerName() and getPortName() would reflect what the user typed in
the browser and would work in most cases. It is obviously not what the
CGI is doing.
My advice for anyone would be to avoid getServerName() and getPortName()
and use getHeader( "Host" ) - that would work in any servlet container
consistently and is far more portable ( if the host is what you want -
if you want the real host/port, you're out of luck with servlet2.4 but you
can use 2.3 and 2.2 without problems ).
Costin
costinm@covalent.net wrote:
> On Thu, 29 Aug 2002, Bill Barker wrote:
>
>> > So: getServerPort() should return the same as the CGI variable
>> > SERVER_PORT ( which returns the server port, not the host header ! ),
>> > meaning the value of the part after : in the Host header.
>> >
>> > I didn't know that the servlet spec can define new meanings for the
>> > CGI spec.
>> >
>>
>> FWIW, I agree that the 2.4 servlet-spec and the CGI-spec are out of sync
>> here. If I actually thought that any members of the JCP were subscribed
>> to this list, I'd think to ask for clarification before 2.4 went final.
>> :)
>
> Nah... As long as they're returning the port from the host header -
> I don't want any new clarification :-)
>
> Actually, it is right about the server port, since the CGI says:
> "The port number to which the request was sent."
>
> But not for the server name:
> "The server's hostname, DNS alias, or IP address as it would appear in
> self-referencing URLs. "
>
> And the port can be interpreted easily to mean the Host header. Except
> that apparently nobody implements it this way. Sometimes it is better to
> provide all informations about the request - the port it was received
> on and the host header. If you return the info from the host header in
> both getServerPort and getHeader(), the port info is lost.
>
> For getServerName() - the CGI interpretation is more 'the canonical name'.
> If I access http://10.0.0.1, the Host will include the IP but
> SERVER_NAME will be the canonical name. But now that the servlet
> spec finally 'clarified' the CGI spec, we can wait for IIS and Apache
> to fix their implementation and be compliant with the CGI spec at least
> :-)
>
>
>
> Costin
>
>
>>
>> > Costin
>> >
>> >
>> > > <spec-quote version="2.4" section="14.2.16">
>> > > getServerName()
>> > > public java.lang.String getServerName()
>> > > Returns the host name of the server to which the request was sent.
>> > > For
>> HTTP
>> > > servlets, same as the value of the CGI variable SERVER_NAME, meaning
>> > > the value of the part before ":" in the Host header, if any, or the
>> > > resolved server
>> > > name, or the server IP address.
>> > > Returns: a String containing the name of the server
>> > >
>> > > getServerPort()
>> > > public int getServerPort()
>> > > Returns the port number to which the request was sent. For HTTP
>> servlets,
>> > > same as the value of the CGI variable SERVER_PORT, meaning the value
>> > > of
>> the
>> > > part after ":" in the Host header, if any, or the server port where
>> > > the client
>> > > connection was accepted on.
>> > > Returns: an integer specifying the port number
>> > > </spec-quote>
>> > >
>> > > >
>> > > > Note that a load balancer or proxy is required ( AFAIK ) to insert
>> > > > Host: headers if none is present.
>> > > >
>> > > > Costin
>> > > >
>> > > > On 29 Aug 2002, Bojan Smojver wrote:
>> > > >
>> > > > > On Thu, 2002-08-29 at 04:28, Bill Barker wrote:
>> > > > >
>> > > > > > The question in 12052 is whether Apache should use the socket
>> > > > > > port
>> (as
>> > > it
>> > > > > > does now), or the port in the Host header. When this came up
>> > > > > > with
>> the
>> > > > > > Coyote/Http11 connector, the decision was that the Host header
>> > > > > > was
>> the
>> > > > > > correct one. I'd have to say that the bug is valid.
>> > > > >
>> > > > > This is what the API (2.2) docs say about the getServerPort():
>> > > > >
>> > > > > ----------------
>> > > > > Returns the port number on which this request was received. For
>> > > > > HTTP servlets, same as the value of the CGI variable SERVER_PORT.
>> > > > > ----------------
>> > > > >
>> > > > > This in itself could be contradicting, but I think that in the
>> > > > > case
>> of
>> > > > > Apache it is pretty straightforward.
>> > > > >
>> > > > > This is what Apache 2.0 does to populate the variable
>> > > > > SERVER_PORT:
>> > > > >
>> > > > > ----------------
>> > > > > apr_table_addn(e, "SERVER_PORT",
>> > > > > apr_psprintf(r->pool, "%u",
>> ap_get_server_port(r)));
>> > > > > ----------------
>> > > > >
>> > > > > And this is the ap_get_server_port():
>> > > > >
>> > > > > ----------------
>> > > > > AP_DECLARE(apr_port_t) ap_get_server_port(const request_rec *r)
>> > > > > {
>> > > > > apr_port_t port;
>> > > > > core_dir_config *d =
>> > > > > (core_dir_config *)ap_get_module_config(r->per_dir_config,
>> > > > > &core_module);
>> > > > >
>> > > > > if (d->use_canonical_name == USE_CANONICAL_NAME_OFF
>> > > > > || d->use_canonical_name == USE_CANONICAL_NAME_DNS) {
>> > > > >
>> > > > > /* With UseCanonicalName off Apache will form
>> self-referential
>> > > > > * URLs using the hostname and port supplied by the
>> > > > > client
>> if
>> > > > > * any are supplied (otherwise it will use the canonical
>> name).
>> > > > > */
>> > > > > port = r->parsed_uri.port ? r->parsed_uri.port :
>> > > > > r->server->port ? r->server->port :
>> > > > > ap_default_port(r);
>> > > > > }
>> > > > > else { /* d->use_canonical_name == USE_CANONICAL_NAME_ON */
>> > > > >
>> > > > > /* With UseCanonicalName on (and in all versions prior to
>> 1.3)
>> > > > > * Apache will use the hostname and port specified in the
>> > > > > * ServerName directive to construct a canonical name for
>> the
>> > > > > * server. (If no port was specified in the ServerName
>> > > > > * directive, Apache uses the port supplied by the client
>> > > > > if * any is supplied, and finally the default port for
>> > > > > the
>> > > > > protocol
>> > > > > * used.
>> > > > > */
>> > > > > port = r->server->port ? r->server->port :
>> > > > > r->connection->local_addr->port ?
>> > > > > r->connection->local_addr->port
>> > > > > ap_default_port(r);
>> > > > > }
>> > > > >
>> > > > > /* default */
>> > > > > return port;
>> > > > > }
>> > > > > ----------------
>> > > > >
>> > > > > This doesn't seem like coming from headers, but rather from URL
>> > > > > or
>> as
>> > > > > indicated by the server itself. What do you think?
>> > > > >
>> > > > > Bojan
>> > > > >
>> > > > >
>> > > > > --
>> > > > > To unsubscribe, e-mail:
>> > > <ma...@jakarta.apache.org>
>> > > > > For additional commands, e-mail:
>> > > <ma...@jakarta.apache.org>
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > > > --
>> > > > To unsubscribe, e-mail:
>> > > <ma...@jakarta.apache.org>
>> > > > For additional commands, e-mail:
>> > > <ma...@jakarta.apache.org>
>> > > >
>> > >
>> > >
>> > > --
>> > > To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org>
>> > > For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>> > >
>> > >
>> >
>> >
>> > --
>> > To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org>
>> > For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>> >
>>
>>
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org> For additional
>> commands, e-mail: <ma...@jakarta.apache.org>
>>
>>
--
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Spec question: RE BUG 12052
Posted by Ryan Lubke <Ry...@Sun.COM>.
On Thu, 2002-08-29 at 11:13, Craig R. McClanahan wrote:
>
>
> On Thu, 29 Aug 2002, Bill Barker wrote:
>
> > FWIW, I agree that the 2.4 servlet-spec and the CGI-spec are out of sync
> > here. If I actually thought that any members of the JCP were subscribed to
> > this list, I'd think to ask for clarification before 2.4 went final. :)
> >
>
> The way to ask would be to send feedback to
> <se...@eng.sun.com>.
I've forwarded the thread to the spec lead for 2.4 and it has been
brought up to the expert group. However, as Craig mentioned, the best
way to ask is using the email address he listed.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Spec question: RE BUG 12052
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 29 Aug 2002, Bill Barker wrote:
> FWIW, I agree that the 2.4 servlet-spec and the CGI-spec are out of sync
> here. If I actually thought that any members of the JCP were subscribed to
> this list, I'd think to ask for clarification before 2.4 went final. :)
>
The way to ask would be to send feedback to
<se...@eng.sun.com>.
Personally, I'd prefer to banish any mention of CGI environment variables
in the servlet spec. That was useful when the servlet api was introduced
because it was familiar, but today it just causes confusion.
It's probably too late for that big a change this time around :-(, but
with my new job role (Web Layer Architect for J2EE) I might have a better
shot at convincing people next time ...
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Spec question: RE BUG 12052
Posted by co...@covalent.net.
On Thu, 29 Aug 2002, Bill Barker wrote:
> > So: getServerPort() should return the same as the CGI variable SERVER_PORT
> > ( which returns the server port, not the host header ! ), meaning the
> > value of the part after : in the Host header.
> >
> > I didn't know that the servlet spec can define new meanings for the
> > CGI spec.
> >
>
> FWIW, I agree that the 2.4 servlet-spec and the CGI-spec are out of sync
> here. If I actually thought that any members of the JCP were subscribed to
> this list, I'd think to ask for clarification before 2.4 went final. :)
Nah... As long as they're returning the port from the host header -
I don't want any new clarification :-)
Actually, it is right about the server port, since the CGI says:
"The port number to which the request was sent."
But not for the server name:
"The server's hostname, DNS alias, or IP address as it would appear in
self-referencing URLs. "
And the port can be interpreted easily to mean the Host header. Except
that apparently nobody implements it this way. Sometimes it is better to
provide all informations about the request - the port it was received
on and the host header. If you return the info from the host header in
both getServerPort and getHeader(), the port info is lost.
For getServerName() - the CGI interpretation is more 'the canonical name'.
If I access http://10.0.0.1, the Host will include the IP but
SERVER_NAME will be the canonical name. But now that the servlet
spec finally 'clarified' the CGI spec, we can wait for IIS and Apache
to fix their implementation and be compliant with the CGI spec at least :-)
Costin
>
> > Costin
> >
> >
> > > <spec-quote version="2.4" section="14.2.16">
> > > getServerName()
> > > public java.lang.String getServerName()
> > > Returns the host name of the server to which the request was sent. For
> HTTP
> > > servlets, same as the value of the CGI variable SERVER_NAME, meaning the
> > > value of the part before ":" in the Host header, if any, or the resolved
> > > server
> > > name, or the server IP address.
> > > Returns: a String containing the name of the server
> > >
> > > getServerPort()
> > > public int getServerPort()
> > > Returns the port number to which the request was sent. For HTTP
> servlets,
> > > same as the value of the CGI variable SERVER_PORT, meaning the value of
> the
> > > part after ":" in the Host header, if any, or the server port where the
> > > client
> > > connection was accepted on.
> > > Returns: an integer specifying the port number
> > > </spec-quote>
> > >
> > > >
> > > > Note that a load balancer or proxy is required ( AFAIK ) to insert
> > > > Host: headers if none is present.
> > > >
> > > > Costin
> > > >
> > > > On 29 Aug 2002, Bojan Smojver wrote:
> > > >
> > > > > On Thu, 2002-08-29 at 04:28, Bill Barker wrote:
> > > > >
> > > > > > The question in 12052 is whether Apache should use the socket port
> (as
> > > it
> > > > > > does now), or the port in the Host header. When this came up with
> the
> > > > > > Coyote/Http11 connector, the decision was that the Host header was
> the
> > > > > > correct one. I'd have to say that the bug is valid.
> > > > >
> > > > > This is what the API (2.2) docs say about the getServerPort():
> > > > >
> > > > > ----------------
> > > > > Returns the port number on which this request was received. For HTTP
> > > > > servlets, same as the value of the CGI variable SERVER_PORT.
> > > > > ----------------
> > > > >
> > > > > This in itself could be contradicting, but I think that in the case
> of
> > > > > Apache it is pretty straightforward.
> > > > >
> > > > > This is what Apache 2.0 does to populate the variable SERVER_PORT:
> > > > >
> > > > > ----------------
> > > > > apr_table_addn(e, "SERVER_PORT",
> > > > > apr_psprintf(r->pool, "%u",
> ap_get_server_port(r)));
> > > > > ----------------
> > > > >
> > > > > And this is the ap_get_server_port():
> > > > >
> > > > > ----------------
> > > > > AP_DECLARE(apr_port_t) ap_get_server_port(const request_rec *r)
> > > > > {
> > > > > apr_port_t port;
> > > > > core_dir_config *d =
> > > > > (core_dir_config *)ap_get_module_config(r->per_dir_config,
> > > > > &core_module);
> > > > >
> > > > > if (d->use_canonical_name == USE_CANONICAL_NAME_OFF
> > > > > || d->use_canonical_name == USE_CANONICAL_NAME_DNS) {
> > > > >
> > > > > /* With UseCanonicalName off Apache will form
> self-referential
> > > > > * URLs using the hostname and port supplied by the client
> if
> > > > > * any are supplied (otherwise it will use the canonical
> name).
> > > > > */
> > > > > port = r->parsed_uri.port ? r->parsed_uri.port :
> > > > > r->server->port ? r->server->port :
> > > > > ap_default_port(r);
> > > > > }
> > > > > else { /* d->use_canonical_name == USE_CANONICAL_NAME_ON */
> > > > >
> > > > > /* With UseCanonicalName on (and in all versions prior to
> 1.3)
> > > > > * Apache will use the hostname and port specified in the
> > > > > * ServerName directive to construct a canonical name for
> the
> > > > > * server. (If no port was specified in the ServerName
> > > > > * directive, Apache uses the port supplied by the client if
> > > > > * any is supplied, and finally the default port for the
> > > > > protocol
> > > > > * used.
> > > > > */
> > > > > port = r->server->port ? r->server->port :
> > > > > r->connection->local_addr->port ?
> > > > > r->connection->local_addr->port
> > > > > ap_default_port(r);
> > > > > }
> > > > >
> > > > > /* default */
> > > > > return port;
> > > > > }
> > > > > ----------------
> > > > >
> > > > > This doesn't seem like coming from headers, but rather from URL or
> as
> > > > > indicated by the server itself. What do you think?
> > > > >
> > > > > Bojan
> > > > >
> > > > >
> > > > > --
> > > > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Spec question: RE BUG 12052
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: <co...@covalent.net>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Wednesday, August 28, 2002 7:12 PM
Subject: Re: Spec question: RE BUG 12052
> On Wed, 28 Aug 2002, Bill Barker wrote:
>
> > > I think the decision to use the Host header is right, but
> > > I agree that it violates the wording in the servlet spec.
> > >
> > > The SERVER_PORT and the port in the Host: header are different
> > > beasts - in most use cases I've seen the user is interested
> > > in the second.
> >
> > Not anymore. ;-) In the current 2.4 spec draft it is required to be
taken
> > from the Host header.
>
> I hope this is listed in the 'incompatible changes between 2.3 and 2.4'
:-)
Nope.
<spec-quote version="2.4" section="S.1">
Clarification of SERVER_NAME and SERVER_PORT in getServerName()
and getServerPort() (14.2.16)
</spec-quote>
>
> As for the new wording - am I missing the ':-)' ?
Here's mine :-)
>
> So: getServerPort() should return the same as the CGI variable SERVER_PORT
> ( which returns the server port, not the host header ! ), meaning the
> value of the part after : in the Host header.
>
> I didn't know that the servlet spec can define new meanings for the
> CGI spec.
>
FWIW, I agree that the 2.4 servlet-spec and the CGI-spec are out of sync
here. If I actually thought that any members of the JCP were subscribed to
this list, I'd think to ask for clarification before 2.4 went final. :)
> Costin
>
>
> > <spec-quote version="2.4" section="14.2.16">
> > getServerName()
> > public java.lang.String getServerName()
> > Returns the host name of the server to which the request was sent. For
HTTP
> > servlets, same as the value of the CGI variable SERVER_NAME, meaning the
> > value of the part before ":" in the Host header, if any, or the resolved
> > server
> > name, or the server IP address.
> > Returns: a String containing the name of the server
> >
> > getServerPort()
> > public int getServerPort()
> > Returns the port number to which the request was sent. For HTTP
servlets,
> > same as the value of the CGI variable SERVER_PORT, meaning the value of
the
> > part after ":" in the Host header, if any, or the server port where the
> > client
> > connection was accepted on.
> > Returns: an integer specifying the port number
> > </spec-quote>
> >
> > >
> > > Note that a load balancer or proxy is required ( AFAIK ) to insert
> > > Host: headers if none is present.
> > >
> > > Costin
> > >
> > > On 29 Aug 2002, Bojan Smojver wrote:
> > >
> > > > On Thu, 2002-08-29 at 04:28, Bill Barker wrote:
> > > >
> > > > > The question in 12052 is whether Apache should use the socket port
(as
> > it
> > > > > does now), or the port in the Host header. When this came up with
the
> > > > > Coyote/Http11 connector, the decision was that the Host header was
the
> > > > > correct one. I'd have to say that the bug is valid.
> > > >
> > > > This is what the API (2.2) docs say about the getServerPort():
> > > >
> > > > ----------------
> > > > Returns the port number on which this request was received. For HTTP
> > > > servlets, same as the value of the CGI variable SERVER_PORT.
> > > > ----------------
> > > >
> > > > This in itself could be contradicting, but I think that in the case
of
> > > > Apache it is pretty straightforward.
> > > >
> > > > This is what Apache 2.0 does to populate the variable SERVER_PORT:
> > > >
> > > > ----------------
> > > > apr_table_addn(e, "SERVER_PORT",
> > > > apr_psprintf(r->pool, "%u",
ap_get_server_port(r)));
> > > > ----------------
> > > >
> > > > And this is the ap_get_server_port():
> > > >
> > > > ----------------
> > > > AP_DECLARE(apr_port_t) ap_get_server_port(const request_rec *r)
> > > > {
> > > > apr_port_t port;
> > > > core_dir_config *d =
> > > > (core_dir_config *)ap_get_module_config(r->per_dir_config,
> > > > &core_module);
> > > >
> > > > if (d->use_canonical_name == USE_CANONICAL_NAME_OFF
> > > > || d->use_canonical_name == USE_CANONICAL_NAME_DNS) {
> > > >
> > > > /* With UseCanonicalName off Apache will form
self-referential
> > > > * URLs using the hostname and port supplied by the client
if
> > > > * any are supplied (otherwise it will use the canonical
name).
> > > > */
> > > > port = r->parsed_uri.port ? r->parsed_uri.port :
> > > > r->server->port ? r->server->port :
> > > > ap_default_port(r);
> > > > }
> > > > else { /* d->use_canonical_name == USE_CANONICAL_NAME_ON */
> > > >
> > > > /* With UseCanonicalName on (and in all versions prior to
1.3)
> > > > * Apache will use the hostname and port specified in the
> > > > * ServerName directive to construct a canonical name for
the
> > > > * server. (If no port was specified in the ServerName
> > > > * directive, Apache uses the port supplied by the client if
> > > > * any is supplied, and finally the default port for the
> > > > protocol
> > > > * used.
> > > > */
> > > > port = r->server->port ? r->server->port :
> > > > r->connection->local_addr->port ?
> > > > r->connection->local_addr->port
> > > > ap_default_port(r);
> > > > }
> > > >
> > > > /* default */
> > > > return port;
> > > > }
> > > > ----------------
> > > >
> > > > This doesn't seem like coming from headers, but rather from URL or
as
> > > > indicated by the server itself. What do you think?
> > > >
> > > > Bojan
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> > > >
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> > For additional commands, e-mail:
<ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Spec question: RE BUG 12052
Posted by co...@covalent.net.
On Wed, 28 Aug 2002, Bill Barker wrote:
> > I think the decision to use the Host header is right, but
> > I agree that it violates the wording in the servlet spec.
> >
> > The SERVER_PORT and the port in the Host: header are different
> > beasts - in most use cases I've seen the user is interested
> > in the second.
>
> Not anymore. ;-) In the current 2.4 spec draft it is required to be taken
> from the Host header.
I hope this is listed in the 'incompatible changes between 2.3 and 2.4' :-)
As for the new wording - am I missing the ':-)' ?
So: getServerPort() should return the same as the CGI variable SERVER_PORT
( which returns the server port, not the host header ! ), meaning the
value of the part after : in the Host header.
I didn't know that the servlet spec can define new meanings for the
CGI spec.
Costin
> <spec-quote version="2.4" section="14.2.16">
> getServerName()
> public java.lang.String getServerName()
> Returns the host name of the server to which the request was sent. For HTTP
> servlets, same as the value of the CGI variable SERVER_NAME, meaning the
> value of the part before ":" in the Host header, if any, or the resolved
> server
> name, or the server IP address.
> Returns: a String containing the name of the server
>
> getServerPort()
> public int getServerPort()
> Returns the port number to which the request was sent. For HTTP servlets,
> same as the value of the CGI variable SERVER_PORT, meaning the value of the
> part after ":" in the Host header, if any, or the server port where the
> client
> connection was accepted on.
> Returns: an integer specifying the port number
> </spec-quote>
>
> >
> > Note that a load balancer or proxy is required ( AFAIK ) to insert
> > Host: headers if none is present.
> >
> > Costin
> >
> > On 29 Aug 2002, Bojan Smojver wrote:
> >
> > > On Thu, 2002-08-29 at 04:28, Bill Barker wrote:
> > >
> > > > The question in 12052 is whether Apache should use the socket port (as
> it
> > > > does now), or the port in the Host header. When this came up with the
> > > > Coyote/Http11 connector, the decision was that the Host header was the
> > > > correct one. I'd have to say that the bug is valid.
> > >
> > > This is what the API (2.2) docs say about the getServerPort():
> > >
> > > ----------------
> > > Returns the port number on which this request was received. For HTTP
> > > servlets, same as the value of the CGI variable SERVER_PORT.
> > > ----------------
> > >
> > > This in itself could be contradicting, but I think that in the case of
> > > Apache it is pretty straightforward.
> > >
> > > This is what Apache 2.0 does to populate the variable SERVER_PORT:
> > >
> > > ----------------
> > > apr_table_addn(e, "SERVER_PORT",
> > > apr_psprintf(r->pool, "%u", ap_get_server_port(r)));
> > > ----------------
> > >
> > > And this is the ap_get_server_port():
> > >
> > > ----------------
> > > AP_DECLARE(apr_port_t) ap_get_server_port(const request_rec *r)
> > > {
> > > apr_port_t port;
> > > core_dir_config *d =
> > > (core_dir_config *)ap_get_module_config(r->per_dir_config,
> > > &core_module);
> > >
> > > if (d->use_canonical_name == USE_CANONICAL_NAME_OFF
> > > || d->use_canonical_name == USE_CANONICAL_NAME_DNS) {
> > >
> > > /* With UseCanonicalName off Apache will form self-referential
> > > * URLs using the hostname and port supplied by the client if
> > > * any are supplied (otherwise it will use the canonical name).
> > > */
> > > port = r->parsed_uri.port ? r->parsed_uri.port :
> > > r->server->port ? r->server->port :
> > > ap_default_port(r);
> > > }
> > > else { /* d->use_canonical_name == USE_CANONICAL_NAME_ON */
> > >
> > > /* With UseCanonicalName on (and in all versions prior to 1.3)
> > > * Apache will use the hostname and port specified in the
> > > * ServerName directive to construct a canonical name for the
> > > * server. (If no port was specified in the ServerName
> > > * directive, Apache uses the port supplied by the client if
> > > * any is supplied, and finally the default port for the
> > > protocol
> > > * used.
> > > */
> > > port = r->server->port ? r->server->port :
> > > r->connection->local_addr->port ?
> > > r->connection->local_addr->port
> > > ap_default_port(r);
> > > }
> > >
> > > /* default */
> > > return port;
> > > }
> > > ----------------
> > >
> > > This doesn't seem like coming from headers, but rather from URL or as
> > > indicated by the server itself. What do you think?
> > >
> > > Bojan
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Spec question: RE BUG 12052
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: <co...@covalent.net>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Wednesday, August 28, 2002 5:01 PM
Subject: Re: Spec question: RE BUG 12052
> I think the decision to use the Host header is right, but
> I agree that it violates the wording in the servlet spec.
>
> The SERVER_PORT and the port in the Host: header are different
> beasts - in most use cases I've seen the user is interested
> in the second.
Not anymore. ;-) In the current 2.4 spec draft it is required to be taken
from the Host header.
<spec-quote version="2.4" section="14.2.16">
getServerName()
public java.lang.String getServerName()
Returns the host name of the server to which the request was sent. For HTTP
servlets, same as the value of the CGI variable SERVER_NAME, meaning the
value of the part before ":" in the Host header, if any, or the resolved
server
name, or the server IP address.
Returns: a String containing the name of the server
getServerPort()
public int getServerPort()
Returns the port number to which the request was sent. For HTTP servlets,
same as the value of the CGI variable SERVER_PORT, meaning the value of the
part after ":" in the Host header, if any, or the server port where the
client
connection was accepted on.
Returns: an integer specifying the port number
</spec-quote>
>
> Note that a load balancer or proxy is required ( AFAIK ) to insert
> Host: headers if none is present.
>
> Costin
>
> On 29 Aug 2002, Bojan Smojver wrote:
>
> > On Thu, 2002-08-29 at 04:28, Bill Barker wrote:
> >
> > > The question in 12052 is whether Apache should use the socket port (as
it
> > > does now), or the port in the Host header. When this came up with the
> > > Coyote/Http11 connector, the decision was that the Host header was the
> > > correct one. I'd have to say that the bug is valid.
> >
> > This is what the API (2.2) docs say about the getServerPort():
> >
> > ----------------
> > Returns the port number on which this request was received. For HTTP
> > servlets, same as the value of the CGI variable SERVER_PORT.
> > ----------------
> >
> > This in itself could be contradicting, but I think that in the case of
> > Apache it is pretty straightforward.
> >
> > This is what Apache 2.0 does to populate the variable SERVER_PORT:
> >
> > ----------------
> > apr_table_addn(e, "SERVER_PORT",
> > apr_psprintf(r->pool, "%u", ap_get_server_port(r)));
> > ----------------
> >
> > And this is the ap_get_server_port():
> >
> > ----------------
> > AP_DECLARE(apr_port_t) ap_get_server_port(const request_rec *r)
> > {
> > apr_port_t port;
> > core_dir_config *d =
> > (core_dir_config *)ap_get_module_config(r->per_dir_config,
> > &core_module);
> >
> > if (d->use_canonical_name == USE_CANONICAL_NAME_OFF
> > || d->use_canonical_name == USE_CANONICAL_NAME_DNS) {
> >
> > /* With UseCanonicalName off Apache will form self-referential
> > * URLs using the hostname and port supplied by the client if
> > * any are supplied (otherwise it will use the canonical name).
> > */
> > port = r->parsed_uri.port ? r->parsed_uri.port :
> > r->server->port ? r->server->port :
> > ap_default_port(r);
> > }
> > else { /* d->use_canonical_name == USE_CANONICAL_NAME_ON */
> >
> > /* With UseCanonicalName on (and in all versions prior to 1.3)
> > * Apache will use the hostname and port specified in the
> > * ServerName directive to construct a canonical name for the
> > * server. (If no port was specified in the ServerName
> > * directive, Apache uses the port supplied by the client if
> > * any is supplied, and finally the default port for the
> > protocol
> > * used.
> > */
> > port = r->server->port ? r->server->port :
> > r->connection->local_addr->port ?
> > r->connection->local_addr->port
> > ap_default_port(r);
> > }
> >
> > /* default */
> > return port;
> > }
> > ----------------
> >
> > This doesn't seem like coming from headers, but rather from URL or as
> > indicated by the server itself. What do you think?
> >
> > Bojan
> >
> >
> > --
> > To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> > For additional commands, e-mail:
<ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Spec question: RE BUG 12052
Posted by co...@covalent.net.
I think the decision to use the Host header is right, but
I agree that it violates the wording in the servlet spec.
The SERVER_PORT and the port in the Host: header are different
beasts - in most use cases I've seen the user is interested
in the second.
Note that a load balancer or proxy is required ( AFAIK ) to insert
Host: headers if none is present.
Costin
On 29 Aug 2002, Bojan Smojver wrote:
> On Thu, 2002-08-29 at 04:28, Bill Barker wrote:
>
> > The question in 12052 is whether Apache should use the socket port (as it
> > does now), or the port in the Host header. When this came up with the
> > Coyote/Http11 connector, the decision was that the Host header was the
> > correct one. I'd have to say that the bug is valid.
>
> This is what the API (2.2) docs say about the getServerPort():
>
> ----------------
> Returns the port number on which this request was received. For HTTP
> servlets, same as the value of the CGI variable SERVER_PORT.
> ----------------
>
> This in itself could be contradicting, but I think that in the case of
> Apache it is pretty straightforward.
>
> This is what Apache 2.0 does to populate the variable SERVER_PORT:
>
> ----------------
> apr_table_addn(e, "SERVER_PORT",
> apr_psprintf(r->pool, "%u", ap_get_server_port(r)));
> ----------------
>
> And this is the ap_get_server_port():
>
> ----------------
> AP_DECLARE(apr_port_t) ap_get_server_port(const request_rec *r)
> {
> apr_port_t port;
> core_dir_config *d =
> (core_dir_config *)ap_get_module_config(r->per_dir_config,
> &core_module);
>
> if (d->use_canonical_name == USE_CANONICAL_NAME_OFF
> || d->use_canonical_name == USE_CANONICAL_NAME_DNS) {
>
> /* With UseCanonicalName off Apache will form self-referential
> * URLs using the hostname and port supplied by the client if
> * any are supplied (otherwise it will use the canonical name).
> */
> port = r->parsed_uri.port ? r->parsed_uri.port :
> r->server->port ? r->server->port :
> ap_default_port(r);
> }
> else { /* d->use_canonical_name == USE_CANONICAL_NAME_ON */
>
> /* With UseCanonicalName on (and in all versions prior to 1.3)
> * Apache will use the hostname and port specified in the
> * ServerName directive to construct a canonical name for the
> * server. (If no port was specified in the ServerName
> * directive, Apache uses the port supplied by the client if
> * any is supplied, and finally the default port for the
> protocol
> * used.
> */
> port = r->server->port ? r->server->port :
> r->connection->local_addr->port ?
> r->connection->local_addr->port
> ap_default_port(r);
> }
>
> /* default */
> return port;
> }
> ----------------
>
> This doesn't seem like coming from headers, but rather from URL or as
> indicated by the server itself. What do you think?
>
> Bojan
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Spec question: RE BUG 12052
Posted by Bojan Smojver <bo...@rexursive.com>.
On Thu, 2002-08-29 at 04:28, Bill Barker wrote:
> The question in 12052 is whether Apache should use the socket port (as it
> does now), or the port in the Host header. When this came up with the
> Coyote/Http11 connector, the decision was that the Host header was the
> correct one. I'd have to say that the bug is valid.
This is what the API (2.2) docs say about the getServerPort():
----------------
Returns the port number on which this request was received. For HTTP
servlets, same as the value of the CGI variable SERVER_PORT.
----------------
This in itself could be contradicting, but I think that in the case of
Apache it is pretty straightforward.
This is what Apache 2.0 does to populate the variable SERVER_PORT:
----------------
apr_table_addn(e, "SERVER_PORT",
apr_psprintf(r->pool, "%u", ap_get_server_port(r)));
----------------
And this is the ap_get_server_port():
----------------
AP_DECLARE(apr_port_t) ap_get_server_port(const request_rec *r)
{
apr_port_t port;
core_dir_config *d =
(core_dir_config *)ap_get_module_config(r->per_dir_config,
&core_module);
if (d->use_canonical_name == USE_CANONICAL_NAME_OFF
|| d->use_canonical_name == USE_CANONICAL_NAME_DNS) {
/* With UseCanonicalName off Apache will form self-referential
* URLs using the hostname and port supplied by the client if
* any are supplied (otherwise it will use the canonical name).
*/
port = r->parsed_uri.port ? r->parsed_uri.port :
r->server->port ? r->server->port :
ap_default_port(r);
}
else { /* d->use_canonical_name == USE_CANONICAL_NAME_ON */
/* With UseCanonicalName on (and in all versions prior to 1.3)
* Apache will use the hostname and port specified in the
* ServerName directive to construct a canonical name for the
* server. (If no port was specified in the ServerName
* directive, Apache uses the port supplied by the client if
* any is supplied, and finally the default port for the
protocol
* used.
*/
port = r->server->port ? r->server->port :
r->connection->local_addr->port ?
r->connection->local_addr->port
ap_default_port(r);
}
/* default */
return port;
}
----------------
This doesn't seem like coming from headers, but rather from URL or as
indicated by the server itself. What do you think?
Bojan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Spec question: RE BUG 12052
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Costin Manolache" <cm...@yahoo.com>
Newsgroups: gmane.comp.jakarta.tomcat.devel
To: <to...@jakarta.apache.org>
Sent: Wednesday, August 28, 2002 10:36 AM
Subject: RE: Spec question: RE BUG 12052
> John Trollinger wrote:
>
>
> > I can agree that mod_jk can be seen as part of the servlet container,
> > but
> > I wonder how you are going to "fake" tomcat into thinking the request
> > came from
> > port 80 when it really came from port 8009 and what other implication /
> > assumptions
> > would occur because of this.
>
> That's simple - all web servers provide the port used to receive
> the request. And that's forwarded to tomcat, and set in the request.
> That's how it allways worked.
>
Costin is correct. mod_jk has always set request.getServerPort() to 80 when
Apache is running on 80, and forwarding on 8009 to TC.
The question in 12052 is whether Apache should use the socket port (as it
does now), or the port in the Host header. When this came up with the
Coyote/Http11 connector, the decision was that the Host header was the
correct one. I'd have to say that the bug is valid.
>
> Costin
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Spec question: RE BUG 12052
Posted by Costin Manolache <cm...@yahoo.com>.
John Trollinger wrote:
> I can agree that mod_jk can be seen as part of the servlet container,
> but
> I wonder how you are going to "fake" tomcat into thinking the request
> came from
> port 80 when it really came from port 8009 and what other implication /
> assumptions
> would occur because of this.
That's simple - all web servers provide the port used to receive
the request. And that's forwarded to tomcat, and set in the request.
That's how it allways worked.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Spec question: RE BUG 12052
Posted by co...@covalent.net.
On Wed, 28 Aug 2002, Craig R. McClanahan wrote:
> If you run Tomcat behind Apache using JK, the entire combination is the
> "container" from the perspective of the servlet specification. The entire
> combination has to meet all the spec rules or it's not compliant.
>
> The fact that the servlet spec defines things differently than web servers
> did things is totally irrelevant to spec compliance.
Apache, IIS and iPlanet all follow some rules that are different from
the servlet spec. And I don't expect those web servers to be changed to
match what the JCP defines.
Apache is a web server, it provides support for a servlet container
( tomcat + jk ), and also for PHP, mod_perl and even ASP.
Apache+PHP+mod_perl+ASP+jk+tomcat is not a servlet container.
We do have a problem that jk+tomcat has to deal with what becomes
a bigger and bigger mismatch, but that's mostly irrelevant to
the web server.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Spec question: RE BUG 12052
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 28 Aug 2002 costinm@covalent.net wrote:
> Date: Wed, 28 Aug 2002 10:03:34 -0700 (PDT)
> From: costinm@covalent.net
> Reply-To: Tomcat Developers List <to...@jakarta.apache.org>
> To: Tomcat Developers List <to...@jakarta.apache.org>
> Subject: RE: Spec question: RE BUG 12052
>
> On Wed, 28 Aug 2002, John Trollinger wrote:
>
> > > Consider Apache running on port 80, forwarding to Tomcat on
> > > 8009 (the default setup). I think it's reasonable for the
> > > application developer to assume that getServerPort() is going
> > > to return 80 and not 8009, because they should conceptually
> > > view the entire "Apache+Tomcat" thing as a single server.
> >
> > I have to disagree with you there. If a request comes to the servlet
> > engine
> > on port 8009 then getServerPort() should return that. It is bad to have
> > Tomcat try and guess where its requests are coming from.
>
> And what if Apache+jk is used with unix domain sockets or JNI ?
>
> The 8009 is just an implementation detail of something internal.
> In Apache+jk, the 'container' is Tomcat( java side ) plus at least
> a small piece of jk.
>
> It is an open question if Apache can be considered a part of the
> 'servlet container' in this case and should abide the rules set
> by the servlet spec. My answer is no - mostly because the spec
> sets some mapping rules that just can't match any of the main
> 3 web servers, and at least IIS is not going to change to follow
> the servlet spec. So the only practical aproach is to consider
> the web server is not part of the serlvet container.
>
> But mod_jk is IMO a part of the servlet container.
>
If you run Tomcat behind Apache using JK, the entire combination is the
"container" from the perspective of the servlet specification. The entire
combination has to meet all the spec rules or it's not compliant.
The fact that the servlet spec defines things differently than web servers
did things is totally irrelevant to spec compliance.
>
> Costin
Craig
>
>
>
> >
> > >
> > > As for implementing this, a couple of possibilities:
> > >
> > > * Include the port number along with the host name (haven't checked
> > > if this is already happening)
> > >
> > > * Add a protocol variable in the JK protocol so that the web server
> > > can forward which port number the request was received on.
> > >
> > > * Add a Connector property saying the port number that should be
> > > used for getServerPort() for all requests processed by this
> > > connector
> > > (the deprecated HttpConnector code had proxyPort for this purpose).
> > >
> > > If a load balancer or proxy *ahead* of Apache is doing the
> > > port shifting, there's not a lot we can do. But we should
> > > cover the case for requests that come in to the web server
> > > and get forwarded by us.
> > >
> > > > Bojan
> > >
> > > Craig
> > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > > <mailto:tomcat-dev-> unsubscribe@jakarta.apache.org>
> > > For
> > > additional commands,
> > > e-mail: <ma...@jakarta.apache.org>
> > >
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Spec question: RE BUG 12052
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 28 Aug 2002, John Trollinger wrote:
> Date: Wed, 28 Aug 2002 13:21:26 -0400
> From: John Trollinger <ja...@trollingers.com>
> Reply-To: Tomcat Developers List <to...@jakarta.apache.org>
> To: 'Tomcat Developers List' <to...@jakarta.apache.org>
> Subject: RE: Spec question: RE BUG 12052
>
>
>
> > -----Original Message-----
> > From: costinm@covalent.net [mailto:costinm@covalent.net]
> > Sent: Wednesday, August 28, 2002 1:04 PM
> > To: Tomcat Developers List
> > Subject: RE: Spec question: RE BUG 12052
> >
> >
> > On Wed, 28 Aug 2002, John Trollinger wrote:
> >
> > > > Consider Apache running on port 80, forwarding to Tomcat on
> > > > 8009 (the default setup). I think it's reasonable for the
> > > > application developer to assume that getServerPort() is going
> > > > to return 80 and not 8009, because they should conceptually
> > > > view the entire "Apache+Tomcat" thing as a single server.
> > >
> > > I have to disagree with you there. If a request comes to
> > the servlet
> > > engine on port 8009 then getServerPort() should return that. It is
> > > bad to have Tomcat try and guess where its requests are coming from.
> >
> > And what if Apache+jk is used with unix domain sockets or JNI ?
> >
> > The 8009 is just an implementation detail of something
> > internal. In Apache+jk, the 'container' is Tomcat( java side
> > ) plus at least a small piece of jk.
> >
> > It is an open question if Apache can be considered a part of
> > the 'servlet container' in this case and should abide the rules set
> > by the servlet spec. My answer is no - mostly because the
> > spec sets some mapping rules that just can't match any of the main
> > 3 web servers, and at least IIS is not going to change to
> > follow the servlet spec. So the only practical aproach is to consider
> > the web server is not part of the serlvet container.
> >
> > But mod_jk is IMO a part of the servlet container.
> >
> >
> > Costin
>
> I can agree that mod_jk can be seen as part of the servlet container,
> but
> I wonder how you are going to "fake" tomcat into thinking the request
> came from
> port 80 when it really came from port 8009 and what other implication /
> assumptions
> would occur because of this.
>
I included at least three different ways to implement this. It's just a
matter of including the requierd information in the messages sent to
Tomcat, just like the host name is forwarded.
The implications of implementing this correctly include:
* A web application can construct an absolute URL that will
always be able to get back to this app (consider what
happens if you return a URL with 8009 in it because that
is what getServerPort() returned).
* Tomcat can construct correct URLs for redirects (it is
required to do relative->absolute conversion) and
URL-rewriting for session management.
The implications of not implementing this correctly include:
* Web applications have to include separately configured or
hard coded information about the server port number when
constructing absolute URLs.
* Bug reports from users (there have been several on this
topic).
Craig
>
>
> >
> >
> >
> > >
> > > >
> > > > As for implementing this, a couple of possibilities:
> > > >
> > > > * Include the port number along with the host name
> > (haven't checked
> > > > if this is already happening)
> > > >
> > > > * Add a protocol variable in the JK protocol so that the
> > web server
> > > > can forward which port number the request was received on.
> > > >
> > > > * Add a Connector property saying the port number that should be
> > > > used for getServerPort() for all requests processed by this
> > > > connector
> > > > (the deprecated HttpConnector code had proxyPort for
> > this purpose).
> > > >
> > > > If a load balancer or proxy *ahead* of Apache is doing the
> > > > port shifting, there's not a lot we can do. But we should
> > > > cover the case for requests that come in to the web server
> > > > and get forwarded by us.
> > > >
> > > > > Bojan
> > > >
> > > > Craig
> > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > > <mailto:tomcat-dev-> unsubscribe@jakarta.apache.org>
> > > > For
> > > > additional commands,
> > > > e-mail: <ma...@jakarta.apache.org>
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <mailto:tomcat-dev-> unsubscribe@jakarta.apache.org>
> > > For
> > additional commands,
> > e-mail:
> > > <ma...@jakarta.apache.org>
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:tomcat-dev-> unsubscribe@jakarta.apache.org>
> > For
> > additional commands,
> > e-mail: <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Spec question: RE BUG 12052
Posted by John Trollinger <ja...@trollingers.com>.
> -----Original Message-----
> From: costinm@covalent.net [mailto:costinm@covalent.net]
> Sent: Wednesday, August 28, 2002 1:04 PM
> To: Tomcat Developers List
> Subject: RE: Spec question: RE BUG 12052
>
>
> On Wed, 28 Aug 2002, John Trollinger wrote:
>
> > > Consider Apache running on port 80, forwarding to Tomcat on
> > > 8009 (the default setup). I think it's reasonable for the
> > > application developer to assume that getServerPort() is going
> > > to return 80 and not 8009, because they should conceptually
> > > view the entire "Apache+Tomcat" thing as a single server.
> >
> > I have to disagree with you there. If a request comes to
> the servlet
> > engine on port 8009 then getServerPort() should return that. It is
> > bad to have Tomcat try and guess where its requests are coming from.
>
> And what if Apache+jk is used with unix domain sockets or JNI ?
>
> The 8009 is just an implementation detail of something
> internal. In Apache+jk, the 'container' is Tomcat( java side
> ) plus at least a small piece of jk.
>
> It is an open question if Apache can be considered a part of
> the 'servlet container' in this case and should abide the rules set
> by the servlet spec. My answer is no - mostly because the
> spec sets some mapping rules that just can't match any of the main
> 3 web servers, and at least IIS is not going to change to
> follow the servlet spec. So the only practical aproach is to consider
> the web server is not part of the serlvet container.
>
> But mod_jk is IMO a part of the servlet container.
>
>
> Costin
I can agree that mod_jk can be seen as part of the servlet container,
but
I wonder how you are going to "fake" tomcat into thinking the request
came from
port 80 when it really came from port 8009 and what other implication /
assumptions
would occur because of this.
>
>
>
> >
> > >
> > > As for implementing this, a couple of possibilities:
> > >
> > > * Include the port number along with the host name
> (haven't checked
> > > if this is already happening)
> > >
> > > * Add a protocol variable in the JK protocol so that the
> web server
> > > can forward which port number the request was received on.
> > >
> > > * Add a Connector property saying the port number that should be
> > > used for getServerPort() for all requests processed by this
> > > connector
> > > (the deprecated HttpConnector code had proxyPort for
> this purpose).
> > >
> > > If a load balancer or proxy *ahead* of Apache is doing the
> > > port shifting, there's not a lot we can do. But we should
> > > cover the case for requests that come in to the web server
> > > and get forwarded by us.
> > >
> > > > Bojan
> > >
> > > Craig
> > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > > <mailto:tomcat-dev-> unsubscribe@jakarta.apache.org>
> > > For
> > > additional commands,
> > > e-mail: <ma...@jakarta.apache.org>
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:tomcat-dev-> unsubscribe@jakarta.apache.org>
> > For
> additional commands,
> e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
> <mailto:tomcat-dev-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Spec question: RE BUG 12052
Posted by co...@covalent.net.
On Wed, 28 Aug 2002, John Trollinger wrote:
> > Consider Apache running on port 80, forwarding to Tomcat on
> > 8009 (the default setup). I think it's reasonable for the
> > application developer to assume that getServerPort() is going
> > to return 80 and not 8009, because they should conceptually
> > view the entire "Apache+Tomcat" thing as a single server.
>
> I have to disagree with you there. If a request comes to the servlet
> engine
> on port 8009 then getServerPort() should return that. It is bad to have
> Tomcat try and guess where its requests are coming from.
And what if Apache+jk is used with unix domain sockets or JNI ?
The 8009 is just an implementation detail of something internal.
In Apache+jk, the 'container' is Tomcat( java side ) plus at least
a small piece of jk.
It is an open question if Apache can be considered a part of the
'servlet container' in this case and should abide the rules set
by the servlet spec. My answer is no - mostly because the spec
sets some mapping rules that just can't match any of the main
3 web servers, and at least IIS is not going to change to follow
the servlet spec. So the only practical aproach is to consider
the web server is not part of the serlvet container.
But mod_jk is IMO a part of the servlet container.
Costin
>
> >
> > As for implementing this, a couple of possibilities:
> >
> > * Include the port number along with the host name (haven't checked
> > if this is already happening)
> >
> > * Add a protocol variable in the JK protocol so that the web server
> > can forward which port number the request was received on.
> >
> > * Add a Connector property saying the port number that should be
> > used for getServerPort() for all requests processed by this
> > connector
> > (the deprecated HttpConnector code had proxyPort for this purpose).
> >
> > If a load balancer or proxy *ahead* of Apache is doing the
> > port shifting, there's not a lot we can do. But we should
> > cover the case for requests that come in to the web server
> > and get forwarded by us.
> >
> > > Bojan
> >
> > Craig
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:tomcat-dev-> unsubscribe@jakarta.apache.org>
> > For
> > additional commands,
> > e-mail: <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Spec question: RE BUG 12052
Posted by John Trollinger <ja...@trollingers.com>.
> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> Sent: Wednesday, August 28, 2002 12:15 PM
> To: Tomcat Developers List
> Subject: Re: Spec question: RE BUG 12052
>
>
>
>
> On 28 Aug 2002, Bojan Smojver wrote:
>
> > Date: 28 Aug 2002 23:27:18 +1000
> > From: Bojan Smojver <bo...@rexursive.com>
> > Reply-To: Tomcat Developers List <to...@jakarta.apache.org>
> > To: Tomcat Dev List <to...@jakarta.apache.org>
> > Subject: Spec question: RE BUG 12052
> >
> > Craig,
> >
> > I think this bug report is invalid, since Tomcat/Apache has no
> > knowledge of load balancers and firewalls, so it is unrealistic to
> > expect to return port numbers that it doesn't know about.
> What do you
> > think?
> >
> > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12052
> >
> > Other opinions welcome :-)
> >
>
> There are circumstances when we're not going to know the port
> number, but normal use of Tomcat behind JK doesn't seem to be
> one of them, IMHO.
>
> Consider Apache running on port 80, forwarding to Tomcat on
> 8009 (the default setup). I think it's reasonable for the
> application developer to assume that getServerPort() is going
> to return 80 and not 8009, because they should conceptually
> view the entire "Apache+Tomcat" thing as a single server.
I have to disagree with you there. If a request comes to the servlet
engine
on port 8009 then getServerPort() should return that. It is bad to have
Tomcat try and guess where its requests are coming from.
>
> As for implementing this, a couple of possibilities:
>
> * Include the port number along with the host name (haven't checked
> if this is already happening)
>
> * Add a protocol variable in the JK protocol so that the web server
> can forward which port number the request was received on.
>
> * Add a Connector property saying the port number that should be
> used for getServerPort() for all requests processed by this
> connector
> (the deprecated HttpConnector code had proxyPort for this purpose).
>
> If a load balancer or proxy *ahead* of Apache is doing the
> port shifting, there's not a lot we can do. But we should
> cover the case for requests that come in to the web server
> and get forwarded by us.
>
> > Bojan
>
> Craig
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:tomcat-dev-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Spec question: RE BUG 12052
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On 28 Aug 2002, Bojan Smojver wrote:
> Date: 28 Aug 2002 23:27:18 +1000
> From: Bojan Smojver <bo...@rexursive.com>
> Reply-To: Tomcat Developers List <to...@jakarta.apache.org>
> To: Tomcat Dev List <to...@jakarta.apache.org>
> Subject: Spec question: RE BUG 12052
>
> Craig,
>
> I think this bug report is invalid, since Tomcat/Apache has no knowledge
> of load balancers and firewalls, so it is unrealistic to expect to
> return port numbers that it doesn't know about. What do you think?
>
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12052
>
> Other opinions welcome :-)
>
There are circumstances when we're not going to know the port number, but
normal use of Tomcat behind JK doesn't seem to be one of them, IMHO.
Consider Apache running on port 80, forwarding to Tomcat on 8009 (the
default setup). I think it's reasonable for the application developer to
assume that getServerPort() is going to return 80 and not 8009, because
they should conceptually view the entire "Apache+Tomcat" thing as a single
server.
As for implementing this, a couple of possibilities:
* Include the port number along with the host name (haven't checked
if this is already happening)
* Add a protocol variable in the JK protocol so that the web server
can forward which port number the request was received on.
* Add a Connector property saying the port number that should be
used for getServerPort() for all requests processed by this connector
(the deprecated HttpConnector code had proxyPort for this purpose).
If a load balancer or proxy *ahead* of Apache is doing the port shifting,
there's not a lot we can do. But we should cover the case for requests
that come in to the web server and get forwarded by us.
> Bojan
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>