Henri Gomez wrote:
Well there was some provision in mind in AJP 1.4 :
Context informations forwarding for Servlet engine to Web Server
With this kind of information requested by webserver, we could
determine the version of Servlet AJP implementation and as such use
32/64k buffers.
the jk could send question like 'do you support 32k buffers ?'
In fact it should start the first dialog by asking the version of AJP TC
is supporting, otherwise we will never be able to improve the protocol.
Probably a CPING answered by a PONG + version before the first request.
Cheers
Jean-Frederic
In fact, the idea was to help jk side to discover information on the
Servlet engine implementation, and act accordingly.
2006/7/10, Mladen Turk <[EMAIL PROTECTED]>:
Costin Manolache wrote:
> 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 point is that it will be backward compatible.
It means that for headers < 8K any current AJP 1.3 protocol
could be used as is.
If there is a larger header, then the current AJP1.3 implementation
will return 'error message' (as now), while the new one will
handle it by requesting additional header packets.
Also if the old 1.3 consumer is in front of the new 1.4 producer
nothing will change.
Resolving 8K header limitation and allowing a single header to be
larger then 33K, while presere the backwards compatibility and it can
be done. It would make receiver and producer a little bit more
complex, but not that much. It would still maintain the zero-copy
failover, that IMHO is the major advantage of AJP protocol, without
the need to prefetch the entire header data.
Regards,
Mladen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
