Ben Sifuentes at [EMAIL PROTECTED] wrote:
> I looked at the mocked up admin tool and didn't see anything for setting up
> virtual hosts configurations.
Yeah, it's not _that_ easy to find out... Click and select "Service" on the
left, and then there's a drop-down combo on the right with "Actions"... It's
in there...
But IMO, all that part is wrong because a virtual host is (should) be
defined as the merger of "host" and "port", which currently all web servers
support, but TC40... The selection of the virtual host should be made
(according to RFC-2616), on this dual selector, section 14.23 says:
The Host request-header field specifies the Internet host and port
number of the resource being requested [...] This allows the origin
server or gateway to differentiate between internally-ambiguous URLs,
such as the root "/" URL of a server for multiple host names on a
single IP address.
Host = "Host" ":" host [ ":" port ] ; Section 3.2.2
A "host" without any trailing port information implies the default
port for the service requested (e.g., "80" for an HTTP URL). [...]
A client MUST include a Host header field in all HTTP/1.1 request
messages . If the requested URI does not include an Internet host
name for the service being requested, then the Host header field
MUST be given with an empty value. [...]
All Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad
Request) status code to any HTTP/1.1 request message which lacks a
Host header field. [...]
So, how do I read it? Host MUST be there in HTTP, Host represents the
virtual server, Host is made up of name:port, and if port is not there, it
is defaulted to 80.
The selection of the virtual host, then MUST be done in terms of the joint
value "host:port", and this is not present in Catalina, as the selection is
made only in terms of the first value, the host name, completely
disregarding the port value, unless, of course, you don't start ANOTHER
<Service> with another <Connector> and blablabla (you know where I'm ending
up to, don't you?)...
So, the current implementation is (IMO) not conformant to the HTTP spec, and
to just be more clear, try presenting Catalina with an HTTP request not
containing the header:
# telnet localhost 8080
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
>> GET / HTTP/1.1
>>
<< HTTP/1.1 302 Moved Temporarily
<< Content-Type: text/html
<< Date: Sat, 03 Nov 2001 03:44:36 GMT
<< Location: http://nagoya.apache.org:8080/index.html
<< Transfer-Encoding: chunked
<< Server: Apache Tomcat/4.0.1 (HTTP/1.1 Connector)
[...]
Plain wrong.. The response is not 400, but 302. Look if I do the same under
Apache:
# telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
>> GET / HTTP/1.1
>>
<< HTTP/1.1 400 Bad Request
<< Date: Sat, 03 Nov 2001 03:44:57 GMT
<< Server: Apache/1.3.20 (Unix)
<< Connection: close
<< Transfer-Encoding: chunked
<< Content-Type: text/html; charset=iso-8859-1
[...]
Well, this one looks _way_ better...
Of course, we could add that in Catalina, and make it compliant, but when it
comes down to virtual host selection, if I want to differentiate between two
servers, I would always have to have two different <Service> clusters in my
server.xml...
But here comes another problem... Let's say that a proxy is absolutely sure
that a resource under "server:8080" can be accessed thru "server:80", we're
perfectly confident about this. A simple proxy implementation could then
reroute all requests he gets for "server" on port 8080 to "server" on port
80... Nowhere in the HTTP RFC is said that I cannot do it.
So, my "access" to the resource, is different from the usual way, but the
selector in this case "server:8080" is still valid, I should find that
resource there... (I'm thinking about a weird firewall setup, OK?) Now, the
guy on "server", decides to swap from Apache to Tomcat, gets on with his
life, configures two different <Service> with two different <Connnector> and
forgets to notify the proxy folk... Now, all my requests for "server:8080"
will be incorrectly redirected to "server:80", because the way in which
Catalina processes virtual hosts is wrong...
It might sound purely academic, now, but when you start facing the problem
of decoupling the connector to the container (such as using Apache with a
module), kids, things are starting to hurt... All web servers behave in a
way, the selector is "server:port", but Catalina... Something flaky.
In fact, if you go back in the logs and see my very first implementation of
"WarpHost", the very first thing I added was the "port" selector, which then
looked like a hack, and so got removed. But then all other sorts of
wierdness happened, and to solve this problem I believe that the only
solution is completely decoupling the virtual-host selection process from
the web-application selection process: Something like:
<Service ...>
<Protocol>
<Connector ... port="80"/>
<Connector ... Port="8080"/>
<Host name="test:80">
<Context reference="myContextA"/>
<Context reference="myContextB"/>
</Host>
<Host name="test:8080">
....
</Host>
</Protocol>
<Engine>
<Realm .../>
<Logger .../>
<Context path="/example" docBase="example.war" reference="myContextA"/>
</Engine>
...
</Service>
And so on... In cases where the HTTP protocol stack is completely separated
(read Apache), the <Service> configuration would be trivial, because all the
first part <Protocol> is _already_present_ in the web-server itself, I would
just have to put in my httpd.conf something that will tell the web server to
use that particular reference... Such as:
WebAppUse myContextA myConnection
If we're using mod_webapp. Depending in which "virtualhost" that is put, it
means that that web application is there, and the other directive
"WebAppDeploy" would be used only for "on-the-fly" deployment of contexts
(as right now does, but it's all crummed up...)...
Sorry for the long email, but it's three months I'm pondering about this in
my solitary confinment here in London, and I see something wrong... As I
started saying last week on tomcat-user, I'm just going to remove the
concept of host from the WARP classes, and allow deployment up one level...
In the <Engine>...
(gee, that was three pages :) :) :)
Pier
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
