On Sat, 2007-03-03 at 21:26 -0600, William A. Rowe, Jr. wrote: > Mladen Turk wrote: > > Not even that. We are talking for more then a year for > > a next generation binary http(s) protocol. > > > > Almost everyone agreed that we need > > at least few things: > > 1. Encryption > > 2. Variable sized messages > > 3. Client connection close notification. > > Talk about a hijaak :) > > I'm going to argue; 'no', but let me offer my rational...
So you are suggesting to add http/https to mod_jk. How would you handle the SSL attributes when using http/https? javax.servlet.request.X509Certificate javax.servlet.request.cipher_suite javax.servlet.request.ssl_session javax.servlet.request.key_size Adding 4 Headers and a valve when using mod_proxy and Tomcat solves the problem with Apache httpd. Would you do the same with other web servers? > > 1. These features are available through the HTTP connector which is > easier to troubleshoot (sniff) and already standardized. > > 2. The HTTP connector was somewhat neglected; to ensure that it is > completely conformant needs more eyes, not fewer. More effort > at AJP 1.x is less effort towards HTTP/1.1 conformance. (This > is not only a developer issue, but speaks to how well exercised > the HTTP connector is with many users choosing AJP and not seeing > or reporting specific quirks.) > > 3. We would honestly win more bandwidth from fully supporting the > content encoding deflate from tomcat to the proxy server than from > the few bytes saved with AJP. And SSL Encryption + deflate provided > by TLS today will already give you this win, so binary protocol > is really not that significant (OpenSSL 0.9.8 supports it, don't ask > me if JSSE does.) > > 4. Waka. Why reinvent a wheel in motion? With the new focus at the > httpd Amsterdam code to break apart http from apache, we are adding > wiggle room for some to come behind and code to Roy's binary http > protocol plan. The difference? Already a link to some doc? Cheers Jean-Frederic > Waka when done will be an accepted > spec, while I don't see that ever happening to AJP. > > :) > > That said, those are technical arguments against but I have no vote > here - I'll leave it to you all to weight these against your itches > and designs. > > Bill > > --------------------------------------------------------------------- > 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]
