tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <wbar...@wilshire.com>
Subject Re: Ajp14 and Ajp13
Date Thu, 15 Nov 2001 23:40:38 GMT
I'm in favor of this, since the protocol is only being extended, not really
changed.

However, I think that one of the extensions that should be implemented early
on is a version negotiation so that the newer side can gracefully degrade in
the future without having to rely on the user changing configuration
settings.
----- Original Message -----
From: <cmanolache@yahoo.com>
To: <tomcat-dev@jakarta.apache.org>
Sent: Thursday, November 15, 2001 3:19 PM
Subject: Ajp14 and Ajp13


> Hi,
>
> Right now we treat Ajp13 and 14 as 2 separate workers ( even if most of
> the code is shared). The problem is that this adds complexity that we
> could avoid.
>
> Given that Ajp14 is not 'official' yet, I would propose to change it to
> "Ajp14 == Ajp13 + extra functions".
>
> We should use exactly the same header and encapsulation as in Ajp13 -
> since this is very well tested. The main difference is in the startup
> phase, where Ajp14 will login and auto-configure.
>
> That can be easily configured and we can have the new Ajp14 clients
> talking with older Ajp13 servers ( so most fixes will go in the same
> codebase, without needing to fix both the new 1.4 worker and the old one).
>
> If the ajp14 worker will be configured with a login password - then it'll
> do the extra login and configuration steps. If not - it'll be just our old
> ajp13 client, capable to speak with tomcat3.2 ... tomcat4.0.
>
> On tomcat side, if the connector will be configured to require a login
> it'll behave as a ajp14 server, and do the autoconfiguration ( and refuse
> connections from unauthenticated ajp13 clients ).
>
> This can be extended in future as more callbacks are added. Instead of
> having ajp15, 16... we'll keep Ajp13 as the base and configure the
> calls and callbacks to use.
>
> The main reason for this is simplifying the code - which is very
> important to do before any extension. This would also allow a smooth
> transition - all new features will be included in mod_jk and the new java
> connector, but the user will be able to use only what he needs and
> support multiple server versions.
>
> What do you think ?
>
> Costin
>
>
>
>
>
>
>
>
>
> --
> To unsubscribe, e-mail:
<mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:tomcat-dev-help@jakarta.apache.org>
>
>


*----*

This message is intended only for the use of the person(s) listed above 
as the intended recipient(s), and may contain information that is 
PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient, 
you may not read, copy, or distribute this message or any attachment.  
If you received this communication in error, please notify us immediately 
by e-mail and then delete all copies of this message and any attachments.


In addition you should be aware that ordinary (unencrypted) e-mail sent 
through the Internet is not secure. Do not send confidential or sensitive 
information, such as social security numbers, account numbers, personal 
identification numbers and passwords, to us via ordinary (unencrypted) 
e-mail. 

--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message