On Tue, Nov 17, 2009 at 9:55 AM, Mike Cardwell <apache-users@xxxxxxxxxxxxxxxxxx> wrote: > Brian Mearns wrote: > >>>> Just curious to know whether Google announcement on SPDY >>>> http://blog.chromium.org/2009/11/2x-faster-web.html needs change only in >>>> Apache web server side or even needs change in application point of view >>>> also. Sorry to spam you guys . >>> >>> Both the server and the client would need to be updated in order to take >>> advantage of it. If one or both don't support it, then the fallback would >>> be >>> normal HTTP. >>> >>> -- >>> Mike Cardwell - IT Consultant and LAMP developer >>> Cardwell IT Ltd. (UK Reg'd Company #06920226) http://cardwellit.com/ >>> Technical Blog: https://secure.grepular.com/blog/ >> >> [clip] >> >> Yes, SPDY is a new protocol which will require both the server and >> client to support in order for it to work. However, from a user >> perspective, I believe the goal is for it to be transparent. In other >> words, if your browser and the web server it's talking to both support >> SPDY, they will figure that out and use it. If either of them don't >> support it, they'll just use plain old HTTP. Either way, you won't see >> the difference as a user other than the potential speed benefits. >> >> Just to be clear, SPDY is far from being a new web-standard. Right >> now, it's just a research project Google is undertaking: I think it's >> going to be quite a while (a year at minimum) before any one (other >> than Google, at least) thinks seriously about deploying it. But that's >> just my $0.02. > > I agree with the above. I started this thread to make people aware of it's > existance and to provoke discussion on the matter. However, if someone were > to take up the reigns and begin developing an Apache module for it using the > open source code and specs Google has published, I think the project has a > more serious chance of succeeding. I also think that an Apache with SPDY > support available before the spec is finalised would be in a stronger > position to influence how the protocol evolves during it's development. I understand your point, but I personally think it's too early in the life of the spec to pull it from the sandbox. Putting it to actual use in the wild before it's had a chance to mature at all will just cause compatibility issues if and when the spec changes (which is likely when it's such a young and relatively isolated thing, meaning it hasn't had anybody from IETF or W3C or much of anybody else whack on it at all). > > I also wonder if a transition like this to a new protocol could/should be > taken advantage of to get rid of the one SSL cert per IP:port limitation we > currently suffer from? Although the transition to ipv6 will get rid of this > problem (lack of ip addresses) anyway without having to do any further work. I really don't see how they're related. I think removing this limitation is crucial if we're going to try to move towards a web that requires SSL (as SPDY is currently slated for, I believe), but it doesn't have anything to do with HTTP or SPDY, it's a limitation of SSL itself. The SNI extension to SSL resolves the issue by essentially allowing the equivalent of an HTTP Host: header to be included in the SSL handshake. This is already supported in most modern web browsers, and in Apache 2.2.12, I believe. Cheers, -Brian > > -- > Mike Cardwell - IT Consultant and LAMP developer > Cardwell IT Ltd. (UK Reg'd Company #06920226) http://cardwellit.com/ > Technical Blog: https://secure.grepular.com/blog/ [snip] -- 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-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|