>> 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]>
