RE: More on ajp14
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
Re: More on ajp14
a couple quick thoughts (i haven't fully processed all of this yet :))... feels like the right thing to do is freeze ajp13, and only add new stuff to ajp14. perhaps code can be refactored so that common stuff in ajp13/14 can be pulled out of the ajp13 code and put into a common place in org.apache.ajp. or... have one implementation on the java side that can determine the protocol version (1.3, 1.4, X.x ...) and behave appropriately. for example, the web server would send protocol version info, or maybe the packet header is enought (the 0x1234) for the java side to determine if the ssl key size is a valid attribute. i'm kind of in a hurry, so these thoughts are going straight from brain to keyboard with no processing in between ;-) -kevin. GOMEZ Henri wrote: 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 Name: java.diff java.diffType: unspecified type (application/octet-stream) Encoding: quoted-printable Name: native.diff native.diffType: unspecified type (application/octet-stream) Encoding: quoted-printable
RE: More on ajp14
protocol negociation is present in ajp14 but didn't exist in ajp13... Adding new command to ajp13 in the protocol need to have both native (web-server) and java (servlet-engine) to be upgraded at the same time. :! - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: kevin seguin [mailto:[EMAIL PROTECTED]] Sent: Monday, June 04, 2001 5:48 PM To: [EMAIL PROTECTED] Subject: Re: More on ajp14 a couple quick thoughts (i haven't fully processed all of this yet :))... feels like the right thing to do is freeze ajp13, and only add new stuff to ajp14. perhaps code can be refactored so that common stuff in ajp13/14 can be pulled out of the ajp13 code and put into a common place in org.apache.ajp. or... have one implementation on the java side that can determine the protocol version (1.3, 1.4, X.x ...) and behave appropriately. for example, the web server would send protocol version info, or maybe the packet header is enought (the 0x1234) for the java side to determine if the ssl key size is a valid attribute. i'm kind of in a hurry, so these thoughts are going straight from brain to keyboard with no processing in between ;-) -kevin. GOMEZ Henri wrote: 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 --- - Name: java.diff java.diffType: unspecified type (application/octet-stream) Encoding: quoted-printable Name: native.diff native.diffType: unspecified type (application/octet-stream) Encoding: quoted-printable
Re: More on ajp14
GOMEZ Henri wrote: protocol negociation is present in ajp14 but didn't exist in ajp13... Adding new command to ajp13 in the protocol need to have both native (web-server) and java (servlet-engine) to be upgraded at the same time. yep... so, i believe the right thing to do is not change ajp13. only do new stuff in ajp14. :! - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: kevin seguin [mailto:[EMAIL PROTECTED]] Sent: Monday, June 04, 2001 5:48 PM To: [EMAIL PROTECTED] Subject: Re: More on ajp14 a couple quick thoughts (i haven't fully processed all of this yet :))... feels like the right thing to do is freeze ajp13, and only add new stuff to ajp14. perhaps code can be refactored so that common stuff in ajp13/14 can be pulled out of the ajp13 code and put into a common place in org.apache.ajp. or... have one implementation on the java side that can determine the protocol version (1.3, 1.4, X.x ...) and behave appropriately. for example, the web server would send protocol version info, or maybe the packet header is enought (the 0x1234) for the java side to determine if the ssl key size is a valid attribute. i'm kind of in a hurry, so these thoughts are going straight from brain to keyboard with no processing in between ;-) -kevin. GOMEZ Henri wrote: 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 --- - Name: java.diff java.diffType: unspecified type (application/octet-stream) Encoding: quoted-printable Name: native.diff native.diffType: unspecified type (application/octet-stream) Encoding: quoted-printable
Re: More on ajp14
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. 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
