You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by GOMEZ Henri <hg...@slib.fr> on 2001/05/07 14:40:17 UTC
[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 : hgomez@slib.fr (. .)
PGP KEY : 697ECEDD ...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
Re: [PROPOSAL AJP14] AJP13 Evolution
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
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 : hgomez@slib.fr (. .)
> PGP KEY : 697ECEDD ...oOOo..(_)..oOOo...
> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
>
> --------------------------------------------------------------------------------
> Name: AJPv14.txt
> AJPv14.txt Type: Plain Text (text/plain)
> Encoding: quoted-printable
Re: [PROPOSAL AJP14] AJP13 Evolution
Posted by cm...@yahoo.com.
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 %XXXX 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
Posted by kevin seguin <se...@motive.com>.
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 : hgomez@slib.fr (. .)
> PGP KEY : 697ECEDD ...oOOo..(_)..oOOo...
> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
>
> ------------------------------------------------------------------------
> Name: AJPv14.txt
> AJPv14.txt Type: Plain Text (text/plain)
> Encoding: quoted-printable
Re: [PROPOSAL AJP14] AJP13 Evolution
Posted by cm...@yahoo.com.
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
Posted by Dan Milstein <da...@shore.net>.
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 : hgomez@slib.fr (. .)
> PGP KEY : 697ECEDD ...oOOo..(_)..oOOo...
> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
>
> ----------------------------------------------------------------------------
> Name: AJPv14.txt
> AJPv14.txt Type: Plain Text (text/plain)
> Encoding: quoted-printable
--
Dan Milstein // danmil@shore.net
RE: [PROPOSAL AJP14] AJP13 Evolution
Posted by cm...@yahoo.com.
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
Posted by Mike Braden <mi...@nc.rr.com>.
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
mikeb@nc.rr.com
mikeb@mwbinc.com
-----Original Message-----
From: GOMEZ Henri [mailto:hgomez@slib.fr]
Sent: Monday, May 07, 2001 8:40 AM
To: tomcat-dev@jakarta.apache.org
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 : hgomez@slib.fr (. .)
PGP KEY : 697ECEDD ...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6