tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject RE: Jk2: jkctl handler
Date Fri, 14 Dec 2001 17:10:20 GMT
On Fri, 14 Dec 2001, GOMEZ Henri wrote:

> What the result on login phase ?
> webserver send ping.
> tomcat send a loginseed in reply
> webserver send the loginsequence
> tomcat reply by sending log granted/deny
> How did tomcat will send uriMaps/ContextStatus without knowing from
> which VirtualHost the login came ? Did we add the VirtualHost info
> in login message ?

The login is not specific to a virtual host - the endpoint can be shared
and used for requests for the entire server. I think it would be a waste
to have an endpoint per virtual host.

The login is concerned only with authentication. Webserver opens the
connection and sends the initial message. Tomcat can then send messages,
including request for credentials ( either md5 or others ), or request
for config informations ( in my proposal, where all apps are deployed
and configured with apache and tomcat pulls the info ) or sends config
info ( if the apps are deployed on tomcat and apache will get this info
from there ).

The benefit of 'stateless' ( or at least of not having a fixed sequence
of messages ) is that all options are open. Each end will maintain some
state and can act on it, but that's part of each handler's code, not part
of the protocol ( just like in http ).

> webserver send ping.
> tomcat send a loginseed in reply
> webserver send the loginsequence
> tomcat reply by sending log granted/deny
> tomcat send ok to ping ?

- webserver sends ping
- tomcat sends a message asking for md5 auth ( seed as parameter )
- webserver send a message with the credentials
- tomcat checks the credentials. If they don't match, it sends
a login deny and close connections ( webserver's deny handler will
close the connection on apache side ).
- If the credentials are ok, tomcat either asks for config or sends
it's config to apache ( based on it's settings ) ( or both )
- More messages can be exchanged, negotiations ( for example tomcat
can request a different protocol).
- Finally, tomcat sends an 'ok' message ( reply to the original ping ).
This will act like the "END_RESPONSE" message - apache will continue

> Ok, what about waiting for jk2 freeze, and then let us start in writing
> callback handlers ? May be good to prepare for us empty callback which
> will be implemented by contributors ;)

I think we should first make sure jk2 works and builds for ajp13,
add the other server adapters.

jk_handler_logon and the others can be used as examples.

Of course - nothing is cast in stone, and based on feeback/discussion/vote
anything can and will be changed :-)


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

View raw message