RE: Spec question: RE BUG 12052

[Bojan Smojver]

On Fri, 2002-08-30 at 23:51, Ignacio J. Ortega wrote:
> > De: Bojan Smojver [mailto:[EMAIL PROTECTED]]
> > Enviado el: 30 de agosto de 2002 1:11
> > Para: Tomcat Dev List
> > Asunto: RE: Spec question: RE BUG 12052
> > 
> > 
> > On Thu, 2002-08-29 at 23:49, Ignacio J. Ortega wrote:
> >  
> > > We know how r->parsed_uri.port gets his value?
> > 
> > Yep. It's getting it from the URL, not the headers.
> > 
> 
> Wrong, It takes the port and ServerName from the Host: header if the
> Request-uri is relative ( most common case ) and from the Reqeust-Uri if
> it is absolute.. rfc2616 Section 5.2 strict compliance..

I had another look at Apache 2.0 code and I think you're right.

Bojan


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Spec question: RE BUG 12052

[Ignacio J. Ortega]

> De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Enviado el: 30 de agosto de 2002 20:50
> Para: Tomcat Developers List
> Asunto: RE: Spec question: RE BUG 12052

> The server may have 2 ip addresses, one visible from outside and one
> restricted by firewalls to only internal users ( and used for example
> for content updates ). 
> 
> In servlet 2.2 and 2.3, it is perfectly valid to use getServerName() 
> and get the address that received the request. Since the servlet

:), I need to announce that TC is not behaving this way since 2 years
ago or more, getServerName and getServerPort relies in the Host header
:)), so one never knows if the adapter where the request was received is
one or another.. only that the user seems to request some Host: or
another.. of course there are ways ( at least in 4.X ) to get to know
that a request comes exactly from one address, but they are config
tricks.. 

> spec doesn't provide any 'declarative' support for this kind of 
> access control - I think this is a valid solution. A firewall or 
> routing can protect the internal address ( say 10.0.0.1 - on a network
> card connected only to the internal net, and a firewall restricting
> outside access to this IP ). In 2.4 this will fail ( opening potential
> holes ) and in addition this kind of check will be impossible to 
> implement - since the address where the request was received will
> no longer be available.

What 2.4 is trying to specify, is what TC is doing right now, and i
agree that the definition open some holes, when TC is behind a
webserver, it must be the webserver who decides which are the actual
servername and port is, not TC.. 

Back to the roots, the only use the Host: header has is to select a
particular VS, and to get back to the original Request uri ( module
encode problems of course :) that was typed by the user, for example to
form a correct Location: header in case a 301.. 

For the second use, clearly Apache does what it suppoussed todo, and
more, it documents his behavior in the httpd.conf file

"
# UseCanonicalName: Determines how Apache constructs self-referencing 
# URLs and the SERVER_NAME and SERVER_PORT variables.
# When set "Off", Apache will use the Hostname and Port supplied
# by the client.  When set "On", Apache will use the value of the
# ServerName directive.
#
UseCanonicalName Off
"

:)

For the VS Matching, apache2 just uses the name ( for name based VS
there is no other way to do it ), but not the port supplied ( Just
tested ), the port for a VS match in A2 has to be the real socket port..
but never the name can be other than the supplied, cheated or not..

Anyway i have some doubts with the 2.4 spec definition, maybe is too
hard to tie this info in the API to the one present in the Host: header,
and probably the good behavior is to distinguish if the request comes
from the Standalone connector or not, in the case the request comes from
SC follow A2 strategies, adding our own "UseCanonicalName" and so on,
but trust A2 ( or IIS or whatever ) if used behind them

Saludos ,
Ignacio J. Ortega


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Spec question: RE BUG 12052

[Steve Downey]

I think you're missing the virtual server angle. There is NOT a 1-1 mapping
from ip address to DNS name. It's N-M. Even from the standpoint of a single
machine which received the request, there are many possible names for the IP
address.
So, given a request like:

   GET /pub/WWW/TheProject.html HTTP/1.1
   Host: www.w3.org

The only way to know which host the client intended is the Host header.

So, yes, this is spoofable, and should not be used as a security mechanism.
It was never designed to be one.

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Friday, August 30, 2002 2:50 PM
> To: Tomcat Developers List
> Subject: RE: Spec question: RE BUG 12052
>
>
> On Fri, 30 Aug 2002, Ignacio J. Ortega wrote:
>
> > > It may very well be a security issue ( and quite a big one !
> > > ). There are
> > > sites using all kinds of firewalls and settings in httpd.conf to
> > > restrict access to some hosts or ports ( say from internal network ).
> > > If Host: info is used for security checkings - it would be trivial to
> > > bypass some of this security.
> > >
> > > In particular - people may have servlets that check getServerName() to
> > > find if 'localhost' was used - the spec change will leave them with
> > > a huge hole ( any request with forged Host: localhost will pass ).
> > >
> > >
> >
> > Good Comment..
> >
> > In the particular case you have pointed, it's a user problem, a request
> > with Host: Localhost can be only be issued by someone with Remote
> > Ip=localhost..
>
> 'localhost' is just an example.
>
> The server may have 2 ip addresses, one visible from outside and one
> restricted by firewalls to only internal users ( and used for example
> for content updates ).
>
> In servlet 2.2 and 2.3, it is perfectly valid to use getServerName()
> and get the address that received the request. Since the servlet
> spec doesn't provide any 'declarative' support for this kind of
> access control - I think this is a valid solution. A firewall or
> routing can protect the internal address ( say 10.0.0.1 - on a network
> card connected only to the internal net, and a firewall restricting
> outside access to this IP ). In 2.4 this will fail ( opening potential
> holes ) and in addition this kind of check will be impossible to
> implement - since the address where the request was received will
> no longer be available.
>
>
> > So one can take some security measures to check the correctness of the
> > request..
>
> For example ?
>
>
> > All other use case i can imagine fall within the users problems, if the
> > correct VS has received the request, it's the Remote IP appropiate for
> > that VS? matchs port where the request has been received the port where
> > is suppoussed that the VS is?
>
> If by 'user' you mean the servlet author - I disagree. Such checks are
> prefectly reasonable and correct IMO.
>
>
> > But By far in the Journey we have learned something, never trust a Host
> > Header without first trust the Remote IP, at least for ultra-secure
> > apps..
>
> Well, the remoteIP is much more difficult to test - if you're a big
> organization you may have dozens of internal IPs. And most people do trust
> their firewalls to restrict access to a particular IP, I've seen this
> kind of setup in several cases ( where you use a special interface
> for internal users ).
>
>
> > And another thing, i wonder if it would be appropiate to check if a
> > request came from the (at least) correct port before dispatching it to
> > the VS.. at least within TC, and check if Apache2 is taking any measures
> > to be certain of this fact..
>
> The comment in apache sugest that Host shouldn't be trusted. If they
> started to trust it sudenly - they should at least modify the comment
> and explain how is this trust justified.
>
> Host is sent by the user - it is trivial to forge. The port and host that
> actually receives the request are pretty safe and difficult to trick,
> especially if a firewall is used in front.
>
> Costin
>
>
>
> --
> 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]>

RE: Spec question: RE BUG 12052

[costinm]

On Fri, 30 Aug 2002, Ignacio J. Ortega wrote:

> > It may very well be a security issue ( and quite a big one ! 
> > ). There are 
> > sites using all kinds of firewalls and settings in httpd.conf to 
> > restrict access to some hosts or ports ( say from internal network ). 
> > If Host: info is used for security checkings - it would be trivial to
> > bypass some of this security. 
> > 
> > In particular - people may have servlets that check getServerName() to
> > find if 'localhost' was used - the spec change will leave them with 
> > a huge hole ( any request with forged Host: localhost will pass ). 
> > 
> > 
> 
> Good Comment..
> 
> In the particular case you have pointed, it's a user problem, a request
> with Host: Localhost can be only be issued by someone with Remote
> Ip=localhost.. 

'localhost' is just an example. 

The server may have 2 ip addresses, one visible from outside and one
restricted by firewalls to only internal users ( and used for example
for content updates ). 

In servlet 2.2 and 2.3, it is perfectly valid to use getServerName() 
and get the address that received the request. Since the servlet
spec doesn't provide any 'declarative' support for this kind of 
access control - I think this is a valid solution. A firewall or 
routing can protect the internal address ( say 10.0.0.1 - on a network
card connected only to the internal net, and a firewall restricting
outside access to this IP ). In 2.4 this will fail ( opening potential
holes ) and in addition this kind of check will be impossible to 
implement - since the address where the request was received will
no longer be available.


> So one can take some security measures to check the correctness of the
> request..

For example ? 


> All other use case i can imagine fall within the users problems, if the
> correct VS has received the request, it's the Remote IP appropiate for
> that VS? matchs port where the request has been received the port where
> is suppoussed that the VS is?

If by 'user' you mean the servlet author - I disagree. Such checks are 
prefectly reasonable and correct IMO.  


> But By far in the Journey we have learned something, never trust a Host
> Header without first trust the Remote IP, at least for ultra-secure
> apps..

Well, the remoteIP is much more difficult to test - if you're a big
organization you may have dozens of internal IPs. And most people do trust
their firewalls to restrict access to a particular IP, I've seen this 
kind of setup in several cases ( where you use a special interface 
for internal users ). 


> And another thing, i wonder if it would be appropiate to check if a
> request came from the (at least) correct port before dispatching it to
> the VS.. at least within TC, and check if Apache2 is taking any measures
> to be certain of this fact..

The comment in apache sugest that Host shouldn't be trusted. If they 
started to trust it sudenly - they should at least modify the comment
and explain how is this trust justified. 

Host is sent by the user - it is trivial to forge. The port and host that
actually receives the request are pretty safe and difficult to trick,
especially if a firewall is used in front.

Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Spec question: RE BUG 12052

[Ignacio J. Ortega]

> -Mensaje original-
> De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Enviado el: 30 de agosto de 2002 19:54
> Para: Tomcat Developers List
> Asunto: RE: Spec question: RE BUG 12052
> 

> 
> 
> It may very well be a security issue ( and quite a big one ! 
> ). There are 
> sites using all kinds of firewalls and settings in httpd.conf to 
> restrict access to some hosts or ports ( say from internal network ). 
> If Host: info is used for security checkings - it would be trivial to
> bypass some of this security. 
> 
> In particular - people may have servlets that check getServerName() to
> find if 'localhost' was used - the spec change will leave them with 
> a huge hole ( any request with forged Host: localhost will pass ). 
> 
> 

Good Comment..

In the particular case you have pointed, it's a user problem, a request
with Host: Localhost can be only be issued by someone with Remote
Ip=localhost.. 

So one can take some security measures to check the correctness of the
request..

All other use case i can imagine fall within the users problems, if the
correct VS has received the request, it's the Remote IP appropiate for
that VS? matchs port where the request has been received the port where
is suppoussed that the VS is?

But By far in the Journey we have learned something, never trust a Host
Header without first trust the Remote IP, at least for ultra-secure
apps..

And another thing, i wonder if it would be appropiate to check if a
request came from the (at least) correct port before dispatching it to
the VS.. at least within TC, and check if Apache2 is taking any measures
to be certain of this fact..

Saludos ,
Ignacio J. Ortega


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Spec question: RE BUG 12052

[costinm]

On Fri, 30 Aug 2002, Ignacio J. Ortega wrote:

> > - Another cause to worry is the comment in apache2 core.c:
> > 
> >   There are two options regarding what the "name" of a server is.  The
> >  "canonical" name as defined by ServerName and Port, or the "client's
> >   name" as supplied by a possible Host: header or full URI.  We never
> >   trust the port passed in the client's headers, we always use the
> >   port of the actual socket.
> 
> Reviewed the code ( briefly ) and it seems there is a contradiction
> between this comment and the actual behavior the apache2 has..
> 
> Apache2 allways obey a Host: header if present in the request ( for
> relative request uris of course) .. for both Servername and port, maybe
> this comment is directed to not use internally the parsed port only the
> real socket port, i dont know..

It may very well be a security issue ( and quite a big one ! ). There are 
sites using all kinds of firewalls and settings in httpd.conf to 
restrict access to some hosts or ports ( say from internal network ). 
If Host: info is used for security checkings - it would be trivial to
bypass some of this security. 

In particular - people may have servlets that check getServerName() to
find if 'localhost' was used - the spec change will leave them with 
a huge hole ( any request with forged Host: localhost will pass ). 


I love this kind of aparently trivial 'clarifications' with deep 
implications. 

Costin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Spec question: RE BUG 12052

[Ignacio J. Ortega]

> - Another cause to worry is the comment in apache2 core.c:
> 
>   There are two options regarding what the "name" of a server is.  The
>  "canonical" name as defined by ServerName and Port, or the "client's
>   name" as supplied by a possible Host: header or full URI.  We never
>   trust the port passed in the client's headers, we always use the
>   port of the actual socket.

Reviewed the code ( briefly ) and it seems there is a contradiction
between this comment and the actual behavior the apache2 has..

Apache2 allways obey a Host: header if present in the request ( for
relative request uris of course) .. for both Servername and port, maybe
this comment is directed to not use internally the parsed port only the
real socket port, i dont know..

Saludos ,
Ignacio J. Ortega


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Spec question: RE BUG 12052

[costinm]

On Fri, 30 Aug 2002, Ignacio J. Ortega wrote:

> 
> Wrong, It takes the port and ServerName from the Host: header if the
> Request-uri is relative ( most common case ) and from the Reqeust-Uri if
> it is absolute.. rfc2616 Section 5.2 strict compliance..

The comment in apache2.0 core.c seems to sugest otherwise ( "we never
trust the port from the user" ).

Costin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Spec question: RE BUG 12052

[Ignacio J. Ortega]

> De: Bojan Smojver [mailto:[EMAIL PROTECTED]]
> Enviado el: 30 de agosto de 2002 1:11
> Para: Tomcat Dev List
> Asunto: RE: Spec question: RE BUG 12052
> 
> 
> On Thu, 2002-08-29 at 23:49, Ignacio J. Ortega wrote:
>  
> > We know how r->parsed_uri.port gets his value?
> 
> Yep. It's getting it from the URL, not the headers.
> 

Wrong, It takes the port and ServerName from the Host: header if the
Request-uri is relative ( most common case ) and from the Reqeust-Uri if
it is absolute.. rfc2616 Section 5.2 strict compliance..

Saludos ,
Ignacio J. Ortega


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Spec question: RE BUG 12052

[Bojan Smojver]

On Thu, 2002-08-29 at 23:49, Ignacio J. Ortega wrote:
 
> We know how r->parsed_uri.port gets his value?

Yep. It's getting it from the URL, not the headers.

Bojan


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Spec question: RE BUG 12052

[Costin Manolache]

To answer my own email - with a summary:

- what the user really wants is to know how to form URLs - that's 
how the server name and port are used in most cases

- the real problem is getServerName(). In CGI it is the 'canonical'
name. A server may have multiple aliases for a host, and in many 
cases it is desirable to return URLs that point to the 'canonical'
or main name.

- Host: header allways returns the host and port the user typed in.

- the 'canonical name' is no longer available for servlets, if 
getServletName() is to return the info from Host ( i.e. the alias that
the user typed ). That IMO is a _major_ loss.

- Another cause to worry is the comment in apache2 core.c:

  There are two options regarding what the "name" of a server is.  The
 "canonical" name as defined by ServerName and Port, or the "client's
  name" as supplied by a possible Host: header or full URI.  We never
  trust the port passed in the client's headers, we always use the
  port of the actual socket.

For tomcat, I would propose adding 1 'implementation specific' attribute
( allowed by the spec AFAIK ) to compensate for the loss of info.
This attribute ( say 'CANONICAL_HOST' ?) would pass the 'official'
name of the server ( and port ). Another option is to make this a 
context attribute. 

getServerName() and getPortName() would reflect what the user typed in
the browser and would work in most cases. It is obviously not what the 
CGI is doing. 

My advice for anyone would be to avoid getServerName() and getPortName()
and use getHeader( "Host" ) - that would work in any servlet container
consistently and is far more portable ( if the host is what you want - 
if you want the real host/port, you're out of luck with servlet2.4 but you 
can use 2.3 and 2.2 without problems ).
 
Costin

[EMAIL PROTECTED] wrote:

> On Thu, 29 Aug 2002, Bill Barker wrote:
> 
>> > So: getServerPort() should return the same as the CGI variable
>> > SERVER_PORT ( which returns the server port, not the host header ! ),
>> > meaning the value of the part after : in the Host header.
>> >
>> > I didn't know that the servlet spec can define new meanings for the
>> > CGI spec.
>> >
>> 
>> FWIW, I agree that the 2.4 servlet-spec and the CGI-spec are out of sync
>> here.  If I actually thought that any members of the JCP were subscribed
>> to this list, I'd think to ask for clarification before 2.4 went final.
>> :)
> 
> Nah... As long as they're returning the port from the host header -
> I don't want any new clarification :-)
> 
> Actually, it is right about the server port, since the CGI says:
>   "The port number to which the request was sent."
> 
> But not for the server name:
>   "The server's hostname, DNS alias, or IP address as it would appear in
> self-referencing URLs. "
> 
> And the port can be interpreted easily to mean the Host header. Except
> that apparently nobody implements it this way. Sometimes it is better to
> provide all informations about the request - the port it was received
> on and the host header. If you return the info from the host header in
> both getServerPort and getHeader(), the port info is lost.
> 
> For getServerName() - the CGI interpretation is more 'the canonical name'.
> If I access http://10.0.0.1, the Host will include the IP but
> SERVER_NAME will be the canonical name. But now that the servlet
> spec finally 'clarified' the CGI spec, we can wait for IIS and Apache
> to fix their implementation and be compliant with the CGI spec at least
> :-)
> 
> 
> 
> Costin
> 
> 
>> 
>> > Costin
>> >
>> >
>> > > 
>> > > getServerName()
>> > > public java.lang.String getServerName()
>> > > Returns the host name of the server to which the request was sent.
>> > > For
>> HTTP
>> > > servlets, same as the value of the CGI variable SERVER_NAME, meaning
>> > > the value of the part before ":" in the Host header, if any, or the
>> > > resolved server
>> > > name, or the server IP address.
>> > > Returns: a String containing the name of the server
>> > >
>> > > getServerPort()
>> > > public int getServerPort()
>> > > Returns the port number to which the request was sent. For HTTP
>> servlets,
>> > > same as the value of the CGI variable SERVER_PORT, meaning the value
>> > > of
>> the
>> > > part after ":" in the Host header, if any, or the server port where
>> > > the client
>> > > connection was accepted on.
>> > > Returns: an integer specifying the port number
>> > > 
>> > >
>> > > >
>> > > > Note that a load balancer or proxy is required ( AFAIK ) to insert
>> > > > Host: headers if none is present.
>> > > >
>> > > > Costin
>> > > >
>> > > > On 29 Aug 2002, Bojan Smojver wrote:
>> > > >
>> > > > > On Thu, 2002-08-29 at 04:28, Bill Barker wrote:
>> > > > >
>> > > > > > The question in 12052 is whether Apache should use the socket
>> > > > > > port
>> (as
>> > > it
>> > > > > > does now), or the port in the Host header.  When this came up
>> > > > > > with
>> the
>> > > > > > Coyote/Http11 connector, the decision was that the Host head

Re: Spec question: RE BUG 12052

[costinm]

On Thu, 29 Aug 2002, Bill Barker wrote:

> > So: getServerPort() should return the same as the CGI variable SERVER_PORT
> > ( which returns the server port, not the host header ! ), meaning the
> > value of the part after : in the Host header.
> >
> > I didn't know that the servlet spec can define new meanings for the
> > CGI spec.
> >
> 
> FWIW, I agree that the 2.4 servlet-spec and the CGI-spec are out of sync
> here.  If I actually thought that any members of the JCP were subscribed to
> this list, I'd think to ask for clarification before 2.4 went final. :)

Nah... As long as they're returning the port from the host header - 
I don't want any new clarification :-)

Actually, it is right about the server port, since the CGI says:
  "The port number to which the request was sent."

But not for the server name:
  "The server's hostname, DNS alias, or IP address as it would appear in 
self-referencing URLs. "

And the port can be interpreted easily to mean the Host header. Except 
that apparently nobody implements it this way. Sometimes it is better to 
provide all informations about the request - the port it was received
on and the host header. If you return the info from the host header in
both getServerPort and getHeader(), the port info is lost.  

For getServerName() - the CGI interpretation is more 'the canonical name'.
If I access http://10.0.0.1, the Host will include the IP but 
SERVER_NAME will be the canonical name. But now that the servlet
spec finally 'clarified' the CGI spec, we can wait for IIS and Apache
to fix their implementation and be compliant with the CGI spec at least :-)



Costin


> 
> > Costin
> >
> >
> > > 
> > > getServerName()
> > > public java.lang.String getServerName()
> > > Returns the host name of the server to which the request was sent. For
> HTTP
> > > servlets, same as the value of the CGI variable SERVER_NAME, meaning the
> > > value of the part before ":" in the Host header, if any, or the resolved
> > > server
> > > name, or the server IP address.
> > > Returns: a String containing the name of the server
> > >
> > > getServerPort()
> > > public int getServerPort()
> > > Returns the port number to which the request was sent. For HTTP
> servlets,
> > > same as the value of the CGI variable SERVER_PORT, meaning the value of
> the
> > > part after ":" in the Host header, if any, or the server port where the
> > > client
> > > connection was accepted on.
> > > Returns: an integer specifying the port number
> > > 
> > >
> > > >
> > > > Note that a load balancer or proxy is required ( AFAIK ) to insert
> > > > Host: headers if none is present.
> > > >
> > > > Costin
> > > >
> > > > On 29 Aug 2002, Bojan Smojver wrote:
> > > >
> > > > > On Thu, 2002-08-29 at 04:28, Bill Barker wrote:
> > > > >
> > > > > > The question in 12052 is whether Apache should use the socket port
> (as
> > > it
> > > > > > does now), or the port in the Host header.  When this came up with
> the
> > > > > > Coyote/Http11 connector, the decision was that the Host header was
> the
> > > > > > correct one.  I'd have to say that the bug is valid.
> > > > >
> > > > > This is what the API (2.2) docs say about the getServerPort():
> > > > >
> > > > > 
> > > > > Returns the port number on which this request was received. For HTTP
> > > > > servlets, same as the value of the CGI variable SERVER_PORT.
> > > > > 
> > > > >
> > > > > This in itself could be contradicting, but I think that in the case
> of
> > > > > Apache it is pretty straightforward.
> > > > >
> > > > > This is what Apache 2.0 does to populate the variable SERVER_PORT:
> > > > >
> > > > > 
> > > > > apr_table_addn(e, "SERVER_PORT",
> > > > >   apr_psprintf(r->pool, "%u",
> ap_get_server_port(r)));
> > > > > 
> > > > >
> > > > > And this is the ap_get_server_port():
> > > > >
> > > > > 
> > > > > AP_DECLARE(apr_port_t) ap_get_server_port(const request_rec *r)
> > > > > {
> > > > > apr_port_t port;
> > > > > core_dir_config *d =
> > > > >   (core_dir_config *)ap_get_module_config(r->per_dir_config,
> > > > > &core_module);
> > > > >
> > > > > if (d->use_canonical_name == USE_CANONICAL_NAME_OFF
> > > > > || d->use_canonical_name == USE_CANONICAL_NAME_DNS) {
> > > > >
> > > > > /* With UseCanonicalName off Apache will form
> self-referential
> > > > >  * URLs using the hostname and port supplied by the client
> if
> > > > >  * any are supplied (otherwise it will use the canonical
> name).
> > > > >  */
> > > > > port = r->parsed_uri.port ? r->parsed_uri.port :
> > > > >r->server->port ? r->server->port :
> > > > >ap_default_port(r);
> > > > > }
> > > > > else { /* d->use_canonical_name == USE_CANONICAL_NAME_ON */
> > > > >
> > > > > /* With UseCanonicalName on (and in all versions prior to
> 1.3)
> > > > >  * Apache will use the hostn

Re: Spec question: RE BUG 12052

[Ryan Lubke]

On Thu, 2002-08-29 at 11:13, Craig R. McClanahan wrote:
> 
> 
> On Thu, 29 Aug 2002, Bill Barker wrote:
> 
> > FWIW, I agree that the 2.4 servlet-spec and the CGI-spec are out of sync
> > here.  If I actually thought that any members of the JCP were subscribed to
> > this list, I'd think to ask for clarification before 2.4 went final. :)
> >
> 
> The way to ask would be to send feedback to
> <[EMAIL PROTECTED]>.

I've forwarded the thread to the spec lead for 2.4 and it has been
brought up to the expert group.  However, as Craig mentioned, the best
way to ask is using the email address he listed.





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Spec question: RE BUG 12052

[Craig R. McClanahan]

On Thu, 29 Aug 2002, Bill Barker wrote:

> FWIW, I agree that the 2.4 servlet-spec and the CGI-spec are out of sync
> here.  If I actually thought that any members of the JCP were subscribed to
> this list, I'd think to ask for clarification before 2.4 went final. :)
>

The way to ask would be to send feedback to
<[EMAIL PROTECTED]>.

Personally, I'd prefer to banish any mention of CGI environment variables
in the servlet spec.  That was useful when the servlet api was introduced
because it was familiar, but today it just causes confusion.

It's probably too late for that big a change this time around :-(, but
with my new job role (Web Layer Architect for J2EE) I might have a better
shot at convincing people next time ...

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Spec question: RE BUG 12052

[Ignacio J. Ortega]

> -Mensaje original-
> De: Bojan Smojver [mailto:[EMAIL PROTECTED]]
> Enviado el: 29 de agosto de 2002 1:46
> Para: Tomcat Dev List
> Asunto: Re: Spec question: RE BUG 12052
> 
> 

> 
> 
> AP_DECLARE(apr_port_t) ap_get_server_port(const request_rec *r)
> {
> apr_port_t port;
> core_dir_config *d =
>   (core_dir_config *)ap_get_module_config(r->per_dir_config,
> &core_module);
> 
> if (d->use_canonical_name == USE_CANONICAL_NAME_OFF
> || d->use_canonical_name == USE_CANONICAL_NAME_DNS) {
> 
> /* With UseCanonicalName off Apache will form self-referential
>  * URLs using the hostname and port supplied by the client if
>  * any are supplied (otherwise it will use the 
> canonical name).
>  */
> port = r->parsed_uri.port ? r->parsed_uri.port :
>r->server->port ? r->server->port :
>ap_default_port(r);

>From the comment it seems to say, that Apache will get the port form
client supplied infos, and in the rfc2616(5.2) says that if the request
uri is relative ( i think actual clients only produce relative uris )
the host+port SHOULD be readed from the Host header.. 

So, i dont see any contradiction here, Apache2 does the rights thing
too.. at least with the port, for sure the servername will be the same..

> 
> This doesn't seem like coming from headers, but rather from URL or as
> indicated by the server itself. What do you think?
> 

We know how r->parsed_uri.port gets his value? but for sure Apache is
following the HTTP rfc 5.2.. reading it from Host header if needed
(raletive uris), if not it's a bug in Apache2 ( 2 days to be
sufficiently daring to say that :) 

All of that if you USE_CANONICAL_NAME_OFF, but is the default, i think.

Saludos ,
Ignacio J. Ortega


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Spec question: RE BUG 12052

[Bill Barker]

- Original Message -
From: <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, August 28, 2002 7:12 PM
Subject: Re: Spec question: RE BUG 12052


> On Wed, 28 Aug 2002, Bill Barker wrote:
>
> > > I think the decision to use the Host header is right, but
> > > I agree that it violates the wording in the servlet spec.
> > >
> > > The SERVER_PORT and the port in the Host: header are different
> > > beasts - in most use cases I've seen the user is interested
> > > in the second.
> >
> > Not anymore. ;-)  In the current 2.4 spec draft it is required to be
taken
> > from the Host header.
>
> I hope this is listed in the 'incompatible changes between 2.3 and 2.4'
:-)

Nope.

Clarification of SERVER_NAME and SERVER_PORT in getServerName()
and getServerPort() (14.2.16)


>
> As for the new wording - am I missing the ':-)' ?

Here's mine :-)

>
> So: getServerPort() should return the same as the CGI variable SERVER_PORT
> ( which returns the server port, not the host header ! ), meaning the
> value of the part after : in the Host header.
>
> I didn't know that the servlet spec can define new meanings for the
> CGI spec.
>

FWIW, I agree that the 2.4 servlet-spec and the CGI-spec are out of sync
here.  If I actually thought that any members of the JCP were subscribed to
this list, I'd think to ask for clarification before 2.4 went final. :)

> Costin
>
>
> > 
> > getServerName()
> > public java.lang.String getServerName()
> > Returns the host name of the server to which the request was sent. For
HTTP
> > servlets, same as the value of the CGI variable SERVER_NAME, meaning the
> > value of the part before ":" in the Host header, if any, or the resolved
> > server
> > name, or the server IP address.
> > Returns: a String containing the name of the server
> >
> > getServerPort()
> > public int getServerPort()
> > Returns the port number to which the request was sent. For HTTP
servlets,
> > same as the value of the CGI variable SERVER_PORT, meaning the value of
the
> > part after ":" in the Host header, if any, or the server port where the
> > client
> > connection was accepted on.
> > Returns: an integer specifying the port number
> > 
> >
> > >
> > > Note that a load balancer or proxy is required ( AFAIK ) to insert
> > > Host: headers if none is present.
> > >
> > > Costin
> > >
> > > On 29 Aug 2002, Bojan Smojver wrote:
> > >
> > > > On Thu, 2002-08-29 at 04:28, Bill Barker wrote:
> > > >
> > > > > The question in 12052 is whether Apache should use the socket port
(as
> > it
> > > > > does now), or the port in the Host header.  When this came up with
the
> > > > > Coyote/Http11 connector, the decision was that the Host header was
the
> > > > > correct one.  I'd have to say that the bug is valid.
> > > >
> > > > This is what the API (2.2) docs say about the getServerPort():
> > > >
> > > > 
> > > > Returns the port number on which this request was received. For HTTP
> > > > servlets, same as the value of the CGI variable SERVER_PORT.
> > > > 
> > > >
> > > > This in itself could be contradicting, but I think that in the case
of
> > > > Apache it is pretty straightforward.
> > > >
> > > > This is what Apache 2.0 does to populate the variable SERVER_PORT:
> > > >
> > > > 
> > > > apr_table_addn(e, "SERVER_PORT",
> > > >   apr_psprintf(r->pool, "%u",
ap_get_server_port(r)));
> > > > 
> > > >
> > > > And this is the ap_get_server_port():
> > > >
> > > > 
> > > > AP_DECLARE(apr_port_t) ap_get_server_port(const request_rec *r)
> > > > {
> > > > apr_port_t port;
> > > > core_dir_config *d =
> > > >   (core_dir_config *)ap_get_module_config(r->per_dir_config,
> > > > &core_module);
> > > >
> > > > if (d->use_canonical_name == USE_CANONICAL_NAME_OFF
> > > > || d->use_canonical_name == USE_CANONICAL_NAME_DNS) {
> > > >
> > > > /* With UseCanonicalName off Apache will form
self-referential
> > > >  * URLs using the hostname and port supplied 

Re: Spec question: RE BUG 12052

[Bojan Smojver]

Quoting [EMAIL PROTECTED]:

> So: getServerPort() should return the same as the CGI variable SERVER_PORT
> ( which returns the server port, not the host header ! ), meaning the
> value of the part after : in the Host header. 
> 
> I didn't know that the servlet spec can define new meanings for the 
> CGI spec.

Pretty cool, ha?

:-))

Bojan

-
This mail sent through IMP: http://horde.org/imp/

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Spec question: RE BUG 12052

[costinm]

On Wed, 28 Aug 2002, Bill Barker wrote:

> > I think the decision to use the Host header is right, but
> > I agree that it violates the wording in the servlet spec.
> >
> > The SERVER_PORT and the port in the Host: header are different
> > beasts - in most use cases I've seen the user is interested
> > in the second.
> 
> Not anymore. ;-)  In the current 2.4 spec draft it is required to be taken
> from the Host header.

I hope this is listed in the 'incompatible changes between 2.3 and 2.4' :-)

As for the new wording - am I missing the ':-)' ? 

So: getServerPort() should return the same as the CGI variable SERVER_PORT
( which returns the server port, not the host header ! ), meaning the
value of the part after : in the Host header. 

I didn't know that the servlet spec can define new meanings for the 
CGI spec.

Costin


> 
> getServerName()
> public java.lang.String getServerName()
> Returns the host name of the server to which the request was sent. For HTTP
> servlets, same as the value of the CGI variable SERVER_NAME, meaning the
> value of the part before ":" in the Host header, if any, or the resolved
> server
> name, or the server IP address.
> Returns: a String containing the name of the server
> 
> getServerPort()
> public int getServerPort()
> Returns the port number to which the request was sent. For HTTP servlets,
> same as the value of the CGI variable SERVER_PORT, meaning the value of the
> part after ":" in the Host header, if any, or the server port where the
> client
> connection was accepted on.
> Returns: an integer specifying the port number
> 
> 
> >
> > Note that a load balancer or proxy is required ( AFAIK ) to insert
> > Host: headers if none is present.
> >
> > Costin
> >
> > On 29 Aug 2002, Bojan Smojver wrote:
> >
> > > On Thu, 2002-08-29 at 04:28, Bill Barker wrote:
> > >
> > > > The question in 12052 is whether Apache should use the socket port (as
> it
> > > > does now), or the port in the Host header.  When this came up with the
> > > > Coyote/Http11 connector, the decision was that the Host header was the
> > > > correct one.  I'd have to say that the bug is valid.
> > >
> > > This is what the API (2.2) docs say about the getServerPort():
> > >
> > > 
> > > Returns the port number on which this request was received. For HTTP
> > > servlets, same as the value of the CGI variable SERVER_PORT.
> > > 
> > >
> > > This in itself could be contradicting, but I think that in the case of
> > > Apache it is pretty straightforward.
> > >
> > > This is what Apache 2.0 does to populate the variable SERVER_PORT:
> > >
> > > 
> > > apr_table_addn(e, "SERVER_PORT",
> > >   apr_psprintf(r->pool, "%u", ap_get_server_port(r)));
> > > 
> > >
> > > And this is the ap_get_server_port():
> > >
> > > 
> > > AP_DECLARE(apr_port_t) ap_get_server_port(const request_rec *r)
> > > {
> > > apr_port_t port;
> > > core_dir_config *d =
> > >   (core_dir_config *)ap_get_module_config(r->per_dir_config,
> > > &core_module);
> > >
> > > if (d->use_canonical_name == USE_CANONICAL_NAME_OFF
> > > || d->use_canonical_name == USE_CANONICAL_NAME_DNS) {
> > >
> > > /* With UseCanonicalName off Apache will form self-referential
> > >  * URLs using the hostname and port supplied by the client if
> > >  * any are supplied (otherwise it will use the canonical name).
> > >  */
> > > port = r->parsed_uri.port ? r->parsed_uri.port :
> > >r->server->port ? r->server->port :
> > >ap_default_port(r);
> > > }
> > > else { /* d->use_canonical_name == USE_CANONICAL_NAME_ON */
> > >
> > > /* With UseCanonicalName on (and in all versions prior to 1.3)
> > >  * Apache will use the hostname and port specified in the
> > >  * ServerName directive to construct a canonical name for the
> > >  * server. (If no port was specified in the ServerName
> > >  * directive, Apache uses the port supplied by the client if
> > >  * any is supplied, and finally the default port for the
> > > protocol
> > >  * used.
> > >  */
> > > port = r->server->port ? r->server->port :
> > >r->connection->local_addr->port ?
> > > r->connection->local_addr->port
> > >ap_default_port(r);
> > > }
> > >
> > > /* default */
> > > return port;
> > > }
> > > 
> > >
> > > This doesn't seem like coming from headers, but rather from URL or as
> > > indicated by the server itself. What do you think?
> > >
> > > Bojan
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> 
> > > For additional commands, e-mail:
> 
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> 
> > For additional commands, e-mail:
> 
> >
> 
> 
> --
> To unsubscribe, e-m

Re: Spec question: RE BUG 12052

[Bojan Smojver]

Quoting Bill Barker <[EMAIL PROTECTED]>:

> Not anymore. ;-)  In the current 2.4 spec draft it is required to be taken
> from the Host header.

Huh, I guess that's that then. The bug does seem to be valid. At least according
to the newer spec.

Bojan

-
This mail sent through IMP: http://horde.org/imp/

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Spec question: RE BUG 12052

[Bill Barker]

- Original Message -
From: <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, August 28, 2002 5:01 PM
Subject: Re: Spec question: RE BUG 12052


> I think the decision to use the Host header is right, but
> I agree that it violates the wording in the servlet spec.
>
> The SERVER_PORT and the port in the Host: header are different
> beasts - in most use cases I've seen the user is interested
> in the second.

Not anymore. ;-)  In the current 2.4 spec draft it is required to be taken
from the Host header.


getServerName()
public java.lang.String getServerName()
Returns the host name of the server to which the request was sent. For HTTP
servlets, same as the value of the CGI variable SERVER_NAME, meaning the
value of the part before ":" in the Host header, if any, or the resolved
server
name, or the server IP address.
Returns: a String containing the name of the server

getServerPort()
public int getServerPort()
Returns the port number to which the request was sent. For HTTP servlets,
same as the value of the CGI variable SERVER_PORT, meaning the value of the
part after ":" in the Host header, if any, or the server port where the
client
connection was accepted on.
Returns: an integer specifying the port number


>
> Note that a load balancer or proxy is required ( AFAIK ) to insert
> Host: headers if none is present.
>
> Costin
>
> On 29 Aug 2002, Bojan Smojver wrote:
>
> > On Thu, 2002-08-29 at 04:28, Bill Barker wrote:
> >
> > > The question in 12052 is whether Apache should use the socket port (as
it
> > > does now), or the port in the Host header.  When this came up with the
> > > Coyote/Http11 connector, the decision was that the Host header was the
> > > correct one.  I'd have to say that the bug is valid.
> >
> > This is what the API (2.2) docs say about the getServerPort():
> >
> > 
> > Returns the port number on which this request was received. For HTTP
> > servlets, same as the value of the CGI variable SERVER_PORT.
> > 
> >
> > This in itself could be contradicting, but I think that in the case of
> > Apache it is pretty straightforward.
> >
> > This is what Apache 2.0 does to populate the variable SERVER_PORT:
> >
> > 
> > apr_table_addn(e, "SERVER_PORT",
> >   apr_psprintf(r->pool, "%u", ap_get_server_port(r)));
> > 
> >
> > And this is the ap_get_server_port():
> >
> > 
> > AP_DECLARE(apr_port_t) ap_get_server_port(const request_rec *r)
> > {
> > apr_port_t port;
> > core_dir_config *d =
> >   (core_dir_config *)ap_get_module_config(r->per_dir_config,
> > &core_module);
> >
> > if (d->use_canonical_name == USE_CANONICAL_NAME_OFF
> > || d->use_canonical_name == USE_CANONICAL_NAME_DNS) {
> >
> > /* With UseCanonicalName off Apache will form self-referential
> >  * URLs using the hostname and port supplied by the client if
> >  * any are supplied (otherwise it will use the canonical name).
> >  */
> > port = r->parsed_uri.port ? r->parsed_uri.port :
> >r->server->port ? r->server->port :
> >ap_default_port(r);
> > }
> > else { /* d->use_canonical_name == USE_CANONICAL_NAME_ON */
> >
> > /* With UseCanonicalName on (and in all versions prior to 1.3)
> >  * Apache will use the hostname and port specified in the
> >  * ServerName directive to construct a canonical name for the
> >  * server. (If no port was specified in the ServerName
> >  * directive, Apache uses the port supplied by the client if
> >  * any is supplied, and finally the default port for the
> > protocol
> >  * used.
> >  */
> > port = r->server->port ? r->server->port :
> >r->connection->local_addr->port ?
> > r->connection->local_addr->port
> >ap_default_port(r);
> > }
> >
> > /* default */
> > return port;
> > }
> > 
> >
> > This doesn't seem like coming from headers, but rather from URL or as
> > indicated by the server itself. What do you think?
> >
> > Bojan
> >
> >
> > --
> > 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]>
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Spec question: RE BUG 12052

[costinm]

I think the decision to use the Host header is right, but
I agree that it violates the wording in the servlet spec.

The SERVER_PORT and the port in the Host: header are different
beasts - in most use cases I've seen the user is interested
in the second.

Note that a load balancer or proxy is required ( AFAIK ) to insert 
Host: headers if none is present. 

Costin

On 29 Aug 2002, Bojan Smojver wrote:

> On Thu, 2002-08-29 at 04:28, Bill Barker wrote:
> 
> > The question in 12052 is whether Apache should use the socket port (as it
> > does now), or the port in the Host header.  When this came up with the
> > Coyote/Http11 connector, the decision was that the Host header was the
> > correct one.  I'd have to say that the bug is valid.
> 
> This is what the API (2.2) docs say about the getServerPort():
> 
> 
> Returns the port number on which this request was received. For HTTP
> servlets, same as the value of the CGI variable SERVER_PORT.
> 
> 
> This in itself could be contradicting, but I think that in the case of
> Apache it is pretty straightforward.
> 
> This is what Apache 2.0 does to populate the variable SERVER_PORT:
> 
> 
> apr_table_addn(e, "SERVER_PORT",
>   apr_psprintf(r->pool, "%u", ap_get_server_port(r)));
> 
> 
> And this is the ap_get_server_port():
> 
> 
> AP_DECLARE(apr_port_t) ap_get_server_port(const request_rec *r)
> {
> apr_port_t port;
> core_dir_config *d =
>   (core_dir_config *)ap_get_module_config(r->per_dir_config,
> &core_module);
> 
> if (d->use_canonical_name == USE_CANONICAL_NAME_OFF
> || d->use_canonical_name == USE_CANONICAL_NAME_DNS) {
> 
> /* With UseCanonicalName off Apache will form self-referential
>  * URLs using the hostname and port supplied by the client if
>  * any are supplied (otherwise it will use the canonical name).
>  */
> port = r->parsed_uri.port ? r->parsed_uri.port :
>r->server->port ? r->server->port :
>ap_default_port(r);
> }
> else { /* d->use_canonical_name == USE_CANONICAL_NAME_ON */
> 
> /* With UseCanonicalName on (and in all versions prior to 1.3)
>  * Apache will use the hostname and port specified in the
>  * ServerName directive to construct a canonical name for the
>  * server. (If no port was specified in the ServerName
>  * directive, Apache uses the port supplied by the client if
>  * any is supplied, and finally the default port for the
> protocol
>  * used.
>  */
> port = r->server->port ? r->server->port :
>r->connection->local_addr->port ?
> r->connection->local_addr->port
>ap_default_port(r);
> }
> 
> /* default */
> return port;
> }
> 
> 
> This doesn't seem like coming from headers, but rather from URL or as
> indicated by the server itself. What do you think?
> 
> Bojan
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Spec question: RE BUG 12052

[Bojan Smojver]

On Thu, 2002-08-29 at 04:28, Bill Barker wrote:

> The question in 12052 is whether Apache should use the socket port (as it
> does now), or the port in the Host header.  When this came up with the
> Coyote/Http11 connector, the decision was that the Host header was the
> correct one.  I'd have to say that the bug is valid.

This is what the API (2.2) docs say about the getServerPort():


Returns the port number on which this request was received. For HTTP
servlets, same as the value of the CGI variable SERVER_PORT.


This in itself could be contradicting, but I think that in the case of
Apache it is pretty straightforward.

This is what Apache 2.0 does to populate the variable SERVER_PORT:


apr_table_addn(e, "SERVER_PORT",
  apr_psprintf(r->pool, "%u", ap_get_server_port(r)));


And this is the ap_get_server_port():


AP_DECLARE(apr_port_t) ap_get_server_port(const request_rec *r)
{
apr_port_t port;
core_dir_config *d =
  (core_dir_config *)ap_get_module_config(r->per_dir_config,
&core_module);

if (d->use_canonical_name == USE_CANONICAL_NAME_OFF
|| d->use_canonical_name == USE_CANONICAL_NAME_DNS) {

/* With UseCanonicalName off Apache will form self-referential
 * URLs using the hostname and port supplied by the client if
 * any are supplied (otherwise it will use the canonical name).
 */
port = r->parsed_uri.port ? r->parsed_uri.port :
   r->server->port ? r->server->port :
   ap_default_port(r);
}
else { /* d->use_canonical_name == USE_CANONICAL_NAME_ON */

/* With UseCanonicalName on (and in all versions prior to 1.3)
 * Apache will use the hostname and port specified in the
 * ServerName directive to construct a canonical name for the
 * server. (If no port was specified in the ServerName
 * directive, Apache uses the port supplied by the client if
 * any is supplied, and finally the default port for the
protocol
 * used.
 */
port = r->server->port ? r->server->port :
   r->connection->local_addr->port ?
r->connection->local_addr->port
   ap_default_port(r);
}

/* default */
return port;
}


This doesn't seem like coming from headers, but rather from URL or as
indicated by the server itself. What do you think?

Bojan


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Spec question: RE BUG 12052

[Bojan Smojver]

On Thu, 2002-08-29 at 02:14, Craig R. McClanahan 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.

To avoid confusion, I have tested what comes back. The combo is Apache
2.0.40, mod_jk 1.2.0, Tomcat 3.3.x. The port 80 comes back over HTTP and
443 over SSL. This is also indicated by the current source in the bug
report.

The real problem is that the bug report asks to go a step further and to
fake the ports when there is a load balancer or firewall in front of
Apache/Tomcat combo. I don't think we should do that - load balancer or
firewall is not part of the container.

Bojan


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Spec question: RE BUG 12052

[costinm]

On 28 Aug 2002, Ryan Lubke wrote:

> > 1) For me after ( another ) reading of rfc2616, from the point you named
> > and following the references given there, i've found that in 5.2 seems
> > to say that a empty Host: header must be responded by 400 because empty
> > it is not a valid Host name..
> 
> But an empty host header does have a meaning, i.e. the target resource
> is being identified via an IP address and not a host name.

If you use http://127.0.0.1:8080, you'll have '127.0.0.1' in the host 
header.

And you can use ip addresses as host names in the config file, AFAIK.


> I'm reading this that if the host, probably a virtual host on the server
> , can't be determined, then return the 400.  

If a host can't be determined - all servers will use the default 
host. 

Costin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Spec question: RE BUG 12052

[Ryan Lubke]

On Wed, 2002-08-28 at 17:05, Ignacio J. Ortega wrote:
> > De: Ryan Lubke [mailto:[EMAIL PROTECTED]]
> > Enviado el: 28 de agosto de 2002 20:29
> > Para: Tomcat Developers List
> > Asunto: RE: Spec question: RE BUG 12052
> > 
> > 
> > 
> > > The port MUST be the one in the Host Header if one is 
> > present,and should
> > > be present if the request is HTTP1.1 compliant, 
> > > 
> > What if the Host header is supplied, but the value is empty.  
> > This seems
> > legal per section 14.23 of the HTTP/1.1 RFC?
> > 
> > 
> 
> 1) For me after ( another ) reading of rfc2616, from the point you named
> and following the references given there, i've found that in 5.2 seems
> to say that a empty Host: header must be responded by 400 because empty
> it is not a valid Host name..

But an empty host header does have a meaning, i.e. the target resource
is being identified via an IP address and not a host name.

I'm reading this that if the host, probably a virtual host on the server
, can't be determined, then return the 400.  

> 
> 2) Checked Apache2 and it gives a 200 when issuing a GET / with empty
> Host:, at it replies a 200.
> 
> I think your problem is related to issuing a 30X after a request with
> empty Host: header?, well it's really a border case...
> 
> One never can assure if a Location header will have correct information,
> because is mandated to follow a filled Host hdr if present, sending a
> 301 with a guessed Host name in the Location, shouldnt be the worst
> solution to the problem..
> 
> I dont know how to make apache2 (anyone?) issue a unconditional redirect
> (301) after a request, but i suspect that if the Host Header is empty in
> such a request, it will try to form a correct Location header from the
> information it has at hand ( ServerName and his own local port), with
> Firewalls and NATs possibily an incorrect one? maybe..
> 
> In a vote, i would vote to make Tomcat issue a 400 in case of a empty
> Host header..

Is this such a good idea?

Take a look at the following:

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7441

Apache originally would return a 400 on an empty Host header.
The modified the behavior to what you're currently seeing.

The interpretation could be incorrect, but I would be more inclined
to follow a solid HTTP server implementation such as Apache.

> 
> Saludos ,
> Ignacio J. Ortega
> 
> 
> --
> 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]>

RE: Spec question: RE BUG 12052

[Ignacio J. Ortega]

> De: Ryan Lubke [mailto:[EMAIL PROTECTED]]
> Enviado el: 28 de agosto de 2002 20:29
> Para: Tomcat Developers List
> Asunto: RE: Spec question: RE BUG 12052
> 
> 
> 
> > The port MUST be the one in the Host Header if one is 
> present,and should
> > be present if the request is HTTP1.1 compliant, 
> > 
> What if the Host header is supplied, but the value is empty.  
> This seems
> legal per section 14.23 of the HTTP/1.1 RFC?
> 
> 

1) For me after ( another ) reading of rfc2616, from the point you named
and following the references given there, i've found that in 5.2 seems
to say that a empty Host: header must be responded by 400 because empty
it is not a valid Host name..

2) Checked Apache2 and it gives a 200 when issuing a GET / with empty
Host:, at it replies a 200.

I think your problem is related to issuing a 30X after a request with
empty Host: header?, well it's really a border case...

One never can assure if a Location header will have correct information,
because is mandated to follow a filled Host hdr if present, sending a
301 with a guessed Host name in the Location, shouldnt be the worst
solution to the problem..

I dont know how to make apache2 (anyone?) issue a unconditional redirect
(301) after a request, but i suspect that if the Host Header is empty in
such a request, it will try to form a correct Location header from the
information it has at hand ( ServerName and his own local port), with
Firewalls and NATs possibily an incorrect one? maybe..

In a vote, i would vote to make Tomcat issue a 400 in case of a empty
Host header..

Saludos ,
Ignacio J. Ortega


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Spec question: RE BUG 12052

[Costin Manolache]

Ignacio J. Ortega wrote:

>> De: Bojan Smojver [mailto:[EMAIL PROTECTED]]
>> Enviado el: 28 de agosto de 2002 15:27
>> Para: Tomcat Dev List
>> Asunto: Spec question: RE BUG 12052
> 
>> of load balancers and firewalls, so it is unrealistic to expect to
>> return port numbers that it doesn't know about. What do you think?
>> 
>> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12052
>> 
>> Other opinions welcome :-)
> 
> Nice!!! this bug has surfaced many times in the past, in tc 3.2, 3.3, at
> least :)), and related or not to connectors.. :).. and i think the first
> poster on this topic was me long time ago, in late 2000.. :..
> 
> The port MUST be the one in the Host Header if one is present,and should
> be present if the request is HTTP1.1 compliant, if no port is present
> the port must be 80 o 443, regardless of the socket port, that NEVER
> must be a default for getServerPort, NEVER.. and regardless of the
> channel which has be used to forward the request to the container..
> socket,JNI,. or whatever..

You're right. 

If the request is HTTP/1.0 or HTTP/0.9 - then the best choice is to 
use host and port that apache received the request on. IF any 
proxy server is used - I think the HTTP spec implies that it requires it to 
include a Host header if none is present.

Costin


> 
> 
> Saludos ,
> Ignacio J. Ortega
> 
> 
>> -Mensaje original-
>> 
>> 
>> Craig,
>> 
>> I think this bug report is invalid, since Tomcat/Apache has
>> no knowledge
>> 
>> Bojan
>> 
>> 
>> --
>> 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]>

RE: Spec question: RE BUG 12052

[Costin Manolache]

Ryan Lubke wrote:

> 
>> The port MUST be the one in the Host Header if one is present,and should
>> be present if the request is HTTP1.1 compliant,
>> 
> What if the Host header is supplied, but the value is empty.  This seems
> legal per section 14.23 of the HTTP/1.1 RFC?

It is legal in the case that "the requested URI does not include an Internet 
host name". I have no idea what that means - but it is made clear that 
if the user provides a host in the request, that host must be included.

I don't know any way to access a web site by a client without using
an Internet host name. Maybe some of the 'smart URLs' in new browsers or
some tricks with a proxy server ? But even in this case the proxy
server MUST include the right Host - or whoever makes the real
HTTP request on behalf of the client.


Costin


I assume it may be possible 



>> Saludos ,
>> Ignacio J. Ortega
>> 
>> 
>> > -Mensaje original-
>> > 
>> > 
>> > Craig,
>> > 
>> > I think this bug report is invalid, since Tomcat/Apache has
>> > no knowledge
>> > 
>> > Bojan
>> > 
>> > 
>> > --
>> > To unsubscribe, e-mail:
>> 
>> For additional commands, e-mail:
>> 
>> 
>> 
>> --
>> To unsubscribe, e-mail:  
>>  For additional
>> commands, e-mail: 
>>




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Spec question: RE BUG 12052

[costinm]

On Wed, 28 Aug 2002, Craig R. McClanahan wrote:

> If you run Tomcat behind Apache using JK, the entire combination is the
> "container" from the perspective of the servlet specification.  The entire
> combination has to meet all the spec rules or it's not compliant.
> 
> The fact that the servlet spec defines things differently than web servers
> did things is totally irrelevant to spec compliance.

Apache, IIS and iPlanet all follow some rules that are different from
the servlet spec. And I don't expect those web servers to be changed to 
match what the JCP defines. 

Apache is a web server, it provides support for a servlet container 
( tomcat + jk ), and also for PHP, mod_perl and even ASP.
Apache+PHP+mod_perl+ASP+jk+tomcat is not a servlet container. 

We do have a problem that jk+tomcat has to deal with what becomes
a bigger and bigger mismatch, but that's mostly irrelevant to 
the web server. 


Costin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Spec question: RE BUG 12052

[Ryan Lubke]

> The port MUST be the one in the Host Header if one is present,and should
> be present if the request is HTTP1.1 compliant, 
> 
What if the Host header is supplied, but the value is empty.  This seems
legal per section 14.23 of the HTTP/1.1 RFC?


> 
> Saludos ,
> Ignacio J. Ortega
> 
> 
> > -Mensaje original-
> > 
> > 
> > Craig,
> > 
> > I think this bug report is invalid, since Tomcat/Apache has 
> > no knowledge
> > 
> > Bojan
> > 
> > 
> > --
> > To unsubscribe, e-mail:   
> 
> For additional commands, e-mail:
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Spec question: RE BUG 12052

[Bill Barker]

- Original Message -
From: "Costin Manolache" <[EMAIL PROTECTED]>
Newsgroups: gmane.comp.jakarta.tomcat.devel
To: <[EMAIL PROTECTED]>
Sent: Wednesday, August 28, 2002 10:36 AM
Subject: RE: Spec question: RE BUG 12052


> John Trollinger wrote:
>
>
> > 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.
>
> That's simple - all web servers provide the port used to receive
> the request. And that's forwarded to tomcat, and set in the request.
> That's how it allways worked.
>

Costin is correct.  mod_jk has always set request.getServerPort() to 80 when
Apache is running on 80, and forwarding on 8009 to TC.

The question in 12052 is whether Apache should use the socket port (as it
does now), or the port in the Host header.  When this came up with the
Coyote/Http11 connector, the decision was that the Host header was the
correct one.  I'd have to say that the bug is valid.

>
> Costin
>
>
>
> --
> 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]>

RE: Spec question: RE BUG 12052

[Ignacio J. Ortega]

> De: Bojan Smojver [mailto:[EMAIL PROTECTED]]
> Enviado el: 28 de agosto de 2002 15:27
> Para: Tomcat Dev List
> Asunto: Spec question: RE BUG 12052

> of load balancers and firewalls, so it is unrealistic to expect to
> return port numbers that it doesn't know about. What do you think?
> 
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12052
> 
> Other opinions welcome :-)

Nice!!! this bug has surfaced many times in the past, in tc 3.2, 3.3, at
least :)), and related or not to connectors.. :).. and i think the first
poster on this topic was me long time ago, in late 2000.. :..

The port MUST be the one in the Host Header if one is present,and should
be present if the request is HTTP1.1 compliant, if no port is present
the port must be 80 o 443, regardless of the socket port, that NEVER
must be a default for getServerPort, NEVER.. and regardless of the
channel which has be used to forward the request to the container..
socket,JNI,. or whatever.. 


Saludos ,
Ignacio J. Ortega


> -Mensaje original-
> 
> 
> Craig,
> 
> I think this bug report is invalid, since Tomcat/Apache has 
> no knowledge
> 
> Bojan
> 
> 
> --
> 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]>

RE: Spec question: RE BUG 12052

[Craig R. McClanahan]

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

RE: Spec question: RE BUG 12052

[Craig R. McClanahan]

On Wed, 28 Aug 2002 [EMAIL PROTECTED] wrote:

> Date: Wed, 28 Aug 2002 10:03:34 -0700 (PDT)
> From: [EMAIL PROTECTED]
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> 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.
>

If you run Tomcat behind Apache using JK, the entire combination is the
"container" from the perspective of the servlet specification.  The entire
combination has to meet all the spec rules or it's not compliant.

The fact that the servlet spec defines things differently than web servers
did things is totally irrelevant to spec compliance.

>
> Costin

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:[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]>

RE: Spec question: RE BUG 12052

[Costin Manolache]

John Trollinger wrote:

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

That's simple - all web servers provide the port used to receive
the request. And that's forwarded to tomcat, and set in the request.
That's how it allways worked.


Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Spec question: RE BUG 12052

[John Trollinger]

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



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

RE: Spec question: RE BUG 12052

[costinm]

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



> 
> > 
> > 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:   
> >  [EMAIL PROTECTED]>
> > For 
> > additional commands, 
> > e-mail: 
> > 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Spec question: RE BUG 12052

[Craig R. McClanahan]

On Wed, 28 Aug 2002, John Trollinger wrote:

> Date: Wed, 28 Aug 2002 12:19:19 -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: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, August 28, 2002 12:15 PM
> > To: Tomcat Developers List
> > Subject: Re: Spec question: RE BUG 12052
> >
> >
> >
> >
> > On 28 Aug 2002, Bojan Smojver wrote:
> >
> > > Date: 28 Aug 2002 23:27:18 +1000
> > > From: Bojan Smojver <[EMAIL PROTECTED]>
> > > Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> > > To: Tomcat Dev List <[EMAIL PROTECTED]>
> > > Subject: Spec question: RE BUG 12052
> > >
> > > Craig,
> > >
> > > I think this bug report is invalid, since Tomcat/Apache has no
> > > knowledge of load balancers and firewalls, so it is unrealistic to
> > > expect to return port numbers that it doesn't know about.
> > What do you
> > > think?
> > >
> > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12052
> > >
> > > Other opinions welcome :-)
> > >
> >
> > There are circumstances when we're not going to know the port
> > number, but normal use of Tomcat behind JK doesn't seem to be
> > one of them, IMHO.
> >
> > 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.

In other words, you're going to tell application developers "sorry --
there is no way to construct a URL that will come back to this webapp
unless you encode your own knowledge of what port number to include".
That doesn't sound at all useful.  In addition, it's inconsistent with the
results you'd get if you run the same webapp under Tomcat standalone
(where you do get the right answer already).

> It is bad to have Tomcat try and guess where its requests are coming from.

Agreed.  I'm not advocating a guess -- I'm advocating that the Apache side
of JK tell Tomcat what port the request came in on, so that
getServerPort() can tell the application.

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:[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]>

RE: Spec question: RE BUG 12052

[John Trollinger]

> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] 
> Sent: Wednesday, August 28, 2002 12:15 PM
> To: Tomcat Developers List
> Subject: Re: Spec question: RE BUG 12052
> 
> 
> 
> 
> On 28 Aug 2002, Bojan Smojver wrote:
> 
> > Date: 28 Aug 2002 23:27:18 +1000
> > From: Bojan Smojver <[EMAIL PROTECTED]>
> > Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> > To: Tomcat Dev List <[EMAIL PROTECTED]>
> > Subject: Spec question: RE BUG 12052
> >
> > Craig,
> >
> > I think this bug report is invalid, since Tomcat/Apache has no 
> > knowledge of load balancers and firewalls, so it is unrealistic to 
> > expect to return port numbers that it doesn't know about. 
> What do you 
> > think?
> >
> > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12052
> >
> > Other opinions welcome :-)
> >
> 
> There are circumstances when we're not going to know the port 
> number, but normal use of Tomcat behind JK doesn't seem to be 
> one of them, IMHO.
> 
> 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.

> 
> 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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Spec question: RE BUG 12052

[Craig R. McClanahan]

On 28 Aug 2002, Bojan Smojver wrote:

> Date: 28 Aug 2002 23:27:18 +1000
> From: Bojan Smojver <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Dev List <[EMAIL PROTECTED]>
> Subject: Spec question: RE BUG 12052
>
> Craig,
>
> I think this bug report is invalid, since Tomcat/Apache has no knowledge
> of load balancers and firewalls, so it is unrealistic to expect to
> return port numbers that it doesn't know about. What do you think?
>
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12052
>
> Other opinions welcome :-)
>

There are circumstances when we're not going to know the port number, but
normal use of Tomcat behind JK doesn't seem to be one of them, IMHO.

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.

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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Spec question: RE BUG 12052

[Bojan Smojver]

Craig,

I think this bug report is invalid, since Tomcat/Apache has no knowledge
of load balancers and firewalls, so it is unrealistic to expect to
return port numbers that it doesn't know about. What do you think?

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12052

Other opinions welcome :-)

Bojan


--
To unsubscribe, e-mail:   
For additional commands, e-mail: