What's the status with mod_proxy ?
It seems this kind of change would break backward compatibility, and if this
happens - maybe it's better to fix the protocol marshalling limitations or
change it completely.
I hate the idea of patching an old and mostly broken marshalling model.
The only thing we still need is the alternating client/server role using a
single tcp connection. For the actual marshalling, there are plenty of
better choices - with more extensibility, self-describing, easy and fast to
parse, etc.
Examples:
- json
- http://www.caucho.com/resin-3.0/protocols/hessian-1.0-spec.xtp
- yaml.org
- wbxml if we want very compact representation
( every time someone is discussing extending AJP I feel the need to point
that ajp is a very old and not so well designed protocol, it was not
supposed to live that longer and there is no need for a proprietary,
tomcat-specific marshalling mechanism )
I realize that replacing the serialization code would be a large effort, but
I think using a proper format, with existing implementations ( to allow easy
testing ) is far simpler than patching ajp and having all kind of
workarounds and tricks.
Costin
On 7/9/06, Mladen Turk <[EMAIL PROTECTED]> wrote:
You see how desperate I am when writing this on Sunday :)
Anyhow, we are pretty close to the new JK release that I
hope will be the most usable and stable whatsoever.
The things we agreed so many times before, but having
obviously too little resources to actually create are
the 1.3 branch (aka JK3) and the AJP protocol stuff.
Now there is the problem with that. Henri even created
a AJP1.4 protocol enhancements with all that login,
discovery etc... (never implement but thats another story).
Although we got close to the AJP 1.4 protocol conclusion
last year, nowadays all that looks strange to me.
All those things might be implemented, but IMHO only
as a AJP1.5 protocol.
What we desperately need right now are 3 things:
1. Allowing to have +8K headers
2. Allowing to have +0x9999 single header limit
3. Mechanism to tell the Tomcat to gracefully close
the connection.
Now, the number 3 is very easy. A simple message
like we have for SHUTDOW, but instead shutting down
the entire Tomcat instance, closing down the socket/channel.
OTOH first two are little bit tricky :)
I have some ideas:
1. Larger headers can be treated as we handle the POST data.
If there are more headers then 8K, then a servlet container
should send GIVE_ME_MORE_HEADERS message.
2. If the single header is larger then 39321 bytes, then it
should be send as POST data, with servlet container requesting
8K packets. Those headers would be treated as multiple POST
sequences, after the initial header(s) packet(s) have been
read and before the actual POST data is read.
Any comments?
Regards,
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
