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.diff Type: unspecified type (application/octet-stream)
> >> Encoding: quoted-printable
> >>
> >> Name: native.diff
> >> native.diff Type: unspecified type (application/octet-stream)
> >> Encoding: quoted-printable
> >
