-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request - Missing SPDY support in Apache default configuration #262
Comments
TBH I hadn't heard of SPDY before so I just did a little research. So having just done a bit of reading about SPDY my personal preference would be to have some documentation about installing and enabling it (maybe a blog post?) rather than having it set up by default. There are a couple of elements to my argument for that but they basically boil down to: 1 - Debian do not have a SPDY package in the repos (so we'd have to add a 3rd party repo to almost all TKL appliances by default - not something I'd be that keen about). 2 - SPDY for Debian is currently only available in a beta version (I couldn't get full clarity on this and is only an assumption made from the package name 'mod-spdy-beta_current_amd64.deb', please feel free to correct me if I'm wrong). 3 - From what I have read, when you initially install it (by downloading the deb and installing with dpkg), it adds the google repo to your sources.list, but it wouldn't be added to auto security updates. Obviously we could manually configure that, but considering that (from info I could find) the repo only provides updated version (not backported security patches as per Debian security) I would be hesitant to do that. I am certainly open to being persuaded that I am wrong and have overlooked or not considered some other aspects, but considering that currently only ~1% of websites use SPDY (according to Wikipedia) it's still only a 'nice to have' rather than a 'have to have'. References/links of interest: |
You are correct on all fronts. The reason I added this as a feature enhancement was primarily to put it on yours, Liraz's and Alon's radar. With the recent outbreak of hacking of big-name sites triggering a move to "all ssl" the writing is on the wall for TKLX users to need to support "all ssl". An example is Google's statement that they will provide a SEO boost to ssl-enabled websites (http://googlewebmastercentral.blogspot.com.au/2014/08/https-as-ranking-signal.html ). My second reason for putting it in as a feature enhancement is that, although Debian Apache is slow off the mark with SPDY, NGINX has had it in play since inception and it is available in the wheezy backports (see https://packages.debian.org/wheezy-backports/s390x/nginx-extras ). It would be reasonable to have spdy auto-configured in the Nginx PHP FastCGI Server appliance...subject to it not having side-effects for a non-ssl deployment of the Nginx PHP FastCGI Server appliance. |
This Github choice of Comment / Close & Comment button gets me every time...I keep thinking the choice is to close the comment...not close the issue! |
Hehe, yeah I agree, close the comment, not the issue! :) Seeing as Nginx has SPDY available in Wheezy backports - that is an entirely different matter (and one that I didn't research). I would certainly be supportive of Nginx being set to use SPDY as default over SSL (and assuming that your note regarding not interfering with non-SSL could also be met). |
Hey Tim... Have you seen this: So perhaps HTTP/2 instead of SPDY !? Thoughts? |
Hey Jeremy. Thanks for the heads up. I hadn’t seen that. http/2 won’t make it into the next TKLX release which I would expect will be based on Jesse so SPDY will be the way to go for now. SPDY3.1 made it into NGINX 1.6 (https://packages.debian.org/jessie/nginx-full ) and subsequently Jessie ( https://packages.debian.org/jessie/nginx-full ) Apache2.4 made it into Jessie (https://packages.debian.org/jessie/apache2 ) and Google donated mod_spdy to apache.org to include in apache2.4 (http://thetrendythings.com/read/6340 ). It is possible mod_spdy made it into a core release of apache2.4 (https://svn.apache.org/viewvc/httpd/mod_spdy/ ) but it may not have…in which case it would need to be installed by TKLX as a 3rd-party plug-in if the less technical TKLX users are to benefit out-of-the-box. Just a thought J From: Jeremy Davis [mailto:notifications@github.com] Hey Tim... Have you seen this: So perhaps HTTP/2 instead of SPDY !? Thoughts? — |
As per usual; great research and fantastic analysis! Thanks! 👍 |
mod_spdy is only officially supported for Apache 2.2. For Apache 2.4 an unofficial port exists. It is not actively maintained. It does not support SPDY/3.1, which is the only version Google Chrome/Chromium supports. Google are phasing out support for SPDY completely by early 2016 in favor of HTTP/2. The nginx mod does support v3.1 (and Nginx serves 95% of all websites that are served via SPDY), but as the bulk of TKL appliances use Apache as the webserver (about 5 use nginx), I doubt this feature is not a dead end. There is a preliminary alpha mod_h2 for Apache. It is not yet production-ready. The nginx version of HTTP2 is in alpha, too. I am convinced the best way to go about this is to leave SPDY alone and wait until major webserver upstreams catch up with the HTTP2 standard towards the end of 2015. If it ain't broke, don't fix it. cf. https://serverfault.com/questions/660735/apache-httpd-with-spdy-3-1 |
Thanks @qrntz for having a look at this. I am inclined to agree with you so am closing for now. @OnePressTech if you have objections please feel free to update/add-to/reopen/etc this issue! 😄 |
To improve performance of the TKLX server it is suggested that SPDY be enabled by default. Caveat: It would need to be verified first that there would be no negative impacts on http-based websites run off the same Apache server. Google is giving SEO priority to SSL-based sites moving forward so it could be reasonably expected that TKLX should support better performance for SSL-based websites out of the box subject to there being no side-effects on http-based websites.
The text was updated successfully, but these errors were encountered: