On Wed, 28 Aug 2002, John Trollinger wrote:
> Date: Wed, 28 Aug 2002 13:21:26 -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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > 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-> [EMAIL PROTECTED]>
> > > > For
> > > > additional commands,
> > > > e-mail: <mailto:[EMAIL PROTECTED]>
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <mailto:tomcat-dev-> [EMAIL PROTECTED]>
> > > For
> > additional commands,
> > e-mail:
> > > <mailto:[EMAIL PROTECTED]>
> > >
> > >
> >
> >
> > --
> > 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]>
