> If mod jk to working and configured then requests over port > 80 for .do > will be forwarded to mod_jk.
Yes, that works. > If you are getting links with 8080 in the urls then my guess > is you're > not requesting pages over port 80 but 8080. Requests that cause a problem are initiated by redirects. For example: <logic:redirect forward="welcome"/> > So the first question is, is mod_jk working? and how do you know this? I would assume it is functioning fine as all the defined Location's forward to Tomcat appropriately. Am I missing something? For example, this is our site: http://www.objectdomain.com/ when the above is entered, the index.jsp is encountered that contains the redirect. This results in the following URL: http://www.objectdomain.com:8080/welcome.do Note, if you manually remove the port from the above URL and resubmit the request, the port is not re-inserted until it encounters a link with a forward (most, but not all, of our links are currently simple HTML links, not forwards). Dan > -----Original Message----- > From: Mark Lowe [mailto:[EMAIL PROTECTED] > > Okay.. "Struts " doesn't do this at all but the http server catalina, > conveniently bundled with tomcat does .. (I think i've got the > catalina thing right) . > > If mod jk to working and configured then requests over port > 80 for .do > will be forwarded to mod_jk. > > If you are getting links with 8080 in the urls then my guess > is you're > not requesting pages over port 80 but 8080. > > So the first question is, is mod_jk working? and how do you know this? > > > On 14 Jan 2004, at 20:03, Mark Lowe wrote: > > > Okay.. > > > > You better go over the problem again, when you request a *.do over > > port 80 the links render with :8080 or do i not understand? > > > > On 14 Jan 2004, at 19:57, Dan Snider wrote: > > > >> we are using mod_jk2 > >> > >> > >>> -----Original Message----- > >>> > >>> > >>> On 14 Jan 2004, at 18:54, Dan Snider wrote: > >>> > >>>>> For situations like Tomcat running behind an Apache HTTPD > >>>>> server, this normally > >>>>> gets taken care of you automatically. > >>>> > >>>> We have Tomcat running behind an Apache HTTPD and we are > >>> getting the > >>>> port as > >>>> well. Is there perhaps something we are missing in the > >>> configuration? > >>> > >>> What connector are you using mod_jserv? mod_jk? > >>> > >>> > >>>> > >>>>> If you've got a > >>>>> different situation, > >>>>> you'll need to figure out how to tell your servlet container > >>>>> to adjust the > >>>>> server port it reports -- there's nothing Struts can do to help. > >>>> > >>>> If configuration is not the solution, any suggestions on > how to go > >>>> about > >>>> changing the reported port? > >>>> > >>>> To my mind, it is not so much that we want the servlet > container to > >>>> report a > >>>> different port (after all, it is using that port), we just > >>> want struts > >>>> to > >>>> use a different port (80) for links. That is, we want to > >>> ensure routing > >>>> through the front door (i.e., Apache). Would using a Filter be a > >>>> possible > >>>> solution? > >>> > >>> If apache and tomcat are running on the same machine then > >>> there should > >>> be no issue, it will be a matter of having request for *.do, *.jsp > >>> being mapped to the connector module. > >>> > >>> Cheers Mark > >>> > >>>> > >>>> Thanks, > >>>> > >>>> Dan > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> > >>>>> Quoting "Gabriel W." <[EMAIL PROTECTED]>: > >>>>> > >>>>>> Hi, > >>>>>> > >>>>>> I am relatively new to this list so I do not know if this > >>>>> topic was discussed > >>>>>> before (I checked the archive and it does not appear that way). > >>>>>> > >>>>>> It seems that Struts includes the ServerPort in web links > >>>>> if not of the > >>>>>> values 80 or 443 (e.g. http://mydomain.com:8080). In some > >>>>> cases this is not > >>>>>> the welcomed behavior. > >>>>>> Specifically if the Struts server is listening on Port > >>> 8080 behind a > >>>>>> firewall. The firewall receives the request from the outside > >>>>>> internet on port 80 and routes it to the machine listening > >>>>> on Port 8080. > >>>>>> > >>>>>> The Struts machine in this case does not know the > >>>>> difference and so includes > >>>>>> the Port 8080. > >>>>>> > >>>>>> I looked at the Struts source code I assume is behind the logic > >>>>>> (org.apache.struts.taglib.html.BaseTag), and it > >>>>>> does not appear as though there is a configuration flag to > >>>>> turn this logic > >>>>>> on/off. > >>>>>> > >>>>>> Are there any considerations for such an option in the > >>>>> future so that a > >>>>>> firewalled site won't have to show 8080. > >>>>>> > >>>>>> NOTE: This is a situation where the Struts server does not > >>>>> have permission to > >>>>>> listen on Port 80. > >>>>>> > >>>>>> Regards, > >>>>>> Gabe > >>>>>> > >>>>> > >>>>> Struts is basing its decision on the port returned by calling > >>>>> ServletRequest.getServerPort() -- in other words, if you've > >>>>> got a server or > >>>>> proxy that receives requests on port 80 and internally > >>>>> redirects them to some > >>>>> other port, there's absolutely no way that Struts can know > >>>>> what the right port > >>>>> number is unless your servlet container can tell it. > >>>>> > >>>>> For situations like Tomcat running behind an Apache HTTPD > >>>>> server, this normally > >>>>> gets taken care of you automatically. If you've got a > >>>>> different situation, > >>>>> you'll need to figure out how to tell your servlet container > >>>>> to adjust the > >>>>> server port it reports -- there's nothing Struts can do to help. > >>>>> > >>>>> Craig McClanahan > >>>> > >> > >> > --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: > [EMAIL PROTECTED] > >> > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
