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, 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]
