Re: [PROPOSAL AJP14] AJP13 Evolution

[cmanolache]

On Sun, 13 May 2001, kevin seguin wrote:

> in the java side of ajp13, it is pretty much assumed that strings are
> iso-8859-1 encoded.  (i'm not sure how things that deal with
> MessageBytes that come out of ajp13 deal with encoding...).

MessageBytes is supposed to delay the conversion from bytes to strings
until an encoding is found ( that can be as late as servlet execution time
in servlet2.3 ). 

The default is 8859-1, as required by the servlet specs ( if no other
encoding is specified ).

I think the "design" is right - but there are many details that need
to be resolved before this will work as expected. Few modules ( like the
mapper ) are forcing a conversion to String for the URI, and very little
testing has been done.

BTW, there are few major problems I don't know how to resolve, like
the (stupid) behavior of MSIE in the case of UTF8 in javascript ( they
send % instead of %XX%XX - as EcmaScript requires ). 

I spent a lot of time reading and thinking about how to resolve the 
i18n, but it's a nightmare - and I'm not sure I have the energy to do
it.  


> is this a potential problem?  i realize that for things like standard
> header names this will generally not be a problem.  but would it be
> worthwhile to send an encoding across from the webserver to the
> container in ajp14?  or, can iso-8859-1 be assumed, and if a
> content-type header is present and specifies an encoding, it can be
> pulled out of there?

The webserver doesn't know the encoding ( unless it reads the encoding
header ), it works with byte[]. It would be great if it can send the
encoding in advance ( as parsing Content-Type is very expensive ), 
but most browsers do not send it...

Costin

Re: [PROPOSAL AJP14] AJP13 Evolution

[jean-frederic clere]

GOMEZ Henri wrote:
> 
> >> 1) How did we share it in forked (apache 1.3) env ?
> >>=> shared memory => MM or APR
> >
> >APR of course: MM is included in it.
> 
> But APR is only available in Apache 2.0, what about Apache 1.3,
> NES and IIS ? And MM is still only for Unix OS 

APR is only related to Apache 2.0 because Apache 2.0 uses it.
Unfornatunatly I am a Unix expert but totaly beginner for other plaforms, but I
think that APR needs shared memory for all platforms it supports.

> 
> >>
> >> 2) Ditto in a threaded architecture (Apache 2.0)
> >>at least in MPM mode (a forked child which will in turn thread
> >>child), but again how did we info we other forked.
> >>
> >> Also doubling the socket, will double the descriptors open
> >> and will be a problem under heavy load.
> >> In an HTTP architecture we need again to mix data (tons of
> >> messages) with control (very low traffic). And so we need
> >> to read for possible message at some time.
> >>
> >> 1) FORWARD REQUEST FROM WEB-SERVER TO SERVLET ENGINE
> >> 2) WAIT FOR END OF PREVIOUS REPLY AND EVENTUALLY ADMIN MESSAGE
> >> 3) GET ADMIN MESSAGE and evnetually RESPONSE
> >> 4) GET RESPONSE AND FORWARD TO WEB-SERVER.
> >>
> >> The admin message could be send() in socket at any time and
> >> will be handled when a request will came
> >
> >Apjp13 requests are not multiplexed, so we need more that one
> >connection. How
> >could we decide on which connection we send the admin message?
> >Otherwise we will
> >the send the same data more than once.
> 
> The admin response could be sent on EACH AJP13 connections, and
> it will be web-server task to discard allready received admin
> message...
> 
> >What happends when the configuration is changed more than once
> >and no request
> >happend in the meantime...
> >We could get a wrong configuration...
> 
> If we have a DOWN event and then a UP event, the servlet
> engine send a DOWN message and then a UP message. The
> web-servlet will have to read ALL ADMIN messages and
> process the whole block...

Re: [PROPOSAL AJP14] AJP13 Evolution

[kevin seguin]

in the java side of ajp13, it is pretty much assumed that strings are
iso-8859-1 encoded.  (i'm not sure how things that deal with
MessageBytes that come out of ajp13 deal with encoding...).

is this a potential problem?  i realize that for things like standard
header names this will generally not be a problem.  but would it be
worthwhile to send an encoding across from the webserver to the
container in ajp14?  or, can iso-8859-1 be assumed, and if a
content-type header is present and specifies an encoding, it can be
pulled out of there?

i'm sensitive to these issues now, as i'm currently going through the
'joy' of an i18n/l10n release ;)

-kevin.

GOMEZ Henri wrote:
> 
> Hi to all,
> 
> You could find attached a proposal of evolution to
> the current Apache JServ Protocol version 1.3,
> also known as ajp13.
> 
> Let start the comments, questions, remarks cycle.
> 
> PS : I've not cover here the full protocol but only the add-on
>  from ajp13.
> 
> -
> Henri Gomez ___[_]
> EMAIL : [EMAIL PROTECTED](. .)
> PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
> 
>   
>  Name: AJPv14.txt
>AJPv14.txtType: Plain Text (text/plain)
>  Encoding: quoted-printable

Re: [PROPOSAL AJP14] AJP13 Evolution - Second Pass

[kevin seguin]

> > i'm going to go with the "get it to work first, optimize it later"
> > approach :)
> 
> Good, as long as you remember you're going to do the "later" part :-)
> 
> This is one of the critical pieces in the container performance.
> 

in looking at MessageBytes and the rest of the
org.apache.tomcat.util.buf package, it seems that the entire package
could be lifted out of tomcat 3.3. without a problem.  unless i missed
something, it only depends on one other tomcat internal, StringManager. 
seems like this package would be an important part of optimization (lazy
eval)...  true?

Re: [PROPOSAL AJP14] AJP13 Evolution - Second Pass

[cmanolache]

On Thu, 10 May 2001, kevin seguin wrote:

> 
> > The whole idea is to avoid expensive operations until they are actually
> > needed - most servlets don't read all the headers, so there's no need to
> > create the strings and hash them. ( it's not even needed to convert from
> > bytes to chars - another expensive operation ).
> > 
> 
> i'm going to go with the "get it to work first, optimize it later"
> approach :)

Good, as long as you remember you're going to do the "later" part :-)

This is one of the critical pieces in the container performance. 




Costin

Re: [PROPOSAL AJP14] AJP13 Evolution - Second Pass

[kevin seguin]

> The whole idea is to avoid expensive operations until they are actually
> needed - most servlets don't read all the headers, so there's no need to
> create the strings and hash them. ( it's not even needed to convert from
> bytes to chars - another expensive operation ).
> 

i'm going to go with the "get it to work first, optimize it later"
approach :)

Re: [PROPOSAL AJP14] AJP13 Evolution - Second Pass

[cmanolache]

On Thu, 10 May 2001, kevin seguin wrote:

> > This is not the "easiest" solution - from my point of view the easisest
> > would be to just write the Ajp14Interceptor and use the existing and
> > optimized 3.3 infrastructure. ( and use a reimplementation of the protocol
> > for 4.0 - using their low-level objects ).
> > 
> 
> i'm not 100% sure i understand what you're saying, but i'm pretty sure
> you're talking about something i've been thinking about :)

I hope I'm talking about what I'm thinking, and the reverse :-)


> in tc 3.x, the ajp stuff uses core tomcat classes like MessageBytes,
> OutputBuffer, Request, etc..  for my ajp13 implementation for tc 4, i
> removed refs to tc 3 classes, and used tc 4 classes where i could (i.e.
> HttpRequestBase).
> 
> i was thinking that versions of MessageBytes, OutputBuffer, Request (and
> Response??), and other classes might find their way into
> jakarta-tomcat-connector, so they could be used with ajp code across
> different versions of different servlet containers.


Yes, that would be probably the best - as all those classes are quite well
tuned.

Most of tomcat3.3 performance comes from those 5-6 classes - and the fact
that we use lazy evaluation in many cases. ( there are few other tricks in
some modules, but most of the modules and the servlet 22 facade are
mostly the same as in tomct3.1 - i.e. not tuned yet ).

But we know some people have problems with tomcat3.3.


> are you thinking this would be the right thing to do?  seems like you
> might be suggesting multiple ajp13 implementations for multiple servlet
> containers.

It would be the right thing to do from a technical point of view. 

Politically - I don't know, I don't want to go into another war or argue
about the benefits ( you can read the archives for that :-)


> i think it would be better to have the core ajp13 code separate from
> servlet connector/adapter code.  that way, hopefully, you could use the
> same ajp13 core with connectors for tc 3, tc 4, jetty, and so on. 
> thoughts?

Again - that would be the right way to go. In most cases ( even for jetty
- I took a quick look at their code ) using an optimized low-level
representation for data will be good for performance.

The whole idea is to avoid expensive operations until they are actually
needed - most servlets don't read all the headers, so there's no need to
create the strings and hash them. ( it's not even needed to convert from
bytes to chars - another expensive operation ). 

But having separate adapters for each container is also a valid option.


Costin

Re: [PROPOSAL AJP14] AJP13 Evolution - Second Pass

[kevin seguin]

> BTW, we'll need to discuss about the Java side - so
> optimizations on the "lower" level would work on any container.
> 
> At minimum we need MessageBytes or equivalent, MimeHeaders or equivalent
> ( i.e. recyclable, low overhead, etc ), and a simple Request object that
> can be easily adapted to TC3.3 and TC4.0.
> 
> This is not the "easiest" solution - from my point of view the easisest
> would be to just write the Ajp14Interceptor and use the existing and
> optimized 3.3 infrastructure. ( and use a reimplementation of the protocol
> for 4.0 - using their low-level objects ).
> 

i'm not 100% sure i understand what you're saying, but i'm pretty sure
you're talking about something i've been thinking about :)

in tc 3.x, the ajp stuff uses core tomcat classes like MessageBytes,
OutputBuffer, Request, etc..  for my ajp13 implementation for tc 4, i
removed refs to tc 3 classes, and used tc 4 classes where i could (i.e.
HttpRequestBase).

i was thinking that versions of MessageBytes, OutputBuffer, Request (and
Response??), and other classes might find their way into
jakarta-tomcat-connector, so they could be used with ajp code across
different versions of different servlet containers.

are you thinking this would be the right thing to do?  seems like you
might be suggesting multiple ajp13 implementations for multiple servlet
containers.

i think it would be better to have the core ajp13 code separate from
servlet connector/adapter code.  that way, hopefully, you could use the
same ajp13 core with connectors for tc 3, tc 4, jetty, and so on. 
thoughts?

Re: [PROPOSAL AJP14] AJP13 Evolution - Second Pass

[kevin seguin]

> On the native part, I'll need help for autoconf stuff and the
> JServ like JVM start. Jon could you help us here since you were
> on it on JServ ?
> 
> I'd like to see someone take a look at APR, and how we could use it.
> May be by adding some wrapper code to avoid having #ifde USE_APR sprayed
> in all mod_jk.
> 
> Volunteers ?
> 
> On the C side code, all help will be welcome. I'm confident with the
> code but all help is also welcome (toc toc toc Dan).
> May be via review of the regular code commit.
> 

i can help out on c code, time permitting.

> I'm pleased to see the proposal was actively discussed and since many
> users ask about integration of mod_jk and mod_webapp, I reiterate here
> my invitation to Pier.
> 
> >I'll try to implement the Java side as you go with the C changes,
> >unless someone else volunteers ( jasper is taking more than
> >I expected, and xalan has a release planned in few weeks ).
> 
> May be Kevin could help also and could commit it's AJP13 in
> jakarta-tomcat-connector.
> 

most definitely.  my first priority (selfishly motivated :)), is to get
the ajp13 stuff checked in and working for tomcat 4.  after that, i'd
like to help out on the evolution of ajp13 into ajp14.

Re: [PROPOSAL AJP14] AJP13 Evolution - Second Pass

[kevin seguin]

> I wouldn't mind seeing the connector used for Jetty or other servlet
> containers ( the same as many containers are using jasper ) - code sharing
> is allways good.
> 

+100 :)

RE: [PROPOSAL AJP14] AJP13 Evolution - Second Pass

[cmanolache]

On Thu, 10 May 2001, GOMEZ Henri wrote:

> 
> AJP14 will be only available to TC 3.3/4.0 since the 3.2 is closed
> to new features. But did the AJP12/AJP13 in jakarta-tomcat-connectors will 
> contains code for tomcat 3.2 tree also ?
> 

If anyone writes it - yes. Most tomcat users are using tocmat3.2, either
in production or embeded in products, and the new connector will be a
module that may be good for them. 

I wouldn't mind seeing the connector used for Jetty or other servlet
containers ( the same as many containers are using jasper ) - code sharing
is allways good.



Costin

RE: [PROPOSAL AJP14] AJP13 Evolution - Second Pass

[GOMEZ Henri]

The evolution will goes in jakarta-tomcat-connectors to avoid
disturbing mod_jk/ajp13 in the to be released TC 3.3. 
Of course all bugs fixes from TC 3.3 mod_jk will be back ported to 
jakarta-tomcat-connectors.

The auto-update will not be my premium priority and I think to
delay it since it will add too much complexity for a first try. 

On the native part, I'll need help for autoconf stuff and the 
JServ like JVM start. Jon could you help us here since you were
on it on JServ ?

I'd like to see someone take a look at APR, and how we could use it. 
May be by adding some wrapper code to avoid having #ifde USE_APR sprayed
in all mod_jk. 

Volunteers ?

On the C side code, all help will be welcome. I'm confident with the
code but all help is also welcome (toc toc toc Dan). 
May be via review of the regular code commit.
 
I'm pleased to see the proposal was actively discussed and since many 
users ask about integration of mod_jk and mod_webapp, I reiterate here 
my invitation to Pier. 


>I'll try to implement the Java side as you go with the C changes,
>unless someone else volunteers ( jasper is taking more than 
>I expected, and xalan has a release planned in few weeks ).

May be Kevin could help also and could commit it's AJP13 in 
jakarta-tomcat-connector.

>BTW, we'll need to discuss about the Java side - so
>optimizations on the "lower" level would work on any container. 
>
>
>At minimum we need MessageBytes or equivalent, MimeHeaders or 
>equivalent 
>( i.e. recyclable, low overhead, etc ), and a simple Request 
>object that
>can be easily adapted to TC3.3 and TC4.0.

AJP14 will be only available to TC 3.3/4.0 since the 3.2 is closed
to new features. But did the AJP12/AJP13 in jakarta-tomcat-connectors will 
contains code for tomcat 3.2 tree also ?

>This is not the "easiest" solution - from my point of view the easisest
>would be to just write the Ajp14Interceptor and use the existing and
>optimized 3.3 infrastructure. ( and use a reimplementation of 
>the protocol for 4.0 - using their low-level objects ). 

Re: [PROPOSAL AJP14] AJP13 Evolution - Second Pass

[cmanolache]

+1 

I'll try to implement the Java side as you go with the C changes,
unless someone else volunteers ( jasper is taking more than 
I expected, and xalan has a release planned in few weeks ).


BTW, we'll need to discuss about the Java side - so
optimizations on the "lower" level would work on any container. 


At minimum we need MessageBytes or equivalent, MimeHeaders or equivalent 
( i.e. recyclable, low overhead, etc ), and a simple Request object that
can be easily adapted to TC3.3 and TC4.0.

This is not the "easiest" solution - from my point of view the easisest
would be to just write the Ajp14Interceptor and use the existing and
optimized 3.3 infrastructure. ( and use a reimplementation of the protocol
for 4.0 - using their low-level objects ). 


Costin



On Thu, 10 May 2001, GOMEZ Henri wrote:

> Find attached the modified AJP14 proposal which include 
> the remarks and request from the list.
> 
> Nota :
> 
> The launch of Tomcat JVM by the mod_jk/jakarta-connector 
> is not covered since we speak here only about protocol.
> That feature is something asked by many JServ users and
> may be added later in the native part, at least in 
> Apache 1.3/2.0 mode. I'm not sure how it can be done
> when using IIS or NES.
> 
> The automatic context update was an interesting subject 
> and how we can have these kind of admin informations raised
> more questions than answers.
> 
> Opening alternate sockets (control socket) we'll load more
> the web-server with more opened sockets :
> 
> on forked environnement (ie Apache 1.3), 2 x forked (1 data + 1 admin)
> on threaded environnement (ie Apache 2.0), 1 x forked (x threaded data + 1
> admin)
> 
> A solution could be to use the URGENT DATA mode of TCP/IP socket but I'm not
> sure it's supported now in JDK 1.1/1.2/1.3
> 
> Another solution is to delay the automatic update mode.
> AJP14 have provision on NEGOCIATION phase to disactivate this feature.
> 
> But we still need to know when a context is DOWN and later UP.
> 
> * A lazy solution could be to have the servlet engine drop all 
>   AJP connections at each update of context (UP/DOWN). 
> 
>   The web servlet will have then to re-open the connection and
>   will received the UPDATED context list.
> 
> * Another solution will be having the servlet engine sending
>   a 'Context XXX Down' reply when the user send a request against
>   a DOWN context. The servlet engine could then route the 
>   request to another engine (in LB mode), or to indicate 
>   the failure (in simple servlet engine mode). 
>   
>   And when a context is marked DOWN, we need to know when it's UP again.
>   
>   Brute mode : 
>   the web-server continue to forward the requests to the servlet engine,
>   and if it receive the 'Context XXX Down', it try another route.
>   
>   Clean mode :
>   the web-server send a 'Context XXX Status' request, check if the reply is
>   'Context XXX Up', and if still down, try another route. This mode could be
>   tuned. ie for a down context, ask for status each 10 or 50 requests.
>   
> The context UP/DOWN is really a rare case, and we mustn't spend to much time
> in handling this type of event. The protocol must keep its speed.
> 
> Another feature I'd like to have in mod_jk/jakarta-connector and present in
> mod_jserv
> is the backup mode :
> 
> - In standard mode, a request is routed to only one servlet-engine (using a
> know worker).
> 
> - In load balancing mode, a request is sent to a pool of servlet-engine,
> using a load
>   factor.
> 
> - We miss a backup mode, where all requests goes allways to the same servlet
> engine 
>   until the connection is broken (maybe the remote engine is down or network
> link 
>   closed). We define then one (or more) alternate engines to handle
> requests. 
>   In that mode, the web-servlet will try to detect later if the principal
> servlet
>   engine is up each N requests (or after M seconds...)
> 
> -
> Henri Gomez ___[_]
> EMAIL : [EMAIL PROTECTED](. .) 
> PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 
> 
> 

[PROPOSAL AJP14] AJP13 Evolution - Second Pass

[GOMEZ Henri]

Find attached the modified AJP14 proposal which include 
the remarks and request from the list.

Nota :

The launch of Tomcat JVM by the mod_jk/jakarta-connector 
is not covered since we speak here only about protocol.
That feature is something asked by many JServ users and
may be added later in the native part, at least in 
Apache 1.3/2.0 mode. I'm not sure how it can be done
when using IIS or NES.

The automatic context update was an interesting subject 
and how we can have these kind of admin informations raised
more questions than answers.

Opening alternate sockets (control socket) we'll load more
the web-server with more opened sockets :

on forked environnement (ie Apache 1.3), 2 x forked (1 data + 1 admin)
on threaded environnement (ie Apache 2.0), 1 x forked (x threaded data + 1
admin)

A solution could be to use the URGENT DATA mode of TCP/IP socket but I'm not
sure it's supported now in JDK 1.1/1.2/1.3

Another solution is to delay the automatic update mode.
AJP14 have provision on NEGOCIATION phase to disactivate this feature.

But we still need to know when a context is DOWN and later UP.

* A lazy solution could be to have the servlet engine drop all 
  AJP connections at each update of context (UP/DOWN). 

  The web servlet will have then to re-open the connection and
  will received the UPDATED context list.

* Another solution will be having the servlet engine sending
  a 'Context XXX Down' reply when the user send a request against
  a DOWN context. The servlet engine could then route the 
  request to another engine (in LB mode), or to indicate 
  the failure (in simple servlet engine mode). 
  
  And when a context is marked DOWN, we need to know when it's UP again.
  
  Brute mode : 
  the web-server continue to forward the requests to the servlet engine,
  and if it receive the 'Context XXX Down', it try another route.
  
  Clean mode :
  the web-server send a 'Context XXX Status' request, check if the reply is
  'Context XXX Up', and if still down, try another route. This mode could be
  tuned. ie for a down context, ask for status each 10 or 50 requests.
  
The context UP/DOWN is really a rare case, and we mustn't spend to much time
in handling this type of event. The protocol must keep its speed.

Another feature I'd like to have in mod_jk/jakarta-connector and present in
mod_jserv
is the backup mode :

- In standard mode, a request is routed to only one servlet-engine (using a
know worker).

- In load balancing mode, a request is sent to a pool of servlet-engine,
using a load
  factor.

- We miss a backup mode, where all requests goes allways to the same servlet
engine 
  until the connection is broken (maybe the remote engine is down or network
link 
  closed). We define then one (or more) alternate engines to handle
requests. 
  In that mode, the web-servlet will try to detect later if the principal
servlet
  engine is up each N requests (or after M seconds...)

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



Proposal for Apache JServ 1.4 - Second Pass

This document is a proposal of evolution of the current
Apache JServ Protocol version 1.3, also known as ajp13.  
I'll not cover here the full protocol but only the add-on from ajp13.

This second pass include comments from the tomca-dev list

Missing features in AJP13
-

ajp13 is a good protocol to link a servlet engine like tomcat to a web server like 
Apache: 

* use persistants connections to avoid reconnect time at each request
* encode many http commands to reduce stream size
* send to servlet engine many info from web server (like SSL certs)

But ajp13 lacks support for : 

* security between web server and servlet engine.
  Anybody can connect to an ajp13 port (no login mecanism used)
  You could connect, for example with telnet, and keep the remote thread
  up by not sending any data (no timeout in connection)

* context information passed from servlet engine to web server.
  Part of the configuration of mod_jk, the web server connector, is to
  indicate to the web server which URI to handle. 
  The mod_jk JkMount directive, told to web server which URI must be 
  forwarded to servlet engine.
  A servlet engine allready knows which URI it handle and TC 3.3 is
  allready capable to generate a config file for mod_jk from the list
  of available contexts.
 
* state update of contexts from servlet engine to web server.
  Big site with farm of Tomcat, like ISP and virtuals hosters,
  may need to stop a context for admin purposes. In that case the front
  web server must know that the context is currently down, to eventually
  relay the request to another Tomcat
 
* verify state of connection before sending request.
  Actually mod_jk send the request to the servlet engine and next wait 
  for the answer. But one of the beauty of the socket AP

RE: [PROPOSAL AJP14] AJP13 Evolution

[cmanolache]

Regarding APR: 

I do remember the same discussion happened about one year ago, when 
mod_jk was starting up. And at that time we felt that APR is the 
best solution for us, for the long term - and the same is probably true
today.

The "common" dir in mod_jk was intended as a temporary substitute for APR,
until APR is stable and released. 

The only questions are: When ? Who ? Why ? :-)

Right now the common code works reasonably well, and I don't know any
reason to _require_ a switch. There are other changes that are far more 
benefical for mod_jk - so if you have some time it would be better spent
improving the configuration, or the performance. 

If you have a need for APR in mod_jk - I'm all +1. The effort is not in
replacing the calls to jk_XXX to apr_XXX, but in testing on IIS, NES,
AOLServer, and Apache1.3.9. I don't know any module that is using APR and
works on those 3 platforms.

I would also wait for the 1.0 release of APR before doing the switch - and
maybe do the experiments and tests on other servers first. 

( BTW, there is no reason for APR not to work out-of-box, except that
someone needs to do the testing on those cases ).

A good way to do that would be to use some C magic ( #define :-) to allow 
use of either common or apr. 

BTW, I did some homeworks ( one year ago ) and tried APR - I had 
few small problems, but in the end worked. For example, the version of APR
used must match the one in Apache2.0 ( or symbol undefined may happen -
and that may become more tricky for Apache2.1 ), there are problem on
Apache1.3 ( probably IIS, etc) if more than a module is using APR and
certain link options are used ( again, symbol conflits, etc). With a bit
of work it can be resolved, but  I don't think this is the biggest
priority for mod_jk.

Costin

On Thu, 10 May 2001, GOMEZ Henri wrote:

> The question was the availability on system
> running NES (Windows/Unixes) and IIS (Windows).
> 
> I really like APR, but having it at a pre-requisite 
> to mod_jk for AJP14 will raise new questions.
> 
> How could I build APR usinb Borland C++ 5.5 under
> Window Millenium ? 
> 
> -
> Henri Gomez ___[_]
> EMAIL : [EMAIL PROTECTED](. .) 
> PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 
> 
> 
> 
> >-Original Message-
> >From: Jon Stevens [mailto:[EMAIL PROTECTED]]
> >Sent: Wednesday, May 09, 2001 3:16 AM
> >To: tomcat-dev
> >Subject: Re: [PROPOSAL AJP14] AJP13 Evolution
> >
> >
> >on 5/8/01 3:00 PM, "GOMEZ Henri" <[EMAIL PROTECTED]> wrote:
> >
> >> But APR is only available in Apache 2.0, what about Apache 1.3,
> >> NES and IIS ?
> >
> >That isn't true. http://Apr.apache.org/
> >
> >APR is just a library.
> >
> >-jon
> >
> >-- 
> >If you come from a Perl or PHP background, JSP is a way to take
> >your pain to new levels. --Anonymous
> ><http://jakarta.apache.org/velocity/ymtd/ymtd.html>
> >
> 

RE: [PROPOSAL AJP14] AJP13 Evolution

[GOMEZ Henri]

That's present in AJP14 description about 
negociation flags :)

- Negociations Flags -

AJP14_CONTEXT_INFO_NEG   0x8000 /* web-server want context info
after login */
AJP14_CONTEXT_UPDATE_NEG 0x4000 /* web-server want context updates */
AJP14_GZIP_STREAM_NEG0x2000 /* web-server want compressed stream */
AJP14_DES56_STREAM_NEG   0x1000 /* web-server want crypted DES56 stream
with secret key */
AJP14_SSL_VSERVER_NEG0x0800 /* Extended info on server SSL vars */
AJP14_SSL_VCLIENT_NEG0x0400 /* Extended info on client SSL vars */
AJP14_SSL_VCRYPTO_NEG0x0200 /* Extended info on crypto SSL vars */
AJP14_SSL_VMISC_NEG  0x0100 /* Extended info on misc SSL vars */

AJP14_SSL_VCRYPTO_NEG flag !)



-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, May 09, 2001 1:59 AM
>To: [EMAIL PROTECTED]
>Subject: RE: [PROPOSAL AJP14] AJP13 Evolution
>
>
>Just as a note, if you want AJP14 to be usable in a Servlet 2.3
>environment, you *must* expose the cipher suite and key size 
>(which might
>be implied from the cipher suite name) to Tomcat, because 
>Tomcat must in
>turn expose them as request attributes to servlets processing SSL
>requests.
>
>In addition, if there is a client certificate included with 
>the request,
>it also needs to be exposed, but I believe that is already being done,
>isn't it?
>
>Craig
>
>
>On Wed, 9 May 2001, GOMEZ Henri wrote:
>
>> Many users have asked for more web-server env vars
>> they like to use also in Tomcat.
>> 
>> May be something to add to AJP14 will be the
>> ability to define a list of env vars to be forwarded
>> to Tomcat, the same way the SSL web-server vars are 
>> defined :
>> 
>> # What is the indicator for SSL session (default is SSL_SESSION_ID)
>> JkSESSIONIndicator SSL_SESSION_ID
>> # What is the indicator for client SSL cipher suit (default 
>is SSL_CIPHER)
>> JkCIPHERIndicator SSL_CIPHER
>> # What is the indicator for the client SSL certificated (default is
>> SSL_CLIENT_CERT)
>> JkCERTSIndicator SSL_CLIENT_CERT
>> 
>> May be with the directive 
>> 
>> JkEnvVars MYVAR1 MYVAR2 MYVAR3 MYVAR4...
>> 
>> 
>> The traffic will be more important but these informations
>> will be usefull for some...
>> 
>> What about that ?
>> 
>> 
>> -
>> Henri Gomez ___[_]
>> EMAIL : [EMAIL PROTECTED](. .) 
>> PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
>> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 
>> 
>

RE: [PROPOSAL AJP14] AJP13 Evolution

[GOMEZ Henri]

The question was the availability on system
running NES (Windows/Unixes) and IIS (Windows).

I really like APR, but having it at a pre-requisite 
to mod_jk for AJP14 will raise new questions.

How could I build APR usinb Borland C++ 5.5 under
Window Millenium ? 

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: Jon Stevens [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, May 09, 2001 3:16 AM
>To: tomcat-dev
>Subject: Re: [PROPOSAL AJP14] AJP13 Evolution
>
>
>on 5/8/01 3:00 PM, "GOMEZ Henri" <[EMAIL PROTECTED]> wrote:
>
>> But APR is only available in Apache 2.0, what about Apache 1.3,
>> NES and IIS ?
>
>That isn't true. http://Apr.apache.org/
>
>APR is just a library.
>
>-jon
>
>-- 
>If you come from a Perl or PHP background, JSP is a way to take
>your pain to new levels. --Anonymous
><http://jakarta.apache.org/velocity/ymtd/ymtd.html>
>

Re: [PROPOSAL AJP14] AJP13 Evolution

[Jon Stevens]

on 5/8/01 3:00 PM, "GOMEZ Henri" <[EMAIL PROTECTED]> wrote:

> But APR is only available in Apache 2.0, what about Apache 1.3,
> NES and IIS ?

That isn't true. http://Apr.apache.org/

APR is just a library.

-jon

-- 
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous

RE: [PROPOSAL AJP14] AJP13 Evolution

[Craig R. McClanahan]

Just as a note, if you want AJP14 to be usable in a Servlet 2.3
environment, you *must* expose the cipher suite and key size (which might
be implied from the cipher suite name) to Tomcat, because Tomcat must in
turn expose them as request attributes to servlets processing SSL
requests.

In addition, if there is a client certificate included with the request,
it also needs to be exposed, but I believe that is already being done,
isn't it?

Craig


On Wed, 9 May 2001, GOMEZ Henri wrote:

> Many users have asked for more web-server env vars
> they like to use also in Tomcat.
> 
> May be something to add to AJP14 will be the
> ability to define a list of env vars to be forwarded
> to Tomcat, the same way the SSL web-server vars are 
> defined :
> 
> # What is the indicator for SSL session (default is SSL_SESSION_ID)
> JkSESSIONIndicator SSL_SESSION_ID
> # What is the indicator for client SSL cipher suit (default is SSL_CIPHER)
> JkCIPHERIndicator SSL_CIPHER
> # What is the indicator for the client SSL certificated (default is
> SSL_CLIENT_CERT)
> JkCERTSIndicator SSL_CLIENT_CERT
> 
> May be with the directive 
> 
> JkEnvVars MYVAR1 MYVAR2 MYVAR3 MYVAR4...
> 
> 
> The traffic will be more important but these informations
> will be usefull for some...
> 
> What about that ?
> 
> 
> -
> Henri Gomez ___[_]
> EMAIL : [EMAIL PROTECTED](. .) 
> PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 
> 

RE: [PROPOSAL AJP14] AJP13 Evolution

[cmanolache]

On Wed, 9 May 2001, GOMEZ Henri wrote:

> May be with the directive 
> 
> JkEnvVars MYVAR1 MYVAR2 MYVAR3 MYVAR4...
> 
> 
> The traffic will be more important but these informations
> will be usefull for some...
> 
> What about that ?

+1 to add this to a TODO list, but low priority :-)

Let's first get the auto configuration to work, as this seem the most
requested feature, then we can add other callbacks and features.

( I do have few features I will need for some extra optimizations on
tomcat, but again - it's low priority compared with getting things rolling
and improving the config ).


Costin

RE: [PROPOSAL AJP14] AJP13 Evolution

[GOMEZ Henri]

Many users have asked for more web-server env vars
they like to use also in Tomcat.

May be something to add to AJP14 will be the
ability to define a list of env vars to be forwarded
to Tomcat, the same way the SSL web-server vars are 
defined :

# What is the indicator for SSL session (default is SSL_SESSION_ID)
JkSESSIONIndicator SSL_SESSION_ID
# What is the indicator for client SSL cipher suit (default is SSL_CIPHER)
JkCIPHERIndicator SSL_CIPHER
# What is the indicator for the client SSL certificated (default is
SSL_CLIENT_CERT)
JkCERTSIndicator SSL_CLIENT_CERT

May be with the directive 

JkEnvVars MYVAR1 MYVAR2 MYVAR3 MYVAR4...


The traffic will be more important but these informations
will be usefull for some...

What about that ?


-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 

RE: [PROPOSAL AJP14] AJP13 Evolution

[GOMEZ Henri]

>ajp13 reuses connections, but, in general for each "worker" 
>there will be a
>pool of connections between the web server and the servlet 
>engine.  That way
>it can handle multiple requests concurrently, but still save 
>on the socket
>creation time (since connections are reused for many requests).

>So deciding which connection to send the admin messages on is, in fact,
>important.  Not only do we have to watch out for resending 
>data, but we also
>have to make sure we send data to all the participating web servers
>(multiple Apaches can talk to one TC, and, if they do so, they 
>can all hit
>the same port, in which case some ajp13 threads are talking to 
>one, some to
>another).

Each AJP14 thread in Tomcat must send admin messages. It will
be the task of web-server to remove duplicate messages.
 
>Maybe we should tag the TC->Apache admin messages with an id 
>-- that way we
>could just send them out on all conections, and the various 
>Apache children
>would make sure they only react to a given message once (possibly
>communicating w/ each other via shared memory).  This will 
>make the problem
>of informing all participating Apache instances go away, and 
>we may need to
>play some shared memory games in any event, to make sure that 
>all the Apache
>procs are brought up to date.

+1 for the ID of admin messages, which make the removing easier.
shared memory will make mod_jk port on differents web-server/OS
more harder, and we might introduce here the use of APR.

But there is APR specialists around !=)
  
>-Dan
>
>Mike Braden wrote:
>> 
>> Why not just handle each connection as if it is a connection
>> from a different server, logging in each time.
>> 
>> Are ajp13 requests serialized? ajp13 only connects to TC
>> once to the port set in the config, right?
>> 
>> -Original Message-
>> From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED]]On
> Behalf Of jean-frederic clere
> Sent: Tuesday, May 08, 2001 5:19 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [PROPOSAL AJP14] AJP13 Evolution
> 
> Apjp13 requests are not multiplexed, so we need more that one connection.
> How
> could we decide on which connection we send the admin message? Otherwise
we
> will
> the send the same data more than once.

-- 

Dan Milstein // [EMAIL PROTECTED]

RE: [PROPOSAL AJP14] AJP13 Evolution

[GOMEZ Henri]

>> 1) FORWARD REQUEST FROM WEB-SERVER TO SERVLET ENGINE
>> 2) WAIT FOR RESPONSE
>> 3) GET RESPONSE AND FORWARD TO WEB-SERVER.
>
>Well, I see it a bit different :-)
>
>1. Apache sends a message to tomcat with the original request 
>( or part of it ! - for example it can send only some headers that are
>commonly used ), then start waiting.
>
>2. Tomcat receives the message, start processing. When he 
>needs something
>from apache ( like sendHead or get info or auth or admin commands ) it
>sends a message, then start waiting.
>
>3. That goes on, with a message acting as a token. At any time 
>one side is
>listening, and the other ( who reveived the last message ) has the
>control. 
>
>In a way it's like a single "virtual" thread of execution, 
>with the apache
>thread and tomcat thread passing control via messages.

>
>Now, I know this sounds complicated - but it's a good solution 
>with very
>little overhead. This is not a general RPC protocol, but something
>specialized for tomcat, and it works very well with single-threaded
>processes. 

The only reserve will be about speed. Won't these write() and read() 
make web-server too slow. But that's interesting and will need testing
in real condition. AJP14 could test these experimental schemas.

>Even in Apache2.0 - creating threads for each tomcat callback and using
>additional sockets is significant overhead given the time constraints.
>
>The problem is that the "admin" commands can be passed only on certain
>moments: 
>- when apache connects for the first time ( the socket will be 
>kept open )
>- when apache sends a request
>
>I think that should be enough for what we need - if we make it more
>complex we may add too much overhead. ( and we may not be able to have
>good  support for Apache1.3 )

More overhead will make ajp14 slower than ajp13, or even ajp12 and
that's not the goal since admin message are only 1% of the real
traffic

RE: [PROPOSAL AJP14] AJP13 Evolution

[GOMEZ Henri]

>I have the following idea:
>
>JServ has a nice feature "ApJServManual off", the mod_jserv 
>starts the JVM and
>check via pings messages that is goes on running. It would be 
>nice to put the
>feature in AJP14.
>JkStartTomcat path_name server_conf_name time_out

A feature asked by many JServ users which may be easy to add.
Why not 

>Where
>path_name is a path to a C wrapper like catalina.c (C version 
>of catalina.sh)
>server_conf_name is the well known server.xml file.
>time_out a value in second to allow Tomcat to start.
>
>I have the problem that the webserver have to read the 
>server.xml file to find
>the port it should use to connect to Tomcat. - The port used 
>in the server.xml
>file should not be changed before the webserver gets the connection -

The web-server could use the default port (8010 ?) or we could add
it in JkStartTomcat :

JkStartTomcat path_name server_conf_name time_out ajp14port

>Cheers
>
>Jean-frederic
>
>GOMEZ Henri wrote:
>> 
>> Hi to all,
>> 
>> You could find attached a proposal of evolution to
>> the current Apache JServ Protocol version 1.3,
>> also known as ajp13.
>> 
>> Let start the comments, questions, remarks cycle.
>> 
>> PS : I've not cover here the full protocol but only the add-on
>>  from ajp13.
>> 
>> -
>> Henri Gomez ___[_]
>> EMAIL : [EMAIL PROTECTED](. .)
>> PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
>> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
>> 
>>   
>---
>-
>>  Name: AJPv14.txt
>>AJPv14.txtType: Plain Text (text/plain)
>>  Encoding: quoted-printable
>

RE: [PROPOSAL AJP14] AJP13 Evolution

[GOMEZ Henri]

>> 1) How did we share it in forked (apache 1.3) env ?
>>=> shared memory => MM or APR
>
>APR of course: MM is included in it.

But APR is only available in Apache 2.0, what about Apache 1.3,
NES and IIS ? And MM is still only for Unix OS 

>> 
>> 2) Ditto in a threaded architecture (Apache 2.0)
>>at least in MPM mode (a forked child which will in turn thread
>>child), but again how did we info we other forked.
>> 
>> Also doubling the socket, will double the descriptors open
>> and will be a problem under heavy load.
>> In an HTTP architecture we need again to mix data (tons of
>> messages) with control (very low traffic). And so we need
>> to read for possible message at some time.
>> 
>> 1) FORWARD REQUEST FROM WEB-SERVER TO SERVLET ENGINE
>> 2) WAIT FOR END OF PREVIOUS REPLY AND EVENTUALLY ADMIN MESSAGE
>> 3) GET ADMIN MESSAGE and evnetually RESPONSE
>> 4) GET RESPONSE AND FORWARD TO WEB-SERVER.
>> 
>> The admin message could be send() in socket at any time and
>> will be handled when a request will came
>
>Apjp13 requests are not multiplexed, so we need more that one 
>connection. How
>could we decide on which connection we send the admin message? 
>Otherwise we will
>the send the same data more than once.

The admin response could be sent on EACH AJP13 connections, and
it will be web-server task to discard allready received admin
message...

>What happends when the configuration is changed more than once 
>and no request
>happend in the meantime...
>We could get a wrong configuration...

If we have a DOWN event and then a UP event, the servlet 
engine send a DOWN message and then a UP message. The 
web-servlet will have to read ALL ADMIN messages and 
process the whole block...

Re: [PROPOSAL AJP14] AJP13 Evolution

[Dan Milstein]

ajp13 reuses connections, but, in general for each "worker" there will be a
pool of connections between the web server and the servlet engine.  That way
it can handle multiple requests concurrently, but still save on the socket
creation time (since connections are reused for many requests).

So deciding which connection to send the admin messages on is, in fact,
important.  Not only do we have to watch out for resending data, but we also
have to make sure we send data to all the participating web servers
(multiple Apaches can talk to one TC, and, if they do so, they can all hit
the same port, in which case some ajp13 threads are talking to one, some to
another).

Maybe we should tag the TC->Apache admin messages with an id -- that way we
could just send them out on all conections, and the various Apache children
would make sure they only react to a given message once (possibly
communicating w/ each other via shared memory).  This will make the problem
of informing all participating Apache instances go away, and we may need to
play some shared memory games in any event, to make sure that all the Apache
procs are brought up to date.

-Dan

Mike Braden wrote:
> 
> Why not just handle each connection as if it is a connection
> from a different server, logging in each time.
> 
> Are ajp13 requests serialized? ajp13 only connects to TC
> once to the port set in the config, right?
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> Behalf Of jean-frederic clere
> Sent: Tuesday, May 08, 2001 5:19 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [PROPOSAL AJP14] AJP13 Evolution
> 
> Apjp13 requests are not multiplexed, so we need more that one connection.
> How
> could we decide on which connection we send the admin message? Otherwise we
> will
> the send the same data more than once.

-- 

Dan Milstein // [EMAIL PROTECTED]

Re: [PROPOSAL AJP14] AJP13 Evolution

[cmanolache]

On Tue, 8 May 2001, Dan Milstein wrote:

> The only thing we really lose is the ability for the servlet engine to send
> a message to TC in between requests.  And the main messages, as I see it,
> are:
>  
>a) the entire engine is shutting down 
> 
>b) certain contexts are shutting down 
> 
>c) certain contexts are now live

All of those are "low-frequency" events, equivalent with a configuration
change in the web server ( like you edit the apache.conf and add a new 
virtual host, same thing for NES or IIS ).

All servers have mechanisms to deal with such things - like a signal or
some other thing, and that can be abstracted.

( in fact,  this shouldn't even be part of mod_jk - but a different
component )

For multithreaded servers ( or multi-process servers that maintain a
communication chain between servers - like the scoreboard ) this can also
be implemented as a normal server module, that would handle a special
request, and tomcat can do a simple "reconfigure" request using HTTP.

Yet another solution: mod_jk can send a "ping" ( let's say after every 100
requests - or before the first request if a certain timeout ).

There are many solutions for this - without adding complexity to the
"common" case. 

> [Socket trivia -- will this written-but-unread data cause any trouble during
> the TC shutdown process?]

Just an exception ( unless you read before closing the socket ), and of
course only on some platforms ( that implement corectly the TCP spec ).


> That part makes sense.  However, you're also suggesting using that status
> command to send over config information via AJP_CONTEXT_(DOWN|UP|OK).  I
> *do* like the idea of the engine sending over some control information at
> the end of every request-handling cycle, but I have two suggestions:

Let's first solve the first "90%" of the problem: tomcat sending config
at the beginning. That resolves most of the configuration problems ( most
users will not have to touch any server config files ).

The other 10% ( contexts added/removed/changed at runtime ) is identical
with the problem of "web server config changed" - we shouldn't try to be
smarter than the server ( for now ). Just using the normal server restart
should be enough and clean.

With Apache2.0 and most multithreaded servers we can do a normal HTTP
request from tomcat to apache and make a config change ( the config can be
changed at runtime ), with apache1.3 there is no better solution than a
restart ( if we want to let apache do the mappings - the mapping tree is
created at startup time AFAIK ).


> BTW, currently, ajp13 sends over a single byte of status, which determines
> whether or not the connection should be reused.  We'd basically just be
> expanding that.  I like that idea a lot.

+1

> (so that it can tack it onto the end of the request cycle).  Questions: what
> if multiple instances of Apache are forwarding requests to a single TC
> instance?  How can TC "know" that?  It has a single master socket, and then
> it hands off live sockets to individual threads, which hang onto them over
> many requests.  If some of those threads are serving Apache 1, and some are
> serving Apache 2, then we have to make sure that the context change info
> goes into one thread from each group.  And then on the Apache side, we have
> to bubble that config information up so that all the separate child
> processes change their config setup.  (Is this true?  Does Apache work
> differently than this somehow?)

On connection open we need to pass some more info, and we'll have to save
and organize this information. But I think this is orthogonal on the 
communication problem. 

For Apache1.3 we could use a signal or the scoreboard to signal to all
processes.

Costin

Re: [PROPOSAL AJP14] AJP13 Evolution

[Dan Milstein]

I think Costin has summed up the situation very well, in terms of the
control/data issue.  As the person who originally suggested thinking about a
separate data channel, I am now strongly leaning away from that.  The
various complicated threading/process issues are not worth the grief.  

The only thing we really lose is the ability for the servlet engine to send
a message to TC in between requests.  And the main messages, as I see it,
are:
 
   a) the entire engine is shutting down 

   b) certain contexts are shutting down 

   c) certain contexts are now live

Henri, you're trying to cover that via the AJP_STATUS cmd, which the engine
writes to the socket at the end of a request-handling cycle but which the
web server only reads when it next goes to send a request over.  Unless I
misunderstand, the main reason for that delay is so that if the engine shuts
down, and the socket dies, the web server will find out immediately (rather
than sending across a request and only finding out on the subsequent read). 
[Socket trivia -- will this written-but-unread data cause any trouble during
the TC shutdown process?]

That part makes sense.  However, you're also suggesting using that status
command to send over config information via AJP_CONTEXT_(DOWN|UP|OK).  I
*do* like the idea of the engine sending over some control information at
the end of every request-handling cycle, but I have two suggestions:

 1) Don't use APR or OS-specific functions to see if there is more data. 
Instead, make a normal ajp13-style packet with a type of ajp_status_cmd, a
length and a payload.  That way you can fit arbitrarily large data (large
numbers of changed contexts or config information, for example), and take
advantage of the current ajp13 packet-handling functions.  Conceivably, you
could even set it up so that mod_jk could accept those packets *during*
request handling, as well as at the end.  

BTW, currently, ajp13 sends over a single byte of status, which determines
whether or not the connection should be reused.  We'd basically just be
expanding that.  I like that idea a lot.

 2) Have the web server read that config data immediately, but always have
an extra dummy byte (or whatever) of padding at the end which the server can
hold off on reading until the next request.  That way, config information
will flow up into the web server as soon as possible, and the logic will be
much simpler (e.g. you won't get a situation where the server is about to
forward a request and only then reads the config info which tells it that it
can't forward that request).

Then we just have to set up the Java code so that the context change
information can get passed into an ajp13 thread which is servicing requests
(so that it can tack it onto the end of the request cycle).  Questions: what
if multiple instances of Apache are forwarding requests to a single TC
instance?  How can TC "know" that?  It has a single master socket, and then
it hands off live sockets to individual threads, which hang onto them over
many requests.  If some of those threads are serving Apache 1, and some are
serving Apache 2, then we have to make sure that the context change info
goes into one thread from each group.  And then on the Apache side, we have
to bubble that config information up so that all the separate child
processes change their config setup.  (Is this true?  Does Apache work
differently than this somehow?)

That sounds complicated.  How is this handled in mod_webapp?  Anyone?

-Dan

[EMAIL PROTECTED] wrote:
> 
> > Argh, all the subtility is here.
> > Basically even if ajp13 is a bidirectional protocol,
> > it's a request/reply protocol since it's how a web
> > server function :
> 
> > 1) FORWARD REQUEST FROM WEB-SERVER TO SERVLET ENGINE
> > 2) WAIT FOR RESPONSE
> > 3) GET RESPONSE AND FORWARD TO WEB-SERVER.
> 
> Well, I see it a bit different :-)
> 
> 1. Apache sends a message to tomcat with the original request
> ( or part of it ! - for example it can send only some headers that are
> commonly used ), then start waiting.
> 
> 2. Tomcat receives the message, start processing. When he needs something
> from apache ( like sendHead or get info or auth or admin commands ) it
> sends a message, then start waiting.
> 
> 3. That goes on, with a message acting as a token. At any time one side is
> listening, and the other ( who reveived the last message ) has the
> control.
> 
> In a way it's like a single "virtual" thread of execution, with the apache
> thread and tomcat thread passing control via messages.
> 
> Now, I know this sounds complicated - but it's a good solution with very
> little overhead. This is not a general RPC protocol, but something
> specialized for tomcat, and it works very well with single-threaded
> processes.
> 
> Even in Apache2.0 - creating threads for each tomcat callback and using
> additional sockets is significant overhead given the time constraints.
> 
> The problem is that the "admin" commands can be passed only on certain
> mome

RE: [PROPOSAL AJP14] AJP13 Evolution

[Mike Braden]

Why not just handle each connection as if it is a connection
from a different server, logging in each time.

Are ajp13 requests serialized? ajp13 only connects to TC
once to the port set in the config, right?

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of jean-frederic clere
Sent: Tuesday, May 08, 2001 5:19 AM
To: [EMAIL PROTECTED]
Subject: Re: [PROPOSAL AJP14] AJP13 Evolution

Apjp13 requests are not multiplexed, so we need more that one connection.
How
could we decide on which connection we send the admin message? Otherwise we
will
the send the same data more than once.

Re: [PROPOSAL AJP14] AJP13 Evolution

[jean-frederic clere]

Hi all,

I have the following idea:

JServ has a nice feature "ApJServManual off", the mod_jserv starts the JVM and
check via pings messages that is goes on running. It would be nice to put the
feature in AJP14.
JkStartTomcat path_name server_conf_name time_out

Where
path_name is a path to a C wrapper like catalina.c (C version of catalina.sh)
server_conf_name is the well known server.xml file.
time_out a value in second to allow Tomcat to start.

I have the problem that the webserver have to read the server.xml file to find
the port it should use to connect to Tomcat. - The port used in the server.xml
file should not be changed before the webserver gets the connection -

Cheers

Jean-frederic

GOMEZ Henri wrote:
> 
> Hi to all,
> 
> You could find attached a proposal of evolution to
> the current Apache JServ Protocol version 1.3,
> also known as ajp13.
> 
> Let start the comments, questions, remarks cycle.
> 
> PS : I've not cover here the full protocol but only the add-on
>  from ajp13.
> 
> -
> Henri Gomez ___[_]
> EMAIL : [EMAIL PROTECTED](. .)
> PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
> 
>   
>  Name: AJPv14.txt
>AJPv14.txtType: Plain Text (text/plain)
>  Encoding: quoted-printable

Re: [PROPOSAL AJP14] AJP13 Evolution

[jean-frederic clere]

GOMEZ Henri wrote:
> 
> 
> >>  1) We've talked about specifying a response packet to
> >indicate that the
> >> engine (or the web server) doesn't recognize a packet sent
> >over.  This would
> >> allow us much more flexiblity to add packet types to ajpv14,
> >without having
> >> to make ajpv15,16, etc.
> >
> >+1
> >
> >In other words - both ends should deal with unknown packets - maybe by
> >sending back an "UNIMPLEMENTED" message.
> 
> Since AJP indicate size we could deal with unknow packets. But
> if we negociate at startup the common protocol level, we must
> avoid that situation.
> I like the idea of reject cmd, +1
> 
> >
> >>  2) What about specifying a separate, out of band control socket
> >> connection?  If the web server opened up two connections, 1
> >for data, one
> >> for control, then we could have much better communication
> >from the engine to
> >> the server (if it was shutting down contexts, for example).
> >We could also
> >> have a heartbeat without interfering with the data channel.
> >
> >I'm not sure - but I can see some benefits.
> >
> >Right now we have (almost) bidirectional communication - the
> >protocol is
> >based on message passing, and sort of "token"-based:
> >each side sends a message, then waits for a message.
> >
> >The main reason for that is the single-threaded web server. (
> >Apache1.3,
> >maybe other servers ). It is a bit difficult to deal with 2
> >connections in
> >a single threaded env ( while keeping the code as simple as possible ).
> >My feeling is that for most needs of a servlet container we
> >can deal with
> >the single socket protocol. I don't know any (major) use case
> >or feature
> >of tomcat that would require the second socket.
> 
> Argh, all the subtility is here.
> Basically even if ajp13 is a bidirectional protocol,
> it's a request/reply protocol since it's how a web
> server function :
> 
> 1) FORWARD REQUEST FROM WEB-SERVER TO SERVLET ENGINE
> 2) WAIT FOR RESPONSE
> 3) GET RESPONSE AND FORWARD TO WEB-SERVER.
> 
> We could have a second socket for control but :
> 
> 1) How did we share it in forked (apache 1.3) env ?
>=> shared memory => MM or APR

APR of course: MM is included in it.

> 
> 2) Ditto in a threaded architecture (Apache 2.0)
>at least in MPM mode (a forked child which will in turn thread
>child), but again how did we info we other forked.
> 
> Also doubling the socket, will double the descriptors open
> and will be a problem under heavy load.
> In an HTTP architecture we need again to mix data (tons of
> messages) with control (very low traffic). And so we need
> to read for possible message at some time.
> 
> 1) FORWARD REQUEST FROM WEB-SERVER TO SERVLET ENGINE
> 2) WAIT FOR END OF PREVIOUS REPLY AND EVENTUALLY ADMIN MESSAGE
> 3) GET ADMIN MESSAGE and evnetually RESPONSE
> 4) GET RESPONSE AND FORWARD TO WEB-SERVER.
> 
> The admin message could be send() in socket at any time and
> will be handled when a request will came

Apjp13 requests are not multiplexed, so we need more that one connection. How
could we decide on which connection we send the admin message? Otherwise we will
the send the same data more than once.

What happends when the configuration is changed more than once and no request
happend in the meantime...
We could get a wrong configuration...

RE: [PROPOSAL AJP14] AJP13 Evolution

[cmanolache]

> Argh, all the subtility is here.
> Basically even if ajp13 is a bidirectional protocol,
> it's a request/reply protocol since it's how a web
> server function :

> 1) FORWARD REQUEST FROM WEB-SERVER TO SERVLET ENGINE
> 2) WAIT FOR RESPONSE
> 3) GET RESPONSE AND FORWARD TO WEB-SERVER.

Well, I see it a bit different :-)

1. Apache sends a message to tomcat with the original request 
( or part of it ! - for example it can send only some headers that are
commonly used ), then start waiting.

2. Tomcat receives the message, start processing. When he needs something
from apache ( like sendHead or get info or auth or admin commands ) it
sends a message, then start waiting.

3. That goes on, with a message acting as a token. At any time one side is
listening, and the other ( who reveived the last message ) has the
control. 

In a way it's like a single "virtual" thread of execution, with the apache
thread and tomcat thread passing control via messages.


Now, I know this sounds complicated - but it's a good solution with very
little overhead. This is not a general RPC protocol, but something
specialized for tomcat, and it works very well with single-threaded
processes. 

Even in Apache2.0 - creating threads for each tomcat callback and using
additional sockets is significant overhead given the time constraints.

The problem is that the "admin" commands can be passed only on certain
moments: 
- when apache connects for the first time ( the socket will be kept open )
- when apache sends a request

I think that should be enough for what we need - if we make it more
complex we may add too much overhead. ( and we may not be able to have
good  support for Apache1.3 )


We allways have the choice of using a "real" ORB - so there is a limit in
AJP's complexity ( when it starts having all the features of an ORB, we
shoud just replace it with a real one :-)

Costin

RE: [PROPOSAL AJP14] AJP13 Evolution

[GOMEZ Henri]

>2 things:
> 
>> The system is aimed to be simple, we don't want SSH/SSL
>> here but just a basic 'protected' login.
>
>and that you can bind the socket to 127.0.0.1: instead 
>of *:
>through a config change.

In that case, you restrict to a web-sevlet/tomcat on the same
machine, but yes we could do that (allready possible on TC 3.2/3.3)

>>>This level of security would cover most of the installations
>>>and when someone requires an additional level of security or
>>>interface to other security mechanisms, that could be added
>>>later.
>> 
>> We can add native SSH tunneling for example using openssh.
>
>You could do that already with no modifications to the ajp by 
>using port
>forwarded SSH tunneling. Heck, you could do it with STunnel if 
>you want to
>use RSA/SSL instead of SSH also without modifications to ajp.

I better use jonama (http://www.multimania.com/jonama/) to
do SSL tunneling since I wrote this one ;)

RE: [PROPOSAL AJP14] AJP13 Evolution

[GOMEZ Henri]

 
>>  1) We've talked about specifying a response packet to 
>indicate that the
>> engine (or the web server) doesn't recognize a packet sent 
>over.  This would
>> allow us much more flexiblity to add packet types to ajpv14, 
>without having
>> to make ajpv15,16, etc.  
>
>+1
>
>In other words - both ends should deal with unknown packets - maybe by
>sending back an "UNIMPLEMENTED" message. 

Since AJP indicate size we could deal with unknow packets. But 
if we negociate at startup the common protocol level, we must
avoid that situation. 
I like the idea of reject cmd, +1

>
>>  2) What about specifying a separate, out of band control socket
>> connection?  If the web server opened up two connections, 1 
>for data, one
>> for control, then we could have much better communication 
>from the engine to
>> the server (if it was shutting down contexts, for example).  
>We could also
>> have a heartbeat without interfering with the data channel.
>
>I'm not sure - but I can see some benefits.
>
>Right now we have (almost) bidirectional communication - the 
>protocol is
>based on message passing, and sort of "token"-based: 
>each side sends a message, then waits for a message.
>
>The main reason for that is the single-threaded web server. ( 
>Apache1.3,
>maybe other servers ). It is a bit difficult to deal with 2 
>connections in
>a single threaded env ( while keeping the code as simple as possible ).
>My feeling is that for most needs of a servlet container we 
>can deal with
>the single socket protocol. I don't know any (major) use case 
>or feature
>of tomcat that would require the second socket.

Argh, all the subtility is here.
Basically even if ajp13 is a bidirectional protocol,
it's a request/reply protocol since it's how a web
server function :

1) FORWARD REQUEST FROM WEB-SERVER TO SERVLET ENGINE
2) WAIT FOR RESPONSE
3) GET RESPONSE AND FORWARD TO WEB-SERVER.

We could have a second socket for control but :

1) How did we share it in forked (apache 1.3) env ?
   => shared memory => MM or APR

2) Ditto in a threaded architecture (Apache 2.0)
   at least in MPM mode (a forked child which will in turn thread  
   child), but again how did we info we other forked.

Also doubling the socket, will double the descriptors open
and will be a problem under heavy load.
In an HTTP architecture we need again to mix data (tons of
messages) with control (very low traffic). And so we need
to read for possible message at some time.

1) FORWARD REQUEST FROM WEB-SERVER TO SERVLET ENGINE
2) WAIT FOR END OF PREVIOUS REPLY AND EVENTUALLY ADMIN MESSAGE
3) GET ADMIN MESSAGE and evnetually RESPONSE
4) GET RESPONSE AND FORWARD TO WEB-SERVER.

The admin message could be send() in socket at any time and
will be handled when a request will came

RE: [PROPOSAL AJP14] AJP13 Evolution

[Nick Bauman]

2 things:
 
> The system is aimed to be simple, we don't want SSH/SSL
> here but just a basic 'protected' login.

and that you can bind the socket to 127.0.0.1: instead of *:
through a config change.
 
>>This level of security would cover most of the installations
>>and when someone requires an additional level of security or
>>interface to other security mechanisms, that could be added
>>later.
> 
> We can add native SSH tunneling for example using openssh.

You could do that already with no modifications to the ajp by using port
forwarded SSH tunneling. Heck, you could do it with STunnel if you want to
use RSA/SSL instead of SSH also without modifications to ajp.
 

-- 
Nick Bauman
Software Developer
3023 Lynn #22
Minneapolis, MN
55416
Mobile Phone: (612) 810-7406

RE: [PROPOSAL AJP14] AJP13 Evolution

[GOMEZ Henri]

>Will this be the next step to combining mod_webapp with
>mod_jk?

Discussion is open and Pier is my guess, even if he loose
an occasion to eat splendid 'pasta fresca'.

>Maybe this could be the first step to merging the two.
>ajp14 could offer some automatic configuration similar
>to mod_webapp, as you suggested in the proposal.

>I also think that a security mechanism is important.
>There should be some form of login for the connector to
>make sure that communication with the server is allowed.

>I think we should be careful with the security side,
>however.  This could lead into a complex discussion
>over what is appropriate.  My suggestion would be to
>go with something simple, as suggested in the proposal.

The system is aimed to be simple, we don't want SSH/SSL
here but just a basic 'protected' login.

>This level of security would cover most of the installations
>and when someone requires an additional level of security or
>interface to other security mechanisms, that could be added
>later.

We can add native SSH tunneling for example using openssh.

>This proposal hits on the most important issues with mod_jk
>at this point.
>
>+1
>
>As for the security key, would it be possible to generate
>a unique key when mod_jk is first installed?  Maybe we could
>create some basic mechanism, similar to the way ssh generates
>a key when it is installed.  This would avoid the possibility
>of having many TC servers out there that can be logged into
>with the default key or no key.  It could avoid the problem
>that the admin webapp has with the password needing to be changed
>and trust being turned on.

mod_jk could serve many tomcats on different systems. Each Tomcat
could need a different secret key, but worker concept help here.
Cf my previous mail about it
 
>Just a thought.
>
>Mike.
>--
>Mike Braden
>[EMAIL PROTECTED]
>[EMAIL PROTECTED] 
>
>-Original Message-
>From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
>Sent: Monday, May 07, 2001 8:40 AM
>To: [EMAIL PROTECTED]
>Subject: [PROPOSAL AJP14] AJP13 Evolution
>
>
>Hi to all,
>
>You could find attached a proposal of evolution to
>the current Apache JServ Protocol version 1.3, 
>also known as ajp13.  
>
>Let start the comments, questions, remarks cycle.
>
>PS : I've not cover here the full protocol but only the add-on 
> from ajp13.
>
>-
>Henri Gomez ___[_]
>EMAIL : [EMAIL PROTECTED](. .) 
>PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
>PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 
>
>

RE: [PROPOSAL AJP14] AJP13 Evolution

[GOMEZ Henri]

In the doc, the secret key is a string present in
web-server and servlet engine :

must be defined for each workers:

worker.myworker.port=8010
worker.myworker.type=ajp14
worker.myworker.host=myremotesystem
worker.myworker.secretkey=myverysecretkey

<= in TC 3.2.x =>


  

   


<= in TC 3.3 =>



<= in TC 4.0 =>



AJP12/MOD_JSERV used the same system of allready know common key.
The key is passed in md5 to get the 32 chars data

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 

RE: [PROPOSAL AJP14] AJP13 Evolution

[cmanolache]

On Mon, 7 May 2001, Mike Braden wrote:

> +1
> 
> As for the security key, would it be possible to generate
> a unique key when mod_jk is first installed?  Maybe we could
> create some basic mechanism, similar to the way ssh generates

That's what tomcat3.3 does for ajp12 shutdown messages:  at startup it
generates a random password ( if none was explicitely set ). The code is
quite simple to add for ajp14 too.



Costin

RE: [PROPOSAL AJP14] AJP13 Evolution

[Mike Braden]

Will this be the next step to combining mod_webapp with
mod_jk?

Maybe this could be the first step to merging the two.
ajp14 could offer some automatic configuration similar
to mod_webapp, as you suggested in the proposal.

I also think that a security mechanism is important.
There should be some form of login for the connector to
make sure that communication with the server is allowed.

I think we should be careful with the security side,
however.  This could lead into a complex discussion
over what is appropriate.  My suggestion would be to
go with something simple, as suggested in the proposal.

This level of security would cover most of the installations
and when someone requires an additional level of security or
interface to other security mechanisms, that could be added
later.

This proposal hits on the most important issues with mod_jk
at this point.

+1

As for the security key, would it be possible to generate
a unique key when mod_jk is first installed?  Maybe we could
create some basic mechanism, similar to the way ssh generates
a key when it is installed.  This would avoid the possibility
of having many TC servers out there that can be logged into
with the default key or no key.  It could avoid the problem
that the admin webapp has with the password needing to be changed
and trust being turned on.

Just a thought.

Mike.
--
Mike Braden
[EMAIL PROTECTED]
[EMAIL PROTECTED] 

-Original Message-
From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 07, 2001 8:40 AM
To: [EMAIL PROTECTED]
Subject: [PROPOSAL AJP14] AJP13 Evolution


Hi to all,

You could find attached a proposal of evolution to
the current Apache JServ Protocol version 1.3, 
also known as ajp13.  

Let start the comments, questions, remarks cycle.

PS : I've not cover here the full protocol but only the add-on 
 from ajp13.

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 

Re: [PROPOSAL AJP14] AJP13 Evolution

[cmanolache]

On Mon, 7 May 2001, Dan Milstein wrote:

> Henri,
> 
> Lots of good stuff.  A few ideas/possibilities:
> 
>  1) We've talked about specifying a response packet to indicate that the
> engine (or the web server) doesn't recognize a packet sent over.  This would
> allow us much more flexiblity to add packet types to ajpv14, without having
> to make ajpv15,16, etc.  

+1

In other words - both ends should deal with unknown packets - maybe by
sending back an "UNIMPLEMENTED" message. 


>  2) What about specifying a separate, out of band control socket
> connection?  If the web server opened up two connections, 1 for data, one
> for control, then we could have much better communication from the engine to
> the server (if it was shutting down contexts, for example).  We could also
> have a heartbeat without interfering with the data channel.

I'm not sure - but I can see some benefits.

Right now we have (almost) bidirectional communication - the protocol is
based on message passing, and sort of "token"-based: 
each side sends a message, then waits for a message.

The main reason for that is the single-threaded web server. ( Apache1.3,
maybe other servers ). It is a bit difficult to deal with 2 connections in
a single threaded env ( while keeping the code as simple as possible ).
My feeling is that for most needs of a servlet container we can deal with
the single socket protocol. I don't know any (major) use case or feature
of tomcat that would require the second socket.

( that doesn't mean I'm -1 on such thing )

Costin

Re: [PROPOSAL AJP14] AJP13 Evolution

[jean-frederic clere]

GOMEZ Henri wrote:
> 
> >Lots of good stuff.  A few ideas/possibilities:
> 
> Happy to see you allready read it Dan :)
> 
> > 1) We've talked about specifying a response packet to
> >indicate that the
> >engine (or the web server) doesn't recognize a packet sent
> >over.  This would
> >allow us much more flexiblity to add packet types to ajpv14,
> >without having
> >to make ajpv15,16, etc.
> 
> Could you develop ?

I have an idea:

To the "LOGON COMP CMD" from the  WEB-SERVER (second message), Add a CString:
WEB-SERVER INFO
The string could be something like: "Apache mod_jk AJP13 AJP14 AJP15"
Tomcat would answer "Tomcat AJP14" to tell that it supports protocol AJP14.

> 
> > 2) What about specifying a separate, out of band control socket
> >connection?  If the web server opened up two connections, 1
> >for data, one
> >for control, then we could have much better communication from
> >the engine to
> >the server (if it was shutting down contexts, for example).
> >We could also
> >have a heartbeat without interfering with the data channel.
> 
> Good idea, but how could we be sure that we'll have only
> one control channel to a given servlet engine ?

If we allow shutdown it could end confusing the user (which Apache has shutdown
Tomcat?).
So it could be good to have only one control channel. But what to do if more
than one WebServer connect to Tomcat?

> 
> In multi-threaded environnement like Apache 2.0, it's easy to
> launch a thread to handle that, but in Apache 1.3 will have no
> others choice than having each child (forked) opening it's
> own control connection since each child is forked and so have
> it's own copy of 'servlet-engine infos

Probably we need shared memory...

> 
> But I like this approach of splitting data and control.
> 
> >-Dan
> >
> >GOMEZ Henri wrote:
> >>
> >> Hi to all,
> >>
> >> You could find attached a proposal of evolution to
> >> the current Apache JServ Protocol version 1.3,
> >> also known as ajp13.
> >>
> >> Let start the comments, questions, remarks cycle.
> >>
> >> PS : I've not cover here the full protocol but only the add-on
> >>  from ajp13.
> >>
> >> -
> >> Henri Gomez ___[_]
> >> EMAIL : [EMAIL PROTECTED](. .)
> >> PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
> >> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
> >>
> >>
> >---
> >-
> >>  Name: AJPv14.txt
> >>AJPv14.txtType: Plain Text (text/plain)
> >>  Encoding: quoted-printable
> >
> >--
> >
> >Dan Milstein // [EMAIL PROTECTED]
> >

RE: [PROPOSAL AJP14] AJP13 Evolution

[GOMEZ Henri]

>Lots of good stuff.  A few ideas/possibilities:

Happy to see you allready read it Dan :)

> 1) We've talked about specifying a response packet to 
>indicate that the
>engine (or the web server) doesn't recognize a packet sent 
>over.  This would
>allow us much more flexiblity to add packet types to ajpv14, 
>without having
>to make ajpv15,16, etc.  

Could you develop ?

> 2) What about specifying a separate, out of band control socket
>connection?  If the web server opened up two connections, 1 
>for data, one
>for control, then we could have much better communication from 
>the engine to
>the server (if it was shutting down contexts, for example).  
>We could also
>have a heartbeat without interfering with the data channel.

Good idea, but how could we be sure that we'll have only
one control channel to a given servlet engine ?

In multi-threaded environnement like Apache 2.0, it's easy to
launch a thread to handle that, but in Apache 1.3 will have no
others choice than having each child (forked) opening it's 
own control connection since each child is forked and so have
it's own copy of 'servlet-engine infos

But I like this approach of splitting data and control.



>-Dan
>
>GOMEZ Henri wrote:
>> 
>> Hi to all,
>> 
>> You could find attached a proposal of evolution to
>> the current Apache JServ Protocol version 1.3,
>> also known as ajp13.
>> 
>> Let start the comments, questions, remarks cycle.
>> 
>> PS : I've not cover here the full protocol but only the add-on
>>  from ajp13.
>> 
>> -
>> Henri Gomez ___[_]
>> EMAIL : [EMAIL PROTECTED](. .)
>> PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
>> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
>> 
>>   
>---
>-
>>  Name: AJPv14.txt
>>AJPv14.txtType: Plain Text (text/plain)
>>  Encoding: quoted-printable
>
>-- 
>
>Dan Milstein // [EMAIL PROTECTED]
>

Re: [PROPOSAL AJP14] AJP13 Evolution

[Dan Milstein]

Henri,

Lots of good stuff.  A few ideas/possibilities:

 1) We've talked about specifying a response packet to indicate that the
engine (or the web server) doesn't recognize a packet sent over.  This would
allow us much more flexiblity to add packet types to ajpv14, without having
to make ajpv15,16, etc.  

 2) What about specifying a separate, out of band control socket
connection?  If the web server opened up two connections, 1 for data, one
for control, then we could have much better communication from the engine to
the server (if it was shutting down contexts, for example).  We could also
have a heartbeat without interfering with the data channel.

-Dan

GOMEZ Henri wrote:
> 
> Hi to all,
> 
> You could find attached a proposal of evolution to
> the current Apache JServ Protocol version 1.3,
> also known as ajp13.
> 
> Let start the comments, questions, remarks cycle.
> 
> PS : I've not cover here the full protocol but only the add-on
>  from ajp13.
> 
> -
> Henri Gomez ___[_]
> EMAIL : [EMAIL PROTECTED](. .)
> PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
> 
>   
>  Name: AJPv14.txt
>AJPv14.txtType: Plain Text (text/plain)
>  Encoding: quoted-printable

-- 

Dan Milstein // [EMAIL PROTECTED]

[PROPOSAL AJP14] AJP13 Evolution

[GOMEZ Henri]

Hi to all,

You could find attached a proposal of evolution to
the current Apache JServ Protocol version 1.3, 
also known as ajp13.  

Let start the comments, questions, remarks cycle.

PS : I've not cover here the full protocol but only the add-on 
 from ajp13.

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



Proposal for Apache JServ 1.4

This document is a proposal of evolution of the current
Apache JServ Protocol version 1.3, also known as ajp13.  
I'll not cover here the full protocol but only the add-on from ajp13.

Missing features in AJP13
-

ajp13 is a good protocol to link a servlet engine like tomcat to a web server like 
Apache: 

* use persistants connections to avoid reconnect time at each request
* encode many http commands to reduce stream size
* send to servlet engine many info from web server (like SSL certs)

But ajp13 lacks support for : 

* security between web server and servlet engine.
  Anybody can connect to an ajp13 port (no login mecanism used)
  You could connect, for example with telnet, and keep the remote thread
  up by not sending any data (no timeout in connection)

* context information passed from servlet engine to web server.
  Part of the configuration of mod_jk, the web server connector, is to
  indicate to the web server which URI to handle. 
  The mod_jk JkMount directive, told to web server which URI must be 
  forwarded to servlet engine.
  A servlet engine allready knows which URI it handle and TC 3.3 is
  allready capable to generate a config file for mod_jk from the list
  of available contexts.
 
* state update of contexts from servlet engine to web server.
  Big site with farm of Tomcat, like ISP and virtuals hosters,
  may need to stop a context for admin purposes. In that case the front
  web server must know that the context is currently down, to eventually
  relay the request to another Tomcat
 
* verify state of connection before sending request.
  Actually mod_jk send the request to the servlet engine and next wait 
  for the answer. But one of the beauty of the socket API, is you that 
  you could write() to a closed connection without any error reporting, 
  but a read() to a closed connection return you the error code. 


AJP14 add-ons to AJP13
--


Let's descrive here the features and add-on that will be added to AJP13, 
which will became AJP14. Since this document is a proposal, a resonable level 
of chaos must be expected at start.
Be sure that discussion on tomcat list will help clarify points, add 
features but the current list seems to be a 'minimun vital'

* Advanced login features at connect time

* Basic authorisation system, where a shared secret key is
  present in web server and servlet engine :

* Basic protocol negociation, just to be sure that if functionnalities are added
  to AJP14 in the future, current implementations will still works.


Advanced login
--

1) WEB-SERVER send LOGIN INIT CMD + NEGOCIATION DATA

2) TOMCAT respond with LOGIN SEED CMD + RANDOM DATA

3) WEB-SERVER calculted the MD5 of RANDOM DATA+SECRET DATA

4) WEB-SERVER send LOGIN COMP CMD + MD5 (SECRET DATA + RANDOM DATA)

5) TOMCAT respond with LOGIN STATUS CMD + NEGOCIED DATA + SERVLET ENGINE INFO


To prevent DOS attack, the servlet engine will wait
the LOGIN CMD only 15/30 seconds and reports the
timeout exception for admins investigation.

The login command will contains basic protocol
negociation information like compressing ability, 
crypto, context info (at start up), context update at 
run-time (up/down), level of SSL env vars, 

The servlet engine will mask the negociation mask with it's own
mask (what it can do) and return it when loggin is accepted.

This will help having a basic ajp14 implementation
on a web-server working with a more advanced ajp14 on
the servlet engine side or vice-versa.

AJP13 was designed to be small and fast and so many
SSL informations present in the web-server are not
forwarded to the servlet engine. 

We add here four negociations flags to provide more
informations on client SSL data (certs), server SSL datas
, crypto used, and misc datas (timeout...). 


- Messages Stream - 

+-+---+
| LOGIN INIT CMD (1 byte) | NEGOCIATION DATA (32bits) |
+-+---+

+-+---+
| LOGIN SEED CMD (1 byte) | MD5 of entropy (32 chars) |
+-+---+

+-+---+
| LOGIN COMP CMD (1 byte) | MD5 of RANDOM + SECRET KEY (32 chars) |
+-+---+

+++---+
| LOGOK CMD (1 byt