On Wed, 28 Aug 2002, John Trollinger wrote:
> Date: Wed, 28 Aug 2002 12:19:19 -0400
> From: John Trollinger <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: 'Tomcat Developers List' <[EMAIL PROTECTED]>
> Subject: RE: Spec question: RE BUG 12052
>
>
>
> > -----Original Message-----
> > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> > 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 <[EMAIL PROTECTED]>
> > > Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> > > To: Tomcat Dev List <[EMAIL PROTECTED]>
> > > 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-> [EMAIL PROTECTED]>
> > For
> > additional commands,
> > e-mail: <mailto:[EMAIL PROTECTED]>
> >
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
