On Thu, Jan 22, 2004 at 01:16:45PM -0800, Bill Barker wrote:
> However, it is the correct value to pass to Tomcat. Tomcat correctly uses
> this value for getLocalPort. The value of getServerPort (which is the one
> used for redirection) is taken from the Host header (as required by the 2.4
> servlet spec).
Interesting. Because the problem we were having was that a redirect
generated from within Tomcat didn't work. It would put :8000 on the FQ
URL, which the client browser wouldn't be able to reach. That's the
reason I wrote the patch (and my old company is using it in production).
Perhaps there is a bug in the way redirect Locations are built? Is
Tomcat using local port if there is no port on the Host? Because in the
absence of a port, it should use the protocol default.
> ----- Original Message -----
> From: "Kyle VanderBeek" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, January 22, 2004 12:25 PM
> Subject: Re: [PATHCH] ./jk/native2/server/apache2/jk_service_apache2.c
>
>
> On Thu, Jan 22, 2004 at 09:08:48PM +0100, Günter Knauf wrote:
> > Hi Henri,
> > > Thanks to resubmit the latest patch for jk/jk2 on Apache 2 to see if
> > > everybody agree
> > ok.
> > With APR 1.0 apr_sockaddr_port_get() was removed without replacement.
> > I believe that the patch below is the correct replacement to archive
> _same_ behaviour as with apr_sockaddr_port_get() before, and I tested that
> it also works with APR 0.9.x (Apache 2.0.48 tested):
>
> Please look at the bug 16901 again. This is the WRONG behavior. The
> port that should be passed back to the tomcat layer isn't necessarily
> the same as the port being listened on. For example, configuring Apache
> httpd2 like this is perfectly legal:
>
> Listen 8000
> ...
> ServerName www.example.com:80
>
> This sort of thing is frequently used by people with server farms behind
> load balancers. This way they can run several httpd's on the same
> machine on different ports, group them, use NAT, all kinds of stuff.
>
> The point is: the port visible to the world is a configured value, not
> one that should be inferred from the socket. Please look at the patch
> on the bug again. It uses ap_get_server_port() to look up the
> *configured* port of the server record. Note, this is "ap_" not "apr_".
> The patch on the bug removes the dead "apr_" function you describe, but
> replaces it with the correct way of looking up the server name and port:
> by asking the httpd config functions.
>
> Please re-read the bug, and look at the UseCanonicalName doc mentioned
> therein.
>
> > # patch for APR 1.0 compatiblity
> > #
> > --- jk_service_apache2.c.orig Tue Sep 30 18:16:14 2003
> > +++ jk_service_apache2.c Wed Jan 21 17:43:14 2004
> > @@ -343,7 +343,6 @@
> > static int JK_METHOD jk2_init_ws_service(jk_env_t *env, jk_ws_service_t
> *s,
> > jk_worker_t *worker, void
> *serverObj)
> > {
> > - apr_port_t port;
> > char *ssl_temp = NULL;
> > jk_workerEnv_t *workerEnv;
> > request_rec *r=serverObj;
> > @@ -377,8 +376,7 @@
> > r->server->server_hostname);
> >
> > /* get the real port (otherwise redirect failed) */
> > - apr_sockaddr_port_get(&port,r->connection->local_addr);
> > - s->server_port = port;
> > + s->server_port = r->connection->local_addr->port;
> >
> > s->server_software = (char *)ap_get_server_version();
> >
> > ===================================================================
> > There's an outstanding patch in bugzilla:
> > http://nagoya.apache.org/bugzilla/showattachment.cgi?attach_id=8969
> >
> > --- jk/native2/server/apache2/jk_service_apache2.c 30 Sep 2003
> 13:42:02 -00001.36
> > +++ jk/native2/server/apache2/jk_service_apache2.c 7 Nov 2003
> 00:20:16 -0000
> > @@ -343,7 +343,6 @@
> > static int JK_METHOD jk2_init_ws_service(jk_env_t *env, jk_ws_service_t
> *s,
> > jk_worker_t *worker, void
> *serverObj)
> > {
> > - apr_port_t port;
> > char *ssl_temp = NULL;
> > jk_workerEnv_t *workerEnv;
> > request_rec *r=serverObj;
> > @@ -373,12 +372,10 @@
> > s->remote_addr = NULL_FOR_EMPTY(r->connection->remote_ip);
> >
> > /* get server name */
> > - s->server_name= (char *)(r->hostname ? r->hostname :
> > - r->server->server_hostname);
> > + s->server_name= (char *)ap_get_server_name(r);
> >
> > /* get the real port (otherwise redirect failed) */
> > - apr_sockaddr_port_get(&port,r->connection->local_addr);
> > - s->server_port = port;
> > + s->server_port = ap_get_server_port(r);
> >
> > s->server_software = (char *)ap_get_server_version();
> >
> > with this patch I'm also fine since it uses an API which still exists in
> APR 1.0 (just compiled with httpd-2.1-dev); but since I've no NAT setup for
> testing the issue described in bugzilla I cant tell if the patch solves the
> isssue, nor if it hurts something else....
> > but according to the 5 votes in bugzilla it seems to solve their problems,
> so I tend to this patch now ...
> >
> > once it is decided what we use now, I will create the other patches for
> mod_jk again...
> >
> >
> > thanks, Guenter.
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
> --
> [EMAIL PROTECTED]
> Some people have a way with words, while others... erm... thingy.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
> This message is intended only for the use of the person(s) listed above as the
> intended recipient(s), and may contain information that is PRIVILEGED and
> CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or
> distribute this message or any attachment. If you received this communication in
> error, please notify us immediately by e-mail and then delete all copies of this
> message and any attachments.
>
> In addition you should be aware that ordinary (unencrypted) e-mail sent through the
> Internet is not secure. Do not send confidential or sensitive information, such as
> social security numbers, account numbers, personal identification numbers and
> passwords, to us via ordinary (unencrypted) e-mail.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
[EMAIL PROTECTED]
Some people have a way with words, while others... erm... thingy.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
