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
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
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
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
: 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
+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
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
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
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 :)
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
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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 =
Connector
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
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:PORT instead of *:PORT
through a config change.
This level of security would cover most of the installations
and when someone requires an
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
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:PORT instead
of *:PORT
through a config change.
In that case, you restrict to a web-sevlet/tomcat on the same
machine, but yes we could
35 matches
Mail list logo
