httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Henderson <>
Subject Re: [users@httpd] SPDY protocol
Date Fri, 13 Nov 2009 16:47:43 GMT
Brian Mearns wrote:
> On Fri, Nov 13, 2009 at 11:15 AM, David Henderson
> <> 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?
>>> Patches welcome!  Or in this case, maybe a module.
> [clip]
> Well as one blogger pointed out
> (,
> 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

I agree with everything stated.  There are some issues that need to be 
worked out.  The SSL thing is a big one!

As far as SPDY and HTTP working together, I would almost envision the 
browser informing the user if they are using HTTP or SPDY much like a 
cell phone indicates if a person is in a 3G area.  I'm also very 
interested to see where this goes.


    Sorry for the top post earlier gang!

View raw message