RE: More on ajp14

2001-06-05 Thread GOMEZ Henri

>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

2001-06-04 Thread Mike Anderson

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 





Re: More on ajp14

2001-06-04 Thread kevin seguin

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

2001-06-04 Thread GOMEZ Henri

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

2001-06-04 Thread kevin seguin

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