You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by GOMEZ Henri <hg...@slib.fr> on 2001/05/07 15:59:52 UTC

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 : hgomez@slib.fr        (. .)                     
PGP KEY : 697ECEDD    ...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-----Original Message-----
>From: GOMEZ Henri [mailto:hgomez@slib.fr]
>Sent: Monday, May 07, 2001 2:40 PM
>To: tomcat-dev@jakarta.apache.org
>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 : hgomez@slib.fr        (. .)                     
>PGP KEY : 697ECEDD    ...oOOo..(_)..oOOo...
>PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 
>
>

RE: About bug#208

Posted by Marc Saegesser <ma...@apropos.com>.
I think this area is sufficiently grey.  The *only* place I've been able to
find reference to the return value of getRemoteHost() is in the JavaDoc.
The specification text is silent on this topic.  The JavaDoc makes two
statements:

1)  Returns either a fully qualified host name or an IP address.
2)  Same as the CGI REMOTE_HOST variable.

As Nick points out, these two statements are not compatible.  I'm inclined
to lean towards option 1 simply because it is the behaviour that is
explicitly spelled out in the JavaDoc, but the point could be argued in
either way.

In any case, the current implementation is no more broken then the previous
one.

> -----Original Message-----
> From: Nick.Holloway@pyrites.org.uk [mailto:Nick.Holloway@pyrites.org.uk]
> Sent: Monday, May 07, 2001 4:58 PM
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: About bug#208
>
>
> craigmcc@apache.org (Craig R. McClanahan) writes:
> > On Mon, 7 May 2001, Marc Saegesser wrote:
> > > 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.
> >
> > Agreed.  You should get either a host name or an IP address (in string
> > form).
>
> Disagree.
>
> The CGI specification (1.1) has the following to say:
>
>     * REMOTE_HOST
>       The hostname making the request. If the server does not have this
>       information, it should set REMOTE_ADDR and leave this unset.
>
> I would say the equivalent of not setting the REMOTE_HOST CGI variable
> is to have request.getRemoteHost() return null.
>
> --
>  `O O'  | Nick.Holloway@pyrites.org.uk
> // ^ \\ | http://www.pyrites.org.uk/


Re: About bug#208

Posted by "Craig R. McClanahan" <cr...@apache.org>.

On 7 May 2001, Nick Holloway wrote:

> craigmcc@apache.org (Craig R. McClanahan) writes:
> > On Mon, 7 May 2001, Marc Saegesser wrote:
> > > 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.
> > 
> > Agreed.  You should get either a host name or an IP address (in string
> > form).
> 
> Disagree.
> 
> The CGI specification (1.1) has the following to say:
> 
>     * REMOTE_HOST       
>       The hostname making the request. If the server does not have this
>       information, it should set REMOTE_ADDR and leave this unset.
> 
> I would say the equivalent of not setting the REMOTE_HOST CGI variable
> is to have request.getRemoteHost() return null.
> 

"Equivalent" doesn't matter any more, because the semantics for this and
several other calls are no longer identical to CGI semantics.  (I've been
lobbying to get rid of all the "same as CGI variable FOO" comments in the
JavaDocs, but that is a different story ...).

Interestingly, this issue is being discussed by the JSR-053 expert group
as we speak, so a refinement in the semantics might show up in 2.3
final.  In the mean time, we need to obey what the Javadocs say:

  "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."

> -- 
>  `O O'  | Nick.Holloway@pyrites.org.uk
> // ^ \\ | http://www.pyrites.org.uk/
> 

Craig McClanahan



Re: About bug#208

Posted by Nick Holloway <Ni...@pyrites.org.uk>.
craigmcc@apache.org (Craig R. McClanahan) writes:
> On Mon, 7 May 2001, Marc Saegesser wrote:
> > 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.
> 
> Agreed.  You should get either a host name or an IP address (in string
> form).

Disagree.

The CGI specification (1.1) has the following to say:

    * REMOTE_HOST       
      The hostname making the request. If the server does not have this
      information, it should set REMOTE_ADDR and leave this unset.

I would say the equivalent of not setting the REMOTE_HOST CGI variable
is to have request.getRemoteHost() return null.

-- 
 `O O'  | Nick.Holloway@pyrites.org.uk
// ^ \\ | http://www.pyrites.org.uk/

RE: About bug#208

Posted by "Craig R. McClanahan" <cr...@apache.org>.

On Mon, 7 May 2001, Marc Saegesser wrote:

> 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.

Agreed.  You should get either a host name or an IP address (in string
form).

>  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.
> 

That works for the web-connected case.  If you're running Tomcat
stand-alone you need to be able to do the lookup.  In 4.0, that is only
done if the web app actually calls getRemoteHost(), so you don't pay the
performance hit unless you ask for it.

Craig


RE: About bug#208

Posted by Marc Saegesser <ma...@apropos.com>.
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.

> -----Original Message-----
> From: GOMEZ Henri [mailto:hgomez@slib.fr]
> Sent: Monday, May 07, 2001 9:00 AM
> To: tomcat-dev@jakarta.apache.org
> 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 : hgomez@slib.fr        (. .)
> PGP KEY : 697ECEDD    ...oOOo..(_)..oOOo...
> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
>
>
>
> >-----Original Message-----
> >From: GOMEZ Henri [mailto:hgomez@slib.fr]
> >Sent: Monday, May 07, 2001 2:40 PM
> >To: tomcat-dev@jakarta.apache.org
> >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 : hgomez@slib.fr        (. .)
> >PGP KEY : 697ECEDD    ...oOOo..(_)..oOOo...
> >PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
> >
> >