>I agree that even if you have option b) working, option a) is the
>correct way to go so that we don't break backwards compatibility.
The consensus seems to be in freezing ajp13 and adding new features
in ajp14 only. It will avoid conflict with servlet-engine using
standard ajp13 protocol (TC 3.2/3.3).
The ajp13 protocol use an int header which is 0x1234 when
packet in from web-server to servlet-engine and 'AB' in
servlet-engine to web-server.
ajp14 (which is ajp13++ ;) will use 0x1235 and 'AC'. It will
help people writting disector (protocol decoder) determine
the rigth protocol.
I'll start to move some code from jk_ajp13.c to jk_ajp_common.c
and make ajp13/ajp14 use them via flags a protocol flag :)
Stay tuned.
>
>Mike Anderson
>Senior Software Engineer
>Platform Services Group
>[EMAIL PROTECTED]
>Novell, Inc., the leading provider of Net services software
>www.novell.com
>
>>>> [EMAIL PROTECTED] 06/04/01 06:24AM >>>
>Hi to all,
>
>The work in still on progress on AJP14 and I've got new
>questions on ajp14.
>
>1) AJP14 could be considered like an evolution of AJP13.
>
> Basically the same protocol but with added commands.
>
> AJP13 use the 'AB' chars in start of protocol, what about
> using something like 'DE' in the case of AJP14.
>
> It will help detect and fixes problem when trying to
> use AJP14 on AJP13. Smarted servlet engine could even
> route the incorrect ajp protocol
>
>2) Servlet 2.3 (I can't get the Proposed Final Draft 2)
> add as requirement cipher_suite and key_size.
> cipher_suite is allready present in current ajp13.
>
> I've added key_size to a test ajp13 but adding it
> to current ajp13 may break compatibility since I'll add
> a command #11 in the ajp13 stream, something which will not
> be understand by current ajp13 java implementation.
>
> So what to do now ?
>
> a) Freeze the ajp13 in all branches and add the key_size only in
>ajp14
> b) add key_size to ajp13 in mod_jk (in jtc) and in all the java
>implementations ?
>
> I've done the b) case, and so I've adapated mod_jk (native) and
>ajp13
> (java for TC 4.0) on jakarta-tomcat-connector to
>recognize and use
>the new command.
> I attached the diff :)
>
> Even if I've worked on the b) case, I think it will be
>more secure
>to use a)
> and freeze ajp13 now.... Just to keep compatibility
>with TC 3.2.2
>which are
> now closed to new features an which didn't require the
>Servlet 2.3
>compatibility.
>
>
>-
>Henri Gomez ___[_]____
>EMAIL : [EMAIL PROTECTED] (. .)
>PGP KEY : 697ECEDD ...oOOo..(_)..oOOo...
>PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
>
>
