On Fri, Nov 13, 2009 at 11:15 AM, David Henderson <dhender...@digital-pipe.com> wrote: > I would vote to make it a module over a patch due to Brian Mearns making a > good point about it possibly not moving beyond the IEFT. At least a modular > design can just be dropped from the operation of the server without having > to remove code from the core of the project (and network admins having > upgrade etc). > > From what has been stated in the whitepaper, it shows very good positives > with very few drawbacks. I can't believe it would be voted against by the > IEFT with the increases that have been stated. Plus, using the application > layer, the incorporation of the protocol can be made painlessly (to the end > user) by the browser and web server companies/developers. > > Dave > > > Nick Kew wrote: >> >> Mike Cardwell wrote: >>> >>> Does Apache intend to add support for Googles recently announced SPDY >>> protocol? >>> >>> http://sites.google.com/a/chromium.org/dev/spdy/spdy-whitepaper >>> >> Patches welcome! Or in this case, maybe a module. >> [clip]
Well as one blogger pointed out (http://arstechnica.com/web/news/2009/11/spdy-google-wants-to-speed-up-the-web-by-ditching-http.ars), the IETF is usually pretty reluctant to do a "wholesale" replacement of widely used protocols. I'm sure if it showed any promise at all, Firefox and (obviously) Chrome will implement support quickly, Opera and Safari probably will too. IE might be pretty reluctant until push really comes to shove. Therefore, HTTP and SPDY would need to co-exist side by side at least for a while in order to avoid mass disruption of the web. Could SPDY be snuck in as a backwards compatible extension to HTTP? In otherwords, could HTTP-only browsers still download resources the same way, while still allowing SPDY-enabled browsers to take advantage of the protocol? That would greatly simplify the transition, but I'm not sure that it's possible, at least based on the current SPDY design. Another thing pointed out in the same article is that SPDY requires the use of SSL. The author there mostly focused on the increased load this puts on processors, but I think this is relatively minor. The more important issue, to me, is that every site will need to have an SSL certificate to support SPDY. For name based virtual hosts, that's a problem (until SNI catches on). Additionally, casual site owners like myself are not typically going to want to invest in a CA signed certificate. All in all, if the entire web is SSL-only, there's going to be a huge chunk of it running with "invalid" or "untrusted" certificates, which is going to a) be a hassle, and b) cause people to disregard such warnings and just get accustomed to visiting sites with bad certificates, even if it's something important like a bank or on-line shopping site. Anyway, I think there are some kinks to work out but I'm very interested to see where it goes. -Brian -- Feel free to contact me using PGP Encryption: Key Id: 0x3AA70848 Available from: http://keys.gnupg.net --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org " from the digest: users-digest-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
