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 ? Or: - 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 processing. > 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 :-) Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
