Return-Path: Delivered-To: apmail-httpd-users-archive@www.apache.org Received: (qmail 41038 invoked from network); 13 Nov 2009 16:48:21 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 13 Nov 2009 16:48:21 -0000 Received: (qmail 45362 invoked by uid 500); 13 Nov 2009 16:48:18 -0000 Delivered-To: apmail-httpd-users-archive@httpd.apache.org Received: (qmail 45349 invoked by uid 500); 13 Nov 2009 16:48:18 -0000 Mailing-List: contact users-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: users@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@httpd.apache.org Received: (qmail 45340 invoked by uid 99); 13 Nov 2009 16:48:18 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Nov 2009 16:48:18 +0000 X-ASF-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [209.85.211.174] (HELO mail-yw0-f174.google.com) (209.85.211.174) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Nov 2009 16:48:15 +0000 Received: by ywh4 with SMTP id 4so3238463ywh.10 for ; Fri, 13 Nov 2009 08:47:54 -0800 (PST) Received: by 10.151.94.35 with SMTP id w35mr8278610ybl.194.1258130873895; Fri, 13 Nov 2009 08:47:53 -0800 (PST) Received: from ?192.168.0.122? (64.146.33.65.cfl.res.rr.com [65.33.146.64]) by mx.google.com with ESMTPS id 13sm1946160gxk.9.2009.11.13.08.47.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 13 Nov 2009 08:47:52 -0800 (PST) Message-ID: <4AFD8DAF.1040909@digital-pipe.com> Date: Fri, 13 Nov 2009 11:47:43 -0500 From: David Henderson User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: users@httpd.apache.org References: <4AFD7287.4030705@lists.grepular.com> <4AFD84A6.6040302@webthing.com> <4AFD8637.4090102@digital-pipe.com> <4df3a1330911130829vc15e334xe20674ad679b4d5a@mail.gmail.com> In-Reply-To: <4df3a1330911130829vc15e334xe20674ad679b4d5a@mail.gmail.com> Content-Type: multipart/alternative; boundary="------------060801040602050206090205" Subject: Re: [users@httpd] SPDY protocol --------------060801040602050206090205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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? >>>> >>>> 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 > > 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. Dave PS. Sorry for the top post earlier gang! --------------060801040602050206090205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Brian Mearns wrote: 
On Fri, Nov 13, 2009 at 11:15 AM, David Henderson
<dhenderson@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

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.

Dave

PS.
    Sorry for the top post earlier gang!
--------------060801040602050206090205--