For Tomcat 3.2.2 I think the existing solution is OK.  If 3.3 and 4.0 want
to add DNS lookup, thats fine.  If someone wants to add DNS lookup to 3.2.3,
thats OK, too.  The 2.2 specification only says that if we don't know the
remote host's name we have to supply the remote host's IP address, it
doesn't say how hard we have to try to figure out the host name if all we
have is an IP address.

The previous behavior violated the spec and therefore had to be changed
prior to releasing 3.2.2.  Right now I can live with a simple solution.

I'm waiting to hear back from a user to make sure that the last change for
JDK 1.1 support fixed his problem and then I plan to call a final release
vote for TC3.2.2.  Adding DNS lookups is not something I'm comfortable with
at this point.

Marc "Just ship it" Saegesser

> -----Original Message-----
> From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
> Sent: Monday, May 07, 2001 4:14 PM
> To: [EMAIL PROTECTED]
> Subject: RE: About bug#208
>
>
> >I just commited the fix for 3.2.2.
>
> Not really.
>
> When the hostname is null or missing, you copy the host IP
> adress, but we there the name (DNS resolution). Something
> done by the caller (which agree to pay the price).
>
> >> -----Original Message-----
> >> From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
> >> Sent: Monday, May 07, 2001 11:16 AM
> >> To: [EMAIL PROTECTED]
> >> Subject: RE: About bug#208
> >>
> >>
> >> >According to the JavaDoc for ServletRequest.getRemoteHost()
> >> >
> >> >Returns the fully qualified name of the client that sent the
> >> >request, or the
> >> >IP address of the client if the name cannot be determined. For HTTP
> >> >servlets, same as the value of the CGI variable REMOTE_HOST.
> >> >
> >> >Based on that I would say that both implementations are wrong,
> >> >you should
> >> >never get an empty or a null value back.  I would also
> >argue strongly
> >> >against having tomcat do any reverse DNS look ups.  If the
> >web server
> >> >doesn't tell us the remote host name just use the IP address.
> >>
> >> Ok, I'll do accordingly.
> >> Did the 3.2.2 tree is closed ?
> >>
> >> >> -----Original Message-----
> >> >> From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
> >> >> Sent: Monday, May 07, 2001 9:00 AM
> >> >> To: [EMAIL PROTECTED]
> >> >> Subject: About bug#208
> >> >>
> >> >>
> >> >> Hi,
> >> >>
> >> >> The BUG #208 (request.getRemoteHost() returns empty string when
> >> >> using mod_jk
> >> >> BugRat Report#320)
> >> >> is still there (3.2.2b4). The difference is that when we're
> >> >using ajp12,
> >> >> getRemoteHost = ""
> >> >> and in ajp13, getRemoteHost = null.
> >> >>
> >> >> The fix is easy the getRemoteAddr() is allways set but :
> >> >>
> >> >> - Did we want to Tomcat ask the DNS to resolve the name
> >since it may
> >> >>   be time consuming ?
> >> >>
> >> >> - ajp12 return empty string, ajp13 return null, what solution is
> >> >> recommanded
> >> >>   in that case ?
> >> >>
> >> >> I also suspect TC 3.3 to have the same kind of problem ;(
> >> >>
> >> >> -
> >> >> Henri Gomez                 ___[_]____
> >> >> EMAIL : [EMAIL PROTECTED]        (. .)
> >> >> PGP KEY : 697ECEDD    ...oOOo..(_)..oOOo...
> >> >> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
> >> >>
> >> >>
> >> >>
> >> >> >-----Original Message-----
> >> >> >From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
> >> >> >Sent: Monday, May 07, 2001 2:40 PM
> >> >> >To: [EMAIL PROTECTED]
> >> >> >Subject: [PROPOSAL AJP14] AJP13 Evolution
> >> >> >
> >> >> >
> >> >> >Hi to all,
> >> >> >
> >> >> >You could find attached a proposal of evolution to
> >> >> >the current Apache JServ Protocol version 1.3,
> >> >> >also known as ajp13.
> >> >> >
> >> >> >Let start the comments, questions, remarks cycle.....
> >> >> >
> >> >> >PS : I've not cover here the full protocol but only the add-on
> >> >> >     from ajp13.
> >> >> >
> >> >> >-
> >> >> >Henri Gomez                 ___[_]____
> >> >> >EMAIL : [EMAIL PROTECTED]        (. .)
> >> >> >PGP KEY : 697ECEDD    ...oOOo..(_)..oOOo...
> >> >> >PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
> >> >> >
> >> >> >
> >> >
> >

Reply via email to