"Mladen Turk" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> 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.
>

I'd like to see as well:
4. Separate the SSL variables into a separate message, since these are
    rarely actually looked at and we should start sending the entire cert 
chain.
5. Implement some method to let Httpd notify Tomcat that the client has
    dropped the connection, rather than rudely closing the connection.

Although it is possible that having an ACK for 5. would turn out to be more 
expensive then the occational having to re-open the socket 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.
+1

> 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.
>
Or, simpiler (but less compatible :) whould be to change the String length 
field to be 4 bytes instead of 2, and Tomcat would know that the beginning 
of the next GMMH message is the continuation of the previous String.

> Any comments?
>
> Regards,
> Mladen. 




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to