RE: Ajp14 and Ajp13
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. Yes, Henri already implemented this in the login phase - however Ajp13 doesn't support this. We should be carefull with the login phase. The distinction between post Ajp14 will be the number of callbacks supported - and login/negotiation is the essential one to diferentiate between Ajp13 and Ajp14+. Yes, but what will happen to a worker using ajp14 trying to connect (and so using md5 login phase) to a good old ajp13 server ? If the user doesn't set the login callback - we will use 'plain' ajp13. What do you mean by user setting callback ? in httpd.conf for examples ? If the user does have a login - it's clear he wants ajp14 ( or later ) and we can detect the number of callbacks supported. The distinction between ajp13, 14, ... will be in the number of callbacks - each version will have a set of callbacks ( sort of API version instead of protocol version ). Regardless of the Ajp version, we should support all previous ones up to 13. This will also minimize the amount of pain for 3.2.x users, who are unlikely to get Ajp14 ported, and also for users of 4.0 - again, support for ajp14 is likely to be available in 4.0.2 or later. They'll still be able to get most fixes, and we'll have less code to maintain. Make sense, but making ajp14 a sort of ajp13++, using the same port and same headers will put users in trouble. I'm in favor of having an ajp13/ajp14 unique Interceptor (java side), which will detect the rigth protocol by looking at msg headers. ajp13 use 0x1234 as header and 'AB' (0x4142) as trailer and I used 0x1235 for both header and trailer for ajp14. Also having separate headers will help people writing network disector for network dumper (ie ethereal). And on native camp, it should be easy since we'll could have an ajp13 callback and another one for ajp14, may be a protocol init callback which could set headers accordingly for future message sent/received. The client side should be able also to detect it speak ajp14 on an ajp13 server and fallback to ajp13 protocol -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Ajp14 and Ajp13
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: [EMAIL PROTECTED] To: [EMAIL PROTECTED] 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:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] ** 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:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Ajp14 and Ajp13
On Thu, 15 Nov 2001, Bill Barker wrote: 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. Yes, Henri already implemented this in the login phase - however Ajp13 doesn't support this. The distinction between post Ajp14 will be the number of callbacks supported - and login/negotiation is the essential one to diferentiate between Ajp13 and Ajp14+. If the user doesn't set the login callback - we will use 'plain' ajp13. If the user does have a login - it's clear he wants ajp14 ( or later ) and we can detect the number of callbacks supported. The distinction between ajp13, 14, ... will be in the number of callbacks - each version will have a set of callbacks ( sort of API version instead of protocol version ). Regardless of the Ajp version, we should support all previous ones up to 13. This will also minimize the amount of pain for 3.2.x users, who are unlikely to get Ajp14 ported, and also for users of 4.0 - again, support for ajp14 is likely to be available in 4.0.2 or later. They'll still be able to get most fixes, and we'll have less code to maintain. Costin - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] 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:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] ** 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:[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]
